The CTO of a mid-sized manufacturer near Stuttgart has three proposals for moving forty applications from the company’s own data centre to a public cloud. The first is €180,000, fixed price. The second is €260,000 on time and materials, labelled a “non-binding estimate”. The third is €330,000 with a long technical annex nobody on the board has read. The CFO asks the obvious question: why are we not taking the cheapest?
The answer is not in the totals. It is in what each vendor has promised. The first proposal ends the moment the virtual machines boot in the cloud. The second does not say when it ends. The third includes performance testing, a tested restore from backup, six weeks of support after cutover and handover of the infrastructure code into the client’s repository. These are three different services sold under one name.
This article is for the person making that choice. We covered what a migration partner actually does, how partners charge and how cloud provider programmes co-fund the work in our guide to cloud migration services and choosing a partner. Here we go one step further: what to put in the statement of work, how to define acceptance, how to tie payments to progress, and which contract clauses protect both the price and your independence. The thesis is simple: the cost of a migration depends less on the partner’s day rate than on how precisely you specify the job.
Why do three quotes for the same migration differ by half?
Because “migration” has no single definition. For one vendor it means replicating virtual machines with a migration tool and confirming that the system responds. For another it includes the landing zone design, moving the database to a managed service, performance testing and cost optimisation after go-live. Both price honestly what they understand by the word. The trouble is that the buyer compares totals rather than scopes.
The gap usually comes from five places. The first is the strategy per workload: rehosting a system unchanged costs a fraction of re-architecting it, and proposals often assume different strategies without saying so. The second is the landing zone: accounts, network, identity, baseline security and logging, which some include and others assume already exist. The third is data: volume, synchronisation method and the cutover window. The fourth is testing: who prepares the tests, who runs them and who signs the result. The fifth is the period after cutover: does the partner stay when the first overnight batch job fails, or disappear the next day?
On top of that sits the risk premium. A vendor quoting a fixed price without a proper inventory has to find a margin for surprises somewhere. Either it adds that margin to the price, or it narrows the scope and adds a list of assumptions whose breach opens the door to change requests. In the first case you overpay for risk that may never materialise. In the second you pay less up front and more along the way.
The practical conclusion: before comparing prices, bring the proposals to a common denominator. The simplest way is to write your own statement of work and ask every bidder to price the same document. If you do not yet have the data to write that document, the first engagement should be an assessment, not a migration.
What must the statement of work contain for proposals to be comparable?
The statement of work (SOW) is the most important annex of a migration contract. It is the SOW, not the recitals or the general terms, that settles disputes in month three. A good one has ten elements.
A workload list as an annex. Every application, database and service in scope, with its business owner, environments (production, test, development), data volume and dependencies. The list should be closed: anything not on it is not in scope.
A strategy per workload. For each item, the decision: rehost, replatform, refactor, replace with SaaS, retain or retire. If a decision has not been made yet, write down who will make it and by when.
The landing zone. Account or subscription structure, networking and connectivity to company sites, identity management, baseline security policies, central logging and a cost tagging standard. If a landing zone already exists, state that the partner works within it and does not change it without approval.
Data transfer. The method (continuous replication, export and import, physical transfer), the maximum acceptable downtime window per application and how data completeness will be verified. Our glossary entry on data migration describes the common approaches.
The test plan. Types of test (functional, integration, performance, restore), who prepares the scenarios, who runs them and who signs off.
Cutover and rollback. A procedure for each wave, with go/no-go criteria (more on this below).
Hypercare. How many weeks the partner remains on standby after cutover, during which hours and with what response time.
Documentation and knowledge transfer. Which documents will be produced (architecture, runbooks, incident procedures), in what format, and how many hours of handover workshops your team gets.
Exclusions. An explicit list of what the partner does not do: for example application code modernisation, third-party software licences, operations after hypercare.
Assumptions. The conditions behind the price: availability of your people, dates by which environments are made available, the number of maintenance windows. This list is the most common source of change requests, so read it more carefully than the price itself.
When every bidder prices the same document, price differences start to mean something. They may still reflect rates, experience or margin, but they no longer reflect the fact that everyone priced a different service.
Who is responsible for what, and why does a responsibility matrix settle disputes?
A cloud migration is joint work. The partner cannot test the business rules of an application it does not know, cannot agree a downtime window with the sales department and cannot get the HR system owner to approve a cutover on Thursday evening. Those things are the buyer’s job. When the contract does not say so, every delay on your side becomes grounds for moving dates and another invoice, and every delay on the partner’s side is easy to attribute to “missing access”.
So attach a responsibility matrix in RACI format to the contract: who does the work, who approves it, who is consulted and who is informed. One accountable person for every activity in the SOW. Typical buyer-side items are: providing access and accounts by a given date, naming application owners, preparing test data, running user acceptance tests, approving maintenance windows, making the go/no-go call at cutover and buying or transferring licences.
A separate layer is the cloud provider’s shared responsibility model. AWS, Microsoft and Google are responsible for the security of the cloud itself, meaning the physical infrastructure and the virtualisation layer, while the customer is responsible for what it runs in the cloud: configuration, identity, data and applications. The migration partner works in that second half. The matrix should clearly separate which configuration elements the partner builds and hands over, and which you then operate.
Pay particular attention to licences. Moving a system whose licence is tied to a physical server onto shared cloud infrastructure can breach the licence terms or cost far more. That deserves its own analysis, which we describe in our article on license planning for on-premise to cloud migration. In the matrix, it is enough to name who verifies the licence position of each workload before it moves.
How should acceptance criteria be written for each migration wave?
Acceptance is where most migration contracts are weakest. A clause saying “acceptance follows the successful transfer of systems” means nothing, because “successful” is not defined. In practice the acceptance certificate gets signed when the servers respond, and every problem found in the following weeks becomes yours.
Accept per wave rather than once at the end. A wave is a group of workloads moved together because they depend on each other. Each wave has its own criteria, and passing them unlocks the next wave and the next payment. Criteria should be measurable and checkable without argument. Here is a set to start from:
- Functionality. Test scenarios prepared by the application owner executed and passed, with a record signed by that person.
- Performance. Response times for key operations and batch job durations no worse than measured before migration, within a stated tolerance. This needs a baseline measurement before the move, so put it into the SOW.
- Restore. A backup taken in the new environment and actually restored in a test, not merely configured. State the target RPO and RTO, the acceptable data loss and time to recover.
- Monitoring and alerting. Metrics, logs and notifications working and routed to the team that will operate the system.
- Security. Configuration matching the landing zone’s baseline policies, no publicly exposed resources that should not be, permissions following least privilege.
- Cost. All resources tagged according to the standard so that the bill can be attributed to an application and an owner.
- Documentation. The runbook for the wave handed over and reviewed by your team.
The last two look like formalities but carry real financial weight. According to the Flexera 2025 State of the Cloud report, published in March 2025 and based on a survey of more than 750 technical professionals and executives, 84% of respondents named managing cloud spend as their top cloud challenge, and cloud budgets were already being exceeded by 17%. Untagged resources are resources whose cost cannot be attributed and therefore are hard to control. How to build that control after migration is covered in FinOps 101.
The contract should also set out the acceptance procedure: how many working days you have to verify, how you report defects, how severity is classified and which defects block acceptance. A good practice is to distinguish blocking defects from minor ones that the partner fixes within an agreed period after acceptance.
What belongs in the cutover and rollback plan?
Cutover is the moment user traffic moves to the new environment. It is the riskiest hour of the whole project, and in many proposals it gets one sentence. The cutover plan should be a separate document for each wave, prepared by the partner and approved by you before the wave starts.
It contains a list of steps with durations and owners, preconditions (for example completed data synchronisation and a change freeze on the source system), checkpoints and the decision criteria at each of them. The most important element is the point of no return: the moment after which rolling back costs more than fixing forward in the new environment. Up to that point, a decision to roll back must be possible and rehearsed.
The rollback plan answers the question of what happens when something goes wrong. How long the source system stays ready, how data changed in the new environment gets back to the old one, how long the return takes and who decides. ARDURA’s page on cloud architects describes a six-phase migration methodology in which full migration execution runs with rollback plans. Whoever you choose, insist that the rollback plan exists in writing and is tested on at least one pilot wave with less critical workloads.
In the contract, state that the go/no-go decision is made by a named person on your side, based on the criteria in the plan. The partner recommends; you decide. Also state who bears the cost of a second attempt if a cutover is rolled back for reasons on the partner’s side. Without that clause, every failed cutover means extra billable days.
It also helps to plan a change freeze. For a few days before and after cutover, development teams do not release new versions of the applications being moved. That freeze needs agreement inside the company, so put it into the schedule and the responsibility matrix rather than discovering it in migration week.
How can the price be protected against scope changes?
Scope changes in a migration are inevitable. No inventory is ever complete: there is always a forgotten scheduled job, an undocumented integration or a server that “is not used” until someone switches it off. The aim of the contract is not to rule out change but to make it predictable and priced according to rules known in advance.
The first tool is a two-stage structure. The assessment, the inventory with dependencies and the migration plan form a separate, short, fixed-price engagement. Its output is the SOW for the second stage, the migration itself. This split reduces the risk premium in the second stage and gives you a document you can take to another supplier if the first one does not convince you. Make sure the assessment contract transfers the rights to its results to you.
The second tool is unit pricing. Instead of one figure for everything, ask for a price per workload type, for example: web application rehosted unchanged, database moved to a managed service, application requiring replatforming. Add day rates per role for work outside the price list. When ten additional servers appear mid-project, pricing them is arithmetic rather than negotiation.
The third tool is a change request procedure. Every change in scope requires a written request with a description, a price and the schedule impact, approved by a named person on your side before work begins. Work done without an approved request is not billable. It sounds bureaucratic, but it protects both sides from arguing about what was “obviously in scope”.
The fourth tool is a cap. On time and materials, set a monthly or total cap on hours that cannot be exceeded without your approval, and require weekly reporting of consumption with a forecast to completion. A comparison of commercial models and how they split risk between the parties is in our article on team subscription, time and materials and fixed price.
How do you tie payments to progress rather than to the calendar?
The most common payment schedule in migration proposals is monthly instalments, or an advance followed by instalments. That pays for the passage of time, not for results. If the project slips, you keep paying and the partner has no financial reason to speed up.
It is better to tie payments to milestones that can be checked objectively. An example: payment for the assessment on acceptance of the report and plan, payment for the landing zone on acceptance against the security and tagging criteria, payment for each wave on acceptance against the criteria above, and a final payment at the end of hypercare and documentation handover.
Consider a retention. A share of each wave’s value, typically single-digit to low double-digit percent depending on project risk, is paid only after hypercare for the whole project ends. That covers the case where problems surface after several weeks, for example at the first month-end close in the finance system. The amount is a matter for negotiation; what matters is that the release conditions are unambiguous.
On time and materials, milestones still make sense, though not as a condition for paying for hours worked. They can mark review points where you compare budget burn with progress and decide whether to continue. If 60% of the budget is gone after two of six waves, you learn about the problem early enough to act.
Which clauses protect you from lock-in to the partner and to the cloud?
Lock-in has two dimensions. The first is the migration partner: if only the partner knows how the environment was built and only the partner has full access to it, every change needs its involvement and switching supplier becomes a project of its own. The second is the cloud provider: if the architecture relies on services specific to one platform, moving elsewhere is expensive. The first kind of lock-in is almost always unnecessary. The second can be a deliberate choice, but it should be a choice rather than an accident.
Four clauses work against partner lock-in. Cloud accounts, subscriptions and projects belong to your organisation from day one, and the partner gets access through roles you can revoke. Infrastructure code (Terraform, CloudFormation, Bicep) is committed to your repository as work progresses, not at the end. Rights to documentation, scripts and configuration pass to you upon payment for each stage. The contract describes the partner’s exit obligations: handing over credentials and keys, removing its own access and a defined number of support hours while a new team takes over.
Against unplanned cloud lock-in, what helps is an explicit architectural decision, recorded with its rationale in the migration plan, and an exit plan. EU law helps here too. The Data Act, Regulation (EU) 2023/2854, has applied since 12 September 2025. Under Article 25, a contract with a data processing service provider must set a maximum notice period for initiating a switch of no more than two months, and the switch itself should happen without undue delay and, as a rule, within a transitional period of no more than 30 calendar days. Where that is technically unfeasible, the provider may propose a longer period of no more than seven months. Article 29 states that from 12 January 2027 providers may not impose switching charges. The full text is on EUR-Lex. For UK-based buyers, note that the Data Act is EU legislation; check whether your provider contract is governed by it before relying on these rights.
These rules apply to your contract with the cloud provider, not with the migration partner, but they change the economics of exit. Data transfer costs stop being the main barrier, and the number of platform-specific services built into your applications matters more. So require the migration plan to record, for each workload, its dependencies on provider-specific services. How to price that exit cost before you even move in is covered in our cloud migration cost calculator guide.
What does DORA change if you are in financial services?
If your company is a financial entity within the meaning of the Digital Operational Resilience Act (Regulation (EU) 2022/2554), both the migration contract and the cloud provider contract are subject to additional requirements. DORA has applied since 17 January 2025. Its Article 30 sets the minimum content of contracts with ICT third-party service providers, including a clear description of the functions and services provided and termination rights with minimum notice periods. For services supporting critical or important functions the requirements go further and include, among other things, precise performance targets, access and audit rights and exit strategies with an appropriate transition period.
In practice, your legal and risk teams should see the draft contract before negotiations start, not after. A migration partner working in financial services should know these requirements and accept clauses on audit, subcontracting and exit without resistance. If it treats them as exotic demands, that tells you something about its experience.
Even if DORA does not apply to you, its structure is a good template. A description of services, data processing locations, audit rights, rules for subcontractors and an exit plan are worth having in any contract covering infrastructure your business depends on. Sector regulation merely enforces what a sensible buyer should want written down anyway.
How do you compare migration proposals by their terms rather than their totals?
The table below turns the previous sections into one checklist. Work through it for each proposal before comparing prices. A proposal that loses on several rows can be cheaper on paper and more expensive in delivery.
| Area | What to check in the proposal or draft contract | Good sign | Warning sign |
|---|---|---|---|
| Scope | Closed workload list with a strategy for each | Annex with the list and 7R decisions | ”Migration of the environment” with no list |
| Assumptions and exclusions | Explicit pricing conditions and out-of-scope items | Short, specific list | No list, or dozens of generic caveats |
| Responsibilities | RACI matrix for all activities | One accountable person per activity | Client duties described in general terms |
| Acceptance | Measurable criteria per wave | Performance, restore, monitoring, tags | ”Successful transfer of systems” |
| Cutover | Cutover and rollback plan per wave | Point of no return, decision on the client side | One sentence about a “maintenance window” |
| Change | Unit pricing and a change request procedure | Prices per workload type, role rates | Every change priced ad hoc |
| Payments | Linked to stage acceptance | Payment per accepted wave, retention | Monthly instalments regardless of progress |
| Ownership | Accounts, infrastructure code, documentation | Everything in the client’s organisation from day one | Environment built in the partner’s accounts |
| Hypercare | Duration, hours, response time | Defined weeks and a response SLA | ”Support as needed” |
| Knowledge transfer | Documents and workshops for your team | List of documents and number of hours | Documentation “at the end of the project” |
| Cloud costs | Optimisation and tagging | Tagging standard, cost review per wave | No mention of the post-migration bill |
| Exit | Obligations at contract end | Credential handover, support hours | Nothing about termination |
The table does not replace a technical conversation with the people who will deliver the project, but it lets you ask the right questions. A good partner has ready answers to most of them, because it also wants to work under predictable conditions.
Which contract terms should stop you from signing?
Some problems only show up in the draft contract, not in the proposal. These are the clauses worth stopping at and negotiating.
Token liability caps. A partner’s liability capped at one month’s fees, on a project where a failed cutover could halt sales for days, does not match the risk. Caps are normal in IT contracts, but their level should bear some relation to the scale of possible damage.
“Reasonable efforts” with no acceptance criteria. A best-efforts obligation suits advisory work, but a migration has a measurable result. If the contract has no acceptance criteria, the partner is responsible for effort, not outcome.
An environment in the partner’s accounts. If the partner suggests building the environment “for now” in its own cloud organisation and moving it later, the move may turn out to be a project of its own. Require it to work in yours from day one.
Cloud commitments bought by the partner. Reserved instances or savings plans bought before migration and right-sizing lock in poor decisions for one or three years. Commitment decisions are yours and should be made once workloads have stabilised.
Undisclosed subcontractors. You are entitled to know who has access to your environment. The contract should require your consent to subcontractors, or at least a list of them.
Automatic renewal of support. A hypercare period that silently turns into a one-year managed service contract is a sale hidden inside the migration contract. Ongoing operations may make sense, but it should be a separate decision.
Nothing about data at the end. If the partner had copies of your data on its own media or accounts, the contract should state when and how it deletes them and how it confirms deletion.
When is augmenting your own team better than a turnkey engagement?
Handing the whole migration to a partner makes sense when the company lacks cloud skills and the project is large and one-off. It also has a hidden cost: when the project ends, knowledge of the environment stays mostly with the partner, and your team gets documentation and a few workshops. If the cloud is to become the company’s main platform for years, your team will be the one running, extending and optimising it.
The alternative is a model in which your team leads the migration, augmented by experienced cloud architects and engineers who work inside it day to day. Accountability for the result stays with you, and so does the knowledge. This works well when you already have a few people with infrastructure experience and mainly lack a designer for the target architecture and someone who has run similar migrations before.
At ARDURA Consulting, cloud architects work in this model. According to our published rates, cloud specialists cost EUR 370–835 per day net, depending on seniority and specialisation. Standard onboarding into your team takes two weeks, and 48–72 hours in urgent cases. A two-week satisfaction guarantee applies, with free replacement if the specialist does not meet your expectations. DevOps engineers, who build deployment automation and infrastructure as code, also play a large part in migrations. Polish teams work in CET, which overlaps fully with DACH business hours and leaves a one-hour difference with the UK.
A mixed approach is also possible: the assessment and migration plan as a fixed-price external engagement, and execution by your team supported by external specialists. The choice depends on whether you care more about transferring responsibility or building your own capability. A broader comparison of these two logics is on our page on staff augmentation vs outsourcing.
What are the key takeaways before signing a migration contract?
A cloud migration is a project in which it is easy to buy something other than what you think you are buying. Proposals differ less in rates than in the definition of the service, and the difference only becomes visible at the first failed cutover or the first cloud bill.
Remember six things. First, write your own statement of work with a closed workload list and ask every bidder to price the same document. If you lack the data to write it, start with a separate assessment engagement. Second, attach a responsibility matrix in which your obligations are as specific as the partner’s. Third, define measurable acceptance criteria for each wave: functionality, performance, restore, monitoring, security, cost tags and documentation. Fourth, require a cutover and rollback plan with a point of no return and the decision on your side. Fifth, protect the price with unit pricing, a change request procedure and payment for accepted stages rather than elapsed time. Sixth, make sure accounts, infrastructure code and documentation belong to you from day one, and that your exit plan reflects the rights the Data Act gives you.
If you are weighing whether to run the migration with your own team augmented by experienced specialists or hand it over entirely, see how our cloud architects work or book a call. We will tell you which roles you need at which stage and what they will cost.