CLOUD INFRASTRUCTURE
On this page
- Egress is default deny here. That breaks more migrations than anything else.
- There is no managed service tier to fall back on.
- Sequence by blast radius, not by ease.
Assumptions that break
Most migration friction comes from assumptions that were free on a shared platform and are not free here. Work through these before you plan a sequence.
- Open egress. Outbound is default deny. Every outbound destination has to be declared. Teams routinely discover dependencies they did not know existed at this step.
- Elastic capacity. Capacity is physically allocated. You cannot burst beyond your allocation, so peak sizing has to be real rather than aspirational.
- Managed services. There is no managed database or queue tier. If your application depends on one, you are running it yourself or changing the design.
- Instant provisioning. A host is physically racked and imaged. Plan in days, not minutes.
- Provider-side backup. Durable storage is provided. Backup policy, and testing it, is yours.
Sequence
- Inventory outbound dependenciesCapture every outbound destination for each workload while it is still running on the old platform, where egress is open and traffic is observable. This is far harder to reconstruct afterward.
- Start with a low blast radius workloadPick something real but not critical. A workload nobody depends on will not surface the problems you need to find.
- Provision and verifyProvision the target host and verify its attestation before moving any data.
- Declare egress, then testAdd the outbound destinations from step one. Expect to find several you missed, which is why this happens on a low blast radius workload first.
- Replicate and run in parallelRun both environments against production traffic where you can. Parallel running surfaces performance differences that a synthetic test will not.
- Cut over and holdSwitch traffic, then keep the source environment intact for at least a week. Cost during that week is insurance, not waste.
- Repeat by blast radiusWork upward. Each workload teaches you something about the next, and the lessons are cheapest on the small ones.
Compliance during migration
While a workload runs in both places, it sits under two different control environments at once. Your assessor will want to know how the split was handled during the overlap.
Keep a written record of what ran where and when. It is a short document to write during the migration and an unpleasant one to reconstruct a year later.
Tell your deployment engineer your cutover dates. We can align capacity and support coverage, and we would rather know before the window than during it.