December 1, 2026 is an important date for teams using preview declarative workflows in Microsoft Foundry. Microsoft has announced the retirement of that low-code workflow experience and recommends Microsoft Agent Framework for new workflow development. Code-based orchestration in hosted agents is not affected.
It is tempting to see this as a YAML migration exercise. In practice, the difficult part is preserving the behavior around the workflow: who can invoke a tool, when a human must approve an action, what happens after a timeout, and how operators know something has failed.
Start with the workflows that matter
Before choosing a replacement runtime, identify what is actually running. For each workflow, capture its trigger, inputs, outputs, connected systems, business owner and any manual approval. Pay particular attention to steps that create records, send notifications, update databases or trigger downstream processes.
Export the existing definitions and put them under version control. Review parameters and connections before committing anything: credentials and environment-specific secrets should not end up in source control. The export is useful documentation, but it is not a guarantee of one-to-one compatibility with the target runtime.
Also ask whether every workflow needs an agent. If a process is mostly deterministic integration between enterprise systems, Azure Logic Apps may be worth evaluating. Where dynamic reasoning, agent collaboration or custom execution control is central, Microsoft Agent Framework is a more natural candidate. Choose based on the process, not on the product name.
The problem a successful demo can hide
Consider a workflow that checks a request, waits for approval and then creates an order through an external API. The API completes the operation, but the network connection times out before the workflow receives confirmation. If the next run simply retries, the business may end up with two orders.
That is why migration testing needs more than a comparison of final answers. Side-effecting operations should have idempotency or deduplication controls. Long-running steps need recoverable state. Approvals should be associated with the correct request and identity, and operators should be able to distinguish a failed call from an unknown outcome.
Security needs the same attention. Rebuild tool permissions explicitly, use least-privilege identities where supported, and make sure sensitive data does not leak into logs or agent traces. A workflow that produces the right output with excessive permissions is not a successful migration.
Make the cutover boring
I would approach the transition in four passes:
- Inventory: rank workflows by business impact and identify dependencies that could break.
- Rebuild: implement tool contracts, approvals, state handling and observability in the chosen runtime.
- Validate: test normal cases alongside timeouts, retries, permission failures and partial completion. Use shadow execution or test environments so validation does not duplicate real transactions.
- Cut over: move traffic in controlled stages, watch error rates and keep a documented rollback option.
Before switching a critical workflow, agree on what success looks like. That might include acceptable execution latency, a maximum failure rate, audit coverage and the time needed to recover an interrupted process. These measures are more useful than declaring success because a handful of prompts worked in a test environment.
What I would prioritize now
Start with one workflow that has a real external dependency and a meaningful failure mode. It will expose the questions a simple demonstration cannot: how state survives, how tools authenticate, who owns an exception and whether a retry is safe. Use what you learn to establish a repeatable migration pattern for the rest of the estate.
The deadline creates urgency, but it should not drive a rushed replacement. The goal is not to recreate the old canvas. It is to arrive at a workflow that is easier to operate, secure and recover when production behaves differently from the demo.
Reference: Microsoft Foundry workflow migration guidance. More on enterprise Gen AI architecture.
