10.5 Migrating existing systems
You can plan a migration that does not require a heroic weekend.
Migrations fail in the discovery phase before they fail on the weekend, and this topic plans them properly: the six choices — rehost, replatform, refactor, repurchase, retire, retain — then dependency mapping, data migration, and a cutover with a genuine rollback path. It sits late in the architecture module because judging the options takes everything learned so far. The honest economics get their own item: lift-and-shift often costs more than the old servers did, because cloud pricing rewards elasticity and a lifted server is as inelastic as it ever was.
Work through these
The rehost / replatform / refactor / repurchase / retire / retain choices
The standard options run from moving a system unchanged to replacing it or switching it off entirely. Naming which one applies to each system is the first real step of a migration plan.
Assessment, dependency mapping and the discovery phase
Before anything moves, you need to know what exists and what depends on what, and that discovery is nearly always longer than expected. Skipping it is how weekend migrations turn into week-long incidents.
Data migration and cutover with a rollback path
Moving the data and switching over are the risky moments, and a rehearsed path back is what makes them survivable. A cutover with no reverse is a decision you only get to make once.
Why lift-and-shift often costs more than the old servers
Moving a system unchanged often costs more to run than the hardware it left, because it was sized for a machine you bought rather than a machine you rent. This is the most common unpleasant surprise.
Sign in to keep your progress.
Free resources
We haven't checked most of these for screen reader use yet.
Links last checked 29 Aug 2026.
Stuck here?
Ask a mentor. A real person answers, and they can see exactly which topic you're on. Usually within a couple of working days.
Checking your session…
Topics shown in module order.