Step 1
Map the workload
List its users, dependencies, data stores, and operational owner. Include external services and scheduled jobs that a migration could interrupt.
Capture: Create a dependency map and name an owner for each connection.
Step 2
Define acceptable disruption
Agree how long the service can be unavailable and how much data the business can afford to lose. Use those limits to guide recovery and migration decisions.
Capture: Record the recovery requirements alongside the business owner who agreed them.
Step 3
Review the foundations
Check account boundaries, access ownership, networking, and how infrastructure changes are reviewed. Identify settings that only exist as manual changes.
Capture: Keep a list of undocumented configuration and the steps needed to reproduce it.
Step 4
Demonstrate recovery
Choose a representative workload and rehearse recovery in an isolated environment. Record the steps, elapsed time, and checks that show the application works.
Capture: Save the recovery record and assign follow-up work for any failed checks.
Step 5
Plan a reversible rollout
Break the migration into stages with entry criteria, health checks, and a rollback decision. Include data changes that may make reversal harder.
Capture: Write a rollout plan with a named decision maker and a clear stop condition.
Put it into practice
For an application with a database and nightly import, moving the web service alone is not a complete migration plan. Include the import schedule, connection settings, data validation, and recovery sequence in the same review.
What to take away
Finish with a dependency map, recovery evidence, and a prioritized migration backlog. Resolve gaps that could prevent rollback before setting a production cutover date.
Further reading: AWS Well-Architected Reliability Pillar.
Need help working through the findings?
Bring your open questions and constraints. We can discuss the priorities and the implementation support your team needs.