Memory hook: Discover dependencies before moving the workload.
Must remember
Assess the estate: applications, data, dependencies, owners, licenses, utilization, risk and business criticality. Migration Center supports discovery/assessment. Decide whether to retain, retire, rehost, replatform, refactor or replace each workload according to value and constraints; not every application deserves a rewrite.
Build a landing zone with identity federation, hierarchy, networking, logging, guardrails and billing controls before moving important workloads. Map address overlap, DNS, latency, authentication and firewall dependencies. Shared VPC and hybrid connectivity can support staged migration; they also create transition complexity that must be documented.
Choose online transfer, replication/CDC or offline transfer by dataset size, bandwidth, change rate and downtime tolerance. Estimate transfer time using effective throughput, not nominal link speed, then account for verification and catch-up. Database migration requires engine/schema compatibility, consistency, validation and a defined point at which writes move.
A cutover plan names owners, sequence, prechecks, success criteria, communications, rollback triggers and the latest safe rollback point. DNS changes can leave cached clients on the old path. Dual writes create consistency risks unless deliberately designed; rolling back infrastructure does not magically merge diverged databases.
Modernization choices include containers, managed databases, asynchronous events and serverless services. Preserve observability and operational ownership through the transition. API management such as Apigee can support controlled exposure, quotas and lifecycle, but backend authorization and data correctness remain essential.
Train teams, validate support processes and perform load, security, integration and recovery tests before declaring migration complete. Decommission old infrastructure only after acceptance, retention and rollback obligations are satisfied.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Minimal initial application change | Consider rehosting with a later modernization plan. |
| Low-downtime database transition | Supported replication/CDC plus validated cutover. |
| Unknown application dependencies | Discovery and dependency mapping before scheduling migration waves. |
Traps
- A copied VM is not proof that licenses, identity and latency requirements are met.
- Rollback after new writes requires a data-consistency plan.
Active recall
1. Why build the landing zone first?
So migrated workloads inherit intentional identity, network, logging and governance foundations.
2. What makes a migration wave sensible?
Dependencies, criticality, risk and team capacity, not only server count.
3. Why can DNS cutover be gradual?
Clients and resolvers may retain cached answers or existing connections.
4. Why validate CDC catch-up before cutover?
Unapplied changes can violate data-loss and consistency requirements.
5. When is migration complete?
After business/technical acceptance, operational readiness and controlled retirement of obsolete paths.