Migrating Off Azure: Entra ID and Cosmos DB Are the Hard Part

Egress fees are the part of an Azure bill people can point to. It’s a line item with a per-GB rate, and it used to climb every time you tried to leave. So it got blamed for lock-in. But if you’ve tried to actually move an application off Azure, you know the egress bill isn’t what stops you.

What stops you is that your application’s identity layer depends on a system that won’t hand back your users’ passwords, your database’s partition key was fixed the day you created the container, and your orchestration logic lives in a Logic Apps definition tied to the Azure portal. Egress is the fee you notice. The managed services are the trap you built one integration at a time.

This is the same pattern we covered for AWS and Google Cloud, and Azure’s version has its own specific shape, with a couple of real surprises in both directions.

Why This Matters Now

Microsoft was last to waive egress fees, following Google in January 2024 and AWS in March 2024, but Microsoft’s own version, announced the same month as AWS’s, comes with the strictest terms of the three. To qualify, you must notify Azure Support in advance, complete the transfer within 60 days, and cancel every Azure subscription associated with the account.

That last condition is a bigger deal on Azure than it sounds, because a single Azure account commonly bundles Microsoft 365 and Microsoft Entra ID (the rebranded Azure AD) alongside compute and storage. Commenters on Microsoft’s own announcement raised exactly this problem: an organization using Office 365 or Exchange under the same tenant can’t cancel “all Azure subscriptions” without also giving up email and identity services that have nothing to do with the workload they’re trying to move. AWS’s waiver, by contrast, does not require closing the account at all, and Google’s applies only to a defined list of data services rather than the entire tenant.

That distinction matters for planning, but it’s a distinction about the exit paperwork, not about what actually has to be rewritten. If your workloads are mostly Virtual Machines, Managed Disks, and Azure SQL, egress being waivable turns the exit into a data migration and cutover project. The workloads that get stuck are the ones wired into Cosmos DB, Service Bus, Logic Apps, and Azure AD B2C or Entra External ID, because each of those requires code written against an Azure-specific data model, protocol, or credential store that doesn’t move on its own.

Azure Functions and Event Grid: Portable in Theory, Proprietary by Default

Azure Functions can be triggered directly by many Azure services, or routed through Event Grid, Azure’s event backbone. The good news is that Event Grid natively supports the CloudEvents v1.0 schema as both an input and output format, the same open CNCF standard GCP’s Eventarc uses, and it’s the format Microsoft’s own documentation now recommends for new projects specifically because it lets an application move between Event Grid, other CloudEvents-compatible systems, and open-source tooling without changing its event format.

The catch is that CloudEvents is a choice, not a default. Event Grid still ships with its own proprietary Event Grid schema, which is what most built-in Azure service events use unless you explicitly configure a topic to accept CloudEvents instead. A team that took the path of least resistance and let Blob Storage or IoT Hub events flow through in the native Event Grid format is in the same position as an AWS EventBridge user: reformatting every event on the way out. A team that deliberately chose CloudEvents from the start is in materially better shape, closer to the GCP Eventarc position than to AWS’s.

Either way, the IAM wiring, the managed identities, and the trigger configuration binding a function to its event sources are Azure-specific resources that have to be rebuilt on any other platform regardless of which event schema you chose.

Cosmos DB: The Partition Key You Can Never Change

Cosmos DB is Azure’s multi-model database, and its deepest lock-in mechanism is structural rather than syntactic. A container’s partition key is fixed the moment you create it and cannot be changed in place; Microsoft’s own engineering blog describes the workaround as copying the entire container’s data into a new one with a different key, using change feed processors or dedicated copy jobs, which is a full data migration in its own right even when you’re not leaving Azure at all.

If your original partition key stops fitting your query patterns, and Microsoft’s own migration guidance acknowledges this happens often enough to need a documented process for it, you’re already doing a version of the same data-model surgery a DynamoDB or Firestore migration requires, before you’ve even decided to leave the platform.

Layered on top of that is the Request Unit pricing and throughput model, which Microsoft’s own documentation and third-party migration guides both describe as notoriously difficult to estimate up front, since RUs abstract away CPU, memory, and IOPS into a single number that has to be reverse-engineered from your actual query patterns.

Moving off Cosmos DB means redesigning around a partition strategy for a different database, translating RU-based capacity planning into whatever the new system uses (vCores, connections, or raw compute), and migrating the data itself. Cosmos DB does offer API compatibility modes, including a wire-compatible Cassandra API and a MongoDB-compatible option, which genuinely does make some migrations closer to a lift-and-shift than a rewrite; the trap is specific to teams that built directly against the native SQL/NoSQL API rather than one of the compatibility layers.

Service Bus: The One Place Azure Is Genuinely More Open

This is the clearest place where Azure’s lock-in profile is lighter than either AWS’s or GCP’s. Azure Service Bus’s primary wire protocol is AMQP 1.0, an ISO and IEC international standard (ISO/IEC 19464:2014) developed through an industry consortium that included Microsoft and Red Hat, among more than 20 technology vendors and end users. That’s a categorically different position from AWS’s SQS and SNS, which have no equivalent open protocol at all, and from GCP’s own documentation, which recommends its Kafka-compatible service over Pub/Sub specifically because Pub/Sub’s API isn’t broadly adopted outside Google.

Because Service Bus speaks a real open standard, tools exist to bridge it directly to RabbitMQ using standard AMQP 0.9.1-to-1.0 shovels, and application code written against a generic AMQP client library, rather than the Azure-specific SDK, can often point at a different AMQP broker with comparatively small changes.

The caveat is that most production Service Bus code doesn’t take that path. Teams that built against the Azure.Messaging.ServiceBus SDK, rather than a protocol-neutral AMQP library, still have to rewrite for a new client, and Service Bus features like sessions, message deferral, and duplicate detection are service-specific behaviors layered on top of the open protocol that don’t have a drop-in equivalent elsewhere. The protocol itself being open is a real advantage. It doesn’t erase the work of migrating application code that was never written with that portability in mind.

Logic Apps: The Same Shape as Step Functions, Aimed at a Different User

Logic Apps is Microsoft’s low-code workflow orchestration service, defining workflows in a proprietary JSON schema and stitching together triggers, connectors, and actions largely through Azure’s portal-based designer. It’s aimed more at citizen-developer and business-process automation than at the code-first orchestration Step Functions or Cloud Workflows typically handle, but the lock-in mechanism is the same: the control flow lives in a proprietary definition tied to one vendor’s designer and runtime, not in application code your team owns.

Migrating a nontrivial Logic Apps workflow to Temporal, Airflow, or Argo means the same exercise as leaving Step Functions, translating a visual, connector-based definition into code, while also accounting for the hundreds of prebuilt Azure and Microsoft 365 connectors that Logic Apps workflows commonly lean on and that have no equivalent outside the Microsoft ecosystem.

Azure AD B2C and Entra External ID: The Same Problem as Cognito

This is the place Azure is arguably worse than GCP and matches AWS’s worst case exactly. Azure AD B2C, and its successor Microsoft Entra External ID, do not support exporting password hashes. Microsoft’s own migration documentation for moving from B2C to External ID confirms this directly: you either force every user to reset their password, or you implement just-in-time migration, where a custom policy validates each user’s credentials against the legacy system on their next login and writes the verified password into the new one. That’s structurally identical to the AWS Cognito problem and the opposite of what GCP’s Identity Platform allows, where documented, exportable password hash parameters mean a migration can preserve every user’s password with no reset at all.

Microsoft is actively pushing customers through this exact migration right now: Azure AD B2C Premium P2 features, including Identity Protection integration, were retired in March 2026, and while Microsoft has committed to supporting B2C for existing customers into 2030, new capabilities are landing in Entra External ID only. Teams running B2C today are already living the migration timeline this article describes, whether or not they’re planning to leave Azure at all, and the credential-export limitation is the same bottleneck regardless of whether the destination is External ID or a completely different platform.

The Pattern Underneath All of These

Across every service here, the underlying shape repeats: a proprietary interface sits between your application and infrastructure that has an open equivalent elsewhere, and your code inherits that interface’s data model, credential store, or workflow syntax. Azure’s specific profile has real texture to it.

Service Bus’s use of an actual ISO standard protocol is a genuine point in Azure’s favor, better than either AWS or GCP on this specific axis. Event Grid’s native CloudEvents support puts it on par with GCP’s Eventarc, provided a team chose that path deliberately rather than defaulting to the proprietary schema. But Cosmos DB’s partition key rigidity and Azure AD B2C’s non-exportable credentials are exactly as severe as their AWS counterparts, and the egress waiver’s all-Azure-subscriptions requirement is arguably the most restrictive exit condition of the three major clouds, given how often an Azure tenant is entangled with Microsoft 365 licensing.

The work required to undo any of this is the same regardless of platform: rewrite the SDK calls, redesign the data model or partitioning scheme where one exists, replace the managed-identity-based permission model, migrate the data itself, and re-test everything downstream of the old integration.

None of that appears on an Azure invoice. All of it appears in engineering time, which is why it’s easy to underestimate when a team first reaches for a managed service and expensive to discover only once leaving is under discussion.

Where OpenStack Avoids This Trap Entirely

The reason this pattern doesn’t repeat on an OpenStack-based private cloud is architectural. Nova, Cinder, Neutron, and Swift are open, community-governed APIs with multiple independent implementations, so there’s no single vendor’s SDK, credential store, or partition scheme to get welded to in the first place. For a fuller comparison of how these map to hyperscaler services, see What Your Cloud API Choice Is Actually Costing You.

What runs on top of that infrastructure is the bigger point.

• Instead of Cosmos DB, you run PostgreSQL, Cassandra, or ScyllaDB, with a partitioning strategy you control and can change without a change-feed migration project.
• Instead of Service Bus, you run RabbitMQ or Kafka directly, speaking the same open AMQP or Kafka protocols rather than a vendor SDK layered on top of one.
• Instead of Logic Apps, you run Temporal, Airflow, or Argo, with orchestration logic in your own codebase instead of a portal-based designer.
• Instead of Azure AD B2C or Entra External ID, you run Keycloak or another standard OIDC provider, one that was never built to withhold your own users’ credentials from you.

Every one of these speaks an open protocol or format rather than one vendor’s interface, which removes the lock-in at the source rather than managing around it after the fact.

The honest caveat is the same one that applies to any hyperscaler exit. Azure’s managed services are managed for a reason, and running PostgreSQL, RabbitMQ, or Keycloak yourself means your team owns the operational work Microsoft was doing for you.

OpenMetal’s assisted management options cover hardware and platform support, not full management of every application-layer service you choose to run on top of it. If your team doesn’t already have that operational depth, budget for building it rather than treating it as a footnote. For guidance on managing the organizational side of a similar migration, see From VMware to OpenStack: The People and Process Side of Migration and A Practical Guide to a Successful Public Cloud Exit Strategy.

Deciding What to Untangle First

Not every Azure dependency deserves the same urgency. A reasonable way to sequence this:

• Start with Virtual Machines, Managed Disks, and Blob Storage. These are close to commodity, egress is waivable if you’re leaving entirely, and there’s no proprietary data model standing in the way.
• Audit the managed services next, ranked by how hard they actually are to leave rather than by monthly cost. Cosmos DB and Azure AD B2C or Entra External ID are the hardest, because one requires a partition-key data migration and the other can’t hand back your users’ credentials. Service Bus is comparatively lighter, especially if your code already uses a protocol-neutral AMQP client rather than the Azure SDK directly. Logic Apps sits in between, depending on how many Microsoft-specific connectors a given workflow depends on.
• Budget the hard dependencies in engineer-months. An Azure AD B2C migration in particular is a project with its own multi-month, dual-tenant coexistence period, not a data transfer task with a deadline, and Microsoft’s own migration guidance says as much directly.
• And be honest about which workloads should stay. Deep Microsoft 365 integration, specific compliance certifications, or genuinely elastic workloads are legitimate reasons to remain on Azure for some portion of your estate. This isn’t an argument for leaving everywhere. It’s an argument for knowing which of your Azure dependencies are actually load-bearing versus which ones were the easiest option at the time. If you want help sizing that for your own environment, you can start with a proof of concept.

FAQ

Is Azure egress still a major lock-in cost?

Less than it used to be, but Azure’s waiver is the strictest of the three major clouds. Since March 2024, Microsoft waives data transfer fees for customers moving all their data off Azure, but only if you cancel every Azure subscription tied to the account, which can include Microsoft 365 and Entra ID if they share a tenant.

Is Azure’s lock-in the same as AWS’s or GCP’s?

The pattern is the same, but the severity varies by service. Service Bus’s use of the open AMQP 1.0 standard makes it more portable than AWS’s SQS/SNS or GCP’s Pub/Sub. Azure AD B2C and Entra External ID’s inability to export password hashes matches AWS Cognito’s worst case and is worse than GCP’s Identity Platform, which allows password export.

Which Azure managed service is hardest to migrate away from?

Azure AD B2C or Entra External ID, because of the non-exportable credentials, and Cosmos DB, because its partition key can’t be changed without a full data migration. Both require a genuine data or credential migration project, not just a rewrite of integration code.

Can I export my users if I’m on Azure AD B2C?

User profile data, yes. Password hashes, no. Microsoft’s own migration documentation for moving to Entra External ID confirms that password migration requires either a forced reset or a just-in-time migration that captures credentials as users log in after cutover.