AWS Server Migration Service: What Replaced It and What Teams Use Now

Understand the current server rehosting workflow

AWS Transform MGN uses continuous block-level replication and machine conversion to prepare source servers for launch in AWS. Teams configure replication and launch settings, allow the source data to replicate, and launch test instances before making the production cutover decision. The target compute environment is Amazon EC2.

AWS currently describes both a self-directed route through the MGN console and an agentic rehost route through AWS Transform. Both use the underlying replication and cutover engine. Choose the operating approach that fits the team's permissions, review requirements, and delivery responsibilities; automation does not remove the need to approve target settings.

Confirm operating-system support, target Region availability, replication prerequisites, and installation constraints before committing a workload. Particular configurations may need remediation or a different migration path. A successful demonstration on one server should not become an assumption that every server in the estate will behave identically.

Rebuild the plan around applications and dependencies

Start with the business service, then identify the infrastructure that supports it. Record the owner, critical transactions, authentication methods, upstream systems, downstream consumers, and recovery expectations. Include less visible dependencies such as nightly exports, license servers, SMTP relays, certificate renewal, and third-party access rules.

Group tightly connected components into migration waves. Moving an application server ahead of an authentication dependency can create failures that look like network problems. Leaving a database behind may introduce latency that changes transaction behavior. A dependency map helps teams decide what must move together and what can remain temporarily connected.

For example, a finance application may appear to consist of two virtual machines. Its month-end process could also depend on a file share and a scheduled reporting job. A test that checks only login and screen loading would miss the process that matters most to the finance team. This is an illustrative planning scenario, not a client result.

Assign an owner to every dependency and ask that owner to confirm the proposed sequence. The confirmation should cover technical readiness and the business calendar. Payroll, month-end close, seasonal demand, and contractual reporting can all affect the available change window. A wave that is convenient for infrastructure teams may still be poorly timed for the people who use the service.

Prepare the AWS environment before replication becomes a deadline

The destination needs an approved account structure, identity model, network design, logging, backup approach, and ownership model. Establish target subnets, access rules, name resolution, and connectivity to systems that will remain outside AWS. Document who can change replication settings and who can authorize production actions.

Review launch settings with the application and operations teams. Instance selection, storage performance, encryption, access permissions, and monitoring should reflect workload requirements. Existing virtual-machine allocations may contain unused capacity, but reducing resources without representative testing can introduce a different problem at the moment the application moves.

Define the operating handoff early. After cutover, someone must own patching, incident response, backup checks, access reviews, and cost allocation. A migration team that leaves those responsibilities unresolved transfers operational uncertainty along with the servers. Clear ownership also makes the post-migration acceptance period easier to manage.

Test business behavior, not just instance startup

A running EC2 instance is evidence that a machine launched. Business acceptance requires more. Test authentication, complete transactions, integration calls, scheduled processing, reporting, and recovery procedures. Compare response times with a source baseline under representative conditions, and record which defects must be resolved before cutover.

Keep test environments controlled. A copied application may contain production endpoints, notification settings, or job schedules. Prevent tests from sending customer messages, processing real payments, or writing to unintended systems. Identify which integrations should be isolated, redirected, or explicitly approved for the rehearsal.

Use the rehearsal to test the runbook as well as the application. Measure the duration of individual steps, verify access for each responsible person, and confirm that validation evidence reaches the decision-maker. Repeat material tests after configuration changes. A previous pass does not establish that the revised target configuration remains acceptable.

Record the expected result for each test rather than using a broad statement such as "application works." A transaction should produce the correct record, an integration should reach its intended destination, and a batch job should complete with reconciled output. Give the business owner enough evidence to approve the move without having to interpret infrastructure dashboards.

Make cutover and rollback explicit decisions

Continuous replication can reduce the amount of data left to transfer at cutover, but it does not guarantee zero downtime. The business interruption also depends on stopping writes, application startup, routing changes, validation, and user access. Agree on a tested window rather than promising a duration taken from a generic migration example.

Before cutover, confirm replication health, unresolved defects, the write-freeze procedure, backups, named approvers, and communication channels. Set measurable stop conditions: missing data, failed transactions, unacceptable response times, or an integration that cannot be restored within the window. Make the rollback decision before those conditions become an urgent debate.

Rollback becomes more difficult after users create new data on the AWS target. Returning traffic to the source requires a plan for those writes and their consistency. Reverting a migration workflow action does not automatically reconcile application data. Agree on the authoritative system and the point beyond which recovery requires a different procedure.