A CTO at a US logistics company receives three proposals to migrate 80 applications from a colocation data centre whose contract expires in 14 months. The first is a fixed price of USD 450,000. The second is time and materials with an estimate of USD 800,000. The third quotes USD 1.2 million and includes “managed services” for a year. The board asks the obvious question: why does the same migration cost almost three times more at one company than at another?
The answer is that these are not three prices for the same thing. The first proposal covers moving virtual machines unchanged and leaves the landing zone, security and database upgrades to the client. The second assumes the partner will re-platform a third of the portfolio. The third includes a year of operations the other two ignore. Cloud migration services are not a commodity, and the word “migration” hides very different scopes.
This matters because migrations go wrong expensively. McKinsey’s survey of nearly 450 CIOs and IT leaders found that inefficiencies in coordinating migrations cost the average company 14% more in migration spend than planned, and 38% of companies saw migrations delayed by more than a quarter. Below we break down what a migration partner should do in each phase, how the four pricing models compare on a worked example, how the hyperscalers fund partner work in 2026 and how to spot a weak proposal before you sign it.
What do cloud migration services actually include?
A complete cloud migration engagement covers six areas. Most proposals cover some of them, and the gaps are where budgets break:
- Assessment — inventory of servers, applications and dependencies, a business case and a total cost of ownership model.
- Migration strategy — a decision for every workload: retire it, keep it where it is, move it as is, or change it on the way.
- Landing zone — the target environment: account structure, network, identity, security baseline, logging and policies.
- Migration waves — moving workloads in groups, testing, cutover and hypercare.
- Optimization and FinOps — right-sizing, commitments, cost allocation and governance after go-live.
- Managed operations — optional ongoing run, monitoring and incident response.
A good partner also brings the connecting tissue: program management, change management for your teams, security and compliance sign-off, and knowledge transfer so you are not dependent on them afterwards.
The practical test for any proposal is simple: map every line of the proposal to these six areas and mark what is missing. A cheap proposal that covers two areas is not cheaper than an expensive one that covers five — it simply moves the other three onto your team, usually without anyone budgeting for them.
This article focuses on the partner: what they deliver, how they charge and how to choose one. If you need the operational side — what to do in which week — see our step-by-step cloud migration checklist. For the business case itself, our cloud migration cost calculator guide walks through the TCO model.
What happens in the assessment phase, and what should it deliver?
The assessment is the cheapest phase and the one with the highest leverage. In our worked example below it accounts for about 5% of the partner budget, yet it determines the other 95%.
A proper assessment delivers five artefacts:
- An inventory with dependencies. Not just a server list from the CMDB, but discovered network flows between applications. Tools such as AWS Application Discovery Service, Azure Migrate or Google Cloud Migration Center collect this automatically. Dependencies decide which applications must move together — and therefore how waves are built.
- A classification of every workload by strategy. Each application gets one of the 7 Rs with a rationale (next section).
- A target cost model. Projected monthly cloud spend per workload, including storage, egress and licensing — not only compute.
- A licensing review. Microsoft, Oracle and other vendors’ licenses behave differently in each cloud. Getting this wrong can wipe out the savings; our article on licensing in an on-premise to cloud migration covers the traps.
- A wave plan and risk register. Which groups move when, what could go wrong and who decides.
Ask the partner how long the assessment will take and what exactly you will receive at the end. For a portfolio of around 80 applications, four to six weeks is realistic. An “assessment” delivered in a week from a spreadsheet you sent them is a sales presentation.
One more point: the assessment should be allowed to conclude that some workloads should not move. A partner paid only for migrated servers has an incentive to move everything. A partner paid for the assessment as a separate deliverable can tell you that a legacy system due for replacement in 18 months should stay where it is.
How does a partner choose between the 7 Rs for each workload?
AWS Prescriptive Guidance documents seven migration strategies, known as the 7 Rs. Other providers use similar lists under different names, so it is worth understanding them regardless of the target cloud:
| Strategy | What it means | Typical use |
|---|---|---|
| Retire | Decommission the application | Unused or duplicated systems |
| Retain | Keep it where it is for now | Systems due for replacement, regulatory constraints |
| Rehost | Move as is (“lift and shift”) | Most of the portfolio in a deadline-driven migration |
| Relocate | Move at the hypervisor level, e.g. VMware to a cloud VMware service | Large VMware estates with a hard exit date |
| Replatform | Move with limited changes, e.g. to a managed database | Databases, middleware, standard application servers |
| Repurchase | Replace with a SaaS product | CRM, HR, collaboration tools |
| Refactor | Re-architect for cloud-native services | Core systems where scalability or speed of change justifies the cost |
The guidance is explicit on one point that proposals often ignore: for large migrations, AWS recommends mainly rehost, replatform, relocate and retire, and modernizing after the move. Refactoring during migration is the most complex strategy, and mixing it into a migration with a hard deadline is how programs slip by quarters.
The share of each strategy drives the cost more than anything else. In our worked example, refactoring 10% of the applications consumes almost half of all migration effort. When two proposals differ by a factor of two, the first thing to check is how many applications each partner assumed would be refactored or re-platformed — often the difference is entirely there.
A good partner shows you the strategy per application with a rationale and an effort estimate, and lets you move applications between categories to see the effect on cost and timeline. A weak one gives you a single percentage split for the whole portfolio.
Why does the landing zone come before the first migrated server?
The landing zone is the foundation of the target environment: the structure of accounts or subscriptions, network topology and connectivity back to your offices and data centres, identity and access management, security baseline, logging and monitoring, and policies that stop teams from creating resources outside the rules. It is usually built as infrastructure as code, so it can be reviewed, versioned and reproduced.
Skipping or rushing it is the most expensive shortcut in cloud migration. Workloads moved into an ad hoc environment have to be moved again when security or networking is redone properly — the migration is effectively paid for twice.
The landing zone is also where responsibility most often falls between the cracks. Who owns identity integration with your directory? Who approves firewall rules? Who holds the root credentials? The proposal should state explicitly what the partner builds, what your team builds and who operates it afterwards. “Landing zone included” without that split means you will discover the gaps during the first wave.
The three hyperscalers publish reference architectures — the AWS Landing Zone Accelerator and Control Tower, Microsoft’s Cloud Adoption Framework landing zones, and Google Cloud’s foundation blueprints. A partner should start from these rather than invent its own design, and explain where and why they deviate. If you have not yet settled on a provider, our AWS vs Azure vs GCP selection guide compares them.
How are migration waves executed and cut over?
Migration waves group applications that must move together because of dependencies, shared databases or business calendars. A typical program starts with a pilot wave of a few low-risk applications to test tooling, runbooks and the landing zone, then scales up.
For each wave, a mature partner delivers:
- A runbook — step-by-step cutover procedure with owners, timings and rollback criteria.
- Replication and synchronisation — tools such as AWS Application Migration Service (now branded AWS Transform MGN), Azure Migrate or Google Cloud Migrate to VMs replicate servers continuously, so cutover is minutes or hours rather than days. AWS gives 2,160 free hours of replication per source server — 90 days of continuous replication — after which replication is billed per hour.
- Testing — functional, performance and security testing in the target before cutover.
- Cutover and hypercare — the switch itself, usually in a maintenance window, followed by one to two weeks of heightened support.
Databases deserve special attention. Moving a large database with minimal downtime requires continuous replication, and the window for the final switch is determined by data volume and change rate, not by optimism. Ask the partner how they plan database cutovers and what they did the last time a cutover had to be rolled back.
What might the schedule look like for our example portfolio? After removing retired and retained applications, 60 remain to move. A sensible layout is a pilot wave of three to five low-risk applications, then waves of eight to twelve applications every two to three weeks, and finally separate waves for critical systems and the largest databases, scheduled around the business calendar — not during year-end close or peak sales. Refactored applications follow their own track, because developer work, not replication tooling, sets their pace.
The cadence matters for cost. Waves that run in parallel shorten the program but require more people at once. A partner who proposes a single “big bang” cutover for 80 applications is either very confident or has not looked at your dependencies.
What happens after go-live: optimization, FinOps and managed services?
Migration ends at cutover. Value begins after it. Flexera’s 2026 State of the Cloud report estimates that 29% of IaaS and PaaS spend is wasted, reversing a five-year downward trend, and 85% of respondents name managing cloud spend as a top challenge. Workloads moved as is are typically oversized, because they were sized for on-premise peaks with headroom.
The scale is easy to calculate. If the portfolio from our example ends up with a monthly cloud bill of USD 40,000 and waste sits at Flexera’s average, the company loses about USD 139,000 a year — more than the assessment and landing zone cost together. That is why much of a partner’s value lies in what they do after cutover, not only in how smoothly they move servers.
A partner’s optimization phase should cover:
- Right-sizing — adjusting instance sizes to observed usage after a few weeks of production data.
- Commitments — savings plans, reserved instances or committed use discounts once the usage baseline is known. Buying them before migration locks in the wrong sizes.
- Cost allocation — tagging and showback, so business units see what they consume.
- Governance — budgets, alerts and policies that prevent waste from returning.
This is the discipline of FinOps. It is continuous rather than a project, and our FinOps 101 guide explains how to organise it internally.
Managed services — the partner running your environment after migration — are optional. They make sense when you lack a cloud operations team or need 24/7 coverage. They are also where lock-in happens. If you buy them, insist on documented infrastructure as code in your repositories, runbooks you own, and a termination clause with a handover period.
What pricing models do cloud migration companies use?
Cloud migration partners use four main pricing models, often mixed within one program:
Fixed price per phase. A fixed fee for the assessment, another for the landing zone, and fixed prices per wave once the scope of each wave is known. This works well when each phase has a clear deliverable. The partner prices uncertainty as a risk premium — in our experience typically 15–25% on top of the effort estimate — and protects itself with change requests. As we described in our article on who really pays for risk transfer in fixed-price software, a fixed price does not remove risk; it moves the cost of risk into the price.
Time and materials (T&M). You pay for hours worked at agreed rates. It is the most transparent model and suits phases with high uncertainty, such as refactoring. It requires active management on your side: a backlog, priorities and regular reviews of burn rate against progress.
Staff augmentation. The partner provides cloud architects and DevOps engineers who join your team under your management. You own the plan and the decisions; the partner supplies capacity and expertise. This suits organisations with a strong internal lead who need more hands, not a turnkey project. See how our staff augmentation services work.
Outcome-based pricing. Part of the fee depends on results — applications migrated, a data centre vacated by a date, or cloud cost reduction achieved. It aligns incentives but requires precise, measurable definitions of the outcome agreed in advance. It is less common for full migrations and more common for optimization engagements, where savings are easy to measure.
When comparing proposals, also check what exactly sits behind the rate. A T&M proposal with a rate 20% lower can turn out more expensive if the partner plans more hours, staffs the team with less experienced people or charges separately for project management, tool licences and on-call cover during cutovers. Ask for hours broken down by role and phase, and for a list of items billed outside the rate. Only then can rates be compared.
In practice, the most robust combination for a mid-size migration is: fixed price for the assessment, fixed price or T&M for the landing zone, fixed price per wave for rehost and replatform, and T&M or staff augmentation for refactoring.
How much does a cloud migration project cost — a worked example?
To make the models comparable, here is an explicit worked example. It is not a quote — it is a transparent model you can adapt to your own numbers.
Assumptions: 80 applications, around 200 virtual machines, one data centre, a 12-month program. Strategy mix: retire 10%, retain 15%, rehost 40%, replatform 20%, repurchase 5%, refactor 10%. Partner effort per application: retire 2 person-days, retain 1, rehost 6, replatform 15, repurchase 12, refactor 60. Assessment 60 person-days, landing zone 90, hypercare 10% on top of migration waves, program management 12% on top of everything. Blended rate: a 60/40 mix of senior DevOps engineers and cloud architects at the midpoints of the Polish nearshore ranges from our body leasing rate benchmark (PLN 240 and PLN 300 per hour), which gives PLN 264 per hour — about USD 71 per hour at an assumed rate of PLN 3.70 per USD.
| Component | Person-days | Cost (T&M) |
|---|---|---|
| Assessment | 67 | USD 38,000 |
| Landing zone | 101 | USD 58,000 |
| Migration waves incl. hypercare | 1,217 | USD 695,000 |
| Total | 1,385 | USD 791,000 |
| Fixed price with 15% risk premium | — | USD 909,000 |
| Fixed price with 25% risk premium | — | USD 988,000 |
Three findings stand out:
- Refactoring dominates. The eight applications to be refactored — 10% of the portfolio — account for 49% of migration effort (480 of 988 person-days). Moving three of them to “replatform now, refactor later” cuts total cost by about USD 95,000.
- The assessment and landing zone are cheap relative to their impact. Together they are about 12% of the budget and determine the cost of everything else.
- The fixed-price premium is the price of uncertainty. Paying USD 120,000–200,000 more for a fixed price makes sense only if the scope is well understood — that is, after the assessment, not before.
Nearshore rates matter too. The same 11,000 hours at onshore US consulting rates would cost a multiple of this figure, which is why many US companies combine an onshore lead with a nearshore delivery team. Current role ranges are on our pricing page.
How do AWS, Microsoft and Google funding programs reduce the partner bill?
All three hyperscalers co-fund migrations, because a migrated workload becomes years of consumption. The funding usually flows through a certified partner, so the partner’s status with the provider directly affects your cost.
AWS Migration Acceleration Program (MAP). Structured in three phases — Assess, Mobilize, and Migrate & Modernize. The Assess phase includes a Migration Readiness Assessment across the dimensions of the AWS Cloud Adoption Framework and a TCO model. Mobilize closes capability gaps, builds the landing zone and produces a detailed migration plan. Migrate & Modernize moves the workloads. Funding and credits are tied to projected AWS spend and earned against milestones and consumption; migrated resources must be tagged for credits to apply, and credits are not granted retroactively. Partner guides published in 2026 describe credits in the Migrate & Modernize phase typically in the range of 15–25% of first-year projected run rate — treat that as indicative and confirm with your AWS account team.
Microsoft: from Azure Migrate & Modernize to Frontier Accelerate for Azure. In 2025 Microsoft consolidated Azure Migrate & Modernize, Azure Innovate and the new Cloud Accelerate Factory into a single program, Azure Accelerate. Cloud Accelerate Factory offers zero-cost deployment support for more than 30 Azure services delivered by Microsoft experts. In 2026, as part of its fiscal 2027 partner framework, Microsoft rebranded the program as Frontier Accelerate for Azure. The name has changed twice in two years; what matters is that funding, assessments and delivery support still come through qualified partners.
Google Cloud Rapid Migration and Modernization Program (RaMP). It starts with a free migration assessment. Workloads qualify from a projected annual run rate of USD 60,000, with baseline service funds of 20% of projected annual recurring revenue — capped at USD 2 million per workload — to offset partner or Google Professional Services costs, plus consumption-based credits paid quarterly on growth of tagged workloads.
Three practical points. First, ask every partner which programs they are qualified for and how much funding they expect to secure for you — then check it with the provider. Second, funding is not free money: it comes with commitments to projected consumption, so the target cost model must be realistic. Third, programs change names and rules every year, as Microsoft’s history shows; any figure in a proposal should be dated and sourced.
When do you not need a full-service migration partner?
Not every migration needs a partner running the whole program. There are three situations in which a lighter model works better and costs less.
You already have a strong cloud team. If your organisation has run production workloads in the target cloud for years, has a working landing zone and an experienced platform team, the missing piece is usually capacity, not know-how. Adding a few engineers under your own lead — staff augmentation — is cheaper than paying a partner’s program management and risk premium for decisions your team can make itself.
The migration is small or homogeneous. Ten virtual machines running standard web applications, or a single database moving to a managed service, is a project for an internal team with a few days of expert review, not a multi-phase program. The tooling from AWS, Microsoft and Google has matured enough that straightforward rehosting is well documented.
The hard part is not the migration. Sometimes the real problem is an application that needs to be rewritten, or a data platform that needs to be redesigned, and “cloud migration” is the label on a modernisation project. In that case you need a software development partner who understands cloud architecture, not a migration factory optimised for moving servers quickly.
There is also a middle ground that works well for many mid-size companies: a partner delivers the assessment and landing zone as fixed-price packages — the phases where specialist experience matters most and mistakes are most expensive — and your team, reinforced by a few external engineers, executes the waves. You keep control and build internal capability, and you pay premium rates only where they buy the most.
The question to ask yourself is: after the migration, who will run and change this environment? If the answer is your team, the partner’s most important job is to make that team capable — and the engagement model should reflect that from day one. If the answer is the partner, then managed services, exit terms and documentation become the core of the contract, not an appendix.
How do you choose a cloud migration partner?
Certifications and partner badges are a filter, not a decision. Nearly every serious candidate will have them. What distinguishes partners is how they work. Six criteria matter most:
- A named team. Who exactly will lead the program and do the architecture? Ask for CVs and interview the lead architect. A proposal staffed with “a senior cloud architect” is a promise, not a team.
- Comparable references. Migrations of similar size, similar technology (e.g. Oracle, SAP, mainframe, VMware) and similar regulatory context. Call the references and ask what went wrong.
- Assessment before commitment. A partner who insists on a paid assessment before quoting the full migration is being honest about uncertainty.
- Clear responsibility split. Especially for security, identity, networking and operations after go-live. Ask for a RACI matrix.
- Knowledge transfer and exit. How will your team learn to run the environment? What happens at the end of the contract? Infrastructure as code in your repositories is non-negotiable.
- Pricing matched to uncertainty. Fixed price where the scope is known, T&M or staff augmentation where it is not.
A question worth asking every candidate: “Tell us about a migration that went badly and what you changed afterwards.” A partner without an answer either has little experience or is not telling you. The best answers include a specific cutover rollback, a dependency that was missed or a cost model that was wrong — and what process changed as a result.
Finally, consider the operating model after migration. If your team will own the cloud environment, you need a partner that builds capability alongside delivery — for example by embedding cloud architects and DevOps engineers in your team rather than working in a black box.
What red flags should you watch for in a cloud migration proposal?
Some patterns in proposals predict trouble reliably:
- A fixed price for the whole migration before any assessment. Either the risk premium is inflated, or the partner plans to recover costs through change requests. Both cost you money.
- A single strategy percentage for the whole portfolio. “70% rehost, 30% replatform” without a per-application list means nobody has looked at the applications.
- No mention of the landing zone, or “landing zone included” without detail. The foundation is the most common source of rework.
- Savings promised without a cost model. “30% lower infrastructure cost” without per-workload numbers, licensing and egress is marketing. McKinsey’s finding of 14% average migration overspend should make you sceptical of any round-number promise.
- Commitment purchases before migration. A partner who recommends buying three-year reservations before workloads are running and right-sized is optimising for the provider, not for you.
- Managed services bundled in by default. Operations may be valuable, but they should be a separate decision with its own price and exit terms.
- No rollback plan. Every cutover runbook needs explicit rollback criteria and a tested rollback procedure.
- Proprietary tooling you cannot keep. If the environment can only be operated with the partner’s tools, you are buying lock-in.
None of these alone disqualifies a partner, but two or three together should prompt a much harder conversation before signing.
What checklist should you use to compare cloud migration partners?
The table below condenses the article into a scoring tool. Score each partner from 0 to 2 on every line; a partner below 12 of 20 points needs a strong reason to stay on the shortlist.
| Criterion | 0 points | 1 point | 2 points |
|---|---|---|---|
| Scope coverage | 1–2 of the six areas | 3–4 areas | All six areas, gaps stated explicitly |
| Assessment | None or from a spreadsheet | Short, tool-based | 4–6 weeks, dependencies, TCO, licensing, wave plan |
| Strategy per workload | Portfolio-level percentages | Per application, no rationale | Per application with rationale and effort |
| Landing zone | Not mentioned | ”Included” | Reference architecture, IaC, RACI |
| Pricing model | Fixed price before assessment | One model for everything | Model matched to phase uncertainty |
| Hyperscaler funding | Not mentioned | Mentioned generally | Named program, expected amount, conditions |
| Team | Roles only | Named lead | Named team, interviewed lead architect |
| References | Generic logos | Similar size or technology | Similar size, technology and regulation, contactable |
| Knowledge transfer and exit | Not addressed | Documentation promised | IaC in your repositories, runbooks, handover period |
| Post-migration value | Not addressed | Optimization mentioned | Right-sizing, commitments, FinOps governance |
Key takeaways:
- Compare scopes before prices. Proposals that differ threefold usually describe different projects.
- Pay for the assessment separately. It is about 5% of the budget and determines the rest.
- Watch the refactoring share. In our example, 10% of applications drive half of the migration effort.
- Fix the price only where the scope is known. A fixed price before assessment is a risk premium or a future change request.
- Use hyperscaler funding, but verify it. Program names and rules change every year.
- Plan for after go-live. With 29% of cloud spend wasted on average, optimization is where the business case is won or lost.
At ARDURA Consulting we support cloud migrations for clients in the USA, Europe and the Middle East, drawing on more than ten years of experience in software development and team augmentation. We work in whichever model fits the phase: a fixed-price assessment, a dedicated team for the landing zone and waves, or cloud architects and DevOps engineers who join your team and build your capability along the way. We start by showing you our assumptions — just like the worked example above.
If you are comparing cloud migration proposals or preparing a request for one, talk to our team. We will review your scope, help you build a comparable model and tell you honestly which parts you can run yourself.