India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Cloud to Cloud Migration Between AWS, Azure and Google Cloud
Cloud to cloud migration moves running workloads from one hyperscaler to another, for example AWS to Azure or Google Cloud to AWS, including compute, managed databases, storage, identity and infrastructure code. NTSPL maps every source service to a target equivalent, plans data transfer and egress waivers, rewrites IaC and IAM, and cuts over with a short dual-run period.
Delivered on
In scope
Why Managed Services Make Cloud Switches Harder Than VMs
Companies switch clouds for commercial and structural reasons: a group-wide Microsoft agreement, an acquisition that brings a second provider, a retired service such as Google Cloud IoT Core, or credits that ran out. Moving cloud to cloud looks easier than leaving a data centre, but it is not. VMs move easily; managed services do not. Lambda functions, Cosmos DB containers, BigQuery datasets and provider-specific IAM policies all need a target design, and Terraform written for one provider is mostly rewritten for another.
NTSPL starts with a service map: every resource in the source accounts, subscriptions or projects is exported and paired with a target service and a move method, from replicate to rebuild. Data volumes set the transfer plan and the egress waiver request. Identity, networking and IaC are rebuilt on the target first, then workloads move in groups with a dual-run window so the source can be switched back within minutes.
Reasons That Justify Switching Hyperscaler
Signals you need Cloud to Cloud Migration
- A group-wide enterprise agreement or credits make the other provider at least 20% cheaper for the same workloads.
- An acquisition leaves two clouds with duplicated landing zones, tooling and contracts.
- A service you depend on has been retired or no longer meets your needs on the current provider.
- Your monthly bill exceeds INR 10 lakh and a written target-side commercial offer is on the table.
When to choose something else
- If the main issue is cost waste on the current cloud, fix it with optimization first; switching rarely saves more than rightsizing and commitments.
- If more than half the estate is deeply serverless or uses proprietary analytics, a switch can cost more than three years of savings; consider multi-cloud for new work only.
Service Mapping, Data Transfer and IaC Rebuild
Resource export
All accounts, subscriptions or projects exported with resource types, sizes, tags and spend.
Service map
Each source service paired with a target and a method: replicate, migrate data, rebuild or retire.
Identity and network rebuild
Target IAM, SSO federation, VPC or VNet design and inter-cloud connectivity built before any workload moves.
IaC and pipeline rewrite
Terraform modules, pipelines and policy rules rewritten for the target provider.
Data transfer and egress
Transfer method per dataset, sizing, and the provider's egress waiver request where eligible.
Source-to-Target Service Map and Dual-Run Pipeline
Source-to-Target Service Map and Dual-Run Cloud Switch
Source resources are exported and mapped to target services, with identity and network built on the target first. Workloads move by group over inter-cloud links and run in parallel briefly before source shutdown.
Select any component
Source-to-Target Service Map and Dual-Run Cloud Switch: click any of its 7 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Inbound Migration Tools on Each Hyperscaler
MGN replicates VMs from Azure or Google Cloud like any server, and DataSync can read from other clouds' object storage into S3.
Azure Migrate discovers and replicates AWS and Google Cloud VMs through its physical server path; AzCopy copies directly from S3 into Blob Storage.
Migrate to Virtual Machines has native AWS and Azure sources, and Storage Transfer Service pulls from S3 or Azure Blob on a schedule.
Cloud Switch Choices: Equivalents, Egress, Identity
Equivalent service or rebuild
Map VMs, managed SQL engines, object storage and Kubernetes directly; these have close equivalents. Treat NoSQL, serverless functions, queues and analytics warehouses as rebuilds, because APIs and limits differ. Where a rebuild touches code, estimate it like a refactor. If over 30% of spend is in rebuild categories, revisit the business case before committing.
Egress and transfer method
AWS, Azure and Google Cloud each offer egress waivers for customers moving data out, subject to conditions such as a full exit and advance request. Request the waiver before bulk transfer starts. For under 50 TB, transfer services over the internet are fine; above that, use an interconnect or the target provider's transfer service with parallel streams.
Identity during the switch
Keep one identity provider for people, usually Entra ID or Google Workspace, federated into both clouds during the switch. Rebuild workload roles on the target from least privilege; translating hundreds of AWS IAM policies into Azure RBAC line by line copies years of excess permissions. Remove source access group by group.
Length of dual run
Run both clouds in parallel for 3-14 days per group. Stateless web tiers need 3 days; systems with month-end jobs need a full month-end inside the window. Keep databases single-writer: switch the primary once and replicate back only if rollback is needed. Each extra week of dual run costs roughly a quarter of that group's monthly spend.
Cloud Switch Plan from Export to Source Shutdown
Resource export and service map
Inventory, cost, service equivalents and move method per resource.
Target foundation and IaC
Landing zone, identity, network, inter-cloud link and rewritten modules.
Egress waiver and data seeding
Waiver requested, object and database data seeded.
Group moves with dual run
Workload groups switched with DNS weights and rollback paths.
Source shutdown and account closure
Source resources deleted, backups retained as required, accounts closed.
What you receive
Cloud Switch Completion and Cost Measures
| KPI | Typical target |
|---|---|
| Source spend remaining | Under 5% within 4 weeks of last group |
| Egress charges paid | Near zero where waiver applies |
| Rollbacks during dual run | Under 10% of groups |
| Resources deployed by IaC on target | Above 90% |
Provider-Specific Traps in Cloud-to-Cloud Moves
| Risk | How NTSPL prevents it |
|---|---|
| Serverless and NoSQL rebuilds are underestimated as simple moves. | The service map classifies them as rebuilds with code-level estimates before the business case is approved. |
| Egress charges are billed because the waiver was not requested in time. | Waiver eligibility is checked in week 1 and requested before bulk transfer. |
| Two clouds run in parallel for months, doubling cost. | Each group has a dated dual-run exit, tracked weekly in the steering review. |
Switch cloud providers fully or run multi-cloud?
Switch fully when the commercial case is strong, the estate is mostly VMs, containers and standard databases, and you want one set of tools and skills. Run multi-cloud only when there is a lasting reason, such as a specific AI or analytics service, a regulator or customer requirement, or an acquired business that will stay separate. Multi-cloud by accident, with two half-used landing zones, is the most expensive outcome. If you go multi-cloud, assign each workload a home cloud and avoid cross-cloud calls in transaction paths.
Key facts: Cloud to Cloud Migration
Cloud to Cloud Migration in Practice
2 Cloud to Cloud Migration scenarios, from Solar inverter manufacturing and Shipping line agency, plus related platform case studies.
Solar inverter maker moves its fleet monitoring platform from Google Cloud to AWS
Shipping line agent consolidates from AWS to Azure under a group Microsoft agreement
EPC company vacates its owned data centre in 7 months and halves run cost
D2C fashion brand absorbs 14x festive flash-sale traffic with zero checkout outages
Cloud to Cloud Migration: Frequently Asked Questions
How long does a cloud to cloud migration take?
For an estate of 50-150 workloads, expect 16-20 weeks. The first seven weeks build the service map and target foundation, then groups move with short dual-run windows. Estates heavy in serverless or NoSQL take longer because those parts are rebuilt rather than copied.
Will we pay egress fees to leave our current cloud?
Possibly not. AWS, Azure and Google Cloud each offer egress waivers for customers moving data out, subject to conditions and a request to the provider. We check eligibility early and request the waiver before bulk transfer starts, then track any residual charges.
What does switching clouds cost?
Services usually range from INR 25 lakh to 1.5 crore depending on workload count and how much must be rebuilt. Add the dual-run period and inter-cloud link. We show the payback period against the target provider's commercial offer before you commit.
Can our Terraform code be reused?
Partly. The structure, naming and tagging scheme can be kept, but provider resources and modules must be rewritten. Expect 60-80% of module code to change. Pipelines and policy-as-code rules also need target versions. Existing tests and module boundaries speed up the rewrite.
Does switching clouds affect our compliance in India?
Data must stay in Indian regions throughout, including during transfer and dual run. We map source regions to target regions, such as AWS Mumbai to Azure Central India, keep 180-day logs for CERT-In on both sides, and update DPDP Act 2023 processor records to name the new provider.
What happens to backups on the old cloud?
Backups you must keep for legal or regulatory reasons are either copied to the target with their retention settings or kept in a locked, minimal source account until retention expires. Everything else is deleted when the account is closed, with a record of what was removed.