Copilot to Azure AI Foundry Migration Guide (2026)

Short answer: A Copilot-to-Foundry migration moves your heaviest custom Copilot agents off the Copilot Credits meter and onto Azure AI Foundry, where they run on Azure consumption with per-agent cost controls, governance, and observability. You do not move everything. You move the agents that drive the bill or need governance, keep the lightweight ones in Copilot Studio, and retire the duplicates. This guide covers why, which agents, what Microsoft’s own tools do and do not automate, and how a funded migration runs.

Why teams are moving Copilot agents to Foundry

In 2026 the agentic part of Microsoft Copilot runs on a meter. Custom agents built in Copilot Studio, Azure AI Foundry, or third-party frameworks bill on Copilot Credits, and the credits pool at the tenant level. Grounding, reasoning, and tool calls each add credits, so two agents that look identical to a user can land bills fifty times apart. The result is a Copilot line on the Azure invoice that climbs with usage and that nobody budgeted for.

The full mechanics, the credit rate card, and why one agent can cost 100x another are in why your Copilot bill went variable. The takeaway for this guide: the architecture is the budget, and the fix for the expensive agents is to move them to a platform where cost is governed and predictable.

Step 1: Decide what to move

A migration is a series of per-agent decisions, not one estate-wide switch. Run each agent through four outcomes:

• Keep in Copilot Studio: low-volume, scripted, cheap, business-owned copilots. Leave them as the front door.
• Move to Azure AI Foundry: high-volume, reasoning-heavy, tool-calling, or mission-critical agents that drive the bill.
• Move for governance: any agent touching regulated data, needing data residency, private networking, or a first-class agent identity.
• Retire: duplicate or unused agents, recovered at zero migration effort.

The full framework, including how Copilot Studio and Foundry differ as platforms and what a “custom engine agent” is, lives in Copilot Studio vs Azure AI Foundry: keep or move.

Step 2: Understand what Microsoft’s tools cover

Microsoft ships agentic migration tools that speed the work: the Azure Copilot Migration Agent plans cloud moves, and GitHub Copilot App Modernization upgrades Java and .NET application code. They automate the planning and the code. They do not execute the cutover, convert your Copilot apps into Foundry agents, secure the funding, or run the estate afterward.

Knowing exactly where the tools stop keeps a migration realistic. The breakdown is in Microsoft’s AI migration tools: what they can’t do.

Step 3: Run the migration

With the decisions made and the tools understood, the migration itself follows a repeatable shape:

1. Inventory and price the estate. Model current Copilot Credits spend per agent against projected Azure consumption, so every move has a before-and-after number.
2. Pre-qualify Microsoft funding. Programs like ECIF, ACO, and co-op fund qualifying work, but the nomination is filed before work begins.
3. Convert the heavy agents to Foundry custom engine agents. Rebuild orchestration on Foundry Agent Service, wire in grounding and tools, and give each agent its own Entra Agent ID.
4. Republish to Teams and Microsoft 365 Copilot through a stable endpoint, so users see no change.
5. Cut over and validate in waves, with rollback ready, so production is never at risk.
6. Operate the estate afterward: monitor cost, watch for drift, and manage versions.

Step 4: Keep it governed after go-live

Migration is not the finish line. Foundry agents need ongoing cost management, monitoring, and version control, and new agents keep appearing across the estate. The account that keeps working after go-live is the one where every agent stays inventoried, priced, and owned.

FAQ

What is a Copilot to Azure AI Foundry migration? It is the process of moving your heaviest custom Microsoft 365 Copilot and Copilot Studio agents onto Azure AI Foundry, where they run on Azure consumption with per-agent cost controls, governance, and observability, instead of metering Copilot Credits from a shared tenant pool.

Which agents should move to Foundry, and which should stay? Move the high-volume, reasoning-heavy, tool-calling, or regulated agents that drive the Copilot Credits bill or need governance. Keep lightweight scripted copilots in Copilot Studio, and retire duplicates. The decision is made per agent with real cost and usage data.

Does Microsoft fund the migration? Often, yes. Microsoft funds qualifying Copilot-to-Foundry and Azure migration work through programs like ECIF, ACO, and co-op. The funding has to be pre-qualified and filed before work starts; Microsoft’s migration tools do not do this for you.

Will users be disrupted during the migration? No, when it is done right. A migrated agent republishes to Microsoft Teams and Microsoft 365 Copilot through a stable endpoint, so people reach the same agent in the same place while the engine underneath changes.

---

Start with the number. Onepane runs a two-day Agent Readiness Assessment that inventories every Copilot agent, models Copilot Credits spend against projected Azure consumption, and hands you a per-agent keep, move, or retire plan. Microsoft funding covers most of the migration that follows. Model your ROI or book a demo.