Cloud Migration: Google Cloud, AWS and Azure Planning
Plan a controlled cloud migration through discovery, dependencies, service selection, synchronisation, cutover and rollback.
Content update:
Architecture and operating model
Migration extends beyond booting a VM elsewhere. Licensing, identity, DNS, data, certificates, time and external integrations must move or be redesigned. Rehosting largely preserves the design; replatforming changes operations; refactoring may alter code and data flows. Choose based on business value and accepted risk.
Google Cloud, AWS and Azure offer discovery or transfer tools; fit depends on source hypervisor, OS, disks, database and target support. A completed replication job does not guarantee application consistency or uninterrupted cutover. Examine transaction boundaries in snapshot, log or CDC methods.
Plan final deltas, write suspension or single-writer routing before cutover. Lowering DNS TTL does not instantly move every client; test fixed addresses, caches and connection pools. Simultaneous writes to old and new systems can diverge.
Rollback needs a final decision point and data strategy. Reopening the old system after new writes are accepted is not sufficient. Test delta movement, transaction compatibility and redirection beforehand. Retain the old environment for a defined period and access scope until acceptance.
- 1Discovery and dependencies
- 2Pilot transfer
- 3Final delta and cutover
- 4Acceptance / rollback
Design parameters
- Dependency group
- Map application, data and external links that must change together.
- Data-change rate
- Separate initial-copy and final-delta times; measure actual link capacity.
- Acceptance limit
- Define error rate, record correctness, latency and maximum cutover outage.
- Rollback data
- Define transfer and single-writer handling for transactions created at the target.
Platform implementation
Service names are reference points. Scope, defaults, region availability and operating requirements differ; they are not interchangeable guarantees.
| Concern | Google Cloud | Amazon Web Services (AWS) | Microsoft Azure |
|---|---|---|---|
| Discovery / assessment | Migration Center | AWS migration-assessment tools; verify scope. | Azure Migrate |
| VM migration | Migrate to Virtual Machines | AWS Transform MGN (formerly Application Migration Service) | Azure Migrate VM-migration options |
| Database migration | Database Migration Service; verify engine support. | AWS Database Migration Service; verify source/target and CDC support. | Azure Database Migration Service and engine-specific methods |
| Bulk transfer | Storage Transfer Service | AWS DataSync | Azure Storage transfer tools; select by data type. |
Worked example
An initial 500 GB transfer over a usable 80 Mbps link ideally takes about 13 hours 53 minutes: 500 × 8 × 1000 / 80 seconds. Protocols, metadata, loss and retries extend it. Seed data before the cutover window and measure final deltas in a pilot.
During the window, control write suspension, verify final sync and exercise critical target operations. Row counts alone do not prove correctness; check selected business records, relationships and new transactions. Make rollback decisions against acceptance limits and prevent concurrent writers.
Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Replication completes but the application fails | Identity, licensing or external connectivity may be absent. | Verify dependencies through actual target transactions. |
| Some users remain on the old target | DNS caches, fixed IPs or connection pools may persist. | Check client resolution, connection target and write destination. |
| Records differ after rollback | New target transactions may not have returned. | Inspect the last common transaction point and delta method. |
Acceptance checks
- Prove migration success through actual target business operations.
- Validate source/target support matrices.
- Measure initial-copy and final-delta times separately.
- Maintain one authorised writer during cutover.
- Test DNS and clients with fixed targets.
- Exercise rollback data handling after new transactions.
Related concepts
Dependencies and restart order
Services commonly depend on identity, DNS, time, networking, databases and licensing. Record a dependency graph describing conditions for operation, not merely an equipment list. Recovery order follows that graph; circular dependencies may require emergency access paths. Distinguish restored infrastructure from resumed business activity. Assign an owner, validation method and alternative access path to each dependency. Test assumptions by deliberately making one component unavailable in a controlled end-to-end exercise.
Bandwidth and useful throughput
Link capacity differs from useful application throughput. Protocol headers, encryption, retransmissions, small files and storage waits reduce net transfer speed. Keep bits and bytes distinct: 1 Gbit/s corresponds to a theoretical 125 MB/s, not an application performance guarantee. Estimate transfer time as data size divided by measured useful throughput. Observe the network, source reads and destination writes together to locate the bottleneck. Consider temporary slowdowns and competing workloads as well as average speed.
Application consistency
A copy that boots does not prove application-data consistency. Operating-system caches, database logs and write ordering across disks or services affect the result. A crash-consistent copy resembles recovery after an unexpected shutdown; an application-consistent copy follows supported application preparation and write coordination. Validate transaction integrity, relationships between records and application behaviour after recovery, rather than only counting files. Confirm backup integration, application version and reported errors before assuming that consistency was achieved.
RTO and end-to-end recovery time
RTO specifies how soon a service must become usable after an incident. Downloading a backup or booting a VM accounts for only part of that duration. Record detection, approval, infrastructure preparation, data transfer, application startup and business validation separately. Define exactly what starts and stops the test clock. The same technical restore duration can produce different business interruptions when dependencies or access approvals introduce additional waiting.
Version and support lifecycle
Installability does not prove production support. Review the compatibility chain across OS, application, drivers, extensions and management tools. Update plans should record version, support end, restart needs and rollback methods. An unrepresentative test environment can produce misleading results. Validate service health and existing workflows after a change, not just version numbers. Remember that pinning a version can also prevent future security fixes.
Availability versus recovery
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
Primary documentation
How this guide was prepared
Doz Teknoloji Technical Team. This guide uses provider documentation, shared architecture principles and examples with stated assumptions. Calculations and scenarios illustrate the method; they do not claim completed customer tests or results. Verify versions, regions, service scope and support conditions for implementation.
Related cloud guides
Google Cloud, AWS and Azure: Choosing a Cloud Platform
Evaluate Google Cloud, AWS and Azure through workload, service model, data location, security, recovery and total cost.
Cloud Identity and Access: Google Cloud, AWS, Azure
A three-platform guide to human and workload identities, temporary access, least privilege, resource boundaries and access validation.
Cloud Networking: Google Cloud VPC, AWS VPC and Azure VNet
Design and troubleshoot addressing, platform boundaries, routing, private access, firewall controls and hybrid connectivity.
Cloud Cost and FinOps: Google Cloud, AWS, Azure
Manage compute, storage, egress, logging and licensing alongside budgets, rightsizing and commitments.
Cloud Backup and Disaster Recovery: Google Cloud, AWS, Azure
Distinguish backup, replication and HA; test independent recovery access, RPO/RTO, regional loss and failback.
Cloud deployment, operation and support services
We assess platform choice alongside your existing products, workloads and operational needs.