Business Challenge
The migration runbook has a rollback section, and it is one line long: if the application fails validation, fail back to the source server, which is still running and still replicating. Everyone signs off on it. It is a good plan.
Cutover night goes well. Instances launch, the application comes up, the team runs through the checks. Somewhere in the tidying-up, with the console showing Finalize cutover as the obvious next action, somebody finalises. On Monday morning a batch job fails against something nobody tested, and the rollback plan is discovered to have expired on Saturday.
The documentation is explicit, and it is worth reading slowly: finalizing “changes your source servers' Migration lifecycle status to Cutover complete”, and “In addition, this stops data replication and causes all replicated data to be discarded. All AWS resources used for data replication are terminated.”
Three destructive actions behind a word that sounds administrative. The first clause is bookkeeping. The two that follow are the ones that end your ability to go back, and they are stated in the same sentence, in the same tone.
MGN drives migrations through a lifecycle, and the console surfaces a Next step for each server. That column is a workflow prompt, not a judgement about whether your business has accepted the migration.
After a successful cutover launch it points at finalizing. After finalizing it points at Mark as archived. The path is designed to be followed, which is exactly why the irreversible step in the middle of it needs to be a decision somebody makes rather than a prompt somebody clears.
There is a revert action, and its existence is reassuring in a way that does not survive reading what it does. Reverting a finalized cutover returns the Migration lifecycle to Ready for cutover.
That is a lifecycle state, and lifecycle state is not what you needed. The replicated data was discarded and the replication infrastructure was terminated at finalize time. Reverting puts the label back. Getting the capability back means replicating the server again, from the beginning, at whatever rate your network allows.
Teams size the freeze around the technical cutover — how long until the instances are up and serving. That is the wrong quantity. The freeze has to last as long as the source is the thing you might return to, and the source stops being that the moment replication is discarded.
Which means the freeze window is defined by a decision, not by a duration: it ends when you finalise. Anything that could still send you back — a month-end batch, a quarterly report, a partner integration that runs weekly — belongs inside it.
Architecture
MGN replicates block-level from the source server into a staging area in your account, then launches instances from that replicated data. Understanding where the data lives is what makes the finalize step legible.
Two lifecycles that look like one
There is a lifecycle for testing and a lifecycle for cutover, and they mirror each other. Finalizing a test moves a server to Ready for cutover; reverting a test moves it back to Ready for testing. Finalizing a cutover moves it to Cutover complete; reverting a cutover moves it back to Ready for cutover.
The symmetry is the problem. Finalizing a test is genuinely cheap — it advances a status and nothing is destroyed, so a team that has finalised several tests learns that finalize is a safe, routine action. The cutover version wears the same word and the same dialog and does something categorically different.
What is terminated, and why it cannot come back
Replication runs on infrastructure in your account, paid for by the hour, holding a copy of your source volumes. Finalizing stops replication, discards that copy and terminates the infrastructure. The console then reports Data replication: Disconnected.
This is a reasonable default. Keeping replication running after a completed migration costs money for a copy nobody intends to use, and AWS says plainly that the console does this “to save resource costs”. The cost saving is real. It is simply not free, and what it costs is the rollback.
Archiving is the harmless one
After finalizing, the suggested next step is Mark as archived, which removes the server from the main list so the view shows only servers still to migrate. Archived servers remain accessible through filtering.
That one is genuinely presentational, and it is worth knowing which of the two is which. In a sequence of three prompts — finalize, archive, done — only the first is destructive, and it is the one that reads most like paperwork.
Why This Architecture Holds Up
Every migration plan has a rollback story, and in a rehost the rollback story is almost always the same one: the source is untouched and still replicating, so we can go back. That story is true right up until a step whose name gives no indication that it is the step which ends it.
The failure is not that AWS hid anything. The sentence is in the documentation, in the console dialog, and it is not ambiguous. The failure is that finalize belongs to the vocabulary of paperwork, the same lifecycle offers a harmless finalize on the test path, and the console presents the destructive one as the natural next step at the exact moment a tired team is looking for things to tick off.
Nothing about the resulting state looks wrong. The server reports Cutover complete in green. The application is running. The only thing that changed is that a plan everyone agreed to is no longer executable, and nobody will find out until they try.
Key Architecture Decisions
| Decision | Take this | Because |
|---|---|---|
| When to finalise | After the business has accepted the migration, not when the cutover launch succeeds | It discards the replicated data and terminates replication; acceptance is the real gate |
| Who may finalise | A named person, as an explicit step in the runbook with its own sign-off | It is the only irreversible action in the sequence, and the console offers it as routine |
| Sizing the freeze window | Long enough to cover the slowest business cycle that could reject the migration | Month-end and weekly partner jobs are what fail after the window everyone planned for |
| Rollback plan wording | State that it is valid only until finalize, and name finalize explicitly | "Fail back to the source" is not a plan once replication has been discarded |
| Carrying replication cost | Treat it as the price of the rollback option and budget it into the window | Finalizing early buys a small saving by selling the ability to go back |
| Test finalize vs cutover finalize | Train the team that these are different actions despite the shared name | Finalizing a test destroys nothing, which teaches the wrong instinct for the cutover one |
| Archiving | Safe at any time after finalize; use it to keep the working list clean | It only hides the server from the default view, and filtering brings it back |
Closing Thought
Rehosting is the migration pattern people choose because it is reversible. That reversibility is not a property of the tool — it is a property of the replication you are still paying for, and it lasts exactly as long as you keep paying.
Find the irreversible step before the window opens, put a name against it, and do not let it be something a tired engineer clears at 2am because the console suggested it. In this workflow that step is Finalize cutover, and the word does nothing to warn you.
Comments