What rehost really involves
Rehosting, often called lift and shift, is the fastest route off a data centre and the least glamorous. It is also where many programmes spend most of their effort, because it covers the bulk of the estate. The idea is simple: copy the server, start it in the cloud, point users at it. The practice depends on doing that repeatably for dozens or hundreds of machines without surprises.
Server migration is stage three of the cloud migration service. It runs inside the waves defined in the roadmap and lands on the foundation built beforehand.
What good looks like
- Replication is healthy and monitored long before cutover day.
- Every server has been test-launched at least once, with evidence that its application works.
- Post-launch changes (agents, time sync, DNS, licensing) are automated, not hand edited.
- The cutover runbook is the same for every server of a type, so the team gets faster with practice.
- The source is retired on a schedule that stops double-running costs.
How MGN works
With AWS Application Migration Service, a replication agent on the source reads disk blocks and sends them to lightweight staging instances in your AWS account, writing to low cost volumes. When you launch a test or cutover instance, the service converts the replicated disks into a bootable instance using launch settings you define: instance type, subnet, security groups, tags.
Launch templates keep those settings consistent. Installing the agent is a short operation, and the key inputs are the region, credentials created for the purpose and the disks to replicate. For Linux sources:
# Download and run the replication agent installer (values from your account)
wget -O ./aws-replication-installer-init \
https://aws-application-migration-service-<region>.s3.<region>.amazonaws.com/latest/linux/aws-replication-installer-init
chmod +x aws-replication-installer-init
sudo ./aws-replication-installer-init --region <region> --no-prompt
# Provide access key ID and secret for a dedicated, minimally scoped
# agent installation user when prompted or via the documented flags.
Use the current installer path and options from the AWS documentation for your region, and give the installation user only the permissions the service requires. Credentials are issued for the migration and revoked afterwards.
How Azure Migrate works
For VMware estates, Azure Migrate uses a lightweight appliance that discovers machines, then replicates VMs to Azure managed disks. Hyper-V and physical servers use their own replication arrangements. As with MGN, you perform test migrations into an isolated virtual network, check results, then run the migration, which performs a final sync and creates the Azure VM. Azure Migrate also supports assessment, with sizing recommendations based on performance history, which ties into the readiness assessment.
Test launches are the real work
A test launch catches the problems you want to find on a quiet Tuesday rather than on a cutover night. We check that the operating system boots, that network interfaces and drivers behave, that services start in the right order, that licences activate and that the application can reach its dependencies. A common find is software bound to a MAC address or old IP, or an application that hard-codes the address of another server. These show up as test failures and become fixes in the runbook.
Windows servers need attention to licensing and activation models. Linux servers need a look at fstab entries, network configuration files and any bootloader customisation. Anything tied to hypervisor tools should be reviewed.
Standardise after the move, not during
It is tempting to patch, resize and clean each server during the move. Resist it. Changing the server while moving it makes failures harder to diagnose, because you cannot tell whether the move or the change broke it. We move first, then standardise using configuration management such as Ansible: install the cloud monitoring agent, apply the baseline, adjust instance size from real usage, and move disks to appropriate volume types. The follow-up review is part of cost optimisation.
Decisions and trade-offs
Rehost or replatform. Rehosting is quicker and lower risk per server. Replatforming, for example moving a file server to a managed file service, cuts operational work for the long term. Pick per workload using the 6Rs, and do not let one approach consume the whole estate.
Agent or agentless. Agentless approaches are lighter to deploy but may have longer cutover sync and less control. Agent-based replication handles more sources and gives block-level continuity. For a large VMware estate, agentless discovery plus agent-based migration for sensitive servers is common.
When not to rehost. Servers at end of life, with no owner, or performing a function a SaaS now covers should be retired or repurchased instead.
A worked example: one wave, step by step
Take a wave of ten application servers. In the week before, we confirm replication is healthy on all ten and run a test launch for each in the isolated network, recording what needed fixing. On cutover day the order is: announce the start, stop the application services on the source, wait for the final sync to show no lag, launch the cutover instances from the tested templates, run the validation checks, then switch traffic according to the plan. If a check fails and cannot be fixed within the agreed time, the source is started again and the wave is rescheduled. Afterwards the source servers are kept powered off, not deleted, until the parallel run ends.
Common failure modes
- Replication bandwidth underestimated, so initial sync takes weeks. Check against the network link early.
- Replication lag at cutover on busy servers.
- Firewall rules and host files that point at old addresses.
- Cutover night as first rehearsal, which is the single most avoidable cause of rollbacks.
- Source servers left running for months, doubling cost.
Delivery and handover
We provide per-wave runbooks, the launch templates in code, the test results and a decommissioning checklist. Your team is shadowed during early waves and leads later ones, so the capability stays with you.
How to tell it is working
Test launches succeed on the first or second attempt, cutover windows match rehearsal, and rollbacks, when triggered, are clean. Server counts on the source fall on schedule. To plan a server migration with us, contact us.