Most AWS migrations do not stall because of tooling or bandwidth. They stall because a decision gets made too early, at the wrong altitude — a single migration strategy chosen for an entire estate of applications, as though a fifteen-year-old line-of-business system and a container-ready SaaS product deserve the same treatment. The three main paths available to a team leaving a data center or legacy hosting are rehost, replatform and refactor, and the honest answer to “which one is right?” is that it depends entirely on the workload in front of you. Treating the choice as a per-workload decision, made after discovery rather than before it, is what separates a controlled migration from a rewrite project disguised as a data center exit.
What Rehost, Replatform and Refactor Really Mean for a Running System
Rehosting, often called lift-and-shift, means moving a server to AWS with minimal change to its operating system, application code and configuration. Tools such as AWS Application Migration Service replicate machines block by block into EC2, and a well-planned cutover can happen in a maintenance window with the application behaving much as it did before. The appeal is speed and predictability: existing dependencies stay intact, the change surface is small, and a business-critical system exits a costly or aging facility without a simultaneous development program. The cost is deferred, not avoided — rehosted workloads carry their technical debt with them, often run larger than necessary, and leave elasticity, managed services and native resilience sitting unused.
Replatforming sits in the middle: the application moves, but selected components are swapped for managed equivalents. A self-managed database becomes RDS or Aurora, virtual machines become containers on EKS, ECS or Fargate, a hand-rolled file store becomes S3, and DNS and load balancing shift to Route 53 and ELB. The application core usually survives with configuration and connection-string changes, so the business logic is not rewritten, but the operational burden drops sharply. This is where most mature migrations actually land, because it captures real savings from managed services without the risk and cost of a full architectural redesign.
Refactoring means re-architecting the workload for the cloud model itself — decomposing a monolith into services, introducing event-driven patterns, moving to serverless components, and accepting that the deployment topology will look nothing like the original. It offers the highest long-term payoff in scalability and code agility, and carries the highest cost, longest timeline and greatest delivery risk. It also requires product ownership and engineering capacity, not just infrastructure expertise, because the application team has to live with the new design.
The practical conclusion is that a portfolio usually needs all three. A single strategy applied uniformly either drags a modernization program behind every low-value server, or leaves your most business-critical platform running exactly as it did in 2014. The strategy is a per-workload judgment call.
Signals in Your Workload Portfolio That Point to a Specific Strategy
Decisions should be driven by evidence gathered during discovery: dependency mapping across infrastructure and applications, readiness assessment, business criticality, compliance obligations and the cost of change. A workload with dense, poorly documented dependencies is a poor refactoring candidate no matter how attractive the target architecture looks on a slide. Conversely, a workload whose scaling pain is the reason for the migration rarely benefits from being moved unchanged.
Rehost is the right call when a system is stable, low-change, and holds dependencies that are expensive to untangle — a legacy ERP with custom integrations, a vendor-supplied application with no supported cloud edition, or anything under a hard freeze until after a financial year end. VMware workloads being extracted during a data center exit are frequent rehost candidates, often as a first wave that stops the facilities clock while the optimization conversation happens later. The same logic applies to workloads whose failure would be business-wide: get them across intact, prove them in production, then improve.
Replatform fits when the application is portable but the surrounding operations are not worth preserving. Database engines that are costlier or harder to patch on-premises, end-of-support runtimes, Windows and SQL Server licensing that gets cheaper to run on AWS-managed capacity, and applications that would benefit from containers without a code rewrite all point here. Database-specific paths using AWS DMS and AWS SCT, alongside VMware-to-AWS conversions, are the classic replatform moves. The test is whether the application can tolerate a swapped dependency with configuration changes and a proper test cycle.
Refactor earns its cost where scale, release cadence or product ambition is the actual driver. A SaaS product team that needs room to grow, or a platform whose deployment pipeline is the bottleneck rather than its infrastructure, will get little from a lift-and-shift. Even then, sequencing matters: refactoring a revenue-critical system immediately before a peak trading season is a risk no runbook fully covers.
Whatever the mix, the assessment stage should conclude before any production server is touched, and a structured amazon cloud migration engagement typically front-loads discovery, dependency mapping, a strategy workshop and total-cost-of-ownership modelling so the per-workload decisions are made on evidence rather than instinct.
Executing a Mixed Strategy: Waves, Cutover Discipline and Post-Go-Live Reality
Once workloads are assigned a strategy, sequencing takes over. Wave planning groups workloads by shared dependencies, shared cutover windows and business risk, not by which team is loudest. A rehosted foundation layer often moves in an early wave to establish the landing zone, networking, identity and security baseline; replatformed databases follow once replication is proven; refactoring work usually runs as a parallel track that consumes migrated systems rather than blocking them. Each wave needs its own cutover runbook, its own success criteria and its own rollback path, because a wave that fails without a rollback plan becomes a business-wide outage rather than a delayed project.
Cutover discipline is where rehost and replatform programs are won or lost. Replication lag, DNS and route changes, session handling and batch schedules all behave differently in production than they did in a test migration, so pre- and post-migration testing has to confirm performance held up, not merely that the application started. Security validation belongs in the same window: hardened landing zones, GuardDuty, Security Hub, CloudTrail and WAF should be active before traffic arrives, not retrofitted after an audit finding.
Go-live is not the finish line. Hypercare — typically a support period running from 30 to 90 days after cutover — is where the surprises surface: queries that were fine on dedicated hardware now compete for shared capacity, and the monthly bill reveals instances sized for comfort rather than need. Rightsizing and a post-migration cost review are the difference between a migration that reduced spend and one that simply relocated it. Close the loop with documentation, architecture diagrams, runbooks and knowledge transfer sessions, then clean up access once the engagement ends, so the internal team can operate the environment without a standing dependency on outside help.
Vancouver-born digital strategist currently in Ho Chi Minh City mapping street-food data. Kiara’s stories span SaaS growth tactics, Vietnamese indie cinema, and DIY fermented sriracha. She captures 10-second city soundscapes for a crowdsourced podcast and plays theremin at open-mic nights.