# Azure AI Foundry Classic vs New: Hub vs Foundry Projects

*Published 2026-02-24 · Dmitry Shirokov · shirokoff.ca/blog/azure-ai-foundry-classic-vs-new · as of February 2026*

A developer filed a ticket saying Microsoft's Agent Service quickstart was wrong — step three's option didn't exist in his portal. He was right about what he saw and wrong about why: his project was a **hub-based project**, the quickstart was written for a **Foundry project**, and the feature only exists on one of them. Not a flag, not a region — a different Azure resource type. That cost most of a sprint. **Azure AI Foundry is one product name over two resource architectures, and which one you deployed determines which features you can even see.**

## Why two shapes exist

The hub shape is Azure ML's family tree showing through: a **hub** is a shared collaboration container holding connections, compute quotas, a managed VNet, and security config; **projects** are child workspaces inheriting all of it. One platform team configures once, five product teams get correctly-networked projects. Genuinely good at that — and heavy for a team that just wants a model endpoint and an agent. So Build 2025 introduced a **Foundry resource** (an AI Services account) with lightweight **Foundry projects** as children: self-serve, project-scoped, no hub in the path. The community calls the older world "classic."

The detail that matters for IaC: **they're in different Azure provider namespaces.** A hub is `Microsoft.MachineLearningServices/workspaces` (kind Hub, with kind Project children). A Foundry resource is `Microsoft.CognitiveServices/accounts` (kind AIServices, with `/projects` children). Different RBAC roles, different networking primitives, different diagnostic targets.

## Capability split (February 2026)

| Capability | Hub-based (classic) | Foundry project (new) |
|---|---|---|
| Foundry Agent Service (GA) | Not the path forward | **Yes** — where agent features land |
| Foundry API / project endpoint | No | **Yes** |
| New model families | Lags | **First** |
| Prompt flow authoring | **Yes — only here** | No |
| Managed-compute open-weight hosting | **Yes — only here** | No |
| Azure ML integration (jobs, pipelines, registries) | **Yes** | No |
| Hub-level connections + managed VNet | **Yes** | Account-level, Cognitive Services networking |
| Self-serve project creation | Platform-team gated | **Yes** |

**Prompt flow and managed-compute open-weight hosting are the two real reasons to still be on a hub.** Everything else argues for the new shape.

## Migration: what moves, what doesn't

**Moves:** model deployments, data files, fine-tuned models, assistants, vector stores.
**Doesn't:** preview **agent state** (threads, messages, uploaded files), **managed-compute deployments** (no target to move to), **hub project RBAC** (re-grant on the new resource), prompt flows, hub-level connections.

Plan a migration as a **cutover where conversation history starts fresh** — if your product promises users their history, that's a data-migration project you write yourself, and it belongs in the plan rather than the retro. Good argument for persisting session state in a schema you own, not only the platform's.

Hard date: **the Azure OpenAI Assistants API retires August 26, 2026.** Assistants migrate across shapes but are a dead end either way — build new work on Agent Service + the Responses API.

## IaC, networking, identity

Three consequences: (1) **your hub module isn't a starting point** — budget a new IaC module, new policy assignments, new diagnostic targets; (2) **agent storage is a decision now** — the Agent Service basic setup lets the platform manage thread/file storage, the **standard setup** brings your own Storage + Cosmos DB for NoSQL + AI Search, and anything with residency, CMK, or auditability requirements needs standard (far easier to start there than move later); (3) **don't forget the third resource type** — a plain Azure OpenAI account still works and is still right if all you want is inference behind your own gateway.

Minimum viable new-shape deployment: `az cognitiveservices account create --kind AIServices --custom-domain <name> --assign-identity` (custom subdomain is required for token auth and private endpoints), then set `properties.disableLocalAuth=true` — if a developer can copy a key into a notebook, someone will — then create the project and grant the app's managed identity **project-scoped** roles. Project-scoped RBAC is the point of this shape.

## The trap

**Two portals, and quickstarts that create the wrong resource.** "My colleague can see it and I can't" is usually two people looking at two resource types, not a permissions bug, and nobody checks the resource type first. Worse: plenty of tutorials and one-click templates still provision a *hub*, so a developer following a blog post in the morning can create the architecture you rejected in the afternoon. Two free defences: put the resource type in your naming convention so it's visible in the resource list, and add an Azure Policy denying `Microsoft.MachineLearningServices/workspaces` of kind `Hub` outside the subscriptions where hubs belong. Then the ticket says "policy blocked me" — a five-minute conversation instead of a sprint.

## What to deploy

**New work: Foundry project**, without much deliberation. Existing hub estate, three cases: (1) depending on prompt flow or managed-compute hosting → stay, plan, but stop *adding* to the prompt-flow surface; (2) hub but only models and chat → the easy migration, worth doing soon, roughly a week mostly testing; (3) running both deliberately → fine and common, but the failure is *ambiguity* about which shape a workload belongs to, so write it down, name an owner per shape, and let the naming convention carry the answer.

Keep the application's dependency on Foundry behind an interface — model client, agent invocation, thread persistence, three seams. Teams that called SDKs from business logic did the hard migration; teams with a thin adapter did the easy one. The platform has already changed shape twice.

## Carry-away

One name, two architectures; knowing which you're on is a prerequisite for reading the docs correctly. Hub-based = Azure ML workspaces under a shared hub, still the only home for prompt flow, managed-compute open-weight hosting, and deep Azure ML integration. Foundry projects = children of an AI Services account: lighter, self-serve, project-scoped RBAC, where features actually ship. Migrate the models-and-chat cases; leave prompt-flow ones until there's somewhere to go; remember agent threads, managed-compute deployments and RBAC don't come with you; put the Assistants retirement on the roadmap; choose the standard agent setup if you have any residency or key-management requirement. Then name resources so the shape is obvious, block accidental hubs with policy, and keep an adapter between your app and whichever Foundry you're on.

*Related: [Agent frameworks compared](https://shirokoff.ca/blog/agent-frameworks-compared) · [RAG on Azure](https://shirokoff.ca/blog/rag-on-azure) · [Agent memory](https://shirokoff.ca/blog/ai-agent-memory) · [Regulated multi-agent design](https://shirokoff.ca/blog/regulated-ai-multi-agent-design) · [LLM gateway routing and fallback](https://shirokoff.ca/blog/llm-gateway-routing-fallback) · [Fabric vs Databricks](https://shirokoff.ca/blog/fabric-vs-databricks)*