How to migrate to AWS without stopping operations

Short answer: AWS migrations don't fail because of the technology. They fail because nobody defined what moves first, what depends on what, and what happens if something goes wrong during cutover. What keeps the business running (shifts, invoicing, the plant floor) is an honest inventory, a migration order that starts with low-risk systems, a tested rollback plan, and an abort criterion agreed on before anyone touches production.

This checklist organizes what has to be resolved before, during, and after cutover. It's written for on-premises servers or a hosting provider moving into an AWS account, which is how we work in AWS cloud and DevOps.

What do you inventory before moving anything?

No migration starts at the server. It starts with an inventory of what exists and how it's actually used today, not how the diagram says it should be used:

• Which systems exist and who really uses them. Not the org chart, but the teams that depend on each application to operate.
• Dependencies between applications. What breaks if one system moves before another: integrations, automated reports, batch jobs, scheduled tasks.
• Real operating windows. Plant shifts, month-end close, peak season: times when a cutover simply isn't viable.
• Current licenses and contracts. Which software is tied to a physical server, a hardware dongle, or an agreement that doesn't transfer to the cloud on its own.
• Who owns each dataset. Without a named owner per system, nobody validates afterward whether the migration went right or whether something was lost.

The deliverable is a table, not a diagram: system, users, dependencies, window, license, owner.

What migrates first, and with which strategy?

Not everything migrates the same way. AWS describes seven migration strategies (the "7 Rs": retire, retain, rehost, relocate, repurchase, replatform, refactor) in its large migration guide (https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html). In practice, for a company leaving on-premises servers, they reduce to three decisions per system:

And two that get forgotten: retire what nobody uses (it shows up in the inventory) and retain what stays put because of licensing or hardware.

Order matters more than technique. Start with what causes operational pain but carries low risk if something goes wrong: a file server, a test environment, a secondary application. Never start with the most critical system; that's where there's the least room to learn as you go.

Why is the rollback plan not optional?

A backup that has never been restored isn't a backup; it's an assumption. Before moving anything, test a full restore in an isolated environment and confirm the data arrives intact and usable, not just that the backup file exists.

The abort criterion is defined before cutover, not during it:

• Which signals force a rollback. Data errors, a dependent system going down, a cutover running longer than planned.
• Who has the authority to decide. A named person, deciding with the information available at that moment, not afterward with the benefit of hindsight.
• How long rollback takes and up to what point it's possible. After a certain volume of new data lands in the target, going back is no longer free. That point is marked in the plan.

What does the cutover window look like, step by step?

1. Freeze changes on the source system so no data moves mid-cutover.
2. Sync the final data between source and target.
3. Validate on the target with real use cases, not just synthetic tests: an invoice, an order, a closing report.
4. Cut over: redirect DNS, connections, and access to the new environment.
5. Monitor with the whole available team, not just whoever led the migration.
6. Confirm the cutover or roll back, per the agreed abort criterion.

Each step's timing is rehearsed beforehand in a dry run with test data. Whatever wasn't rehearsed, nobody knows how long it takes.

Why isn't AWS cheap by default?

AWS bills for what you use, not what you provisioned once, and that's only an advantage if you size correctly. Size for your operation's actual usage, not the historical peak that happened once; over-provisioning "just in case" is the most common way a migration ends up costing more than the infrastructure it replaced.

Key points for the budget:

• Estimate before migrating with the public AWS Pricing Calculator (https://calculator.aws/) using the inventory: each machine's size, storage, outbound traffic. The estimate goes into the plan in writing.
• Set budgets with alerts from day one using AWS Budgets (https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html), not after an unexpected bill arrives.
• Shut down test and development environments outside business hours. They don't need to run overnight or on weekends.
• Consider ARM (Graviton) and serverless where they fit. AWS states that Graviton-based instances cost up to 20% less than comparable x86-based EC2 instances (https://aws.amazon.com/ec2/graviton/), and Lambda publishes separate prices for x86 and Arm (https://aws.amazon.com/lambda/pricing/): compare both tables for your region. Those are vendor claims; the number that counts is your bill after migration, measured against the estimate.
• Review monthly spend with the same discipline you apply to any other operating input, not as a line item approved without looking.

What do you validate after cutover?

Cutover isn't the end of the project; it's the start of operating in the new environment.

• Monitoring and alerts configured for the target, not copied from the old environment: adjusted to the new architecture, with a named person receiving them.
• Access and permissions cleaned up. A migration is the right moment to remove accounts and privileges that shouldn't exist anymore, and to leave IAM at the minimum needed.
• Backups running on the target, not pointing at the server that was already shut down. And tested, same as before cutover.
• Documentation of how the new environment operates, so it doesn't depend on the memory of whoever did the migration. Infrastructure as code (SAM or CDK) is the most direct way to make that documentation executable.

This is where SRE and observability make the difference between a migration that holds up on its own and one that accumulates technical debt from day one. Every item can be planned in more or less detail depending on the size of the operation, but none can be skipped without taking on a risk that, sooner or later, costs more than the time it would have taken to do it right.