Microsoft Foundry Workflows will be retired on December 1, 2026. If you have built workflows in the visual designer, now is the time to save those definitions and decide how to run them going forward.
Microsoft lays out three paths: keep orchestrating with the Microsoft Agent Framework, preserve visual business processes with Azure Logic Apps, or let one agent call another directly through A2A. The video demonstrates the first path; below I also explain what problems the other two are suited to solve. Official migration guide
After the retirement, the workflow designer and in-portal execution in the Foundry portal will no longer be supported. According to the documentation, YAML-based workflow definitions deployed as Hosted Agents will continue to run, and code-based orchestration inside existing Hosted Agents is unaffected by this retirement. Whether a given flow actually runs as-is still depends on checking its dependencies and running regression tests.
Before You Migrate: Save the YAML First
In the Foundry workflow designer, switch to the YAML view, copy or export the definition, and keep an untouched copy. It records the original flow's steps, agent calls, variables, and branches — the reference material you will compare against during migration.
Also note down the models, agents, tool connections, and authentication methods involved, plus a few test requests that cover the normal path, the branches, and any approvals. The YAML is useful reference material for all three paths, but do not assume that Logic Apps or A2A can import the file directly and restore the flow automatically.
Figure: three migration directions. The YAML serves as a reference for the original flow; if you adopt Logic Apps or A2A, you will need to redesign for the target solution and verify the result.
Path 1: Keep the YAML Running with Agent Framework
If you want to carry your existing multi-agent orchestration forward and your team can maintain YAML or code, Microsoft recommends most teams start with the Agent Framework. According to the documentation, in many cases the exported YAML needs only minor modifications to run inside an Agent Framework project; reimplementing the orchestration in code is also an option. Official migration notes
The news workflow in the video runs four agents in sequence: topic selection, fetching, filtering, and reporting. The demo adds the workflow YAML to a local Agent Framework project, loads and runs it with WorkflowFactory, and finishes by showing the resulting news output.
Video: export the workflow definition from Foundry, then load and run it in a local Agent Framework project.
This demo shows local execution. To host it on Foundry, you still need to prepare and deploy a Hosted Agent, then test how the deployment behaves. Another option is Generate Code in the Foundry Toolkit, which uses GitHub Copilot to convert the definition into Python or C#; the generated output needs human review — do not assume it is equivalent to the original flow. Toolkit migration guide
Whether you load the YAML or convert it to code, verify agent connections, branches, variables, and human approvals against the original definition. Power Fx expressions and external connections in particular deserve an item-by-item check of how the target implementation handles them.
Path 2: Preserve Visual Business Processes with Logic Apps
If your team needs to keep maintaining flows on a canvas, or the workflow mostly exists to connect business systems, consider Azure Logic Apps. It can trigger flows on events or schedules, and it combines conditionals, connectors, and calls to Foundry agents.
For example, when an expense reimbursement request arrives, Logic Apps reads the form, checks the required fields, and calls an expense-review agent; based on the result, the flow then moves to approval or a request for missing documentation, and finally updates the business system. The flow owns the fixed steps and the system connections; the agent handles understanding the submitted material or making the judgment call.
When migrating, first break the original flow down into "trigger, decisions, agent calls, waits, and writes," then rebuild it piece by piece. Pay close attention to how variables and expressions map over, how an in-flight approval resumes, and whether a retry might write the same data twice. The original YAML is a design reference, not a guarantee of automatic conversion.
Microsoft's Logic Apps integration guide applies to Logic Apps Standard; the capability it describes for bringing Foundry agents into workflows is currently in Preview and may incur charges. Before choosing this path, verify region, connection, authentication, and network requirements, and validate with your actual flow.
Path 3: Delegate Tasks Directly with A2A
If the original flow simply has one agent hand a task to another agent, consider Agent-to-Agent (A2A). For example, a customer service agent delegates a refund-policy question to a refund-policy agent, then continues its reply to the user based on what comes back.
The agent being called must expose an A2A-compatible endpoint; the caller must have the connection and authentication configured before it can make requests. If the target is also a Foundry agent, you need to enable incoming A2A as the documentation describes. Permissions on both sides, the context being passed, timeouts, and failure handling still need to be designed separately. Enable an A2A endpoint; Call A2A from a Foundry agent
A2A fits lightweight delegation, but it does not automatically replace a fixed, multi-step business process. If a task must look up an order, check the amount, wait for a supervisor's approval, and write back to the system — in that order — you need to manage sequencing, approvals, and failure recovery explicitly; consider hosting the flow in Logic Apps or Agent Framework and adding A2A calls where they help.
How to Choose Among the Three Paths
| Your primary need | Consider first | What to verify closely during migration |
|---|---|---|
| Carry existing orchestration forward; the team can maintain YAML or code | Microsoft Agent Framework | YAML compatibility, agent connections, branches and approvals; runtime behavior after deployment |
| Keep the visual canvas; flows need event triggers, cross-system connections, or human approvals | Azure Logic Apps | Rebuilding the flow, connection authentication, retries and approvals; the Preview status of the Foundry agent integration |
| One agent just needs to delegate a task to another | A2A | Endpoints, identity and permissions, the context passed, timeouts, and error handling |
The paths can also be combined: for example, Logic Apps owns the business process, and agents inside the flow delegate specialized tasks through A2A. When choosing, first decide who owns the process sequence, who does the reasoning, and who handles errors when they happen.
After the migration, compare old and new behavior with the same set of requests: does the happy path complete, do edge cases take the right branch, can approvals wait and resume, and do external-service failures leave information you can diagnose? For an agent's natural-language answers, do not demand word-for-word matches — but the business conclusions, the tool calls, and the actual writes should match what you expect.
You can outsource your thinking, but you cannot outsource your understanding.
Official References
- Build a workflow in Microsoft Foundry: retirement announcement and migration guide
- Use and migrate declarative agent workflows with Microsoft Foundry Toolkit
- Automate Foundry agents with workflows in Azure Logic Apps (Preview)
- Enable incoming A2A on a Foundry agent
- Connect to an A2A agent endpoint from Foundry Agent Service
Top comments (0)