Microsoft merged both frameworks into Agent Framework, which reached general availability (1.0) in April 2026. Whether you need to migrate right now depends on your situation.
What Happened
In October 2025, Microsoft announced that AutoGen v0.4 and Semantic Kernel were entering maintenance mode and converging into a new unified product: Microsoft Agent Framework, which reached 1.0 (general availability) in April 2026 with stable APIs and long-term support for .NET and Python. Both Semantic Kernel and AutoGen continue to receive bug fixes and security patches -- Microsoft has committed to critical bug fixes for Semantic Kernel for at least one year after Agent Framework's GA. Neither will receive new orchestration features, new agent patterns, or new plugin types.
The community reaction was mixed: some teams had significant codebases on Semantic Kernel and were not expecting to migrate. Others were relieved to have a single Microsoft-endorsed path. This article explains what maintenance mode actually means for your day-to-day work, and when you genuinely need to migrate.
What Maintenance Mode Does and Does Not Mean
| Will continue to receive | Will NOT receive |
|---|---|
| Bug fixes | New orchestration patterns |
| Security patches | New plugin types or connectors |
| LLM compatibility updates (new models) | Performance improvements |
| Documentation corrections | New agent memory or planning capabilities |
| Critical dependency updates | New framework features of any kind |
Practically speaking: if your Semantic Kernel or AutoGen application works today, it will continue to work. Your workflows will not break. You will not be forced to migrate on any specific timeline. Maintenance mode means 'we are not investing in new features' -- it does not mean 'we are switching it off.'
Do not let 'maintenance mode' trigger a panic migration. Rushed migrations introduce bugs and break working systems. Evaluate migration against your actual requirements, not against a vague fear of being left behind.When You Should Migrate Now
- You are starting a new project and have no existing codebase to preserve -- use Microsoft Agent Framework from the start
- Your use case specifically requires enterprise features only in Agent Framework: Azure AD identity, RBAC, SOC 2 compliance, audit logs
- You are on Semantic Kernel and need a new agent orchestration pattern -- it will not come to SK now
- Your organisation's cloud strategy is fully Azure and you want the tightest possible Microsoft integration
When You Should Not Migrate Yet
- Your existing Semantic Kernel or AutoGen application works and meets your requirements
- You do not need any new features -- the existing feature set is sufficient
- Migration risk is high (large codebase, no dedicated migration time, production traffic)
- You are on Semantic Kernel for Java -- Microsoft Agent Framework (GA since April 2026) supports only .NET and Python, with Go support in progress; there is no Agent Framework migration path for Java yet
What Microsoft Agent Framework Adds
If you do decide to migrate, here is what you gain over Semantic Kernel:
| Feature | Semantic Kernel | Microsoft Agent Framework |
|---|---|---|
| Multi-agent orchestration | Limited | Full (AutoGen-style group chat patterns) |
| Azure AD identity | Manual setup | Native, built-in |
| Role-based access control | Not available | Native |
| Compliance (SOC 2, HIPAA) | Manual | Platform-level |
| Language support | C#, Python, Java | C#, Python (GA); Go in progress. No Java support -- Java stays on Semantic Kernel. |
| Plugin system | SK plugin model | No plugin/Kernel wrapper -- plain function tools (existing KernelFunctions convertible via .as_agent_framework_tool()) |
Migration Path from Semantic Kernel
Microsoft Agent Framework does not carry over Semantic Kernel's Plugin/Kernel wrapper -- tools in Agent Framework are plain Python functions or methods passed directly to an agent. Existing Semantic Kernel KernelFunction objects (including whole plugins) can be reused without rewriting their internal logic via a compatibility method, .as_agent_framework_tool() (requires semantic-kernel 1.38 or later). The primary migration work is in the orchestration layer (how agents are composed and run) and in adapting to Agent Framework's plain-function tool model.
# Semantic Kernel (current)
import semantic_kernel as sk
kernel = sk.Kernel()
kernel.add_plugin(MyPlugin(), plugin_name="my_plugin")
# Microsoft Agent Framework (migration target)
# pip install agent-framework
# Agent Framework has no Plugin/Kernel wrapper -- tools are plain functions.
# Existing @kernel_function methods can be reused via the compatibility
# layer (requires semantic-kernel >= 1.38):
from agent_framework.openai import OpenAIChatClient
my_plugin = MyPlugin()
agent_tool = my_plugin.some_kernel_function.as_agent_framework_tool()
agent = OpenAIChatClient(model="gpt-4o").as_agent(tools=agent_tool)
# What changes: agent composition (Kernel -> plain function tools) and
# orchestration patterns (refer to the official Semantic Kernel ->
# Agent Framework migration guide for specifics)Before migrating any production system, run Microsoft Agent Framework in a staging environment with your existing SK plugins for at least two weeks. Verify that plugin behaviour, tool calling, and LLM responses are equivalent before cutting over production traffic.Quick Reference
- Maintenance mode = no new features, not shutdown. Existing apps continue to work.
- Bug fixes, security patches, and LLM compatibility updates continue for both frameworks.
- Migrate now if: starting new project, need enterprise features, or are Azure-only.
- Do not migrate now if: existing app works, migration risk is high, or you need Java (Agent Framework does not support it yet).
- SK plugin logic can be reused via the .as_agent_framework_tool() compatibility method (semantic-kernel 1.38+) -- but Agent Framework has no Plugin/Kernel wrapper, so the orchestration layer and tool-registration pattern are the primary migration cost.