Konstantin Semenenko
July 29, 2026
4
minutes read
First decide whether to migrate at all: if your Semantic Kernel system works and does not need Agent Framework's new features, staying is valid, this is a how-to for teams that have decided the new capabilities are worth it. The migration itself is an evolution, not a rewrite. Both frameworks share the Microsoft.Extensions.AI foundation, so your model-access layer largely carries over, and the work concentrates in three layers: package and namespace updates (mechanical), agent construction and plugins-to-tools (moderate), and orchestration (the real work, and the biggest gain). Do it incrementally, verifying at each step, not as a big-bang rewrite.
This is a practical guide to migrating a Semantic Kernel system to Microsoft Agent Framework, written for teams that have decided to do it. That qualifier matters, because migration timing depends on your situation. Semantic Kernel is in maintenance and done getting new features, so new work belongs on Agent Framework and a Semantic Kernel system hitting its limits should move, the argument we make in build new .NET agents on Microsoft Agent Framework. So the first step of any migration is confirming you actually want its results: the improved multi-agent orchestration, durable execution, or native MCP and A2A that Agent Framework added. If you have made that call, the good news is that this is an evolution rather than a from-scratch rebuild, because the two frameworks share a foundation. This walks through what carries over, what changes, and how to sequence the work.
We migrate .NET agent systems between these frameworks, so this is the practitioner's version, not a changelog.
The most important step happens before you touch any code, because the wrong reason to migrate leads to work with no payoff. Migrating because Agent Framework is newer is not a reason; migrating because you need something it has is. Good reasons: you want the unified multi-agent orchestration (sequential, concurrent, handoff, group patterns) that is more capable than Semantic Kernel's, you need durable execution and checkpointing for long-running workflows that must survive restarts, or you want native MCP and A2A rather than building that integration yourself.
Weak reasons: the system works fine but you feel you should be on the latest thing, or a blog post said Semantic Kernel is dead. A functioning Semantic Kernel application that does not need the new capabilities gains little from migration and costs real effort, which is the over-automation trap of doing work that costs more than it returns, covered in the cost of over-automation. So before planning the migration, write down the specific Agent Framework capability you are migrating to get. If you cannot name one, the migration is probably not worth doing yet. If you can, the rest of this guide is for you.
The reason this is a migration and not a rewrite is that the foundation is shared, and knowing what stays stable tells you where not to spend effort. Both Semantic Kernel and Agent Framework build on Microsoft.Extensions.AI, the provider-agnostic abstraction layer (IChatClient, embeddings, tools), so the layer where your code connects to models is largely unchanged, the layer we cover in Microsoft.Extensions.AI explained. Your model provider configuration, your embedding setup, and much of the surrounding infrastructure carry over with little change.
The conceptual model carries over too, which makes the migration mostly a matter of translating between two dialects rather than learning a new language. Semantic Kernel and Agent Framework both have the concepts of agents, tools (plugins), and function calling; what changes is the API used to express them, not the ideas. And the non-AI parts of your application, business logic, data access, web layer, are untouched entirely. So the migration is contained: it touches the agent and orchestration code specifically, and leaves the model-access layer and the rest of the application largely alone. That containment is what makes it plannable.
The work sorts into three layers by effort:
The shape of the work: mechanical at the bottom, translation in the middle, genuine redesign at the top, where the new capabilities live.
The failure mode is trying to migrate everything at once and losing the ability to tell what broke. The approach that works is incremental, with verification at each step:
Sequenced this way, you always have a working system and a clear picture of what each change did, which is what keeps a migration from becoming a rewrite in disguise.
Migrating from Semantic Kernel to Microsoft Agent Framework starts with confirming you should: Semantic Kernel is in maintenance, not dead, so migrate only to get a specific capability, improved multi-agent orchestration, durable execution, or native MCP and A2A, not because the newer framework exists. Once you have decided, it is an evolution rather than a rewrite, because both share the Microsoft.Extensions.AI foundation: the model-access layer and non-AI code largely carry over, and the work sorts into mechanical package and namespace changes, moderate agent and plugin translation, and the real effort of rebuilding orchestration, which is also where the new capabilities pay off. Do it incrementally with verification at each step, and it stays a controlled migration rather than a big-bang rebuild.
If you want a Semantic Kernel system migrated to Microsoft Agent Framework cleanly, or help deciding whether the migration is worth it for your case, that is worth a conversation. Book a 15-minute call and we will scope it for your codebase.
Should I migrate from Semantic Kernel to Microsoft Agent Framework? Only if you need a capability Agent Framework added: improved multi-agent orchestration, durable execution and checkpointing, or native MCP and A2A. Semantic Kernel is in maintenance but still works and is supported, so a system that does not need those features is fine to leave in place. Migrate to get something specific, not because the newer framework exists.
Is migrating from Semantic Kernel a full rewrite? No. Both frameworks build on the same Microsoft.Extensions.AI foundation, so your model-access layer and non-AI code largely carry over, and the core concepts (agents, tools, function calling) are preserved with changed APIs. The real work is in the agent construction, plugin-to-tool mapping, and orchestration layers, not the whole application.
What is the hardest part of the migration? The orchestration layer. Package and namespace changes are mechanical, and agent and plugin migration is mostly translation between APIs, but orchestration is rewritten into Agent Framework's unified model. That is also where the payoff is, since it is where durable execution and the improved multi-agent patterns live, the capabilities you migrated to get.
How long does a Semantic Kernel to Agent Framework migration take? It depends on how much orchestration you have, since that is the substantive layer. The mechanical and translation layers are fast; the orchestration rebuild scales with complexity. Doing it incrementally, one agent at a time with verification, spreads the work and keeps a working system throughout rather than concentrating risk in a big-bang cutover.
Can I run Semantic Kernel and Agent Framework side by side during migration? Yes. Because both build on Microsoft.Extensions.AI, they can coexist in the same estate, which is what makes an incremental migration possible, you move agents one at a time rather than converting everything at once, keeping the system running throughout.
