Cloud migration statement of work: what to include and what to ask before signing
The statement of work is the document that defines what the vendor does, how far their responsibility reaches, and what happens when something goes wrong. On an AWS migration, a badly written SOW can cost you months of disputes, work nobody accounted for, or a project that ends half-finished. This guide covers what it must include and what to ask before you sign.
What an SOW is, and why it matters on a cloud migration
A statement of work is a technical contract that sits alongside the commercial one. Where the commercial contract sets price, payment terms and general conditions, the SOW sets the technical scope: which systems migrate, under what methodology, against what acceptance criteria, and with responsibilities split between vendor and company.
On AWS migrations the SOW matters even more, because there are several grey areas. Who configures the AWS accounts? Who buys the licenses? Who validates that the application works in the new environment? What happens if there is unplanned downtime during cutover? Without a clear SOW, every one of those questions can turn into a conflict.
The 7 sections that cannot be missing
Detailed scope: what moves and what does not
The SOW must list the systems in scope explicitly: servers, databases, applications, environments (production, staging, development). The exclusion list matters just as much — what stays out of the project. Without it, any system can turn into “while you are at it, can you move this one too?” at no extra charge.
Acceptance criteria per phase
How do both sides know a phase is done? Acceptance criteria have to be objective and verifiable: “the application responds in under 2 seconds in the new environment under a load of X users”, “regression tests pass 100%”, “the automated backup runs successfully for 3 consecutive days”. Without clear criteria, the vendor can declare a phase complete while the company disagrees.
Split of responsibilities (RACI)
Who does what. A typical AWS migration has shared tasks that cause friction when they are left undefined: access to source systems, database credentials, coordination with the current datacenter provider, user acceptance testing, internal communication to company teams. The SOW should state who is responsible for each item, who approves and who executes.
Cutover and rollback plan
The SOW must describe how the cutover runs: time window, step-by-step procedure, success criteria, and what happens if something fails. The rollback plan matters as much as the migration plan — if a critical problem shows up mid-cutover, the team needs to know exactly how to return to the previous environment without improvising under pressure.
Costs included and costs excluded
The vendor fee is one thing. AWS costs during the project are another. The SOW should make clear: who pays the AWS costs while migrating (test instances, data transfer, DMS)? Are software licenses included? What happens with costs that exceed the estimate? On a project spanning several months, the AWS costs of the project itself are usually a line nobody budgeted, and they show up on next month’s bill.
Post-migration warranty period
Production problems do not always appear on cutover day. Many surface in the first or second week under real load. The SOW should define a warranty period — typically 2 to 4 weeks — during which the vendor handles migration-related problems at no extra cost. Without that clause, any post-cutover incident can turn into an additional charge.
Documentation deliverables
When the migration ends, the company should receive documentation that lets it operate without depending on the original vendor. A reasonable minimum: updated architecture diagram, runbooks for basic operations, inventory of the AWS resources created, and alerting and monitoring configuration. If the SOW does not list these deliverables, you very likely will not get them.
10 questions to ask before signing
Beyond the text of the SOW, these questions reveal whether the vendor has real experience or is selling capabilities they do not have:
- Have you done migrations with AWS DMS before? If they are moving production relational databases, they need experience with Change Data Capture. Without CDC, downtime can run into hours instead of minutes.
- Do you have AWS Business or Enterprise Support? If a problem with an AWS service comes up mid-migration, support response time can decide whether the project stalls for hours or for days.
- How do you handle a late discovery? It is normal for the assessment to surface systems or dependencies that were not in the initial inventory. How is that scope change handled? Is it billed separately? Does the timeline extend?
- Who executes the project — the salesperson or a subcontractor? At some firms whoever sells is not whoever delivers. Ask directly who will be on the project day to day, and ask to speak with that person before signing.
- What happens if the project runs past the agreed timeline? Is there an extra cost per additional week? Is it renegotiated? Settling this beforehand avoids an awkward conversation if the project stretches.
- Do the AWS credentials stay with the company or with the vendor? When the project ends, the AWS account and every credential should be in the company’s hands, not the vendor’s. Some vendors create the accounts under their own name, and that creates dependency.
- How many QA and testing hours are included? Testing in the new environment takes real time. If the SOW does not specify testing hours, that time is probably not budgeted, and the vendor will either rush it or bill it separately.
- Does the price include AWS costs or only the fees? This confusion is more common than it sounds. Clarify whether the SOW value covers only the vendor’s work or also the AWS services consumed during the project.
- What monitoring is left configured at the end? A successful migration includes CPU, memory, availability and cost alerts configured in CloudWatch. If the vendor does not bring this up on their own, ask directly.
- Can you show a similar project you completed? You do not need a published case study — a reference contact at a previous client is enough to verify real experience.
Warning signs in an SOW
These elements should make you pause before signing:
- Scope described in vague terms: phrases like “infrastructure migration to AWS” without listing specific systems are a guarantee of future disputes.
- No documented rollback plan: any vendor with real experience has a plan B. If they do not mention it, it is because they have not thought it through.
- A timeline with no intermediate milestones: an SOW that says “delivery in 8 weeks” with no checkpoints makes it impossible to catch problems in time. Weekly or per-phase milestones are the norm on well-run projects.
- No mention of handover documentation: if the SOW does not list what documentation you receive at the end, you will probably receive nothing.
- A price far below market: a serious migration of 5 to 10 servers with databases takes between 6 and 12 weeks of work. If the price implies the vendor would work 2 weeks, something does not add up — either the scope is smaller than you think, or they will move very fast without the testing the job needs.
How to size the effort without a number
Instead of asking what a migration costs, ask what drives the cost. Three things move the number more than anything else, and you can assess all three before requesting a single quote:
- How many systems have real dependencies between them. Ten independent servers are far simpler than four that talk to each other constantly. Dependencies, not count, drive the effort.
- Whether production databases have to move with minimal downtime. This is usually the single biggest factor. Moving a database that can be offline for six hours is a different project from one that can only stop for fifteen minutes.
- How much of the application has to change. A pure rehost touches no code. The moment sessions, file storage or hardcoded addresses need reworking, you are looking at a different scope.
Answering those three before you talk to vendors also gives you a way to compare quotes: if two proposals differ a lot, it is usually because they read these three answers differently — not because one is cheaper.
Evaluating vendors for a migration?
At CloudTing we hand over a detailed SOW with scope, acceptance criteria, rollback plan and documented deliverables before any project starts. If you want us to look at your case, book a call at no cost.
Talk to an engineer →