AWS to Azure Migration — EC2, S3 and RDS Workloads

Usually because the AWS estate was never a decision — it came with an acquisition, a past team's preference or a vendor's default — and the organization now runs Microsoft 365 and Entra ID for everyone, holds an Azure commitment or credits, and pays for two identity planes, two support relationships and two skill sets. Consolidation is a legitimate reason. A guaranteed saving is not, and we will not offer one. The assessment prices Azure on the delivery date against your real AWS invoices, states every assumption, and includes dispositions that say 'stay in AWS' when that is the honest answer.

Azure Migrate treats EC2 instances as physical servers. A discovery appliance on an EC2 instance in your account inventories them over WinRM and SSH, discovers software and SQL instances, collects utilization and runs agentless dependency analysis, and the assessment is built from that data. Migration is agent-based: a separate replication appliance on another EC2 instance coordinates the work, and Microsoft's Mobility agent on each instance streams changes to a cache storage account in Azure while production keeps running. Cutover is a final sync and a start in Azure. Every replication we set up uses Microsoft's simplified appliance; the classic appliance reaches end of life on 30 September 2026.

Replication runs while everything stays in service, so EC2 downtime is each wave's cutover window: final synchronization, start in Azure, DNS and access changes, validation. Object data copies with no downtime and a short final delta. Databases depend on the engine: PostgreSQL and MySQL cut over online in minutes, while RDS for SQL Server to SQL Managed Instance takes the final backup, copy and restore cycle, which we rehearse and time before the window is agreed. Every EC2 wave is also test-migrated first into an isolated network, which is what keeps cutover nights uneventful.

Azure Migrate can start a copy of a replicated instance in an isolated Azure network without touching production or interrupting replication. We do it for every wave: boot check, administrative access, application smoke tests by the owners you name. Problems surface days before cutover instead of during it, and the runbook is corrected while there is still time to correct it. Skipping it saves an afternoon and costs a weekend.

With AzCopy for most buckets: it copies directly from S3 to Blob Storage or Data Lake Storage using Microsoft's server-side copy, so objects never pass through a client machine, and it works with hierarchical-namespace storage accounts. Scheduled, incremental or very large transfers use Azure Data Factory. We map each bucket to a container, translate lifecycle rules and storage classes to Blob lifecycle management and access tiers, reconcile object counts and sizes per bucket, and flag the one thing tooling cannot fix — application code that calls the S3 API and needs to change to the Azure SDK — as separate scope.

By engine, with Microsoft's tooling. RDS for SQL Server goes to Azure SQL Database through the Azure SQL migration extension for Azure Data Studio, or to SQL Managed Instance through native backups staged in S3 and copied with AzCopy — RDS writes backups without CHECKSUM, so Microsoft's backup-based migration service path is not available for that source — or to SQL Server on an Azure VM where a feature demands it. RDS for PostgreSQL goes to Azure Database for PostgreSQL through Microsoft's migration service, which supports RDS as an online source. RDS for MySQL goes to Azure Database for MySQL through Database Migration Service online or Data-in replication. Aurora, Oracle and DynamoDB are re-platforming decisions and are scoped individually. Where an estate has a serious SQL footprint, our SQL specialists run that part alongside this engagement so nothing falls between the two.

They are redesigned, not copied — Azure's model is different and a literal translation would be worse than either. IAM users, groups and roles map to Entra ID identities and Azure RBAC role assignments; instance profiles become managed identities; access keys are retired in favor of Key Vault and managed identity where the application allows. VPCs and subnets become virtual networks and subnets, security groups and NACLs become NSGs, route tables become user-defined routes, load balancers become Azure Load Balancer or Application Gateway, and Route 53 zones move to Azure DNS with a cutover plan per record. The identity and network mapping is a signed-off deliverable before wave one, and the whole design lands inside your landing zone.

If you have one, we check it is ready. If you do not, yes — subscriptions, management groups, policy, identity governance and the hub network need to exist before workloads land in them, and the assessment says so plainly rather than dropping servers into an unstructured subscription that someone will have to untangle later. The landing zone is a separate engagement with its own scope; sequencing it before wave one is often the right call and costs less than doing it afterwards.

Two things matter. Azure Hybrid Benefit lets Windows Server and SQL Server licenses with active Software Assurance or subscription equivalents offset the licensing portion of Azure pricing, and we apply it per workload where you qualify. But if your EC2 or RDS instances were license-included on AWS, you may not own licenses to bring at all; Azure's license-included pricing then applies unless you acquire eligible licenses, and the cost model shows both cases. Separately, Windows Server versions past end of support receive Extended Security Updates at no extra charge once they run in Azure, which removes a recurring cost and risk for aging servers.

AWS bills you for data transferred out during replication and data copy, and Microsoft bills you for Azure: compute, storage, the replication cache storage account, database services and, after Microsoft's free period for server replication, a per-server monthly charge. Neither is part of our fee. AWS has published a process for waiving data-transfer-out charges for customers moving off AWS, requested through AWS Support and granted at AWS's discretion — we show you how to ask, and the cost model never assumes it is granted. If you would rather have Azure on one invoice with your Microsoft 365, we transact Azure through CSP as a direct-bill partner; Microsoft's meters remain the bill of record either way.

Sometimes. Microsoft operates partner-delivered investment programs for qualifying Azure migrations — Frontier Accelerate for Azure in Microsoft's current fiscal year, the successor to Azure Accelerate and Azure Migrate and Modernize. Eligibility, scope and amounts are Microsoft's decision, change by fiscal year and are never guaranteed. During scoping we tell you honestly whether your estate plausibly fits the current program and help pursue it if it does, but the cost model never depends on funding materializing — migrations built on incentives that lapse are how projects stall halfway.

Anything without a like-for-like target. Amazon Linux instances cannot run on Azure as-is and are rebuilt on a supported distribution. Lambda functions, ECS and EKS workloads, DynamoDB tables and Aurora-specific features are re-platforming work, delivered through our application modernization service. Workloads with a hard reason to stay — a vendor contract, a regional requirement, an AWS-only dependency — stay, and get Azure-side inventory, policy, patching and security visibility through Azure Arc without moving. Each of those is a written disposition in the assessment. What we avoid is the quiet failure mode where the awkward third of the estate is simply never mentioned again.

Because a per-instance price would misprice the work. Ten EC2 instances with one bucket and one RDS database, and three hundred instances across two regions with terabytes in S3 and six database engines, are different projects, and the data and database components do not scale with instance count. Scoping is quick: an EC2 and RDS inventory export, your last two AWS invoices and your driving date get you a wave plan and a written fixed quote, and per our standard terms you pay after you approve delivery. AWS egress and Azure consumption are separate and projected transparently in the assessment.

You own a native Azure estate, and the closeout hands it over cleanly: validation evidence, right-sizing rationale, the identity and network design, and an AWS decommission checklist with the order and retention periods agreed with your finance and compliance owners. Most clients then want two things — someone watching the environment, which is our Azure Resource Monitoring and Maintenance service, and a cost discipline so the Azure bill stays honest, which is the FinOps assessment. Both are deliberately separate engagements: the migration stands on its own, and you choose who operates what follows.