Migrating Einstein Bots to Agentforce

If you run Einstein Bots today, you’ve probably been told to “move to Agentforce” and gone looking for the migration wizard. There isn’t one — not in the sense you’re hoping for. Einstein Bots and Agentforce share zero authoring objects. A bot is a hand-built graph of dialogs, intents, variables, and rules; an Agentforce agent is an LLM under the Atlas reasoning engine, driven by Topics and Actions that didn’t exist when you built the bot. This isn’t a version upgrade. It’s a platform change, and the honest word for what you’ll do is rebuild.

That sounds worse than it is. The rebuild is real work, but it’s tractable work, and — this is the part most “just migrate” advice skips — you don’t have to do it as a big-bang cutover. Einstein Bots have no announced end-of-life, so the pressure isn’t a deprecation deadline; it’s the widening gap between what a rule-based bot can do and what your customers now expect. That gives you room to run both systems side by side, move traffic gradually, and keep a safety net. Here’s how to plan it.

Why there’s no upgrade path (and why that’s not Salesforce being lazy)

The instinct is to look for a converter that turns each dialog node into a Topic. It doesn’t exist because the mapping isn’t one-to-one — it’s not even the same kind of thing.

An Einstein Bot is deterministic. Every dialog, every response path, every variable transition is authored by hand. When a customer says something, the NLU model classifies it to an intent, and the intent fires a dialog you wrote. The bot does exactly what its graph says, which is its strength (predictable, compliant) and its ceiling (it can only handle paths someone anticipated).

Agentforce is probabilistic and goal-driven. The Atlas engine interprets intent, selects Actions, executes them, observes the result, and decides what to do next — a reason-act-observe loop, not a scripted tree. There are no dialog nodes to convert because Agentforce doesn’t have dialog nodes. It has Topics (scopes of what the agent can handle) and Actions (the things it can actually do), and the LLM chooses among them at runtime.

A dialog tree encodes the path. A Topic encodes the goal and the guardrails, and lets the model find the path. You can’t mechanically translate one into the other, because the second deliberately throws away the thing the first was made of.

If you want the deeper contrast between rule-based bots, agents, and RPA before committing, we mapped it in AI agents vs. chatbots vs. RPA. For this post, take it as given: you’re rebuilding intent by intent, not porting a file.

What the beta migration tool actually does

Salesforce does ship a tool — Create AI Agents From Einstein Bots — and it’s genuinely useful as long as you know what it is and isn’t. As of 2026 it’s in beta, you enable it by contacting Salesforce Customer Support, and it’s available in Enterprise, Performance, Unlimited, and Developer editions.

What it does: it reads your bot’s structure and scaffolds a new Agentforce service agent, generating Topics and initial Actions based on your existing intents and dialogs. It’s a head start — it saves you from staring at a blank agent and re-deriving your own taxonomy of what the bot handled.

What it does not do — and this is where teams over-trust it:

No dialog node becomes a Topic verbatim. It infers Topics from your intents and dialogs; it doesn’t transliterate the tree.
It scaffolds Actions, it doesn’t implement them. Every Action still needs its real implementation — the Flow, the Apex, the API call — wired and tested.
It writes no Topic instructions. The natural-language instructions that actually steer the agent are yours to author.
It builds no escalation, routing, presence configuration, or Trust Layer policy. All of that is net-new.

And critically: your existing bot stays active after the agent is created. The tool doesn’t cut anything over. It gives you a parallel scaffold to build against while production keeps running on the bot — which is exactly the property you want for a gradual transition.

Treat the tool’s output as a first draft of your agent’s scope, then do the real build on top of it.

A phased plan that doesn’t bet the contact center on cutover day

The rebuild breaks cleanly into three phases. Timelines below are typical ranges for a moderately complex service bot; yours will move with the number of intents and the depth of integration behind them.

Phase 1 — Audit (roughly 2–3 weeks)

You can’t rebuild what you haven’t inventoried. Catalog every dialog, every NLU intent, every Flow and Apex action the bot invokes, and every integration it touches. For each one, make a three-way call: rebuild, reuse, or retire.

Reuse is the happy case. If a dialog already calls an Invocable Apex method or an autolaunched Flow to do the actual work — check an order status, create a case — that logic often becomes an Agentforce Action almost unchanged. The business logic survives; only the invocation surface changes.
Rebuild covers the conversational scaffolding — the dialogs, prompts, and variable juggling — which becomes Topics and instructions.
Retire is the quiet win. Bots accumulate dead intents and dialogs no one has hit in a year. Don’t rebuild those; delete them from scope. A migration is the best chance you’ll get to shed that weight.

This is also where you find the gaps: does the agent need Data 360 grounding the bot never had? Is your Omni-Channel routing ready to hand off to an agent?

Phase 2 — Design (roughly 3–4 weeks)

Turn the audit into an agent design. Define the Topics — the coherent scopes of work — and the Actions each Topic needs. Author the Topic instructions that constrain the model. Write your Trust Layer policies. And design the escalation architecture deliberately: when does the agent hand to a human, and what does it pass along? Bots handled escalation with a hard-coded transfer dialog; agents need an explicit design for it.

Phase 3 — Build (roughly 6–12 weeks)

Implement every Action, wire grounding, write instructions, and — non-negotiable — test before any of it meets a customer. Agentforce behavior is probabilistic, so you validate it with conversation simulation, not a click-through, using the approach in How to test an Agentforce agent. The build phase is where an under-scoped Phase 1 comes back to bite you, so resist the urge to skip the audit.

The hybrid architecture: run both, on purpose

Here’s the pattern that turns a scary cutover into a controlled rollout. You don’t have to choose “bot” or “agent” on a single day. You can run an Einstein Enhanced Bot in front of an Agentforce Service Agent, in the same contact center, and move work across the seam as your confidence grows.

The division of labor that works in practice:

The Enhanced Bot handles the front door — identity, initial qualification, and the transactional, compliance-heavy, low-latency paths where you want deterministic behavior and guaranteed process adherence. A bot that must ask three fixed KYC questions in a fixed order is doing exactly what it’s good at.
The Agentforce Service Agent handles resolution — the open-ended, reasoning-heavy work where an LLM earns its keep and a scripted tree would dead-end.

This isn’t a permanent architecture for most orgs — it’s a bridge. But it’s a legitimate one, and it lets you migrate a single intent at a time: route that intent to the agent, watch it, and only then move the next. If an agent Topic misbehaves, you reroute that path back to the bot while you fix it. That’s a far safer posture than flipping the whole channel at once.

Wiring the handoff: the Omni-Channel Flow

The mechanism that carries a conversation from bot to agent is an Omni-Channel Flow, and getting the context to survive the jump is the part worth doing carefully.

The routing itself is configured on the bot side. On the Bot Overview page you set the Outbound Omni-Channel Flow — the default flow the enhanced bot uses to route outgoing conversations. That flow does the work:

Create a Flow of type Omni-Channel Flow.
Add a Route Work element.
Set the service channel to LiveMessage.
Route to the Agentforce Service Agent, selecting the specific agent.
Set a fallback queue so a routing miss lands on a human, not a void.

That routes the conversation. To make it intelligent — different intents to different agents or queues — you carry context across the seam. The clean way: extend the Messaging Session object with a custom field (say, Inquiry_Category__c), populate it inside the bot via an Update Messaging Session flow, and then branch on it with a Decision element in the Omni-Channel Flow before the Route Work step. Now the flow routes on the category the bot already determined, instead of making the agent re-establish context the customer just gave.

A schematic of the routing logic:

Enhanced Bot
  └─ qualifies intent, writes Inquiry_Category__c on the Messaging Session
       └─ Outbound Omni-Channel Flow
            ├─ Decision: Inquiry_Category__c?
            │    ├─ "Billing"  → Route Work → Billing Agentforce Service Agent
            │    ├─ "Technical" → Route Work → Technical Service Agent
            │    └─ default     → Route Work → Fallback Queue (human)

Because Agentforce supports the full set of Enhanced Messaging channels — Web (MIAW), SMS, WhatsApp, and the rest — this same handoff pattern works across the channels your bot already serves. If you’re planning to reach the agent from surfaces beyond messaging, the Agent API is the headless path, but for existing bot traffic the Omni-Channel Flow is the seam.

Pitfalls that sink these migrations

Trusting the scaffold as a finished agent. The migration tool’s Topics and Actions are a starting point. Shipping them unimplemented and untested is the fastest way to embarrass yourself in production.
Skipping the audit. Teams that jump straight to building agents rediscover, mid-build, the twelve integrations the bot quietly depended on. The audit is cheap; finding a missing dependency in UAT is not.
Rebuilding dead weight. If you port every intent including the ones nobody uses, you’ve paid to migrate garbage. Retire aggressively.
Losing context at the handoff. A handoff that drops what the customer already said forces them to repeat it and reads as a downgrade, not an upgrade. The custom field on the Messaging Session is the fix — use it.
Under-budgeting the credit line. An Agentforce agent consumes against Flex Credits or a conversation meter that your bot never touched. Model the run-rate before you route real volume, or the first invoice becomes the story instead of the deflection rate.

The takeaway

Migrating Einstein Bots to Agentforce is a rebuild, and pretending otherwise is how projects stall halfway. But rebuild doesn’t mean big bang. Use the beta tool to scaffold your scope, audit ruthlessly so you reuse the business logic and retire the dead paths, and stand up the hybrid architecture so an Enhanced Bot keeps serving the deterministic front door while the agent takes over resolution one intent at a time. Wire the handoff through an Omni-Channel Flow that carries context on the Messaging Session, and you get a migration you can steer — moving traffic when the metrics say the agent is ready, and rolling a Topic back to the bot when they don’t. That control, not a mythical upgrade button, is what a good migration actually buys you.