MGN Cutover: Track the Writes Before You Revert or Finalize

Distinguish AWS MGN launch, revert and finalize operations from application recovery. Work through divergent invoice records and build a cutover evidence record...

Primary sources checked 2026-10-09

The decision: which application state can you safely continue?

A cutover instance has launched. The application starts, the migration dashboard is healthy, and an operator is ready to finalize. Before that decision, ask a smaller question: where did every accepted write go?

This guide helps a migration engineer and application owner decide whether to continue on a target, return to a source, or hold both while resolving divergent work. The output is a cutover record that connects migration identities to application records, outstanding effects and a permitted next action. A service status alone cannot fill it in.

The worked example uses a fictional invoice worker, five synthetic record identities and inert downstream receivers. Its arithmetic and decision checks are an offline exercise, not an executed AWS migration, customer result or recovery-time benchmark. The figures separate phase-specific replication from conditional application recovery, with the same table fields available in stacked records on small screens.

The scope is agent-based migration of one server whose durable application records are on its replicated local disk. Current AWS documentation calls the service AWS Transform MGN. This is a lifecycle and recovery guide, not installation instructions or a claim that a particular operating system, disk layout or clustered database is supported. Check those prerequisites for the actual workload before using the exercise to design a rehearsal.

Keep the three copies and the application writer separate

MGN's workflow describes block-level replication from the source server into the staging area. It also calls for application testing and stopping operational source services before cutover. Those are different controls: copying disk changes is not an application-level decision about who may issue invoices. AWS migration workflow.

The crucial launch boundary is explicit in AWS's cutover documentation: later source changes continue to the staging area, not to the already launched cutover instance. A target can therefore serve new work while missing a later source write. AWS cutover behavior.

Source server and its durable records

Question to answer: Can any application, scheduler, operator or integration still write here?

Staging replication state

Question to answer: Which source changes are available for a subsequent launch, according to the observed replication evidence?

Launched EC2 instance and its durable records

Question to answer: Which application checkpoint is actually readable here, and what has changed since launch?

Business authority

Question to answer: Which system is permitted to accept the next operation, including work not yet acknowledged to a caller?

Do not use one label such as “target” for both staging and the launched application. Give each a separate identity in the change record. This prevents a dangerous ambiguity: “the target has caught up” might mean replication caught up while the running application still contains an earlier state.

A disk replication observation also does not settle an outbound payment, a message already delivered to a consumer, or a request whose response was lost. Those effects need their own operation identities and evidence. The migration may be physically one server while its business transaction crosses several systems.

*Figure 1. Phase-specific replication and launch relationships, not application traffic. The credit and invoice are fictional application observations. Staging replication is not evidence that the running instance includes a later source write. AWS cutover behavior and FinalizeCutover API.*

Establish a bounded workload before choosing a cutover procedure

Start with the exact source server, selected disks, application release, storage engine and recovery method. List every durable dependency outside those disks. If the application writes to an external database, network share or SaaS system, put that dependency in the recovery plan rather than assuming the server copy contains it.

Check the current supported operating systems and agent installation requirements, including version-specific limitations. Agent-based support must not be inferred from a successful installation. An agentless or specialized storage path needs its own applicability review; this guide does not certify it.

Record the effective launch configuration for this source, not just the team's intended template. Include the selected subnet, security groups, attached instance role, storage configuration and application bootstrap revision. AWS exposes subnet and security-group choices through launch preparation and EC2 launch settings. “The server launched” does not establish that these choices enforce your intended boundary. AWS launch preparation.

Assign three decisions to named people: who may stop admission, who may decide application records are correct, and who may authorize finalization. One person can hold multiple roles in a small migration, but the responsibilities should remain explicit. A migration operator should not have to invent a policy for conflicting financial records during an outage.

Make the test clone harmless before booting it

The test instance needs enough connectivity to exercise the application, but it must not accidentally become another production worker. Copied configuration may contain scheduled jobs, consumer identities or credentials. Inspect those inputs before launch and deny unnecessary production destinations. Use inert payment and email receivers for the scenario in this guide.

AWS documents that each new test replaces the earlier test instance and dependent resources, and that subsequent source changes go to staging rather than the running test. A cutover launch also deletes the previous test instance and its dependent resources. Export identified test results before either replacement trigger; the running test instance is not a retained backup. A test performed against yesterday's launched copy is not evidence that today's changed source checkpoint was validated. AWS test-instance behavior and cutover launch behavior.

Post-launch actions deserve the same scrutiny as application code. AWS allows different execution scopes for test and cutover instances and a selected SSM document version. Its template changes apply to newly added servers, not automatically to existing server settings. Inspect the effective settings of the actual source server. AWS post-launch template.

For each action, record what it can modify, its expected result, how a failure is observed and whether repeating it is safe. A script that registers a consumer or sends a notification can create effects even when the HTTP application is not yet exposed. Avoid secrets in an ordinary evidence export. Store restricted evidence separately and reference its location in the change record.

The first negative test should be simple: attempt a connection to an inert test destination that the test configuration is supposed to deny, and confirm the expected denial. Also confirm the permitted test receiver works. Review the actual production-destination restrictions separately; the synthetic denial cannot certify every rule. Do not use a live payment or email operation as a harmless probe.

Stop source writes, then prove the application checkpoint

Before the launch decision, identify every writer, not only the public endpoint. Include scheduled tasks, queue consumers, batch imports, administrator scripts, retry workers and requests already in flight. Define how each is stopped, drained or rejected and how that condition will be observed.

For this guide's single-server scenario, the proposed sequence is:

1. Stop new application admission and scheduled work using the workload's supported controls. Do not turn off the replication path as a substitute for stopping the application.
2. Settle or explicitly inventory in-flight operations. Preserve stable operation IDs and any downstream receipts.
3. Flush or quiesce the local store using its own supported procedure. Capture the source application checkpoint and the relevant writer-denial evidence.
4. Recheck replication after the last acknowledged source change. Record observation times and any unresolved lag or errors.
5. Launch into a target configuration that still prevents real business admission. Validate the application's readable state against the intended checkpoint before granting target write authority.

This is an engineering control sequence to adapt and rehearse, not a replacement for the storage engine's consistency procedure. Do not assume a universal wait duration makes it safe. The evidence needs to establish a bounded application state and account for work that could still change it.

If a writer cannot be fenced, or no one can identify the final source operation, the cutover remains on hold. Lowering a DNS lifetime does not stop a background job. A zero-lag observation taken before a late write does not prove that the launched application includes that write.

Worked scenario: one late source credit and one target invoice

Assume the fictional worker stores append-only invoice and credit records on a single replicated local volume. Record IDs are unique. A credit references an existing invoice, and amounts are signed integer units. They are illustrative bookkeeping units, not a measured customer dataset. External payment and email adapters are inert throughout this exercise.

The opening checkpoint is agreed by the fictional application owner:

INV-101

Meaning: Invoice

Amount: 100

INV-102

Meaning: Invoice

Amount: 200

INV-103

Meaning: Invoice

Amount: 50

Opening total

Meaning: Three identified invoices

Amount: 350

The source is SRC-A; the launched instance is EC2-T1. These are teaching labels, not AWS resource IDs. In a real record, use the account, Region, source-server ID, launch job and EC2 instance ID as well as the application identity.

At checkpoint A, the target has been launched and an application read confirms the three opening records. No target business write or external effect has been admitted. The intended source fence is in place. At checkpoint B, after target admission starts, the target accepts INV-104 for 75 units. A source scheduler that the team missed then creates CR-102, a credit of 20 units against INV-102.

That source write is a failed safety condition, not an acceptable dual-writer design. Stop further admission on both paths, preserve the evidence and withhold finalization. The exercise stipulates that the source change reaches staging. It does not claim an AWS API exposes an application ledger inside staging, or that an operator inspected one.

Source read

Application records: Opening records plus CR-102

Total: 330

Target read

Application records: Opening records plus INV-104

Total: 425

Intended state if both changes are authorized

Application records: Opening records, INV-104 and CR-102

Total: 405

Both observed applications have four records. Equal counts do not identify the missing operation. The 95-unit difference between their totals is also not a repair instruction: adding or subtracting 95 would hide the two different business events. Compare IDs, values, credit references and dispositions, not just aggregates.

The expected 405 is independently calculated as 100 + 200 + 50 + 75 - 20. That is the required total only if the fictional domain owner confirms that both new records are valid. In a real incident, a late credit could be unauthorized, already applied elsewhere or tied to an unsettled payment. Arithmetic cannot decide that question.

Checkpoint A: a source return may still be possible

Before a target-only business write, returning to the source can be the simpler option if the source remains a valid, recoverable system of record. “Before” must include effects, not just rows. A target may have sent a message or accepted a request whose local commit is not yet visible.

The application owner needs evidence that the target admitted no unresolved operation, the source contains the accepted checkpoint, all source dependencies can operate safely, and the target will remain unable to write after the switch. Then the change owner can authorize resuming source admission under the rehearsed procedure. Verify a fresh permitted source operation and a denied target operation after that transition.

AWS's Revert to ready for cutover operation changes the migration lifecycle and offers deletion of cutover instances. It is useful when preparing another launch. It is not an application transaction reconciliation procedure. Do not select deletion while that instance contains the only copy of evidence or a possibly accepted target-side write. AWS revert guidance.

If target activity is unknown, do not label this a pre-write rollback. Preserve that uncertainty as an unresolved operation until application and downstream evidence establish a disposition. A service event timestamp cannot prove the absence of business activity.

Checkpoint B: compare recovery paths against the actual records

After INV-104, the old source is missing an accepted target operation. Reverting the service status or relaunching from source replication cannot, by itself, supply that missing application record. The recovery decision now requires a tested way to preserve or reconcile post-launch work.

Resume SRC-A unchanged

Decision in this fixture: Reject: INV-104 is missing.

Continue EC2-T1 unchanged

Decision in this fixture: Reject: the authorized CR-102 is missing.

Prepare another launch from the source state

Decision in this fixture: Hold: a new instance still needs the disposition of target-only work.

Repair EC2-T1 under an approved application operation

Decision in this fixture: Candidate: apply the missing credit once, then prove the accepted record set and effects.

Restore a checkpoint and replay accepted work

Decision in this fixture: Candidate only with an independently tested restore and replay method that covers both branches.

For the exercise, the fictional owner chooses forward repair. First capture read-only source and target manifests. Confirm that CR-102 refers to INV-102, retains its original identity and is not already in the target. Use the application's approved operation to append that credit to the target. Do not improvise a database write against production from this example.

Then compare the target with the independently specified five-record fixture. Check exact identities, signed amounts and credit references. Repeating the same accepted operation ID must not create a second credit. A replay with a new ID is a different operation and should not be treated as safe merely because the amount is the same.

After the correct repair, the target total is 405. The unchanged source still totals 330, so it remains unsuitable for an unqualified return. Do not erase its divergent evidence simply because target service has recovered. Retain it under the incident's access and retention policy until the recovery owner closes the investigation.

If downstream receipts are unknown, keep the decision on hold even when records match. Do not send a second payment or message just to make logs look complete. Investigate the receiver's supported lookup and retry behavior under its operation identity. The inert adapters make this teaching fixture simpler than a real integration, and that simplification must not disappear from the review.

Checkpoint C: finalization changes the recovery dependency

Finalize only after the target is accepted and the remaining recovery method does not depend on retaining MGN's replication resources. AWS documents that finalization stops replication and discards replicated data. The API reference further distinguishes removal of replication resources from the launched instances, which it says are not terminated by this operation. AWS FinalizeCutover API and cutover lifecycle guidance.

For checkpoint C, suppose the fixture's accepted target has been independently backed up and a restore exercise has checked the required records and writer controls. This is a scenario prerequisite, not a claim that this guide performed such a restore or that MGN provides it automatically. A finalization decision would record that evidence and the authority to remove the migration replication dependency.

Now suppose the target fails after finalization. “Return the lifecycle to ready” is not the recovery evidence. The operator needs the identified backup, keys, permissions, application configuration and accepted-work replay path. If those were never tested, the honest result is that recovery readiness was not established. Do not claim a recovery duration from the successful cutover.

*Figure 2. Application decision paths, not MGN commands or data propagation. A target-only write changes the recovery boundary; discovered divergence or unknown effects requires HOLD. The accepted record set and independent recovery evidence are stipulated prerequisites in this fictional exercise, not performed tests. Reverting the service lifecycle does not reconcile the application records. AWS revert guidance.*

Reusable cutover record

Keep the record in the change system with restricted evidence references. Do not paste credentials, complete invoices or personal data into it. Split observations from the decision: a field should say what was read, where, and by whom, before saying what may happen next.

Filled example at the divergence hold

Identity and revision

Fictional record: SRC-A; EC2-T1; opening checkpoint of three invoices; fixture revision F1, not a real launch job or approval

Service observation

Fictional record: Cutover launched; source change stipulated to reach staging; application copies inspected separately

Write authority

Fictional record: Neither path may admit more work while the unexpected source writer is investigated

Application evidence

Fictional record: Source: CR-102, total 330. Target: INV-104, total 425. Equal counts, unequal identities

Outstanding effects

Fictional record: Inert adapters only. No assertion about a production receiver

Decision and owner

Fictional record: Fictional domain owner accepts both records; recovery owner proposes one credit application on EC2-T1

Acceptance evidence needed

Fictional record: Exact five-record comparison, duplicate-operation rejection, denied source write and settled effects. Test a permitted target operation in a separately identified synthetic population

Forbidden next action

Fictional record: Do not delete the target, resume the unchanged source or finalize while these checks remain unresolved

Blank record for a bounded rehearsal

Complete each group in plain language. An unknown is a useful result if it stops an unsafe decision; a blank “passed” field is not evidence.

Scope

Record before the next action: Application, account, Region, source-server ID, disks, external durable dependencies and exact supported configuration

Launch identity

Record before the next action: Launch job, EC2 instance ID, effective launch settings, application release and post-launch document versions

Replication observation

Record before the next action: State, lag or errors, observation time, final source application change and the evidence connecting them

Writer and effects

Record before the next action: Permitted writer; denied writers; in-flight operations; scheduled jobs; downstream receipt or unresolved status

Checkpoint

Record before the next action: Source and target extract identities, compared population, expected invariants, differences and exceptions

Recovery

Record before the next action: Selected destination, preserved accepted operations, tested restore or repair method and conditions that invalidate it

Decision

Record before the next action: Continue, return, hold or finalize; named owner; supporting evidence; permitted action and expiry or recheck trigger

Have a second operator explain the record without verbal context. If that person cannot identify which instance owns INV-104, or what must be preserved before deletion, the record is not yet usable during an incident. For a larger dataset, use a separate reconciliation contract rather than expanding this worksheet into an unreadable transaction dump.

Rehearsal checks that should fail for the right reason

Run these with synthetic records and explicitly inert integrations before adapting the approach to a real change. Agree the stop authority and cleanup scope first. No production commands or fault-injection permissions are implied by this guide.

A scheduled source writer survives the fence

Expected decision and evidence: Hold. Identify its accepted operation and prove the writer is stopped before resuming admission.

Target-only INV-104 exists before a proposed source return

Expected decision and evidence: Reject the unchanged source. Show the missing record explicitly.

Both sides contain four records but different IDs

Expected decision and evidence: Reject count-only acceptance. The comparator must report CR-102 and INV-104 in the opposite missing sets.

A repair invents a new ID for a repeated credit

Expected decision and evidence: Reject the unexpected extra record. A lower total alone is not the only signal.

Exact local records match but an outbound effect is unknown

Expected decision and evidence: Hold. A matching store does not resolve the receiver's state.

A post-finalization plan names staging as its only recovery source

Expected decision and evidence: Reject the plan before finalization; require a separate tested recovery dependency.

For every failed check, preserve the input revision and observed outcome. Then rerun the corrected path and show why it now passes. A worksheet designed only around the successful case will not reveal whether an operator mistakes “unknown” for “absent.”

Limitations and the next useful action

This guide does not prove application-consistent replication for every storage engine, order simultaneous writes across several servers, or validate clustered failover. It does not cover every MGN replication mode or automate a production rollback. If the workload requires continuous writes with no interruption, assess an application or database migration design with explicit consistency and recovery semantics rather than assuming this single-server exercise meets that requirement.

Source retirement is a separate change. Before disabling a physical source, ending an old contract or deleting retained backups, review remaining consumers, retention obligations and recovery dependencies. An archived source-server entry in the migration console is not proof that those obligations have ended. Use the broader platform migration playbook for wave and retirement governance.

Use the first figure to identify which copy a replication observation describes. Use the second to distinguish a conditional source return, a divergence hold and the separate finalization decision. Neither diagram replaces the application evidence in the cutover record.

The immediate task is to fill in the blank record for one representative workload and rehearse the late-writer failure with fake data. Bring the resulting unknowns to the application owner before booking a cutover. If you need help defining that bounded rehearsal and its acceptance evidence, the relevant next step is an AWS migration review, with the workload and unresolved recovery decision attached.