Skip to content

Migrate a Workload to the Platform

This page describes a phased way to move a workload from an older environment (on-premises, an older landing zone or another cloud) to a spoke on the platform. The primary responsibility for the migration stays with the workload team. The platform team helps with the spoke, the network and the standard changes, and advises on design. It does not migrate your application for you, unless you agreed this separately.

The phases are a guide. Your organisation may add steps, for example approvals, change windows or a migration board. Ask your platform team which apply. See Operating models for who the platform team is.

flowchart LR
    subgraph team["Once per team"]
        A["1. Onboarding"] --> B["2. Workload identification"]
    end
    subgraph wl["Once per workload"]
        C["3. Design"] --> D["4. Spoke deployment"] --> E["5. Workload deployment"]
        E --> F["6. Data and cut-over"] --> G["7. Decommission legacy"] --> H["8. Evaluate"]
    end
    B --> C

Start with one small, low-risk workload to learn the process (crawl). Do the next one with what you learned (walk). Plan the large or critical workloads last (run).

The phases

# Phase What the team does What the platform team can do
1 Onboarding Attend the introduction, read the responsibilities and limits, and name the roles in your team. Introduce the platform and its support. See Onboarding.
2 Workload identification List your workloads, their dependencies and owners. Do a business impact analysis (BIA) per workload and set the classification. Advise on mapping and ownership.
3 Design Compare the current architecture with the platform's rules. Document the changes you must make (private endpoints, identity, tagging, policies). Plan the migration strategy and the cut-over. Review the design. Help you plan the IP range and the firewall rules you will need.
4 Spoke deployment Request the spoke. Check connectivity and access to the spoke. Create the spoke.
5 Workload deployment Deploy the workload into the spoke with your pipelines and code. Request the firewall rules and, for web apps, the Application Gateway entry. Test in dev and tst first. Handle the standard changes.
6 Data and cut-over Migrate the data. Check its integrity. Let users validate. Switch traffic (for example the DNS record) when you are ready. Keep a rollback path until you have verified the result. Advise on the cut-over plan and risks.
7 Decommission legacy Check that nothing depends on the old environment any more. Revoke access and delete the old resources securely. See the checklist below.
8 Evaluate Review how it went, record lessons learned and update your own procedures. Give feedback on the platform. Collect the feedback.

Do the network work early

Most delays come from network access that was requested late: address ranges, firewall rules to other systems and on-premises connectivity. Collect every connection of the workload in phase 2 and request the rules before the cut-over, per environment. Rules between old and new environments may be needed for the duration of the migration.

Checklist for phase 7: retire the old environment

  • All dependencies of other systems on the old environment are moved or removed.
  • The data is migrated, and backups or an archive exist as long as your retention rules require.
  • DNS records, certificates, firewall rules and monitoring that point to the old environment are removed or moved.
  • Access of people and service accounts to the old environment is revoked.
  • The old resources are deleted, and the old subscription is cancelled when it is empty. If the old environment is itself a spoke on this platform, follow Delete a spoke.
  • Cost reporting shows the old costs gone. Record the savings if your organisation tracks them.