Managed cloud architecture is the combination of workload design and operating responsibilities that lets a team use cloud services without losing accountability. A migration is incomplete if applications run in a new provider but nobody can explain identity, network boundaries, backups, service objectives, cost, incident ownership or exit. The Microsoft Cloud Adoption Framework separates strategy, planning, readiness, migration, governance, security and management; that sequence is useful across providers because it prevents “move” from consuming the entire program. Use the checklist below per workload and per managed service, then retain evidence that the operating team can actually execute.
Start with workload and service boundaries
Define the business service, its owner, users, critical data, availability need, recovery objective and material dependencies. Break the application into things the team operates and things a provider operates. “Managed database” does not transfer responsibility for schema design, data classification, access grants, backup policy or recovery testing. Document provider, region, service tier, support plan and the exact control boundary. The managed cloud architecture guide helps turn that shared-responsibility statement into an actionable system map.
| Architecture area | Platform team owns | Workload team owns |
|---|---|---|
| Identity | Federation, privileged access and account lifecycle | Application roles and least-privilege requests |
| Network | Shared connectivity, DNS and egress guardrails | Service endpoints and dependency rules |
| Observability | Collection, retention and common routing | User journeys, SLOs and actionable alerts |
| Recovery | Backup platform and regional patterns | Data criticality, restore order and reconciliation |
| Cost | Billing hierarchy, tags and allocation feeds | Demand, architecture choices and unit economics |
Prepare a landing zone before migration waves
A landing zone provides repeatable account or subscription structure, identity, connectivity, policy, logging, security and automation. Microsoft’s current landing-zone guidance distinguishes a centrally managed platform foundation from application landing zones owned by workload teams. Create the smallest foundation that can enforce non-negotiable controls while allowing product teams to deploy through code. Test subscription vending, log delivery, emergency access, network isolation and policy exceptions in non-production. Avoid delaying every migration for an imagined perfect platform; publish versioned capabilities and a backlog of known gaps.
Sequence migration waves from dependencies
Discover runtime, data, identity, batch, partner and operational dependencies before assigning dates. Microsoft’s migration planning guidance recommends grouping directly connected components and moving non-production before production. Choose an early workload that is representative enough to test the foundation but not so critical that the organization cannot learn. For each wave, record migration method, data transfer, performance baseline, cutover window, rollback boundary, support coverage and acceptance owner. The pre-migration architecture planning guide provides a detailed discovery route.
| Gate | Question to answer | Evidence |
|---|---|---|
| Discover | Do we know owners, users, data and dependencies? | Inventory and dependency map |
| Ready | Can the landing zone enforce and evidence controls? | Policy, identity and logging tests |
| Rehearse | Can data and service move within the window? | Timed non-production migration |
| Cut over | Are health and business outcomes acceptable? | SLO, transaction and reconciliation checks |
| Stabilize | Can the operating team support normal and failed paths? | Incident, restore and cost review |
| Exit legacy | Are records retained and dependencies removed? | Decommission approval and access closure |
Design recovery and service objectives together
A backup policy is not recovery evidence. Set recovery time and recovery point needs from business consequence, then test restore into an isolated environment with identity, dependencies and runbooks. Reconcile transactions created around the failure boundary. Define service-level indicators users can feel and set an objective that leaves room for planned change; Google’s SLO guidance explains how objectives should drive decisions rather than decorate dashboards. The backup and restore planning guide extends this checklist into exercise design.
Make security, cost and exit continuous
Map applicable controls to cloud-native evidence and named owners instead of copying a policy checklist into tickets. NIST SP 800-53 offers a broad control catalog; tailor it to the system and record inherited versus workload-specific responsibility. Add budget alerts and cost allocation before production, then track a unit meaningful to the service. For exit, document data export formats, encryption key ownership, identity dependencies, contractual notice, deletion evidence and the effort to rebuild critical configuration. Exit-aware architecture is not an anti-cloud stance; it keeps recovery and commercial decisions credible.
- Use infrastructure as code for repeatable landing-zone and workload changes.
- Keep platform exceptions dated, owned and visible to affected teams.
- Test emergency access without normal identity dependencies.
- Review provider limits and quotas before each migration wave.
- Decommission legacy systems only after records, integrations and support paths are reconciled.
Require operational acceptance before declaring success
The service owner should accept the migrated workload only after support, alerts, dashboards, on-call access, runbooks, restore evidence, vendor escalation and cost reporting are working. Run a controlled failure and trace the route from alert to recovery. Compare performance and business outcomes with the baseline, including peak and batch behavior. Record temporary risks with owners and expiry dates. The migration closes when the new service can be changed and recovered safely, not when the last data copy finishes.
Treat data migration as a controlled product
Profile source volume, quality, ownership, retention and change rate before selecting transfer tooling. Define transformation rules and a reconciliation method for counts, totals, relationships and business invariants. For long-running copies, capture changes or schedule a defensible freeze; do not assume the final delta is small. Encrypt transfers, restrict staging access and delete temporary copies on a recorded schedule. Rehearse failure halfway through and prove restart or cleanup is safe. After cutover, retain read-only source access only as long as the approved verification and retention plan requires, then close credentials and infrastructure.
Prepare the organization to operate the target
A managed service changes the skills needed but does not remove operational work. Platform staff need policy, identity, network and cost skills; workload teams need service configuration, observability, resilience and provider escalation. Build runbooks and training during migration, then put the receiving on-call team into rehearsals. Update procurement, security and finance processes so new accounts and services do not wait for manual exceptions. Clarify whether a central, application or shared team manages each landing zone. If responsibility remains ambiguous after cutover, the technical migration has moved risk rather than resolved it.
Integrate provider operations and evidence
Document provider service commitments, maintenance behavior, quota process, incident notification, support severity and escalation contacts. Map cloud audit, configuration and security evidence into the organization’s monitoring and retention path. Test a support case before a crisis and record the information the provider requires. Do not depend on a status page as the only outage signal. Review service changes and deprecations on a cadence, with owners for affected workloads. A managed cloud architecture remains current only when the team tracks how both the workload and the provider platform evolve.
Keep migration decisions inspectable
Use short architecture decision records for choices that shape ownership or recovery: managed service selection, region, account boundary, network pattern, data transfer, encryption key, observability route and exit method. Each record should state context, options, decision, consequences, owner and revisit signal. Link it to the workload inventory and implementation change. Avoid vendor feature comparisons without the workload’s service and control needs. A decision record is valuable when an operator can understand why the system is shaped this way during an incident or provider change, not when it restates a diagram.
Review decisions at stabilization and after the first meaningful operating period. Actual demand may invalidate a service tier, provider limits may change a dependency, or support may reveal that central ownership is too slow. Update the record rather than allowing architecture to drift through tickets. Retain superseded decisions so later teams can distinguish a deliberate reversal from forgotten context. This practice also improves exit: the organization knows which provider-specific choices were accepted for value and which abstractions or export paths were retained to reduce lock-in.
Performance acceptance should reflect end-to-end business behavior rather than isolated cloud resource benchmarks. Measure response, throughput and batch completion with realistic network paths, identity, encryption, data size and concurrency. Establish what degradation is acceptable during migration and how scaling affects cost. Review provider throttling and service quotas under peak and recovery scenarios. A workload that is faster in a synthetic test can still be slower for remote offices or partner integrations. Keep baseline and target measurements attached to the migration wave, then revisit them after caches, traffic and operational routines stabilize. Record the measurement owner and test date so later comparisons remain credible when traffic, provider tiers or dependency behavior changes.
Key takeaways
- Define workload and managed-service responsibility separately.
- Use a landing zone to make identity, policy, logging and connectivity repeatable.
- Sequence migration waves from dependency and recovery evidence.
- Test restoration and user outcomes, not only backup completion.
- Include cost allocation, support and exit in architecture acceptance.
Frequently asked questions
What makes an architecture “managed”?
A provider or internal platform team operates specified layers with published responsibilities and service commitments. It does not remove workload ownership; it changes which controls are inherited and how incidents are escalated.
Does exit planning require multi-cloud deployment?
No. Portable data, documented configuration, owned keys and tested restoration may be sufficient. Running every workload in two clouds adds cost and complexity; choose portability controls from realistic business and recovery needs.
What should move in the first wave?
Choose a bounded workload that exercises identity, network, deployment, monitoring and support without combining the estate’s hardest data and regulatory problems. It should teach the platform team something useful and have a credible rollback.
Conclusion
A managed cloud migration succeeds when responsibility becomes clearer, not merely different. Service boundaries, repeatable foundations, rehearsed waves and operational acceptance create an architecture that teams can secure, recover and improve.