Skip to main content
CLOUD ARCHITECTURE

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.

  1. 1Discovery and dependencies
  2. 2Pilot transfer
  3. 3Final delta and cutover
  4. 4Acceptance / rollback
Prove migration success through actual target business operations.

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.

ConcernGoogle CloudAmazon Web Services (AWS)Microsoft Azure
Discovery / assessmentMigration CenterAWS migration-assessment tools; verify scope.Azure Migrate
VM migrationMigrate to Virtual MachinesAWS Transform MGN (formerly Application Migration Service)Azure Migrate VM-migration options
Database migrationDatabase Migration Service; verify engine support.AWS Database Migration Service; verify source/target and CDC support.Azure Database Migration Service and engine-specific methods
Bulk transferStorage Transfer ServiceAWS DataSyncAzure 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

ObservationLikely cause / distinctionVerification
Replication completes but the application failsIdentity, licensing or external connectivity may be absent.Verify dependencies through actual target transactions.
Some users remain on the old targetDNS caches, fixed IPs or connection pools may persist.Check client resolution, connection target and write destination.
Records differ after rollbackNew target transactions may not have returned.Inspect the last common transaction point and delta method.

Acceptance checks

  1. Prove migration success through actual target business operations.
  2. Validate source/target support matrices.
  3. Measure initial-copy and final-delta times separately.
  4. Maintain one authorised writer during cutover.
  5. Test DNS and clients with fixed targets.
  6. 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.

Enterprise IT Product Sales, Licensing and Deployment
Enterprise IT Project & Solution Scenarios
View all related content
Text on WhatsApp
Copied!