Simplifying region migration for cross-service dependencies
Across Amazon, service owners migrating to a new region had no shared playbook: no single source for the steps or the pitfalls, all while keeping current services up and ready to expand later. Region Flexibility was standing up that source, and I built the guide site and key workflows, aligning it to Cloudscape so it read as trustworthy AWS-standard tooling, not another one-off internal site. I worked closely with our product manager, who owned the domain expertise on resource forecasting, turning one of those workflows from a spreadsheet-driven process into guided software.
If you build it, they will come
The guide site became that shared source: one place mapping the steps and the pitfalls, built on Cloudscape so it looked and felt like the AWS tooling engineers already trusted. Two of those workflows, shown here, took the most manual parts of the process and turned them into guided software.
Lessons and data recipes
Migrating a service means defining exactly what data needs to move and how. I designed lessons, a workflow within the process, so engineers could build out data recipes for each dataset instead of tracking it by hand.
Resource forecast plan
Before this, resource forecasting lived entirely in Excel: a team tracking capacity and migration timing by hand, updating files independently as plans changed around events like Prime Day. I designed a visual, guided interface for that process, working closely with the product manager to translate a domain I was learning in real time into something a planning team could actually use.
The team that owned resource planning didn't have experience building software solutions for their own key workflows. What changed their minds wasn't a negotiation, it was seeing the vision: once they saw what forecasting could look like as guided software instead of spreadsheets, they pivoted their own three-year roadmap to align with it.
Moving on up
One of our key metrics was to reduce the estimated average region migration time from 8 weeks to 4 weeks (50% improvement). During my time, we didn't have a demonstrable way to show this as new changes to workflows were implemented a month prior to my contract ending, while use of the product was scaling slowly.
The clearer, causal impact was the guide site itself: content principles and an AI prompt engineers could use to check their own language against those principles, now part of how Region Flexibility communicates across the platform.
Accomplishments
- Redesigned the region migration workflow and information architecture to provide visual consistency across content, UI and experience
- Partnered with 10 feature teams providing UX strategy for improving net new migration automations and features
Reflection
Amazon's surface simplicity hides real technical depth, and the org moves too fast for every team to fully align before starting. Region Flexibility had carte blanche to define what region migration meant and work through edge cases as they came up, rather than waiting years for consensus. The lesson was that shipping something like this takes constant negotiation, not a single pitch: getting buy-in to start is one thing, keeping teams aligned through the months it takes them to actually navigate the migration is the harder, ongoing work.