Delivery models
Choose an Azure delivery model that matches scope, ownership, and change risk.
Sense Cloud structures work as a fixed assessment, architecture and build assignment, migration wave, handover, dedicated team, or managed-service onboarding with explicit roles, gates, and artifacts.
Delivery assurance
- 01DiscoverGateScope agreedArtifactCurrent-state brief
- 02DesignGateArchitecture acceptedArtifactADR and topology
- 03BuildGateChange reviewedArtifactVersioned modules
- 04ValidateGateControls passArtifactTest results
- 05ReleaseGateReadiness acceptedArtifactRunbook and rollback
- 06OperateGateOutcome reviewedArtifactService review record
- Models
- Project or teamBounded outputs, workload waves, retained teams, and managed onboarding.
- Control
- RACI and gatesAuthority and acceptance are established before change.
- Transfer
- Built inCustomer participation starts during discovery and build.
Delivery options
Different cloud objectives need different commercial and team structures.
The statement of work identifies the model, scope unit, outputs, assumptions, and customer roles.
Fixed assessment
A named estate and question produce a baseline, findings, target options, and sequenced recommendations.
Architecture and build
A defined capability moves from design through infrastructure code, configuration, testing, and technical transfer.
Migration wave
A named workload group moves through discovery, preparation, rehearsal, cutover, stabilization, and closure.
Dedicated team
Named engineering roles deliver against a jointly managed backlog within agreed technical and commercial boundaries.
Managed onboarding
Named Azure resources enter a service catalogue after access, monitoring, ticketing, escalation, and runbook readiness checks.
Delivery stages
Every model uses gates suited to its change exposure.
A fixed assessment has lighter implementation controls than a production cutover, but both retain scope and acceptance clarity.
- 01
Mobilize
Confirm scope, RACI, stakeholders, access, environments, tools, assumptions, risks, schedule, and change constraints.
- 02
Design
Validate requirements, compare feasible options, document architecture, estimate consumption, and agree build acceptance.
- 03
Build or execute
Deliver increments through approved repositories, CI/CD, configuration controls, tests, and change procedures.
- 04
Accept and transfer
Resolve critical defects, complete artifacts, run knowledge sessions and exercises, transfer access, and assign remaining work.
Delivery gates
Gates name the authority, inputs, and result for material transitions.
The customer retains business and production-change authority unless the agreement states otherwise.
| Area | Required inputs | Result | Typical authority |
|---|---|---|---|
| Scope gate | Objective, boundary, assumptions, RACI, access | Mobilized assignment | Sponsor and delivery leads |
| Architecture gate | Requirements, options, target design, risks, cost factors | Approved build basis | Customer architecture authority |
| Change gate | Test results, runbook, monitoring, rollback, communications | Authorized production change | Customer change authority |
| Handover gate | Artifacts, access, runbooks, training, open items, acceptance | Transferred ownership or activated service | Customer service owner |
Delivery artifacts
A compact artifact set follows the work from mobilization to transfer.
Artifacts live in agreed customer-accessible systems and are proportionate to risk.
- 01
Engagement brief and RACI
Objectives, scope, exclusions, stakeholders, roles, assumptions, dependencies, access, schedule, and escalation.
- 02
Architecture and backlog
Requirements, target design, service choices, risks, work items, acceptance criteria, and technical ownership.
- 03
Build and change record
Repositories, module versions, test results, release references, configuration, runbooks, rollback, and defects.
- 04
Handover record
Transferred assets, knowledge sessions, exercises, access changes, support boundary, accepted items, and remaining work.
Buying guide
Select the model by uncertainty, production exposure, and ownership needs.
Discovery may be the first paid stage when inputs are insufficient for a responsible build estimate.
Best suited to
- Bounded assessments or builds
- Multi-wave programmes
- Teams needing specialist Azure capacity
- Managed-service transitions
Needed to begin
- Named sponsor and customer lead
- Scope unit and expected outputs defined
- Access, security, procurement, and change constraints available
Customer responsibilities
- Provide timely approvals and specialists
- Retain business priorities and production authority
- Accept transferred assets and remaining-work ownership
Not included by default
- Unbounded transformation under a fixed assessment
- Production change without customer authorization
- Managed support implied by a project handover