{
  "@context": "https://schema.org",
  "@type": "Article",
  "url": "/hire-cloud-consultant/statement-of-work-cloud-projects",
  "markdownUrl": "https://www.desaiinfo.net/kb/hire-cloud-consultant/statement-of-work-cloud-projects.md",
  "publisher": {
    "name": "Desai InfoTech",
    "url": "https://www.desaiinfo.net"
  },
  "type": "article",
  "slug": "statement-of-work-cloud-projects",
  "pillar": "hire-cloud-consultant",
  "order": 5,
  "title": "Statement of Work for Cloud Migration, AI and DevOps Projects (Template Outline)",
  "metaTitle": "Cloud Migration & AI Statement of Work (Template)",
  "description": "What a statement of work for cloud migration, AI and DevOps projects should include - template outline, deliverables, acceptance criteria and change control.",
  "keywords": [
    "cloud migration statement of work",
    "ai consulting statement of work",
    "generative ai project sow",
    "statement of work cloud project",
    "sow template it consulting",
    "devops statement of work",
    "acceptance criteria sow",
    "change control process consulting"
  ],
  "published": "2026-10-17",
  "updated": "2026-10-31",
  "summary": "A statement of work (SOW) for a cloud, AI or DevOps project is the document that defines what will be delivered, how success is measured and how changes are handled. A good SOW states objectives, in-scope and out-of-scope work, deliverables with acceptance criteria, assumptions and client responsibilities, access and security arrangements, schedule, communication rhythm, change control, handover and commercial terms.",
  "keyTakeaways": [
    "Every deliverable needs acceptance criteria that can be checked objectively.",
    "Out-of-scope items and assumptions prevent most later disputes.",
    "Client responsibilities, such as access and timely decisions, belong in the SOW.",
    "A simple change-control process keeps scope changes visible and agreed.",
    "Handover items, such as infrastructure as code and runbooks, should be listed as deliverables."
  ],
  "howTo": {
    "name": "How to write a statement of work for a cloud project",
    "totalTime": "P1W",
    "steps": [
      {
        "name": "State the objectives",
        "text": "Describe the business outcome the project serves and how the client will know it succeeded."
      },
      {
        "name": "Define scope boundaries",
        "text": "List what is in scope and, just as clearly, what is out of scope."
      },
      {
        "name": "List deliverables with acceptance criteria",
        "text": "For each deliverable, write objective checks that confirm it is complete."
      },
      {
        "name": "Record assumptions and responsibilities",
        "text": "Capture assumptions about the environment and what the client must provide, such as access, decisions and test users."
      },
      {
        "name": "Agree schedule, communication and access",
        "text": "Set milestones, reporting rhythm, overlap hours and how secure access to client-owned systems will be granted and removed."
      },
      {
        "name": "Define change control and commercials",
        "text": "Describe how changes are requested, estimated and approved, and the payment model and invoicing schedule."
      }
    ]
  },
  "faqs": [
    {
      "q": "What is the difference between a SOW and a master services agreement?",
      "a": "A master services agreement (MSA) sets the long-term legal terms between two parties, such as confidentiality, liability, intellectual property and payment terms. A statement of work describes one specific project under that agreement, including scope, deliverables, acceptance criteria, schedule and price. Using both means legal terms are negotiated once, and each new project only needs a shorter SOW."
    },
    {
      "q": "How detailed should acceptance criteria be?",
      "a": "Acceptance criteria should be specific enough that both parties can check them without debate, for example \"pipeline deploys to staging and production with an approval gate, and a rollback has been demonstrated\". Avoid subjective criteria like \"works well\". Include who accepts each deliverable, how long they have to review it and what happens if no response is received."
    },
    {
      "q": "What should be out of scope in a cloud project SOW?",
      "a": "Common out-of-scope items include application code changes, licensing purchases, ongoing support after handover, data cleanup, third-party vendor coordination beyond agreed limits, end-user training beyond named sessions and remediation of issues discovered in systems not listed in scope. Listing these explicitly prevents misunderstandings and gives a clear basis for change requests."
    },
    {
      "q": "How does change control work in a consulting project?",
      "a": "Either party raises a change request describing what should change and why. The consultant estimates the impact on effort, schedule and cost, and the client approves or declines in writing before work starts. Approved changes are logged and the SOW is amended. Small changes can be absorbed within an agreed tolerance to avoid paperwork for trivial items."
    },
    {
      "q": "What should a cloud migration statement of work include?",
      "a": "A cloud migration SOW should list every in-scope server, application and database, the migration strategy for each (rehost, replatform, refactor and so on), the wave plan and cutover windows, acceptable downtime, rollback criteria, data validation steps, who performs user acceptance testing, a hypercare period after cutover, and whether decommissioning the old environment is included. Acceptance should be tied to application owners signing off functional tests and a verified backup restore in the new environment."
    },
    {
      "q": "What should an AI consulting statement of work include for an enterprise GenAI automation project?",
      "a": "An AI or GenAI automation SOW should define the business process being automated and a measured baseline, the data sources and permissions the solution may use, data protection and model-provider terms, the evaluation method with an agreed test set and pass thresholds, human review points and guardrails, the pilot and production phases, who pays model and API consumption costs, monitoring and handover of prompts and configuration, and ownership of code, prompts and evaluation data. Acceptance should be based on evaluation results, not on a demonstration."
    }
  ],
  "related": [
    {
      "title": "Consulting Engagement Models: Fixed Price vs Time and Materials vs Retainer",
      "url": "https://www.desaiinfo.net/hire-cloud-consultant/consulting-engagement-models"
    },
    {
      "title": "How to Hire an Azure Consultant (Checklist and Questions to Ask)",
      "url": "https://www.desaiinfo.net/hire-cloud-consultant/how-to-hire-azure-consultant"
    },
    {
      "title": "Agency Subcontracting Partnerships for Cloud, AI and DevOps Work",
      "url": "https://www.desaiinfo.net/hire-cloud-consultant/agency-subcontracting-partnerships"
    },
    {
      "title": "The 7 Rs of Cloud Migration: Choosing a Strategy for Each Workload",
      "url": "https://www.desaiinfo.net/cloud-migration/cloud-migration-strategy-7rs"
    },
    {
      "title": "The Custom Software Development Process, Step by Step",
      "url": "https://www.desaiinfo.net/software-development/custom-software-development-process"
    }
  ],
  "url_path": "/hire-cloud-consultant/statement-of-work-cloud-projects",
  "bodyMarkdown": "A statement of work (SOW) is the most useful document in a consulting engagement. It turns a conversation about goals into a shared, written definition of what will be delivered and how everyone will know it is done. Most consulting disputes trace back to a vague SOW, not to bad intentions. This guide explains what a good SOW contains for cloud, AI and DevOps projects, gives a template outline and shows how to write acceptance criteria and change control. It is part of our guide to [hiring a cloud, AI and DevOps consultant](https://www.desaiinfo.net/hire-cloud-consultant).\n\n## What is a statement of work?\n\nA statement of work is a document, usually under a master services agreement (MSA), that defines a specific project's objectives, scope, deliverables, acceptance criteria, schedule, responsibilities and commercial terms. It is used with every engagement model, from fixed price to time and materials; see [consulting engagement models](https://www.desaiinfo.net/hire-cloud-consultant/consulting-engagement-models).\n\n## What should a cloud project SOW contain?\n\nA good SOW answers what, why, how, when, who and what happens if things change. The outline below works for most cloud, AI and DevOps projects.\n\n### SOW template outline\n\n1. **Parties and references:** names, the MSA or NDA it sits under, version and date\n2. **Background:** current environment and why the project is happening\n3. **Objectives:** the business outcomes the project serves\n4. **Scope:** in-scope work, described by workstream\n5. **Out of scope:** explicit exclusions\n6. **Deliverables:** each with a description and acceptance criteria\n7. **Assumptions:** facts about the environment the plan depends on\n8. **Client responsibilities:** access, decisions, test users, subject-matter experts\n9. **Access and security:** how access is granted, the principle of least privilege, multi-factor authentication, data handling, offboarding\n10. **Schedule and milestones:** phases, target dates and dependencies\n11. **Communication and governance:** status reports, meeting rhythm, overlap hours, escalation path\n12. **Change control:** how changes are requested, estimated and approved\n13. **Acceptance process:** who accepts, review period, how defects are handled\n14. **Handover:** documentation, code, training and knowledge transfer\n15. **Commercial terms:** engagement model, milestones or rates, invoicing schedule and payment terms\n16. **Signatures**\n\n## What deliverables are typical for cloud, AI and DevOps projects?\n\nDeliverables should be tangible outputs, not activities. \"Configure networking\" is an activity; \"hub-and-spoke network deployed from Terraform with documented address plan\" is a deliverable.\n\n| Project type | Example deliverables |\n|---|---|\n| Azure or AWS landing zone | Management group or account structure, policies, hub network, identity and logging, all as code; design document |\n| Cloud migration | Assessment report, wave plan using the [7 Rs](https://www.desaiinfo.net/cloud-migration/cloud-migration-strategy-7rs), migrated workloads, cutover runbooks, post-migration review |\n| CI/CD and DevOps | Pipelines for named applications, branch protection, environments with approvals, secrets in a vault, rollback procedure |\n| Infrastructure as code | Terraform or Bicep modules, remote state, plan-and-apply workflow, README |\n| AI or Copilot rollout | Readiness assessment, data-access remediation plan, pilot configuration, usage policy, adoption plan |\n| Security review | Findings report with risk ratings, prioritized remediation plan, configured baselines |\n\n## What should a cloud migration statement of work include?\n\n**A cloud migration SOW should make the workload list, the migration method and the cutover rules explicit, because those are where migration projects most often go wrong.** Add these sections to the general outline above:\n\n- **Workload inventory:** every server, application and database in scope, by name, with its owner. Anything not listed is out of scope.\n- **Migration strategy per workload:** rehost, replatform, refactor, repurchase, retire or retain, as described in the [7 Rs of cloud migration](https://www.desaiinfo.net/cloud-migration/cloud-migration-strategy-7rs).\n- **Landing zone dependency:** whether the target environment already exists or is built as part of this SOW.\n- **Wave plan and cutover windows:** which workloads move together, on which dates, and inside which maintenance windows.\n- **Downtime and rollback:** the acceptable outage per workload and the conditions that trigger a rollback to the source environment.\n- **Data migration and validation:** how data is copied and synchronized, and how completeness is checked; see the [data migration guide](https://www.desaiinfo.net/cloud-migration/data-migration-guide).\n- **Testing responsibilities:** who writes and runs functional tests and who signs off each workload.\n- **Hypercare:** a defined support period after each cutover, for example two weeks, with response times.\n- **Decommissioning and optimization:** whether shutting down old servers and [post-migration optimization](https://www.desaiinfo.net/cloud-migration/post-migration-optimization) are included or quoted separately.\n\nAn example scope statement: *\"Rehost 14 listed Windows and Linux servers to the client's existing Azure landing zone in three waves between March and May, with cutovers on Saturday mornings, a maximum of four hours of downtime per application, and two weeks of hypercare after each wave. Decommissioning of on-premises hardware is out of scope.\"* The [cloud migration checklist](https://www.desaiinfo.net/cloud-migration/cloud-migration-checklist) covers the tasks behind each of these sections.\n\n## What should an AI or GenAI automation statement of work include?\n\n**An AI SOW needs everything a cloud SOW has, plus clear answers on data, evaluation and cost, because AI output is probabilistic and harder to accept than infrastructure.** For an enterprise generative AI automation project, include:\n\n1. **Process and baseline:** the business process being automated, its current volume, time per task and error rate, so improvement can be measured.\n2. **Data sources and permissions:** which systems, document libraries and fields the solution may read or write, and confirmation that it respects each user's existing access rights.\n3. **Data protection:** how personal and confidential data is handled, where data is processed, retention, and the model provider's terms on data use and training.\n4. **Platform and model choice:** the AI platform and models in scope, and who decides if a model is changed during the project.\n5. **Evaluation method:** an agreed test set built from real examples, how answers are scored, who scores them, and the pass threshold for each phase.\n6. **Human review and guardrails:** which actions need human approval, what the system must refuse to do, and how errors are escalated. Our guide to [AI agents for business](https://www.desaiinfo.net/ai-consulting/ai-agents-for-business) explains common guardrail patterns.\n7. **Phases:** a proof of concept, a limited pilot with real users, and production rollout, each with its own acceptance gate.\n8. **Running costs:** who pays for model, API and hosting consumption during and after the project, and any agreed monthly budget.\n9. **Governance:** alignment with the client's [AI use policy](https://www.desaiinfo.net/ai-consulting/ai-governance-policy-template) and any required security or privacy review.\n10. **Monitoring and handover:** logging, cost and quality monitoring, and documentation of prompts, configuration and evaluation data.\n11. **Ownership:** who owns the code, prompts, evaluation sets and any fine-tuned models.\n\nAcceptance criteria for AI work should be written against the evaluation set rather than a live demonstration:\n\n| Weak criterion | Strong criterion |\n|---|---|\n| Assistant answers policy questions correctly | On the agreed set of 200 real questions, client reviewers rate at least 90% of answers correct and supported by a cited source |\n| Assistant is secure | Testing with three user roles confirms no answer includes content from documents that user cannot open |\n| Automation saves time | Pilot users complete the target task in at least 30% less time than the measured baseline over a four-week pilot |\n\nThe thresholds above are examples; the right numbers depend on the process and its risk. Common out-of-scope items for AI projects are guarantees of accuracy beyond the agreed evaluation, cleanup of poor-quality source data, and ongoing consumption costs after handover. For retrieval-based assistants, the [RAG architecture guide](https://www.desaiinfo.net/ai-consulting/rag-architecture-guide) describes the components the SOW will need to cover.\n\n## How do you write good acceptance criteria?\n\nGood acceptance criteria are objective, testable and agreed before work starts. Each one should let both parties answer \"is this done?\" with yes or no.\n\n| Weak criterion | Strong criterion |\n|---|---|\n| Pipeline is set up | Pipeline builds, tests and scans every pull request; deploys to staging automatically and to production after approval; rollback demonstrated once |\n| Servers migrated | Listed servers running in Azure, application owners have signed off functional tests, backups verified by a test restore |\n| Documentation provided | Architecture diagram, runbooks for listed operations and a recorded walkthrough delivered to the client repository |\n| Copilot is ready | Oversharing report produced, agreed high-risk sites remediated, pilot group licensed and trained |\n\nAlso define the acceptance process: who accepts each deliverable, how many business days they have to review it, how defects are logged and fixed, and whether a deliverable is deemed accepted if no response is received.\n\n## Why do assumptions and client responsibilities matter?\n\nAssumptions and client responsibilities make dependencies visible. A cloud project often stalls not because of technical problems but because access, decisions or test users arrive late.\n\nTypical assumptions:\n\n- The environment matches the inventory provided at scoping\n- Applications support the target platform without code changes\n- Licensing needed for the project is available or will be purchased by the client\n\nTypical client responsibilities:\n\n- Grant named access to client-owned subscriptions, tenants and repositories within an agreed time\n- Provide a project owner who can make decisions within a set number of business days\n- Make application owners available for testing\n- Handle communication with end users and third-party vendors unless stated otherwise\n\n## How should change control work?\n\nChange control should be simple, written and proportionate. The goal is visibility, not bureaucracy.\n\n1. Either party raises a change request describing the change and the reason\n2. The consultant estimates impact on effort, schedule and cost\n3. The client approves or declines in writing\n4. Approved changes are logged and the SOW is amended\n5. Small changes below an agreed threshold can be absorbed without a formal request, but are still logged\n\nFor time-and-materials engagements, change control focuses on reprioritizing the backlog and staying within any monthly cap.\n\n## What should the handover section include?\n\nThe handover section should list the artifacts and knowledge transfer the client will receive, so they are treated as deliverables rather than afterthoughts.\n\n- [ ] Infrastructure as code in client-owned repositories\n- [ ] Architecture diagrams and design decisions\n- [ ] Runbooks for routine operations and incidents\n- [ ] Recorded walkthrough and live question-and-answer session\n- [ ] List of all accounts, service principals and secrets locations\n- [ ] Consultant access removed and credentials rotated\n- [ ] Open issues and recommended next steps\n\n## SOWs for international and subcontracted work\n\nWhen the client or agency is in another country, add overlap hours, communication channels and holidays to the governance section, and attach a data processing agreement where personal data is processed. Agencies subcontracting work can use a short SOW per work package under one master agreement; see [agency subcontracting partnerships](https://www.desaiinfo.net/hire-cloud-consultant/agency-subcontracting-partnerships). For software builds, the [custom software development process](https://www.desaiinfo.net/software-development/custom-software-development-process) describes how requirements feed into scope.\n\nDesai InfoTech writes a SOW for every engagement, from short advisory work to multi-month contracts, and shares a draft for review before anything is signed. See [how to hire an Azure consultant](https://www.desaiinfo.net/hire-cloud-consultant/how-to-hire-azure-consultant) for what to check before signing, or [contact us](https://www.desaiinfo.net/contact) to scope a project."
}