Azure OpenAI to Azure AI Foundry Consolidation: Migrating Existing Deployments

Organisations that adopted generative AI early often began with a standalone Azure OpenAI Service resource, provisioned quickly to test summarisation, retrieval augmented generation, or document processing against a defined use case. As Microsoft consolidates these capabilities into the unified Azure AI Foundry platform, teams that built on the earlier model resource face a shift in how deployments are organised, governed, and connected to the wider estate. This is not simply a rebrand, because the consolidation changes the underlying resource topology, the way quota is requested and tracked, and the mechanisms available for network isolation.

For enterprise and government teams operating under sovereign data obligations, the priority is to replatform without losing continuity of service or the controls that made the original deployment approvable in the first place. The good news is that Microsoft has designed the transition to preserve existing model deployments and endpoints where possible, but the details matter. This article sets out what changes at a practical level and how to plan a migration that maintains security posture, auditability, and predictable performance.

What the consolidation actually changes

Azure AI Foundry, formerly presented as Azure AI Studio, brings model access, agent tooling, evaluation, and content safety into a single environment rather than requiring teams to assemble discrete services. Under this model, an Azure AI Foundry resource can host multiple projects, and model deployments that were previously tied to a lone Azure OpenAI resource now sit within a broader hub and project structure. The practical effect is that the resource you manage in the portal, and the way you reason about scope and access, both change even when the models themselves remain familiar.

Existing Azure OpenAI resources continue to function, and their deployments and API endpoints do not disappear when Foundry becomes the primary surface. However, new capabilities, tooling, and management workflows increasingly assume the Foundry resource type, so continuing to operate solely against the legacy shape gradually limits access to newer features. Teams should therefore treat the consolidation as a deliberate migration to plan and schedule, rather than an event that happens to them, so that they retain control over timing, testing, and change approval.

Resource management, identity, and quota

The most immediate operational change concerns how resources are grouped and secured. In the Foundry model, a hub provides shared configuration such as connections, security settings, and networking, while projects inherit from it and hold the workloads that teams actually build. This encourages a cleaner separation between platform governance and application development, but it also requires you to map existing role assignments, managed identities, and resource group boundaries onto the new structure so that least privilege access is preserved rather than accidentally widened.

Quota handling deserves particular attention because model capacity is expressed and allocated at the level of the deployment and the region, and it remains a finite resource that must be requested and monitored. When you replatform, you should confirm that provisioned throughput or standard deployment quota is available in your chosen Australian region before cutover, rather than assuming it transfers automatically. Establishing quota headroom in advance, and testing under representative load, prevents the situation where a migrated workload throttles because capacity assumptions from the original deployment no longer hold.

Network isolation and sovereign controls

For government and regulated enterprise workloads, network isolation is frequently the control that determines whether a deployment is permitted at all. Azure AI Foundry supports private connectivity through Azure Private Link and private endpoints, allowing traffic to model endpoints to traverse the Microsoft backbone rather than the public internet. When migrating, you must recreate or extend these private networking configurations against the new resource and hub, validate DNS resolution for private endpoints, and confirm that outbound access from the Foundry environment is constrained in line with your existing policy.

Sovereignty and data residency requirements also warrant explicit verification during replatforming. Confirm that the resources are provisioned in an Australian region such as Australia East, review where prompts, completions, and any logging or evaluation data are stored and processed, and align these findings with your obligations under frameworks such as the Australian Government Information Security Manual. Because the Foundry structure introduces shared hub level configuration, it is worth reconfirming that customer managed keys, diagnostic logging destinations, and content filtering settings are applied consistently, so that the assurances documented for the original deployment continue to hold after migration.

Planning a controlled migration

A disciplined migration begins with a full inventory of what exists today, including every model deployment, its version and capacity, the applications and integrations that call it, and the identities and network paths involved. With that baseline established, you can stand up the Foundry hub and project structure in parallel, replicate networking and security controls, and deploy equivalent models before any traffic is redirected. Running the old and new environments side by side allows you to test functional parity, latency, and content safety behaviour under real conditions rather than discovering discrepancies after cutover.

Cutover itself should be staged and reversible, ideally shifting a subset of traffic first and retaining the ability to roll back to the original endpoints until confidence is established. Update client configuration, keys, and endpoint references through your normal change management process, monitor for errors and throttling, and only decommission the legacy resource once the new environment has proven stable across a representative period. Treating the consolidation as a governed project, with clear ownership of quota, networking, and data residency verification, gives enterprise and government teams the continuity they need while positioning their AI workloads on the platform Microsoft is actively developing.

References

• Azure AI Foundry documentation
• Configure private link for Azure AI Foundry
• Australian Government Information Security Manual (ISM)