A CTO signs an AWS migration statement of work expecting a lift-and-shift: move the VMs, cut the datacenter contract, book the savings. Eighteen months later the AWS bill is higher than the datacenter ever was, and half the applications still can’t scale because they were carried across unchanged. This is the most common way AWS migrations fail, and it fails precisely because the word “migration” gets interpreted as “relocation.” AWS migration consulting exists to prevent that interpretation. Done properly, it is a decision-making exercise before it is an engineering exercise — deciding, per workload, whether to move it, change it, retire it, or leave it where it is. The relocation is the easy part. The judgment about what deserves relocation is where the value sits, and where naive migrations skip straight past the hard question. What people think AWS migration consulting is The intuitive model is that a consultant shows up, runs some tooling that copies your servers into EC2, points DNS at the new endpoints, and hands you a decommissioning checklist for the old datacenter. Under this model the consultant is essentially a moving company with AWS credentials. That model is not wrong so much as incomplete, and the incompleteness is expensive. It treats every workload as equivalent cargo, which means it carries forward the same architectural mistakes, the same oversized instances, and the same tightly-coupled dependencies that made the on-premises estate hard to operate in the first place. When those problems land in AWS, they cost money by the hour instead of by the quarter — and now they’re on someone else’s hardware where you can’t just add more RAM to the box. Real AWS migration consulting starts from a different premise: the goal is not to move your estate to AWS, it is to arrive at a defensible per-workload decision about how each application should exist going forward. Some of those decisions are “move it as-is.” Many are not. The assessment phase decides everything downstream Before any workload moves, a credible engagement spends real time on discovery. This is not busywork. It is the phase that determines whether the migration produces savings or a bigger bill. Discovery has three concrete outputs. First, an inventory of what actually runs — not the CMDB’s version of reality, but the observed version, gathered with tooling like AWS Application Discovery Service or third-party agents that watch process and network activity for a few weeks. In our experience, the gap between the documented estate and the running estate is routinely 20–40% (observed pattern across migration assessments; not a benchmarked figure), because old servers never get formally retired and undocumented dependencies accumulate quietly. Second, a dependency map. Applications talk to each other, to shared databases, and to services nobody remembers provisioning. Move one component and break three others — that is the mechanism behind most migration outages. Network flow analysis surfaces these edges before they become 2 a.m. incidents. Third, a cost baseline. You cannot claim savings against a number you never measured. The baseline has to include the fully-loaded on-premises cost — power, cooling, hardware refresh amortization, facilities, and the staff time spent keeping it alive — not just the invoice from the colocation provider. The 7 Rs: the actual decision framework The core of AWS migration consulting is applying a per-workload disposition. AWS formalizes this as the 7 Rs, and it is the structured answer to “what do we do with this application?” Which of the 7 Rs applies to a given workload? Disposition What it means When it fits Relative effort Retire Turn it off, don’t migrate Nobody uses it; discovery shows near-zero traffic Lowest Retain Leave it where it is, for now Regulatory lock-in, imminent EOL, or no business case to move Low Rehost Lift-and-shift to EC2 unchanged Time pressure, stable app, exit deadline on the datacenter Low–medium Relocate Move a whole VMware environment via VMware Cloud on AWS Large VMware estate, want minimal app change Medium Repurchase Replace with a SaaS equivalent Commodity function (email, CRM, ticketing) Medium Replatform Move but swap a component (e.g. self-managed DB → RDS) Some modernization value without a rewrite Medium–high Refactor Re-architect for cloud-native (containers, serverless, managed services) Strategic app, scaling pain, worth the investment Highest The discipline is not memorizing the list — it is resisting the pull toward one column. Teams under deadline pressure rehost everything because it is fastest. Teams chasing cloud-native fashion refactor everything because it feels modern. Both are failures of judgment. A healthy migration portfolio spreads across several dispositions, with retire and retain doing more work than most stakeholders expect — the cheapest workload to migrate is the one you never migrate. Why lift-and-shift so often costs more, not less The single most common disappointment in AWS migrations is a cloud bill that exceeds the datacenter it replaced. The mechanism is straightforward once you name it. On-premises, you buy capacity in large discrete lumps and then run it hot to justify the purchase. A server sized for peak load sits at 15% utilization most of the time, and that idle capacity is a sunk cost you stop thinking about. Rehost that same server as an equivalently-sized EC2 instance and you are now paying for that idle capacity by the hour, continuously, forever. The waste that was invisible on-premises becomes a line item in AWS. This is why replatforming and rightsizing pay for themselves. Moving a self-managed database to Amazon RDS or Aurora, or moving batch workloads to spot instances or serverless, aligns spend with actual usage. In configurations we’ve worked through, rightsizing during migration commonly recovers a meaningful fraction of a naive lift-and-shift bill (observed pattern; the exact figure depends entirely on how oversized the source estate was). The savings are real but they are not automatic — they come from the analysis, not the relocation. There is a related trap worth naming: data transfer costs. AWS charges for data leaving its network (egress), and applications that chat constantly with on-premises systems during a phased migration can rack up transfer charges nobody modeled. This is one reason dependency mapping and migration sequencing matter — you want tightly-coupled components to move together, in the same wave, rather than talking across the boundary for months. The same cost-and-latency discipline applies to where model artifacts and training data live, which is why machine learning storage architecture deserves its own decision rather than being inherited from the source estate. What a migration engagement actually looks like over time The work moves through phases, and the ordering is not arbitrary — each phase de-risks the next. Assess — discovery, dependency mapping, cost baseline, and the first-pass 7 Rs disposition per workload. This is where the business case is won or lost. Mobilize — build the landing zone: AWS account structure, networking, identity and access, security guardrails, and a migration factory pattern so waves can move repeatably rather than as bespoke projects each time. Migrate and modernize — execute in waves, lowest-risk workloads first to prove the pattern, tightly-coupled clusters together, high-value refactors last when the team has cloud operating muscle. Operate — this is not a phase you exit. Cloud cost is a continuous discipline, and without ongoing rightsizing, tagging, and monitoring, the bill drifts upward. This is where migration consulting hands off to cloud operations, and where practices from AI in cloud and DevOps — automated scaling, observability, cost anomaly detection — carry the estate forward. The mistake is treating migration as a project with an end date rather than a transition into a new operating model. The datacenter contract has a termination date; the discipline of running well in the cloud does not. Where AWS-specific choices enter the picture Consulting that is genuinely AWS-specific — rather than generic cloud advice with AWS branding — shows up in the service-selection decisions. Whether to use Application Migration Service (MGN) for block-level replication versus rebuilding via CloudFormation or Terraform. Whether a database belongs on RDS, Aurora, or DynamoDB. How to structure accounts under AWS Organizations for billing isolation and blast-radius control. Whether Savings Plans or Reserved Instances make sense given the commitment appetite. None of that means AWS is automatically the right destination for every workload. The disposition decision includes the possibility that a given workload belongs on a different platform, or should stay hybrid. That platform-fit question deserves its own analysis, which we cover in the AWS vs Azure vs GCP selection guide — migration consulting assumes the destination is already chosen; if it isn’t, that decision comes first. FAQ Is AWS migration consulting just lift-and-shift? No. Lift-and-shift (rehosting) is one of seven possible dispositions, and often not the right one. Credible AWS migration consulting spends its first phase deciding, per workload, whether to retire, retain, rehost, relocate, repurchase, replatform, or refactor — the relocation itself is the smaller part of the work. Why do AWS migrations sometimes cost more than the datacenter? Because rehosting an oversized on-premises server as an equivalently-sized EC2 instance turns previously-invisible idle capacity into an hourly line item. On-premises, running a server at 15% utilization is a sunk cost you ignore; in AWS you pay for that idle capacity continuously. Rightsizing and replatforming during migration are what recover the savings — the relocation alone does not. What are the 7 Rs of AWS migration? Retire, retain, rehost, relocate, repurchase, replatform, and refactor. They are the disposition options applied to each workload during assessment. A healthy migration spreads across several of them rather than defaulting every application into a single column. How long does an AWS migration engagement take? It depends on estate size and how much modernization is in scope, but the structure is consistent: assess, mobilize, migrate in waves, then operate continuously. The operate phase has no end date — cloud cost and reliability are ongoing disciplines, not a box you tick when the datacenter contract lapses. The question that actually matters Before signing any AWS migration statement of work, ask one thing: does the engagement start with an assessment that could conclude “don’t migrate this workload”? If the disposition is decided before discovery runs — if the answer is already “move everything” — then what you have bought is a moving service, and the bill will tell you so within a year. The value of migration consulting is entirely in its willingness to recommend against the move when the move doesn’t earn its keep.
