A 20% discount on the wrong number
The deck that justified this migration had one slide that mattered. A Microsoft Enterprise Agreement, sized against the portfolio's combined Azure consumption commitment, knocked roughly 20% off list. For a sponsor consolidating five tech-services and SaaS holdings under one vendor relationship, that line item is irresistible — it shows up as margin, it simplifies governance, and it gives the operating partner a clean story for the next board meeting. The discount is real. The problem is what it's a discount on.
The 20% applies to Azure consumption. It does not apply to the cost of getting your workloads to behave like Azure workloads — and that's the entire migration. In the last stalled program we inherited, a B2B SaaS target had already spent $1.2 million in systems-integrator fees doing nothing but mapping AWS native services to their nearest Azure cousin. The board was looking at the EA savings; the engineering org was looking at a DynamoDB table with no clean Cosmos DB equivalent and a Slack channel full of people quietly updating their resumes. According to IDC's 2025 Cloud Migration Survey, 43% of enterprises hit significant delays or overruns on cross-cloud programs, with the average overrun north of 35% of the original budget. That 35% does not get netted against your EA discount in any honest model — it sits on top of it.
Here is the disconnect, stated plainly. Procurement bought a price. Engineering inherited an architecture. AWS and Azure are not two interchangeable rooms full of servers; they are two opinionated ecosystems that disagree about identity, data, and how compute is supposed to scale. McKinsey's 2025 Cloud Migration Transformation Analysis found 38% of migration initiatives slip more than a full quarter behind schedule. The slippage isn't laziness. It's the gap between a spreadsheet that treats clouds as commodities and a codebase that was written against one of them specifically.
Where AWS-to-Azure actually breaks
This direction has its own failure signature, and it's worth naming the exact seams because they're what your team is fighting right now. Three of them do most of the damage.
The serverless services have no drag-and-drop equivalent. An EC2 instance becomes an Azure VM in an afternoon — that part lulls everyone into thinking the whole thing is easy. Then the team hits the workloads that actually carry the product. Amazon RDS, AWS Lambda, DynamoDB, SQS — none of these lift cleanly into Azure SQL, Azure Functions, Cosmos DB, or Service Bus. The behavior differs, the SDKs differ, the consistency models differ, and the code has to be rewritten, not relocated. When the team hits this wall against an M&A deadline, they make the choice that kills the deal value: they stop modernizing and start cramming legacy code into oversized Azure IaaS VMs running 24/7. They abandon the elastic, serverless scaling AWS gave them for free.
That panic pivot is exactly how unit economics invert. Flexera's 2025 State of the Cloud Report puts cloud waste at roughly 32% of spend on underutilized resources — and a fleet of always-on VMs sized for peak is how you manufacture that 32% on purpose. I have watched a portfolio company double its monthly infrastructure bill the month it moved off serverless. That cost lands directly on the post-acquisition cloud cost line and bleeds straight out of EBITDA.
IAM does not translate into Entra ID. AWS IAM is policy-and-resource. Microsoft Entra ID (the artist formerly known as Azure AD) is hierarchical and role-based. There is no transpiler between them. Security teams spend months trying to re-express AWS permission boundaries as Entra role assignments, and in the gap between "old policies turned off" and "new roles fully mapped," you get compliance holes that an acquirer's diligence team — or an auditor — will eventually find. This is the work that has no visible output and so gets deprioritized, right up until it becomes the reason the migration can't be signed off.
The S3 egress tax eats week two. AWS prices data leaving its perimeter aggressively, and that's not an accident — it's the retention moat. When you go to drag historical data out of S3 to a competitor's storage, the egress meter runs hard. I've seen migration budgets evaporate in the second week purely on the cost of moving the data, before a single line of application code was touched. Stack the egress bill, the dual-runtime cost of paying for AWS and Azure simultaneously during cutover, and the inflated VM provisioning, and you've built a financial pressure cooker. McKinsey's Cloud Economics Analysis finds migration inefficiencies cost the average company 14% more than planned each year. You are paying that premium to manufacture brand-new Azure technical debt on top of the AWS debt you were trying to escape.
Restarting it: what we do in the first two weeks
Recovery starts with an uncomfortable board conversation, not an architecture diagram. The original timeline is dead — say it out loud and reset expectations, because Gartner's 2025 Cloud Migration Failure Research projects that through 2025, 85% of cloud migrations miss expectations on planning and execution alone. The sunk $1.2 million is gone. Chasing it with more lift-and-shift just moves the debt across vendors faster. Halt every in-flight lift-and-shift the moment you arrive.
Then triage every AWS asset into exactly three buckets, and make the CTO own the calls:
- Replatform — adapt a native service to its Azure analog where the swap is mechanical and low-risk. SQS to Service Bus, an RDS Postgres to Azure Database for PostgreSQL. Fast wins that don't touch business logic.
- Refactor — rewrite the code to use Azure PaaS properly. This is your DynamoDB-to-Cosmos and Lambda-to-Functions work. It's slow, it's the real cost, and it's where the EA savings actually get earned back.
- Retire — kill the stale apps that were on the migration list only because nobody dared cut them. In a typical estate this bucket is larger than anyone admits, and every workload you retire is one you never have to pay egress on.
Freeze the product roadmap while this runs. No new features until the core infrastructure mapping — especially the IAM-to-Entra model — is resolved. You can't re-engine the plane mid-flight, and a half-migrated identity layer is the thing that will ground a sign-off. Critically, treat this as a product-engineering initiative, not an IT chore: the people who built the AWS estate are the only ones who can architect the Azure version, so incentivize them to learn it. Run it as ops-only and your migration talent walks, taking the tribal knowledge with them.
Finally, install cost governance on day one in Azure, not after the bill arrives. Mandatory tagging, defined auto-scaling, locked-down provisioning, and a single target: reach parity with your old AWS unit economics — not merely "it runs." Track it on the same week-by-week board you use for M&A technology integration. A real recovery doesn't just relocate the code; it rebuilds the architecture to use Azure the way Azure wants to be used, so the EA discount finally shows up as value instead of as a line item that justified a stalled project.
