On this page
- Outbound traffic is denied by default. This is the most common source of migration issues.
- Managed database and queue services are not provided.
- Migrate workloads in order of potential impact, starting with the lowest.
Assumptions that change
Most migration challenges arise from capabilities that shared platforms provide by default. Review the following before planning your sequence.
- Open outbound traffic. Outbound traffic is denied by default, and every destination must be declared. Teams frequently discover previously unknown dependencies at this stage.
- Elastic capacity. Capacity is physically allocated and cannot temporarily exceed your allocation, so peak requirements must be sized accurately.
- Managed services. Managed database and queue services are not provided. If your application depends on them, you will need to operate them yourself or adjust the design.
- Instant provisioning. Each server is physically installed and configured. Plan for days rather than minutes.
- Provider-managed backup. Durable storage is provided. Your team is responsible for backup policy and testing.
Sequence
- Inventory outbound dependenciesRecord every outbound destination for each workload while it still runs on the current platform, where traffic can be observed. This is far more difficult to reconstruct afterward.
- Begin with a lower-impact workloadChoose a workload that is in active use but not critical. A workload with no dependents will not reveal the issues you need to identify.
- Provision and verifyProvision the new server and verify its attestation before moving any data.
- Declare outbound destinations, then testAdd the outbound destinations recorded in step one. You may find several that were missed, which is why this step begins with a lower-impact workload.
- Replicate and run in parallelWhere possible, run both environments with production traffic. Parallel operation reveals performance differences that synthetic testing may not.
- Switch over and retainSwitch traffic, then keep the original environment available for at least a week as a safeguard.
- Continue in order of impactProceed to higher-impact workloads. Each migration informs the next, and lessons are least costly on smaller workloads.
Compliance during migration
While a workload runs in both environments, it operates under two sets of controls. Your assessor will want to know how this was managed during the transition.
Keep a written record of what ran where, and when. It is straightforward to maintain during the migration and difficult to reconstruct later.
Share your switchover dates with your deployment engineer in advance, so we can align capacity and support coverage.