Statement of work: Claims data platform migration
Statement of work template under a master agreement
Ardent Analytics migrates Coastline Insurance’s claims database to a cloud platform over 18 weeks under SOW-2026-041, governed by a master services agreement dated 3 March 2026. The work is time and materials with four roles priced by the day and a $394,000 estimate before GST, five dated deliverables, ten business days to accept each one, and five assumptions written down before anyone starts.
The document, page by page
Every page as it renders and as it prints, with nothing summarised. Read the wording before you reuse it.
Section by section
What each section is for, so you can keep the ones you need and drop the rest.
- Document control
- SOW number, client, supplier, effective date, the MSA it sits under, the 18 week term and a contact on each side.
- Background
- Why the claims database is moving and which agreement governs the engagement.
- Scope of work
- Five activities from discovery and data mapping to tooling, a parallel run and cutover.
- Deliverables
- Five items with format, owner and the week each is due.
- Indicative schedule
- Five phases across 18 weeks, from discovery in weeks one and two to go live in week 18.
- Fees and charges
- Four roles with a day rate and estimated days, totalling $394,000 excluding GST.
- Acceptance criteria
- Ten business days per deliverable, deemed acceptance on silence, and a verified cutover for the migration itself.
- Assumptions, dependencies and change control
- Five conditions the estimate relies on, and the MSA change request process for anything outside scope.
- Execution
- Signature lines for both companies.
Clauses in this document
- Acceptance testing clause: deciding when the work is done
- Background IP clause
- Change control clause: requesting, pricing and approving a scope change
- Confidentiality clause
- Delivery clause: where, when and how the handover happens
- Extension of time clause: moving the completion date fairly
- Liquidated damages clause
- Milestone payment clause: paying by stage
- Reporting obligations clause: what the supplier must tell you, and when
- Scope of work clause: what the price includes and excludes
- Time is of the essence clause: when a missed date ends the deal
- Transition assistance clause for outsourcing exits
- Warranty clause: promising a standard and backing it
Who this is for
A consultancy or agency working under a signed master agreement with a client, where each new piece of work needs its own scope but not its own legal terms. If there is no master agreement in place, this document is not enough on its own and a service agreement has to come first.
How to adapt this document
For a fixed price SOW, replace the rate card and the estimate with a price and a payment schedule tied to the same deliverables, so the money and the acceptance points line up. Keep the assumptions section either way, and make it specific: how many environments, whose data, which teams are available and when. Assumptions are the only part of an SOW that protects you when a project slips for reasons on the client side, and a list of vague ones protects nobody.
What it leaves out
No liability cap, no confidentiality clause, no insurance requirement, no termination rights and nothing about who owns the work. All of that sits in the master agreement this SOW hangs off, which is the whole point of splitting the two documents. If you send this to a client who has not signed a master agreement, they are agreeing to a scope with no legal terms behind it, and the first thing their lawyer will do is ask for the rest.
What makes this document work
Acceptance has a clock
Ten business days to review each deliverable and silence counts as acceptance, with the final migration accepted on a verified cutover. That clause prevents most invoice disputes.
Every fact is on page one
SOW number, client, supplier, effective date, MSA reference, term and both contacts sit in one block, so the document can be filed under the MSA and found again.
Assumptions are listed
Client access, a stable source schema, a target platform ready by phase two, client run UAT and change control for anything else. Each turns a delay into a variation instead of a fight.
Questions people ask
What is the difference between an SOW and a proposal?
A proposal sells the work and is written for someone deciding whether to buy. A statement of work defines it for delivery: scope clauses, named deliverables, acceptance criteria, rates, assumptions and what happens when an assumption turns out to be wrong. The same project usually needs both, and the SOW is the one that gets read during the argument.
Should an SOW include rates or a fixed price?
Either, as long as it says which and the customer cannot mistake one for the other. This example is time and materials with a rate card and a total estimate, which suits a migration where the shape is known and the volume is not. A fixed price suits work you have done before. What does not work is a rate card next to a total with no word saying whether the total is a cap.
Who signs a statement of work?
Someone authorised on each side, usually under an existing master agreement that carries the legal terms.
What makes an SOW go wrong?
Vague deliverables and no acceptance process. Both are handled explicitly in this example.
What is the difference between an SOW and an MSA?
The master services agreement carries the legal terms once: liability, confidentiality, insurance, termination, who owns the output. The SOW carries only this piece of work: what is being built, by when, for how much. That is why this document is short and names SOW-2026-041 under an existing master agreement rather than repeating twenty pages of terms.
What do acceptance criteria need to say?
Who tests it, against what, within how many days, and what happens if they say nothing. The last part matters most: without a deemed acceptance window, a deliverable can sit untested for months while the invoice waits behind it. This example names the reviewer and the window for each deliverable.
How do you handle a change mid project?
Through the change control clause, as a written variation to this SOW rather than an email agreement. Price it, say what it does to the dates, and have the same people sign it. A project that ends in dispute almost always has three or four changes that everyone remembers differently.
Build your own in about a minute
The button below opens the generator with this use case already described. Change the wording to match your own, generate, then edit anything you like.
Make one like thisOther document examples
Landscaping contract template with a plant schedule and an establishment period
A garden build is two jobs in one: construction that is finished when it is finished, and planting that is only finished three months later. This contract prices the construction in four stages, lists every plant with its pot size and quantity, and holds the landscaper to a 90 day establishment period for anything that dies.
Software development agreement with sprints and an acceptance test
Custom software goes wrong in the space between delivered and accepted, where one side thinks a sprint is finished and the other is still writing a list. This agreement fixes a ten business day acceptance window against criteria written before the sprint started, and assigns the intellectual property sprint by sprint as each invoice is paid.
Event planning contract with a vendor table and a spending limit
Most event disputes are really one of two arguments: who was actually contracted to the caterer, and who approved the extra $3,000. This contract answers both on the first two pages, with a vendor table that names the contracting party on every line and a spending limit the planner cannot quietly exceed.
Want the steps in the builder? Read Create a document with AI, then Send a PDF for e-signature. For everything this generator can do, see the document maker.
Written and checked by the OneCraft team. Last checked .