What has changed
Since the week of 13 July 2026, new Agentforce agents can only be created in the new Agentforce Builder (vendor, Salesforce). Agents built in the legacy builder keep running and stay editable. Salesforce says they are "not being shut down", and also that the legacy builder gets no new features (vendor, Salesforce). There is no retirement date.
So nothing forces a migration this quarter. What forces the plan is one line on the same page: activating the rebuilt agent automatically deactivates the legacy one (vendor, Salesforce). The upgrade is safe. The activation is the cutover.
Why a rebuilt agent can behave differently
This is not a cosmetic move. Salesforce's developer team describes the legacy engine as prompt-based: it classifies a message into one subagent, runs a reasoning loop, and re-derives state each turn. The new engine follows defined transitions between subagents and carries state in variables, written in Agent Script (vendor, Salesforce Developers). The same post says migration "changes how your agent routes and plans."
The upgrade carries over subagents, actions, the system message, settings, and connections, and the original stays active while you review the new version (vendor, Salesforce Developers). Carrying over the parts is not the same as carrying over the behaviour. Routing is what you have to prove.
Decision: rebuild now or wait?
| Your legacy agent | Call | Why |
|---|---|---|
| Stable, in production, no new features planned | Wait, but write the baseline test suite now | No deadline exists. The suite is what makes a later rebuild cheap. |
| Needs Agentforce Voice, more languages, per-subagent model choice, or agent-to-agent handoff | Rebuild now | Salesforce says these ship first on the new builder (vendor, Salesforce Developers); legacy development is frozen (vendor, Salesforce). |
| Multi-step process where routing errors cost money | Rebuild, test-first | Defined transitions are the reason to move; the test suite is how you show they work. |
| Edited by one admin who is a bottleneck | Rebuild after a permission review | The new builder does not require admin-level permissions; the legacy builder does (vendor, Salesforce). |
Six steps to a safe cutover
Prerequisites: a list of every legacy agent with its channel, its owner, and the actions it calls; and Salesforce CLI access for whoever owns testing.
- Step 1. Inventory the legacy agents. Name an owner for each, and mark which ones are customer-facing. Owner: Agentforce Centre of Excellence lead.
- Step 2. Write a baseline test suite on the legacy agent, before you upgrade. Salesforce's recommended arc is exactly this: baseline on the old agent, convert, run the identical suite on the new version, so a failure points at the migration and not at a new test (vendor, Salesforce Developers). Cover routing, action sequence, and the response. Keep single-turn and multi-turn cases in separate suites; Salesforce reports a mixed suite stalled. Owner: QA lead.
- Step 3. Upgrade to create the new version. In Setup, Agentforce Studio, Agentforce Agents, choose Upgrade to New Builder on the agent (vendor, Salesforce Developers). Review the generated Agent Script in the Canvas view or pull it into a Salesforce DX project. Owner: Salesforce developer.
- Step 4. Run the same suite on the new version and compare. Fix routing and action-sequence regressions before adding any new logic. The newer test runner and its metadata are labelled Beta (vendor, Salesforce Developers), so keep the raw results, not only a pass count. Owner: QA lead with the developer.
- Step 5. Review who can now edit agents. Fewer permissions to build means more people can change a customer-facing agent. Decide who may, before go-live. Owner: Salesforce platform owner.
- Step 6. Activate in a planned window, with one named owner. Activation deactivates the legacy agent. Archive the legacy agent rather than deleting it until the new version has run in production for a period you agree in advance; Salesforce lets you keep, archive, or delete it (vendor, Salesforce). Owner: business owner of the agent.
Trade-offs
- Wait. No migration cost now, and no new features either. Every change made in the legacy builder is a change you migrate later.
- Convert as-is. Salesforce offers a UI path that mirrors the original agent (vendor, Salesforce). Fastest, and it carries over the old design's assumptions.
- Redesign in Agent Script. Salesforce also offers a developer path to redesign with the CLI and coding tools (vendor, Salesforce). Slower, and the only route that uses the new engine on purpose rather than by accident.
Salesforce's own suggestion is to combine them: migrate as-is, test, fix regressions, then harden in small batches (vendor, Salesforce Developers). That is the right order.
Missing
- A retirement date for legacy agents. Salesforce gives none.
- A list of what does not convert cleanly. Salesforce's pages say the upgrade carries the parts over and that behaviour must be tested.
- General availability of the new test runner. It is Beta.
- Independent reports of migrations at scale. We found none, and Prestanda has not published a test of its own.
Frequently asked questions
Will Salesforce switch off our legacy agents?
Salesforce says existing legacy agents are not being shut down and stay editable. They get no new features, and Salesforce has published no retirement date.
Does upgrading take the agent offline?
No. The upgrade creates a new version and the original stays active while you validate it. Activating the new version is what switches the original off.
Does the new builder cost extra?
Salesforce says the new builder and Agent Script are included with Agentforce purchases.
Living page. Last updated 9 Nov 2026. We update this note if Salesforce sets a retirement date for legacy agents or moves the new test runner out of Beta.