Moving a ten-year-old system to AWS without a weekend of downtime

Most migrations fail long before the cut-over. They fail in the spreadsheet where someone decided the old database could be copied “over a weekend”, and the business would simply wait.

The systems we are asked to move are rarely tidy. They have grown for a decade, they talk to partners nobody remembers integrating, and they take orders at three in the morning. Switching them off is not an option, so the plan has to assume they never stop.

Start with what must never stop

Before we draw a single architecture diagram, we list every flow that earns money or keeps people safe: taking an order, confirming a payment, printing a delivery note. The migration is designed around keeping those running, not around the servers they happen to sit on.

• Inventory every inbound and outbound integration, including the ones that only run at month end
• Write down who notices first when each flow breaks, and how
• Agree what “working” means in numbers before anything moves

Run the old and the new side by side

We put a thin routing layer in front of the old system first. On day one it sends everything to the old system and changes nothing. That is the point: once it is in place, every later step is a routing decision we can undo in seconds.

New services go up on AWS behind the same layer. Each one takes over a single feature, and only for a slice of the traffic at first.

The best migration is the one your customers never notice.

Move the data continuously, not in one copy

A one-off copy is out of date the moment it finishes. We replicate the database continuously with AWS DMS, so the new side is always seconds behind the old, and we can compare the two before trusting either.

aws dms start-replication-task \
  --replication-task-arn "$TASK_ARN" \
  --start-replication-task-type resume-processing

Switch traffic in small steps

1. Five percent of one feature, for a day
2. All of that feature, for a week
3. The next feature, while the first one keeps running on the new side

Latency, error rate and queue depth told us more than any diagram. When all three stayed flat for a week, we turned the old system off, and nobody outside the team noticed. If you are planning a move like this, tell us about your system.