Microsoft and OpenAI announced on April 27, 2026, an amended agreement that ends the Azure exclusivity at the heart of their partnership. Under the new terms, OpenAI can serve all of its products to customers through any cloud provider, while Microsoft remains OpenAI's primary cloud partner, OpenAI products ship first on Azure in most cases, and Microsoft keeps a license to OpenAI's intellectual property for models and products through 2032. For developers who build on OpenAI models through Azure, the change widens the set of places those models can come from without removing Azure's head start.

Key Facts#

  • Announcement: published on April 27, 2026, by both Microsoft and OpenAI, each describing it as the next phase of the partnership.
  • Exclusivity: OpenAI can now serve all of its products to customers across any cloud provider.
  • Azure's position: Microsoft remains OpenAI's primary cloud partner, and OpenAI products ship first on Azure unless Microsoft cannot, and chooses not to, support the necessary capabilities.
  • Intellectual property: Microsoft keeps a license to OpenAI IP for models and products through 2032.
  • Revenue share: Microsoft will no longer pay a revenue share to OpenAI, and CNBC reported that OpenAI's revenue-share payments to Microsoft will be capped.
  • Stated goal: the companies said the amendment simplifies how they work together and is grounded in flexibility and certainty.

What Happened#

The amendment rewrites the commercial structure that governed the relationship since Microsoft's first major investment in 2019. Until now, the partnership followed an Azure-exclusive model: Azure was the only cloud provider through which OpenAI's products were offered, which made Azure OpenAI, now part of Microsoft Foundry, the default way for many companies to buy OpenAI models with enterprise controls. The new terms remove that exclusivity, so OpenAI can serve its products through other cloud providers.

Microsoft did not walk away empty-handed. Azure keeps first-ship status, so new OpenAI products are meant to arrive on Azure before other clouds, with an exception only when Microsoft cannot, and chooses not to, support what a product needs. Microsoft's license to OpenAI's models and products runs through 2032, which protects the Copilot portfolio and the many Microsoft services built on OpenAI technology.

The money flows changed as well. Microsoft stops paying OpenAI a share of revenue, while CNBC's coverage described the deal as capping the revenue-share payments OpenAI makes to Microsoft. Redmondmag characterized the overall result as a restructuring and a shift away from exclusivity, and it is not the first time the terms have been revisited as both companies' ambitions grew.

Background#

The Microsoft–OpenAI relationship began as a tight, exclusive arrangement: Microsoft supplied capital and Azure compute, and OpenAI's models powered both Azure's AI services and Microsoft's Copilot products. That arrangement has been loosening for some time. In mid-2025, TechCrunch reported that Microsoft was negotiating to keep access to OpenAI's technology beyond the agreement's AGI milestone, and both companies spent the following months diversifying.

Microsoft's side of that diversification is well documented. At Ignite in November 2025, Microsoft added Anthropic's Claude models to Microsoft Foundry and said it was the only cloud offering both Claude and GPT frontier models on one platform. Anthropic models also became available across Microsoft 365 Copilot experiences under Microsoft's enterprise terms. And in January 2026, Microsoft introduced its Maia 200 inference accelerator, which it said would serve models including OpenAI's latest GPT models on Azure. Seen in that context, the April amendment formalizes a relationship in which each company keeps important rights but neither depends exclusively on the other.

Why It Matters for Developers#

For most .NET developers, nothing breaks on day one. Azure OpenAI deployments in Foundry keep working, and Azure keeps first access to new OpenAI products. The strategic picture changes more than the code does, and it rewards teams that avoid hard-coding a single provider.

  • Keep your model layer portable. If your application talks to models through IChatClient from Microsoft.Extensions.AI, moving a workload between Azure OpenAI, OpenAI's own API and another cloud's offering becomes mostly a configuration change. Our guides to Azure OpenAI and Microsoft Foundry for .NET and the official OpenAI .NET library cover both paths.
  • Revisit procurement assumptions. Organizations that standardized on another cloud may soon have options to buy OpenAI products there. Compare data residency, compliance commitments, network paths and pricing rather than assuming the models alone determine the platform.
  • Plan for first-ship timing. If you need new OpenAI capabilities on day one, Azure remains the most likely place to get them, subject to the stated exception.
  • Measure before you move. Price and latency can differ between platforms serving the same model. Instrument calls as described in observability and cost control for LLM apps so decisions rest on data.

Architects should also note the second-order effect. With Microsoft investing in its own models and OpenAI free to work with other clouds, the market for hosted frontier models is becoming more competitive. That is generally good for customers, but it increases the value of evaluation pipelines and abstractions that let you switch providers without a rewrite.

What's Next#

Several details will only become clear as the new terms play out. It remains to be seen how quickly OpenAI products appear on other clouds, how the first-ship exception will be applied in practice and whether pricing for OpenAI models diverges across platforms. Microsoft, for its part, moved quickly to show that it has alternatives: at Build in June 2026 it launched seven in-house models, covered in our story on Microsoft's MAI models. For .NET teams, the safest response is the same regardless of how those questions resolve: keep model access behind abstractions, and treat the choice of provider as a deployment decision rather than an architectural one.

Sources#