Cumberland Valley's workloads run in Cheatham Mutual's data center and must leave it by September 30, 2024, when TS-05 exits. ACME Health has no production cloud footprint. This strategy sets out how a first-time cloud organization moves an acquired estate onto Microsoft Azure inside twelve months, which of the six migration treatments applies to what, where the service-model boundary falls, and who actually operates the result. Approved September 11, 2023, before closing.
The condition that shapes every decision in this document: a first-time cloud organization under a hard deadline is in the worst possible position to learn cloud. You cannot wait for the organization to mature, because the data center exit is contractual. You cannot pretend maturity exists, because the first incident will prove otherwise in front of a regulator. Everything below is an attempt to reach a fixed date without pretending to be more capable than we are — which mostly means choosing the boring option and refusing the interesting one.
Table of Contents
Part I — Scope and Models
Part II — Treatment
Part III — Operating and Risk
1. What Is Actually Moving
This program does not migrate ACME's estate to the cloud. It migrates what must leave Cheatham Mutual's data center, and it does so once. That boundary is worth stating plainly, because "we are moving to the cloud" is how a twelve-month integration becomes a three-year transformation. ACME's own systems have a separate modernization roadmap on a slower clock, outside this program's scope and budget.
The scope question has a second half that is less obvious. Cumberland Valley's workloads must leave the parent's data center regardless. They could go to ACME's existing on-premises estate instead of Azure — and that option was rejected, because it would mean migrating the same workloads twice: once to survive the TSA exit, and again when ACME's own modernization reaches them.
| In scope | Out of scope |
|---|---|
| Cumberland Valley workloads currently hosted by Cheatham Mutual | ACME's existing on-premises estate |
| The Azure landing zone: accounts, network, identity, guardrails, logging | Modernization of applications ACME already runs |
| The enterprise data warehouse, built new in Azure per AD-20 | Optimization and cost tuning beyond the FinOps foundation |
| FinOps foundation — tagging, showback, reservation posture | Container platform, service mesh, and similar capability the program does not need |
2. Two Decisions, Not One
"How are we doing cloud" is two questions that get conflated, and conflating them is how organizations end up with a contract that does not match the architecture.
| Decision | What it determines | Our answer |
|---|---|---|
| Service model | Where Microsoft's responsibility ends and ACME's begins. IaaS, PaaS or SaaS. | IaaS-primary, PaaS for databases. Follows from rehost-first. |
| Operating model | Who actually runs the part ACME is responsible for. Fully managed, co-managed, or self-managed. | Co-managed with Rutherford Cloud Operations, on a contracted step-down. |
The operating model sits on top of the service model, not instead of it. Choosing IaaS does not tell you who patches the operating system — it tells you that somebody on ACME's side of the line must. Choosing co-managed does not change where Microsoft's responsibility ends. A great many "cloud strategy" arguments are really two people answering different questions.
3. Service Model — Where the Boundary Falls
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical, facility, hardware | Microsoft | Microsoft | Microsoft |
| Virtualization, host | Microsoft | Microsoft | Microsoft |
| Operating system, patching | ACME | Microsoft | Microsoft |
| Runtime, middleware | ACME | Microsoft | Microsoft |
| Application configuration | ACME | ACME | Vendor |
| Identity and access | ACME | ACME | ACME |
| Data, and its classification | ACME | ACME | ACME |
Read the last two rows across. Identity and data never move to the provider under any service model. Whatever else is outsourced, ACME remains accountable for who can reach protected health information and for what happens to it. The most expensive misunderstanding available in healthcare cloud adoption is the belief that moving to a managed platform moves the compliance obligation with it. It does not, and a regulator will not accept that reading.
IaaS-primary is a consequence of the rehost-first position in Section 4 rather than an independent preference. Databases go to managed PaaS services because that is where the operational burden reduction is largest for a team with no cloud experience, and because it removes patching and backup responsibilities that would otherwise land on people learning the platform.
4. The Six Rs, and the First-Timer Position
| Treatment | What it means | Position for a first-time organization under a clock |
|---|---|---|
| Rehost | Move as-is. Lift and shift. | The default, and most of the estate. Fastest, lowest risk, and the only treatment whose duration can be estimated with any confidence by a team that has not done this before. |
| Replatform | Move with targeted change — typically database to a managed service. | Selectively. Where it removes operational burden the team is not ready to carry. Not for its own sake. |
| Repurchase | Replace with a commercial service. | Where the application is being retired anyway. Free of migration cost by definition. |
| Refactor | Rebuild to use cloud-native services. | ⚠ Almost nothing. See Section 6. |
| Retire | Do not move it. Turn it off. | Per the Application Disposition Matrix. The cheapest migration is the one you do not perform. |
| Retain | Leave where it is, for now. | Not available here. The data center exit is contractual — there is no "where it is" to retain. |
The position in one line: rehost to hit the TSA date, optimize afterward. It is an unglamorous answer and it is the right one. Cloud cost optimization, cloud-native re-architecture and platform modernization are all real benefits — and all of them are available in month eighteen, twenty-four or thirty-six, when the contractual clock has stopped and the organization has operated the platform long enough to know what it is doing. None of them are available in month eleven, and pursuing them there puts the data center exit at risk to obtain a benefit that was never time-critical.
The "Retain" row is worth pausing on, because it is normally the safety valve. In most cloud programs, anything difficult can be left on-premises and revisited. Here it cannot: the premises belong to the company ACME just bought the business from, and the lease on that arrangement expires. Removing the retain option removes the usual escape hatch, which is precisely why the rehost bias has to be aggressive.
5. Treatment by Workload
Treatment follows the disposition decided in the Application Disposition Matrix. An application being absorbed into ACME's platform is not migrated to Azure at all — its function moves and the instance is retired.
| Workload group | Treatment | Service model | Reasoning |
|---|---|---|---|
| Core administration platform, and the applications absorbed into ACME's estate | Retire | — | Function moves to ACME's platform per disposition. No cloud migration; the instance is decommissioned at cutover. |
| Care management platform (preserved, AD-07) | Rehost | IaaS | Survives as the go-forward system, so it must leave the parent's data center intact. Rehost preserves configuration and the care model with it. |
| Application databases | Replatform | PaaS | Managed database services remove patching, backup and high-availability burden from a team that has never carried it. |
| Integration layer and interfaces | Rehost | IaaS | Built new for coexistence, hosted on IaaS for control during a period when interfaces change frequently. |
| Enterprise data warehouse (AD-20) | Build new | PaaS | ⚠ The one genuinely new build. Constructed in Azure rather than lifted, because it was being rebuilt regardless — and it carries its own recovery obligation. |
| File shares, print services, utility servers | Rehost | IaaS | Unglamorous, numerous, and the source of most schedule surprise. Inventoried early. |
| Standalone regulatory filing tool (AD-22) | Retire | — | The function ends with the entity. Nothing to move. |
The data warehouse row carries an obligation the other rows do not. Everything else being rehosted inherits an existing backup regime and a tested recovery position, however imperfect. A new build inherits nothing. Its recovery tiering, retention and tested-restore gate conditions are set out in the disposition matrix and must be satisfied before go-live — a new system in a regulated health plan without a demonstrated recovery position does not pass a gate.
6. What We Are Deliberately Not Doing
6.1 Refactoring
Refactoring is where first-time cloud programs die, and the mechanism is always the same. The team discovers that lifting a workload as-is feels wasteful — the application does not use managed services, the architecture is not elastic, the cost profile is unflattering. All true. So a rehost with a known duration is replaced by a rebuild with an unknown one, performed by people who have not built on this platform before, against a contractual deadline they cannot move. The estimate that was uncertain becomes an estimate that is fictional, and the discovery happens in month nine. This program refactors nothing that is not already being rebuilt for an independent reason.
6.2 Other deliberate omissions
| Not doing | Reasoning |
|---|---|
| Containerizing rehosted workloads | Adds a platform the operations team must also learn, during the period they are learning Azure itself. |
| Multi-region active-active | Cost and complexity disproportionate to the recovery tiers actually required. Paired-region backup meets the obligation. |
| Multi-cloud | A second provider doubles the shared-responsibility surface for an organization that has not yet operated one. |
| Cost optimization beyond the FinOps foundation | Optimization needs consumption history to optimize against. Month one is the wrong time; the foundation is what matters now. |
| Retiring the mainframe | Out of scope entirely — it is ACME's, it is not moving, and it is not this program's problem. |
7. Operating Model — Co-Managed, with a Step-Down
ACME will operate an Azure estate it has never operated, immediately, at production scale, for a regulated business. The three available arrangements were assessed against that condition.
| Arrangement | Attraction | Why rejected or chosen |
|---|---|---|
| Fully managed | Capability available immediately; ACME carries no operational burden | Rejected. ACME never builds the capability, so at the end of the term it is exactly where it started — and it would be exiting a TSA dependency straight into a vendor dependency it never planned to exit. That is a rename, not a solution. |
| Self-managed | Full control; no vendor margin; capability owned outright | Rejected. No production cloud experience, and the skills gap is a live risk with an owner. Learning cloud operations during a migration under a contractual wall is the worst available timing. |
| Co-managed | Capability now, capability later | Chosen — but only with the step-down in 7.1. Without it, co-managed becomes fully managed by default. |
7.1 The step-down — the provision that makes it work
A co-managed arrangement with no contracted step-down is a fully managed arrangement with optimistic language. Everyone intends to build internal capability; nobody has time during a migration; the MSP is competent and available; and eighteen months later the capability is exactly where it was on day one, with a renewal on the desk. The step-down is therefore a contractual schedule with named milestones, not a statement of intent — the same lesson the TSA teaches about knowledge transfer, applied to the vendor we are choosing rather than the one we inherited.
| Period | Arrangement |
|---|---|
| Months 1–6 | MSP operates; ACME staff embedded and shadowing |
| Months 7–12 | Shared on-call; ACME leads business hours, MSP nights and escalation |
| Months 13–18 | ACME operates; MSP advisory and escalation only |
| Month 19 onward | ACME self-sufficient; MSP retained for surge and specialist work |
Acceptance mirrors the TSA convention: at each step-down boundary, ACME staff perform and the MSP observes. A demonstration by the MSP proves the MSP is capable, which was never in question.
7.2 Contractual provisions this arrangement requires
- Business Associate Agreement with the MSP — they will hold administrative access to systems processing protected health information
- Step-down schedule as a contractual exhibit, with acceptance criteria per boundary
- Responsibility matrix as a contractual exhibit — see Section 8
- Exit and transition-out terms, including configuration and runbook handover in usable form. ⚠ The lesson of this entire program is that exits must be designed at the start.
- Right to audit, and evidence rights sufficient to satisfy a regulator
- Subcontractor flow-down — the MSP's subcontractors need equivalent obligations
- Personnel continuity for named roles through the step-down, since the transfer depends on the same people being present
8. Three-Party Shared Responsibility
Shared responsibility between two parties has seams. Between three it has more of them, and every seam is a place where each party assumes another has it. Microsoft holds the platform below the service-model line. Rutherford Cloud Operations holds day-to-day operations above it during the early step-down phases. ACME holds accountability throughout and operations increasingly over time. In healthcare, a gap between those three is not a service problem — it is an unowned control, and an unowned control on protected health information is a breach waiting for its occasion.
| Function | Microsoft | MSP | ACME |
|---|---|---|---|
| Physical and platform security | Owns | — | Verifies via attestation |
| Operating system patching | — | Performs | Sets policy, accepts risk on exceptions |
| Backup execution | Provides service | Configures and runs | Sets RTO/RPO, ⚠ owns the restore test |
| Identity and access administration | Provides service | Executes requests | Owns — approval, recertification, privileged access |
| Security monitoring and response | Platform telemetry | Monitors and triages | Owns incident declaration and regulatory notification |
| Data classification and handling | — | — | Owns, entirely |
| Cost management | Provides tooling | Reports | Owns decisions |
| Regulatory accountability | — | — | Owns, entirely and permanently |
Two rows in this table are the ones to defend in an interview. ACME owns the restore test even though the MSP runs the backups — because a party that configures backups and also certifies they work is grading its own homework. And ACME owns incident declaration and regulatory notification even though the MSP does the monitoring — because declaring an incident starts a regulatory clock, and no vendor should ever hold the decision about when a covered entity's clock starts.
9. Programmatic Risks That Are Not Technical
The risks that damage first-time cloud programs are rarely engineering problems. They are omissions of things that had to happen before migration and were treated as things to sort out during it.
| Risk | What goes wrong | Mitigation |
|---|---|---|
| No landing zone | Workloads migrated into an unstructured subscription; network, identity, guardrails and logging retrofitted around live systems | Landing zone before any wave. A hard sequencing rule, not a preference. |
| No FinOps | Consumption grows for months untagged and unattributed; the first large invoice arrives with no way to allocate it | Tagging standard, showback and reservation posture established before volume, not after the invoice |
| Egress and bandwidth math | ⚠ Years of claims history do not fit through the available circuit inside the migration window — discovered in month eight | Volumetrics calculated at planning, not at execution. Physical transfer appliances budgeted for the historical estate. |
| Shared responsibility misunderstood | A control everyone assumed the platform provided is not provided | Section 8 as a contractual exhibit, reviewed by Security and Compliance rather than by Infrastructure alone |
| HIPAA in cloud | Protected health information in a region or service the BAA does not cover | BAA scope confirmed for the enlarged population; encryption in transit and at rest; regulator-grade evidence retained |
| Skills gap | Treated as a training line item rather than a risk; surfaces as slow incident response | ⚠ A risk register entry with a named owner, mitigated by the co-managed step-down and measured at each boundary |
The egress row is the one that most often surprises a schedule, because it is arithmetic nobody does until it is late. Claims history for a health plan is not a database of convenient size; it is decades of transactions, images and correspondence, and the circuit between the parent's data center and Azure was sized for the parent's business, not for a one-time bulk evacuation of it. The volumetrics either fit the window or they do not, and that is knowable on day one with a spreadsheet — which is why physical transfer appliances are in the plan rather than in a change request.
The skills gap is listed last and is arguably first. Every other row on this table is a thing to do. This one is a condition the organization is in, and it does not resolve because a migration completed — it resolves because people operated the platform, made mistakes on it, and were still there afterward. That is what the step-down in Section 7.1 is actually buying, and it is why the step-down has acceptance criteria rather than dates alone.
Related artifacts: 7 — Due Diligence Findings (DD-05) · 8 — Consulting SOW & Engagement Model · 20 — Application Disposition Matrix · 21 — Vendor & Contract Disposition Matrix · 22 — TSA Schedule & Exit Plan (TS-05) · 28 — Risk Register · 34 — Cloud Landing Zone Design · 35 — Cloud Migration Wave Plan