By Michael Branson, Founder/COO, i3solutions

Quick answer. If a review flags the SDK, Microsoft’s archive notice (September 2026) states: “Support tickets for the Bot Framework SDK will no longer be serviced as of December 31, 2025”. Move code-heavy bots to the Agents SDK and content bots to Copilot Studio where your cloud offers the channel.

The bot still answers the questions it answered last year. What changed is underneath it: a security review or a failed support ticket has surfaced that the SDK the bot is built on no longer gets serviced tickets or product updates, and its source repositories are archived. One voice says move it to Copilot Studio, another says rewrite it on the new SDK, and neither can be defended until you know how the bot was built and which cloud it runs in. This guide sets out what Microsoft states, what does not come across, the criteria that pick a destination for each bot, and the order to run the move in.

What Microsoft Says About the Bot Framework SDK

If a scan or an audit has flagged the SDK under a production bot, start from Microsoft’s own wording. The archive notice at the top of Microsoft’s botbuilder-js repository reads: “This means that this project will no longer be updated or maintained. Customers using this tool will not be disrupted.” The same notice states: “Support tickets for the Bot Framework SDK will no longer be serviced as of December 31, 2025.” GitHub shows the repository as archived and read-only, and the .NET and Python repositories carry the same notice.

Read together, those sentences say two things. A running bot is not switched off, and the path for vendor help and fixes is closed. Microsoft’s migration guidance names the successor directly: “The Microsoft 365 Agents SDK is the evolution of the Azure Bot Framework SDK.”

Microsoft’s Two Named Destinations

When the question is where the bot should go, Microsoft’s archive notice names two places. For code: “To build agents with your choice of AI services, orchestration, and knowledge, consider using the Microsoft 365 Agents SDK”. For a managed platform: “If you’re looking for a SaaS-based agent platform, consider Microsoft Copilot Studio.” Both sentences sit in the notice on Microsoft’s botbuilder-js repository, which adds: “If you have an existing bot built with the Bot Framework SDK, you can update your bot to the Agents SDK.”

The two are different kinds of thing. Microsoft’s Agents SDK overview states: “The Microsoft 365 Agents SDK is a development framework for building conversational agents.” and “The Agents SDK isn’t an AI model, an orchestration engine, or a no-code builder.” Copilot Studio is the SaaS platform in Microsoft’s second sentence, where agents are built and managed in the product rather than in a code base. How a Copilot Studio build runs as an engagement is covered in Microsoft Copilot Studio Development Services for Enterprise-Grade Custom Copilots.

What Does Not Come Across

Before anyone picks a destination, list what each bot depends on, because that list sets the size of the move. Microsoft’s migration guidance introduces its table this way: “Bots requiring these functionalities can’t migrate without implementing alternatives:”. Among its rows are these, with Microsoft’s reason quoted:

Functionality Microsoft’s reason, quoted
Adaptive Dialogs “Microsoft doesn’t plan to move this system into the Agents SDK.”
Bot Framework Composer Artifacts “are no longer required and aren’t being brought forward.”
Previous Generation AI Tooling “Tools such as LUIS, Orchestrator, and QnA Maker are no longer needed. The online services for these tools are already disabled. Existing bots that depend on these services need to migrate to different tooling.”
BotFrameworkAdapter “Replaced by CloudAdapter in Bot Framework, and removed from the Agents SDK.”

Read the rest of the table on Microsoft’s page against your own inventory. For a bot built in Composer on Adaptive Dialogs, those parts need alternatives before it can move to the Agents SDK; a bot written in code against the core SDK is closer to a port.

Criterion One: How Much of the Bot Is Custom Code

If the bot’s value sits in code your developers wrote, such as orchestration, calls into line-of-business systems or a custom channel, the Agents SDK keeps that code in a code base. Microsoft’s Agents SDK overview describes the model: “You write your agent logic once, and the SDK translates incoming and outgoing messages to and from the format each channel expects.” That suits a bot a development team will keep maintaining.

Where the bot is mostly question-and-answer content and simple dialogs, and the people who own the content are not developers, Copilot Studio is the closer fit: Microsoft’s archive notice names it for a “SaaS-based agent platform”. Scoping a first agent of that kind is the subject of a separate i3solutions guide, A Copilot Studio IT Help-Desk Agent for a Regulated Tenant: A Guide to Scoping the First Agent and Its Data Boundary. Where the bot will sit among declarative and custom engine agents is covered in Copilot Integration Architecture: Four Paths, One Sequence.

Criterion Two: Which Channels and Which Cloud

If the bot serves Teams users in a GCC High tenant, settle this criterion before the others. Microsoft’s article on deploying Bot Framework bots to Azure Government and Office 365 GCC High states: “Currently, only the Microsoft Teams channel is available in the Office 365 GCC High environment.” In that environment, then, a Bot Framework bot reaches its users through Teams.

Copilot Studio’s listing for that cloud reads differently. As read in September 2026, Microsoft’s Copilot Studio for US Government customers article marks “Teams & M365 Copilot Channel” as “Yes” under “Available in GCC” and “No” under “Available in GCC High”. For a GCC High Teams bot, that row decides against Copilot Studio as the destination until Microsoft’s listing changes.

This guide makes no statement about the Agents SDK in government clouds, because none of the Microsoft pages read for it addresses that: confirm support for your cloud with Microsoft before you plan that path. Where the criteria point different ways, this one takes precedence: a destination that does not offer the bot’s channel in your cloud is not yet a destination. How Copilot Studio and Azure AI Foundry compare on compliance posture is covered in Copilot Studio vs Azure AI Foundry: Which One Fits Your Compliance Posture?

Criterion Three: Keep a Pro-Code Bot and Call It From Copilot Studio

When the business wants Copilot Studio as the front door but one bot carries logic too specialized to rebuild there, there is a third shape. Microsoft’s Azure Bot Service skills article states: “Copilot Studio lets you extend your agent by using Azure Bot Service skills.” For bots built with pro-code tools, including the Agents SDK, it says “you can convert these bots to Azure Bot Service skills and embed them within a Copilot Studio agent.” It also states: “If you have a Teams plan, you can’t use Agents SDK skills.” Check your Copilot Studio licensing before you design around this shape; it is a way to combine the two destinations, not a third one.

How to Run the Migration as a Project

When more than one bot is in scope, run the move as a project with an order, not as a string of rewrites. Microsoft’s migration guidance describes itself as providing “guidance and awareness if you’re considering, or in the process of, migrating from the Azure Bot Framework to the Agents SDK”, and links separate guides for .NET, NodeJS and Python.

  1. Inventory each bot. Record its channels, its cloud, its language and every dependency, and mark each dependency against Microsoft’s table of what does not come across.
  2. Choose a destination per bot. Apply the three criteria above and write the reason beside each choice, so the decision survives a change of owner.
  3. Rebuild or port outside production. Build in a development environment and promote through your normal path; the partner-tenant case is covered in a separate i3solutions guide, Copilot Agent Dev to Production Tenant: A Partner Build Guide.
  4. Test channels and identity. Confirm that each channel the bot served still works for the same users under the same sign-in.
  5. Cut over, then decommission the old registration. Move traffic, confirm it, and remove the old bot resources so the estate record matches what runs.

After cutover the new agents become part of an estate someone governs, which is covered in Copilot Studio Governance for Enterprise Agent Estates.

When Not to Migrate Yet

If a bot’s future is already being decided elsewhere, a migration can be the wrong project. Microsoft’s archive notice states that “Customers using this tool will not be disrupted”, so the pressure is real but it is not an outage. In three situations, plan instead of moving.

  • Leave a bot the business is replacing. If the process it serves is being redesigned or the bot is scheduled to be switched off, spend the effort on what replaces it.
  • Hold a GCC High Teams bot until a destination is confirmed. Where Copilot Studio’s listing does not offer the channel and Agents SDK support for your cloud is not yet confirmed with Microsoft, record the gap and keep the bot running while you confirm.
  • Record the risk you are carrying. A bot left in place still sits on an SDK whose tickets are no longer serviced, so put that on the risk register with an owner and a review date.

How i3solutions Answers

When a Bot Framework estate reaches i3solutions, the work starts from the inventory: which bots exist, what they depend on, which channels and cloud they serve and who will own them. i3solutions implements the Microsoft technology a customer needs, Copilot Studio and custom agents on the Microsoft 365 Agents SDK included, and runs the move as a migration project with defined delivery or with embedded specialists. As our Custom AI Copilot Development on the Microsoft Stack page states: “i3solutions builds custom AI copilots on the Microsoft stack: Azure OpenAI and Azure AI Search for retrieval-augmented generation inside your tenant, Microsoft Copilot Studio for agents that act in your systems, Teams and Microsoft 365 as the surface, and SharePoint or Dataverse as governed knowledge sources that honor the signed-in user’s Entra ID permissions.”

For the Teams side of the estate, our Hire US-Based Microsoft Teams Developers and Enterprise Specialists page describes “Hands-on specialists who design and build custom Teams applications, tabs, bots, and extensions.” Delivery is senior and US-based.

Key Takeaways

  • If a review flags the SDK, start from Microsoft’s archive notice: support tickets for the Bot Framework SDK are no longer serviced, and “Customers using this tool will not be disrupted.”
  • Microsoft’s archive notice names two destinations: the Microsoft 365 Agents SDK for code, and Copilot Studio for “a SaaS-based agent platform”.
  • Microsoft’s migration guidance lists what does not come across, including Adaptive Dialogs, Composer artifacts and LUIS, Orchestrator and QnA Maker.
  • For a Teams bot in GCC High, Microsoft’s Copilot Studio US Government article marks “Teams & M365 Copilot Channel” as “No” under “Available in GCC High”.
  • Choose per bot, record the reason, and run the move as one project in a set order.

Frequently Asked Questions

Will our existing Bot Framework bots keep running?

If nothing else changes, Microsoft says they are not disrupted: its archive notice states “Customers using this tool will not be disrupted.” and “Support tickets for the Bot Framework SDK will no longer be serviced as of December 31, 2025.” The bots run; the ticket path and product updates are what end.

What does not carry over to the Agents SDK?

If a bot uses Composer or the older language services, plan a rebuild of those parts. Microsoft’s migration guidance says of Adaptive Dialogs “Microsoft doesn’t plan to move this system into the Agents SDK.”, of Composer artifacts that they “are no longer required and aren’t being brought forward.”, and of LUIS, Orchestrator and QnA Maker: “The online services for these tools are already disabled.”

When is Copilot Studio the right destination?

When a maker team will own the bot’s content and your cloud offers the channels it serves, Copilot Studio fits. Microsoft’s archive notice points there with “If you’re looking for a SaaS-based agent platform, consider Microsoft Copilot Studio.” A bot whose value is custom code belongs on the Agents SDK instead.

Can we keep a pro-code bot and use it from Copilot Studio?

If the licensing allows it, yes. Microsoft’s Azure Bot Service skills article says “you can convert these bots to Azure Bot Service skills and embed them within a Copilot Studio agent.”, and also states: “If you have a Teams plan, you can’t use Agents SDK skills.”

What changes for a bot in GCC High?

If the bot serves Teams in GCC High, check the channel first. As read in September 2026, Microsoft’s Copilot Studio for US Government customers article marks “Teams & M365 Copilot Channel” as “Yes” under “Available in GCC” and “No” under “Available in GCC High”. Confirm Agents SDK support for your cloud with Microsoft before planning that path.

Inventory the Bots Before You Pick the Destination

If your bots are on the Bot Framework SDK and the destination is still an argument, bring the list of bots, the channels and cloud each one serves and what each depends on. The conversation turns that into a destination per bot and an order to move them in, and leaving a bot where it is for now is one of the answers it can reach. Talk to a senior architect

Sources