Cloud DevOps Migration Statement of Work Template

Count everything. A deliverable a client cannot count is a deliverable a client can expand.

1. 2.1A discovery report for the 9 workloads listed in Appendix 1, covering dependencies, data volumes and target architecture.
2. 2.2A landing zone in the client's AWS Organization: 4 accounts (shared services, dev, staging, production), IAM Identity Center, guardrail SCPs and centralized logging.
3. 2.3Terraform modules for networking, compute (ECS Fargate), RDS PostgreSQL and S3, stored in the client's GitHub organization.
4. 2.4GitHub Actions pipelines for the 9 workloads with build, test, image scan and deploy stages to dev, staging and production.
5. 2.5Migration of workloads in 3 waves with one rehearsal and one production cutover per wave inside agreed maintenance windows.
6. 2.6CloudWatch dashboards and alarms for the golden signals of each workload, routed to the client's on-call tool.
7. 2.7Runbooks, architecture diagrams and two 90-minute knowledge transfer sessions.

Name what the engagement does not include. These are the lines your PMs will cite most often.

1. 3.1Refactoring application code, other than configuration changes needed to read environment variables and secrets.
2. 3.2Workloads, databases or file shares not listed in Appendix 1.
3. 3.3Kubernetes, service mesh or multi-region active-active architecture.
4. 3.4Cloud consumption costs, reserved instance purchases and third-party license fees.
5. 3.524x7 operations, managed service or on-call coverage after hypercare.
6. 3.6Compliance certification work (SOC 2, HIPAA, PCI DSS). Controls are configured to the client's documented requirements only.

The target architecture includes one revision round after the discovery report. After architecture sign-off, changes to services, regions, account structure or tooling are changes, because they affect modules already in build.

Acceptance needs a measurable test and a window. Without both, delivery never formally ends.

1. 5.1Each workload passes the client's smoke test checklist in production after cutover.
2. 5.2Terraform plan shows no drift against the deployed environment at handover.
3. 5.3Pipelines deploy a tagged release to each environment without manual steps.
4. 5.4Hypercare of 10 business days ends with no open severity 1 incidents caused by the migration.

Tie each dependency to a date so a late input has a known effect on the schedule.

1. 6.1The client provides read access to source systems and a technical owner for each workload during discovery.
2. 6.2Application teams fix code defects found during migration testing within the wave schedule.
3. 6.3Maintenance windows are approved at least 10 business days before each cutover.
4. 6.4Source databases are under 2 TB each and support native replication or a dump and restore within the window.

A change is any new workload, environment, region, account, compliance requirement or tooling swap, or code refactoring beyond configuration. The consultancy issues a change order within three business days with the affected wave, estimated hours, cost and revised cutover dates. Cutover dates move only by approved change order or by a missed client dependency, which the consultancy will document in writing at the time.