We Want to Change Cloud Providers Without Rebuilding Everything

Rarely because the old cloud stopped working. More often a company that runs on Microsoft 365 wants its servers next to its identity platform, an acquisition brought a second cloud account nobody planned for, a hosting contract is ending, or the developer who built everything on one provider has moved on and the next team works on another. The reason shapes the plan: consolidation is about cost and simplicity, an acquisition about one set of controls.

Cloud accounts accumulate. Virtual machines, managed databases, storage buckets, serverless functions, queues, DNS zones, certificates, scheduled jobs, and the outside services that call in with API keys. We export the inventory from the provider's own tools and match it against the billing data, because the bill shows what the console hides: a forgotten region, an old snapshot schedule, a test database still running. Anything with no owner gets a name or a retirement date.

AWS, Azure and Google all bill for data leaving their networks, and in a provider-to-provider move the source cloud charges you to take your own data out. Add the period where you pay for both environments while the new one is tested, and transfer cost becomes a real budget line. We measure volumes per bucket and database, delete or archive stale snapshots and old backups before the copy, check your current provider's terms for data transfer out, and decide which data moves over the network and which simply gets left behind.

AWS IAM, Microsoft Entra ID and Google Cloud IAM model permissions differently, so roles are rebuilt for the target rather than translated line by line, and the move becomes a chance to cut back on over-broad access. Networks get address ranges that don't collide with your offices or VPN, firewall rules are rewritten, and site-to-site tunnels are rebuilt to the new provider. DNS TTLs are lowered ahead of time, so each cutover is a record change and a rollback is a record change back.

Every provider has managed databases, object storage, queues, functions and load balancers that do similar jobs with different limits. Amazon RDS, Azure SQL Database and Google Cloud SQL each handle versions, backup retention, maintenance windows and failover their own way. For each service we decide: a direct equivalent, a plain virtual machine for now, or a redesign. Code that calls one provider's storage or queue APIs needs changes, and we list those for your developers or software vendor early, not at cutover.

The move we see most often is a Microsoft-centric business bringing AWS workloads over to Azure, where identity, Microsoft 365 and existing Windows Server and SQL Server licensing already live. That path has its own tooling and licensing questions: Azure Migrate assessments, an Azure landing zone, and whether Azure Hybrid Benefit applies to your licenses. Our Azure migration page covers it in detail, and the egress and DNS planning on this page applies on top.

Leaving a hosting company's private cloud for AWS, Azure or Google Cloud is a cloud-to-cloud move too, with one extra question: what belongs to you and what belongs to the host. Backups, firewall configuration, public IP addresses and licenses bundled into the hosting fee often stay behind. Many VMware-based environments are being re-evaluated since Broadcom completed its acquisition of VMware and moved licensing to subscription bundles. We arrange VM exports or replication access with the host and sequence the work around your contract end date.

Cloud-to-cloud also means file platforms. Microsoft's Migration Manager moves Google Drive and other common cloud file sources into OneDrive and SharePoint. The tool is the easy part. The planning is folder structure mapped to SharePoint libraries, permissions mapped to Microsoft 365 groups, external sharing links that don't carry over and have to be re-shared, and paths too long for the target. A full Google Workspace move including Gmail has its own page, as does a Microsoft 365 tenant-to-tenant move.