Einstein Bots to Agentforce: The Migration That Is Actually a Rebuild

Your bot has been in production for three years. Forty dialogs, a dozen intents, an NLU model somebody retrained last spring, and a containment number you are happy to put on a slide. Then someone asks when it moves to Agentforce. You open the Agentforce Builder for the first time, look for the thing that holds your dialog tree, and there isn't one.

That is not a menu you failed to find. Einstein Bots and Agentforce share zero authoring objects. Your dialogs, your intent training set, your entity definitions, and most of your conversation variables have no destination in the new product. What you have is not an upgrade path. It is a rebuild with a familiar business requirement attached.

Nobody retired anything, and that is the problem

There is no published end-of-life date for Einstein Bots. Salesforce has not put one on a roadmap slide, has not filed a release update, and has not sent the emails it sends when something is actually going away. If you are waiting for a deadline to force the budget conversation, you will be waiting a while.

Compare that to how Salesforce handles a real retirement. Legacy Chat, the product formerly called Live Agent, got a hard date: February 14, 2026. Salesforce published it years ahead, froze new features while critical trust updates continued, and named the replacement. Article Answers inside Einstein Bots got the same treatment on a smaller scale. Support ended in Spring '25, it stopped being available to bots created in Summer '25 or later, and the final cutoff landed on December 31, 2025.

Einstein Bots is getting neither the date nor the investment. What it gets is maintenance. The engineering attention, the release-note real estate, and the pricing model all moved to Agentforce, and the product you are running is being quietly starved rather than shut down. That is worse for planning than a deadline, because there is nothing external to point at when someone asks why this quarter and not next year.

The honest framing for your leadership team: this is a discretionary migration with a non-discretionary direction. You pick the timing. You do not get to pick whether.

The object model does not map

The first instinct is to look for a translation table. Dialog becomes topic, intent becomes topic classification, dialog step becomes action. It is close enough to feel right and wrong enough to sink a project.

A dialog is a script. It defines the order of questions, the branch conditions, and the exact wording of each turn. A topic is a boundary. It defines a scope of work, the instructions the agent should follow inside that scope, and the set of actions available to it. The agent decides the order. You do not.

That single difference invalidates most of the artifacts you would want to carry across.

Your intent training data is the clearest example. Einstein Bots ships with a classifier you train: utterances in, intent labels out, retrain when precision drops. Agentforce has no equivalent surface. The Atlas Reasoning Engine reads your topic descriptions and instructions and decides which topic a message belongs to at runtime. Four thousand tagged utterances become nothing. What replaces them is a paragraph of prose per topic, and the quality of that paragraph is now the thing that determines routing accuracy.

Entity definitions go the same way. So do most conversation variables, because the model holds context across turns instead of you stashing it in a variable and reading it back three dialogs later.

What the beta tool actually gives you

Salesforce does ship a migration assist. It is called Create AI Agents From Einstein Bots, it is in Beta, and it lives on the Einstein Bots setup page as a Create Agent from Bot option. It needs Enterprise, Performance, Unlimited, or Developer edition with Einstein for Service, Einstein Platform, or Agentforce for Service.

What it does: reads the structure of an existing bot and scaffolds an Agentforce Service Agent, generating topics and a first set of actions from your intents and dialogs. Your bot stays active after the agent is created, so both can run at once, and you can configure transfers between the bot and the agent while you move traffic across.

What it does not do is longer. It does not design your escalation path. It does not wire your channel. It does not build your grounding. It does not map your variables. It does not test anything. And because it is Beta, it sits under Salesforce's Beta Services terms, which means no support commitment and no guarantee the output stays stable release to release.

The useful way to think about it: the tool gives you a first draft written in your own vocabulary. Your topic names will match the things your customers actually ask about, which is worth more than it sounds when you are staring at an empty agent. It is not a migration. It is a head start on the naming.

Run it against a small bot first. The output on a forty-dialog bot is a long list of topics that all need editing, and long lists of things that need editing tend to get accepted wholesale instead.

There is a second reason to keep the first run small. Because the source bot stays live, nothing about running the tool is destructive, which makes it tempting to generate agents for every bot in the org in an afternoon and sort them out later. You end up with a Setup page full of half-finished agents, no record of which one was the serious attempt, and a naming scheme somebody has to untangle. Generate one, finish it, then generate the next.

The channel dependency that blocks everything

Here is where migration projects stall, usually in week two, usually in a meeting nobody scheduled.

An Agentforce Service Agent runs on Enhanced Messaging channels. That means Enhanced Chat (the product previously named Messaging for In-App and Web), SMS, WhatsApp, and Bring Your Own Channel. It does not run on legacy Chat, which stopped existing in February 2026 anyway.

If your org already moved off Embedded Chat, you are fine and you paid that cost last year. If you deferred, or you are running a bot on a channel somebody built before the retirement notice, you are now doing two migrations stacked on each other, and the channel one has to finish first.

Routing is the other half. The agent does not receive conversations directly. An Omni-Channel flow picks up the Messaging Session, calls Route Work with the work type set to Agentforce Service Agent, names your agent, and specifies a fallback queue for everything the agent cannot finish or every case where something breaks. Enhanced Omni-Channel Routing has to be enabled in Omni-Channel Settings, terms accepted, before any of that is selectable.

Two constraints that catch teams late. The Service Agent handles inbound conversations only, so anything your bot did on an outbound trigger needs a different home. And you must not build routing that can hand the same session to a human rep and an AI agent at the same time, which is easy to do accidentally when you bolt agent routing onto an existing flow instead of writing a new branch.

Budget the escalation design properly. In Einstein Bots, "Transfer to Agent" was a step you dropped into a dialog. In Agentforce it is a routing decision with a fallback queue behind it, and getting it wrong means a customer sits in a conversation nobody owns.

One scheduling note while you plan. Winter '27 hits sandboxes from August 29, 2026, with production upgrade weekends through October. Doing your first agent build in a sandbox that flips versions halfway through adds a variable you do not need, so either start before the preview window or start after your org's upgrade date and accept the delay.

Intent training becomes grounding

The maintenance work does not disappear. It changes shape, and the new shape catches teams who were good at the old one.

Under Einstein Bots, you looked at misrouted conversations, added utterances, retrained, and watched precision. The failure mode was visible and polite: the bot said it did not understand and offered a menu.

Under Agentforce, routing accuracy comes from how well your topic scopes and instructions are written, and answer accuracy comes from grounding. Knowledge grounding runs through an Agentforce Data Library on Data 360, which ingests, chunks, indexes, and retrieves your content so the agent answers from your material rather than from the model's training data. The Einstein Trust Layer sits in the path for masking, audit, and toxicity checks.

The new failure mode is not polite. An agent grounded on a stale knowledge article will answer confidently and wrongly, and the conversation will read perfectly well to a supervisor skimming transcripts. That is a content-quality problem wearing an AI costume, and the fix lives in your knowledge base rather than in Setup.

Practically: before you build a single topic, audit the articles your bot's Generative Knowledge Answers step already touches. Whatever is out of date there will be out of date in the agent, with more confidence and less hedging. Our guide to Agentforce Service covers what good grounding hygiene looks like once you are live.

The three things that carry over

Not everything is a rewrite. Three categories survive intact, and they happen to be the ones that took the longest to build.

Flows. Any Flow your bot invoked can be registered as an agent action with minimal change. If it takes typed inputs and returns typed outputs, it works.

Apex. Same story for invocable Apex. Your record creation, your entitlement checks, your integration wrappers, all of it is reusable.

Integrations. Named Credentials, external callouts, and the middleware behind them do not care what is calling them.

That is the reason experienced teams build actions before topics. Your Flows and Apex are the migration's real inventory, they port with the least drama, and a topic without working actions is a chatbot that apologises in complete sentences.

Omni-Channel queues sit in a middle category. The queue records survive. The routing configuration around them gets rebuilt, because enhanced routing and the agent work type did not exist in your original setup.

The cost line moves from license to usage

Einstein Bots pricing was easy to forecast. Each Service Cloud Unlimited or Digital Engagement license carries an entitlement of 25 bot conversations per month, and orgs that need more buy conversation blocks. Whatever your volume, the number was knowable in advance and it sat in the license column of the budget.

Agentforce does not work that way. Consumption is metered, and the unit is not a conversation. A single customer interaction can fire several actions, each of which counts. Two bots with identical conversation volume can produce very different bills depending on how many actions their topics call per turn.

This is the part to model before the pilot rather than after. Take your busiest dialog, count how many discrete operations it performs (lookup, verification, update, confirmation), and assume the agent does at least that many. Our breakdown of Digital Labor Units has the arithmetic and the traps.

I have watched a team present a migration business case built on conversation counts, get approved, and then spend the next quarter explaining a bill that was never in the model. The mistake is understandable. The unit changed and the spreadsheet did not.

A plan that fits one quarter

Twelve weeks is realistic for a first topic in production, if the channel work is already done. If it isn't, add the channel migration in front and treat it as its own project.

Weeks 1 and 2, inventory. List every dialog with its conversation volume, the Flows and Apex it calls, and the last time anyone edited it. You will find that a small number of dialogs carry most of your traffic and a long tail carries almost none. Those tail dialogs are not migration candidates. They are retirement candidates, and deleting them is the cheapest work in the whole project.

Weeks 3 and 4, pick one topic. Highest volume, lowest blast radius. Order status, appointment rescheduling, and return eligibility are good first topics. Anything touching billing disputes or account closure is not.

Weeks 5 through 9, build. Actions first, then topic instructions, then escalation. Write the instructions like you are briefing a new hire on their first day: what they own, what they must never do, when to hand off. Vague instructions produce vague routing.

Weeks 10 through 12, parallel run. Both systems live. The bot keeps handling everything except your one migrated topic, transfers configured between bot and agent, and a slice of real traffic on the agent. Use Agentforce Testing Center to run regression sets rather than clicking through conversations by hand.

Then cut over topic by topic. Never bot by bot. A per-bot cutover means one bad topic takes down a channel, and there is no partial rollback once the routing points at the agent.

What I would not do

I would not run the beta tool against the biggest bot in the org on day one, because the output is long enough that people stop reading it and start accepting it.

I would not rebuild all forty dialogs. If half of them serve under two percent of traffic each, they are answering questions that a decent knowledge article handles better, and moving them is paying migration cost for automation nobody uses.

I would not cut over before escalation is tested end to end, including the ugly path where the agent errors mid-conversation and the fallback queue has to catch a customer who is already annoyed.

And I would not wait for a retirement announcement. The announcement is not the signal. The signal is that Einstein Bots stopped getting new capability two years ago while every service AI feature Salesforce ships lands somewhere else.

Start with the list, not the tool

Open Setup, go to Einstein Bots, and export the dialog list for your busiest bot alongside 90 days of conversation volume per dialog. Sort descending. Draw a line under the dialogs that cover 80% of traffic and count what is above it. That number, not the total dialog count, is the size of your migration, and it is almost always small enough to make the conversation with your sponsor an easier one than you expected.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He writes and edits salesforcedictionary.com, published by KineticBit Inc., to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.