Azure AI Services Consolidation Trend: What Microsoft Foundry Means for Your Business

The McKinsey US CSO survey found that more than 90% of companies are using generative AI, yet only 1% say the technology is fundamentally changing the way they operate. Microsoft is now restructuring its cloud AI stack to help close that gap. With the launch of Microsoft Foundry (originally introduced as Azure AI Foundry at Microsoft Ignite 2024), the company has consolidated Azure OpenAI Service, Azure AI Studio, Azure Machine Learning, Azure Cognitive Services, and Azure AI Search into a single platform. Today, more than 10,000 organizations, including Heineken, Fujitsu, and Carvana, have already migrated their AI workloads onto Microsoft Foundry.

This shift matters because the prior Azure AI architecture was already slowing AI-powered feature rollouts. Before 2024, companies had to build custom workflows across multiple AI services just to support a single use case. That meant managing separate SDKs and inconsistent governance across powerful but still siloed Azure AI components. That fragmentation pushed compliance reviews into months-long cycles and inflated the total cost of ownership. The trade-off of the current trend of consolidating Azure AI services is that every Azure AI customer now has to rework their stack.

In this article, we explain why Microsoft is consolidating its AI services under Foundry and what this shift means for businesses already using Azure AI or planning to integrate it.

The consolidation trend was introduced at two consecutive Microsoft Ignite conferences, with the November 2024 launch of Azure AI Foundry and the November 2025 rebrand to Microsoft Foundry expanding the platform’s architecture. Each release added different capabilities that your AI development team needs to plan around.

Each of the services now absorbed into Foundry served a specific role in the old architecture. For instance:

• Azure OpenAI Service handled GPT-based language workloads
• Azure Machine Learning covered custom model training and deployment
• Azure Cognitive Services delivered prebuilt vision, speech, and language APIs
• Azure AI Search powered retrieval-augmented generation patterns
• Azure AI Studio sat above all of them as a separate orchestration layer

Each lived inside its own product surface with its own portal and documentation. Given that, combining two or more services in a single AI feature required custom integration work that could not be reused across projects.

Let’s take a closer look at what has already happened and what is about to be changed.

At Microsoft Ignite in November 2024, Microsoft introduced Azure AI Foundry as a unified platform for creating and managing AI applications. At that time, the platform combined model selection across OpenAI’s GPT, Microsoft’s Phi, and Meta’s Llama with Prompt Flow for visual workflow design. It also had built-in capabilities for fine-tuning and deploying foundation models. Microsoft also introduced Azure Model-as-a-Service (MaaS) to enable customers to integrate, govern, and scale models in production without managing separate model-hosting infrastructure.

When the Leobit team attended Azure Dev Summit 2025 in Lisbon, Microsoft positioned Azure AI Foundry as the “home for all AI development on Azure.”

Last year’s Ignite conference brought a bigger move. Microsoft rebranded Azure AI Foundry to Microsoft Foundry, and that change went far beyond a simple rename. According to Microsoft’s October-November 2025 product update, the platform underwent a major architectural expansion.

The most structurally important change was the introduction of Foundry Tools, which replaced the Azure AI Services brand. Foundry Tools now provide a unified suite of prebuilt, production-ready AI capabilities spanning audio, video, images, documents, and text. Features that previously sat under the Azure AI Services umbrella (and under Azure Cognitive Services before that) now sit inside Foundry Tools. These capabilities cover vision, speech, language, and document intelligence APIs within the same platform stack.

The naming change also signals where Microsoft is taking the platform. Dropping “Azure” from the product name positions Foundry as a Microsoft-wide AI development environment rather than an Azure-only offering.

Microsoft Foundry today is a full-stack AI development platform organized around four building blocks: models, agents, tools, and a shared developer surface. All four sit under a single identity and governance layer, so anything built in Foundry inherits a consistent control plane regardless of which service powers it.

Let’s take a closer look at these four building blocks:

• Models. At the top sits the Foundry model catalog, which gives customers a single API surface to call foundation models from multiple vendors alongside their own fine-tuned variants. Switching between a frontier model for a complex reasoning task and a smaller, cheaper model for a high-volume classification task no longer requires changing service endpoints or rewriting application code.
• Agents. The agent layer is where teams compose autonomous and assisted AI agents. It handles agent state, tool invocation, memory, and multi-step task execution. Agents built here can run as background workers in Azure, be embedded in a customer-facing application, or be made available through Microsoft Copilot for use in Microsoft 365 surfaces.
• Tools. This is the prebuilt skills layer that agents and applications call when they need ready-made AI capabilities they would otherwise have to build from scratch.
• Shared developer surface. Underneath the three sits a shared developer surface that includes the Foundry portal, the Foundry SDK, command-line tools, and connectors for Visual Studio and VS Code. Everything built in Foundry inherits the same identity (Microsoft Entra ID) and the same observability pipeline.

For most teams, the entry point is the Foundry portal in Azure. Once a project is set up in the portal, it becomes accessible programmatically through the Foundry SDK. It exposes models, agents, and tools through a consistent API regardless of which underlying service runs the workload. A team that previously wrote glue code to switch between Azure OpenAI Service and Azure Machine Learning can now route calls through the Foundry SDK, letting the platform handle service-level routing.

For developers using Visual Studio or VS Code, Foundry integrates with GitHub Copilot for Azure. Copilot can call Foundry models, configure agents, generate deployment scripts, and provision Foundry resources without leaving the editor.

Microsoft did not consolidate Azure AI because the underlying services were broken. Each of them worked well at what it was built for. The consolidation answers three structural problems that began to surface as AI moved from pure prototyping to production.

Deloitte’s State of Generative AI in the Enterprise research found that 70% of organizations have moved 30% or fewer of their generative AI experiments into production. The gap between piloting AI and operating it at scale was widening, and Deloitte’s interviews pointed to fragmented tooling as one of the main reasons.

When Microsoft announced Azure AI Foundry, it framed the problem similarly. Companies could build a working prototype on Azure OpenAI Service, but many struggled to operationalize it. The process became more complex when they needed to add retrieval through AI Search, prebuilt skills from Cognitive Services, and orchestration through AI Studio, each with its own SDK and billing model.

The friction was not in the AI itself but in everything that had to wrap around it for production. Microsoft needed a way to remove that friction for customers if it wanted enterprise AI to scale and introducing Foundry was that move.

Companies are no longer building isolated AI features that summarize a document or classify an email. They are building AI-driven business systems in which multiple agents act autonomously to execute end-to-end workflows such as claims processing, support escalations, and financial reconciliations.

Single-service APIs were never designed for this. For instance, an autonomous agent typically calls a frontier model for reasoning, a smaller model for routing, a prebuilt skill for document parsing, an external system for data, and an observability pipeline to log every step. Stitching those together at runtime across separately governed Azure services was technically possible but operationally fragile.

Foundry’s agent layer treats multi-step orchestration as a first-class platform concept rather than something each customer has to reimplement. Without this shift, the agentic workloads that Microsoft and its customers are investing in would still need to be custom-engineered for each individual project.

Foundry’s unified SDK was built specifically to compress the production. The package bundles models, the agent service, evaluations, tracing, and external resource connections into one comprehensive library. So application code that previously had to import and reconcile multiple SDK versions now uses a single Foundry SDK.

Azure OpenAI also moved to next-generation v1 APIs that eliminate the requirement to pin application code to a specific API version string. Developers can target the latest endpoint for stable features and the preview channel for cutting-edge capabilities without changing application logic each time Microsoft ships a new model or feature. That alone removes a recurring source of brittle release work for any team running Azure OpenAI in production.

For teams planning the migration, the most useful view of Foundry is a direct mapping from previous Azure AI services to their current Foundry equivalents. The summary below covers the transitions that matter most for production planning, along with the deadlines that determine how quickly each one needs to happen.

• Azure AI Studio → Microsoft Foundry portal. The Studio’s interface became Foundry’s primary developer portal. Both classic and new portal versions are currently supported, so existing Studio projects continue to open in the same place, now under the Foundry brand.
• Azure OpenAI Service → Foundry Models. The OpenAI Service SKU was not deprecated. It remains creatable as a standalone service and also appears inside Foundry’s broader model catalog, which now includes open-source options like DeepSeek and Grok alongside the OpenAI family.
• Azure Cognitive Services → Foundry Tools. Same capability set, exposed through Foundry’s tools layer with shared identity and observability.
• Assistants API → Foundry Agent Service. The new Foundry Agent Service runs on the Responses API. The Assistants API itself has a hard retirement date of August 26, 2026.

To be prepared and plan your Azure AI services migration to Microsoft Foundry properly and in advance, check on the retirement dates.

• Assistants API. Hard retirement date: August 26, 2026. Any production code that still calls the Assistants API will stop working after that date. Microsoft is replacing it with the Foundry Agent Service. Teams with Assistants API deployments should treat the migration as the highest-priority item on the Foundry roadmap.
• Azure Machine Learning SDK v1. End of support: June 30, 2026. Customers running ML SDK v1 in production need to migrate to v2 before this date. The companion AzureML CLI v1 extension already reached end of support in September 2025, so any infrastructure scripts still calling the v1 CLI today are running on unsupported tooling.
• Azure OpenAI Service. The SKU continues to operate normally and still receives new GPT models on the same delivery schedule it always has. The upgrade to Microsoft Foundry is opt-in and reversible, and the upgrade preserves the resource name, endpoint, key, existing fine-tunes, and PTU reservations. As of May 2026, teams that aren’t ready to commit to Foundry can stay on standalone Azure OpenAI without losing access to new capabilities.

A full mapping table of previous concepts to current equivalents is available in the official Microsoft Learn documentation.

Each of the four biggest gains from the Foundry consolidation closes a gap identified by industry research and mentioned before as a barrier to enterprise AI adoption.

• Faster compliance reviews and a single audit surface. Deloitte’s research on the gap between AI experimentation and production names inconsistent governance as one of the leading bottlenecks, alongside fragmented tooling and separate billing. Foundry runs under a single Azure resource provider. Before the consolidation, each of the five Azure AI services had its own. For platform and security teams, that turns five separate sets of role assignments, network rules, and audit configurations into one.
• Developer self-service within IT-approved guardrails. McKinsey research finds that generative AI tools can help engineers complete coding tasks up to twice as fast as traditional methods, but those gains disappear when IT bottlenecks slow workspace provisioning. Foundry ships with onboarding flows that accelerate configuration, with built-in support for virtual networks and organizational policy compliance. The practical effect is developer self-service within established IT governance frameworks, so engineering teams can stand up Foundry workspaces without waiting for platform-engineering tickets.
• Unified billing and cost management across AI capabilities. The Flexera 2026 State of the Cloud Report found that 85% of companies identify managing cloud spending as their top concern, and 29% of organizations still see waste in their cloud spend. Most of that waste correlates with fragmented billing surfaces that hide consumption from finance teams. Foundry brings AI spend that previously flowed through five separately metered services into a single billing surface. Finance teams can see total AI spend at the workspace or project level without reconciling exports from multiple resource types, and the single billing model makes chargebacks to business units more traceable than before.
• Multi-model flexibility through a single SDK. Gartner’s 2024 API Strategy Survey reports that 71% of digitized organizations now use APIs provided by third parties, with AI vendors among the most common providers. Foundry’s model catalog spans frontier proprietary models, smaller efficient models, and a growing set of open-source alternatives, all callable through one SDK. Teams can match the model to the workload (frontier capability for complex reasoning, lower-cost models for routine classification or extraction) without building custom routing logic or maintaining multiple vendor SDKs.

Now that you know the benefits that Azure AI consolidation into Microsoft Foundry can bring, let’s take a closer look at how it may affect your business.

The consolidation may affect you differently depending on whether you are already running Azure AI services or are still planning your first AI integration. Your situation determines whether the priority is a careful migration or a clean start.

Your existing integrations will not break overnight. As covered earlier, Azure OpenAI Service is not deprecated, and the upgrade to Foundry is opt-in and reversible. You still have room to plan, yet a migration roadmap is still essential. The retirement deadlines are real, and every month you wait adds new work built on patterns you will eventually have to move. The right approach depends on four questions:

1. Are you building agents? If your roadmap includes agentic workloads, prioritize migrating to Foundry’s agent layer, built for multi-agent orchestration.
2. Do you need non-OpenAI models? If you want open-source or non-OpenAI models, Foundry’s unified catalog is the path to them. If you only use GPT models, the standalone Azure OpenAI Service still works.
3. Do you have an Assistant API deployment? If yes, your timeline is set for you. The Assistants API retires on August 26, 2026, and that migration cannot wait.
4. Can your compliance posture absorb the role-assignment changes? The Foundry upgrade expands the set of role assignments your environment uses. For regulated organizations, that expansion needs a compliance review before the upgrade.

Work through these four questions, and your roadmap takes shape: the urgent items, the optional ones, and the items that need compliance sign-off first.

Start directly with Microsoft Foundry. There is no reason to build a new AI integration on the older, separate-service patterns when those patterns are already on a migration path.

This is more than a tooling preference. Microsoft Foundry represents a strategic platform shift toward agent-based architectures. Building on it from the start means your first AI project is already aligned with where Microsoft, and enterprise AI more broadly, is heading. Building on the legacy pattern means re-migrating before your project is even mature.

Knowing which situation you are in is the easy part. Turning that into a migration that does not disrupt production is the real work, and it is work that rewards starting early. The earlier you map your current footprint against the deadlines, the more options you keep open.

The 2026 retirement deadlines turn the Foundry migration from an open-ended project into a scheduled one. The five steps below put the work in the right order: the urgent, deadline-driven items first, then the larger migration decisions that need careful validation.

Start with a complete inventory. List every Azure AI service your teams use today: Azure OpenAI, Cognitive Services, AI Studio, the Machine Learning SDK, and any Assistants API deployments. For each one, record which applications depend on it and which team owns it.

Then flag anything with a 2026 retirement date or what’s already retired. Those items set your timeline. You cannot plan a migration until you know what you have and what is on the clock.

If you have Assistants API code in production, this is the most time-sensitive item on your list. The hard retirement date is August 26, 2026, with no extensions thereafter.

Microsoft provides a migration tool that moves Assistants API workloads to the Foundry Agent Service. Start there. The tool handles the mechanical aspects of the migration, freeing your team to focus on testing how the migrated agents actually behave.

Your team shouldn’t learn about a model retirement from a broken production system. Configure Azure Service Health alerts so you get automated notifications whenever Microsoft announces a change to a service you depend on.

Microsoft commits to advance notice before retiring models: at least 60 days for generally available (GA) models and at least 30 days for preview versions. Service Health alerts make sure that notice reaches the people who need to act on it.

For legacy hub-based projects, the recommended path is to move to Foundry projects. This gives you the latest APIs and the consolidated governance model. When you migrate, prefer the OpenAI SDK v1 endpoints, since they offer the broadest compatibility across models.

Do not rush this step. Validate private endpoints, compliance settings, and role assignments in a staging environment before you touch production. The upgrade is reversible, but a careful staging pass is still cheaper than a rollback.

For anything new, start on the foundation Microsoft is building toward. The Azure AI projects SDK unifies agents, inference, evaluations, and memory into a single package. If your roadmap includes agentic workloads, and for most enterprises and medium-sized companies it now does, this is the right SDK to start on. Building new projects on the older patterns only means migrating them again sooner.

Microsoft’s consolidation around Foundry is not something Azure customers can simply wait out. Some changes are opt-in, such as upgrading from Azure OpenAI Service, while others come with fixed deadlines. Either way, Microsoft’s direction is clear: standalone AI services are moving toward a unified Foundry ecosystem. The real question is whether your team will manage this transition proactively or be forced to react to it later.

The good news is that the destination is stronger than the starting point. Foundry reduces the integration and governance overhead that has slowed enterprise AI adoption for years. It gives teams a unified platform, a single SDK, and a more consistent governance model for building, deploying, and managing AI solutions. For most companies, the migration should become a net gain once the transition is complete.

The main challenge is timing. The August 2026 Assistants API retirement and the June 2026 Machine Learning SDK deadline are fixed, and every quarter spent building on old patterns creates more technical debt to unwind later. The teams that benefit most will be those that put the migration on a clear schedule and start early.

This is where an experienced AI development partner makes the difference. As a Microsoft Solutions Partner for Digital & App Innovation and Data & AI, Leobit can help you assess your Azure AI footprint, plan a migration that protects production systems, and build new workloads on Foundry from day one. If your stack is being reshaped by this consolidation, talk to our Azure team about where to begin.