Enhanced Omni-Channel Migration: What Changed and How to Move
July 2026 · Assigner
Enhanced Omni-Channel migration is the move from Salesforce Standard Omni-Channel to the Enhanced version, which Salesforce made mandatory when it retired Standard Omni-Channel in Summer 26. Orgs that did not migrate stopped having work routed to agents entirely. To migrate, confirm your org is on Hyperforce, allowlist the SCRT2 messaging domain, accept the AWS terms, then run the Enhanced Omni-Channel setup flow and re-point your channels, queues, and flows at the new routing. This guide covers what changed, the prerequisites, a step-by-step path, and how to keep work moving during the switch.
What changed in Summer 26
Salesforce retired Standard Omni-Channel with the Summer 26 release. This was not a soft deprecation with a warning banner: on production orgs the change landed in mid-June 2026 (sandboxes saw it earlier, around early May), and any org still running Standard Omni-Channel stopped routing work. Agents opened their consoles and no cases, chats, or leads flowed to them, because the engine that used to push work was gone. If your team hit a morning where nothing was being assigned and presence looked fine, this is the most likely cause.
Enhanced Omni-Channel is the replacement, and it is not just a rename. It runs on a different backend (the same SCRT2 real-time infrastructure Salesforce uses for Messaging and Voice), which is why the prerequisites below are stricter than the old feature. The upside is a more capable router: better support for messaging channels, enhanced presence, and tighter integration with Flow-based routing. The catch is that the migration has real prerequisites, and skipping them leaves you stuck.
Prerequisites before you migrate
Enhanced Omni-Channel will not turn on until these are in place. Check each one first, because discovering a missing prerequisite halfway through the switch is where teams lose a day.
| Prerequisite | Why it matters |
|---|---|
| Org on Hyperforce | Enhanced Omni-Channel runs on Hyperforce infrastructure. Most orgs are already migrated, but confirm yours is before you start. |
| SCRT2 domain allowlisted | The real-time routing backend uses a messaging domain that must be reachable. If your network or CSP policy blocks it, routing silently fails. |
| AWS terms accepted | Because the backend runs on AWS, an admin has to accept the associated terms in Setup before the feature enables. |
| My Domain deployed | Enhanced routing and the messaging components depend on a deployed My Domain, which nearly all orgs already have. |
None of these are exotic, but they are gating. The domain allowlist in particular trips teams up, because everything looks configured in Setup while work quietly fails to route until the SCRT2 domain is reachable from the agent side.
How to migrate, step by step
- Audit your current routing first. List every queue, routing configuration, and flow that assigns work today, plus which channels feed them. You are going to re-point these, so you need the map before you change anything.
- Confirm the prerequisites. Verify Hyperforce, allowlist the SCRT2 domain, accept the AWS terms, and check My Domain. Do this in a sandbox first so nothing on production breaks while you learn the flow.
- Enable Enhanced Omni-Channel in a sandbox. Turn it on in Omni-Channel Settings and work through the migration assistant Salesforce provides. Recreate your routing configurations and presence statuses under the new model.
- Re-point channels, queues, and flows. Move each channel to route through Enhanced Omni-Channel. Flow-based routing becomes the primary way you express routing logic, so rebuild rule-heavy routing as flows rather than legacy configuration where needed.
- Test with real agents. Log in as agents across each channel and confirm work actually arrives, presence and capacity behave, and nothing lands on someone offline. Watch for cases that match no rule and go nowhere.
- Cut over production during a quiet window. Once the sandbox behaves, repeat on production during low volume, keep an admin watching the routing, and have a rollback plan for the channels you can pause.
If custom integrations push cases or leads into Omni-Channel from outside Salesforce, confirm they still reach the new routing after cutover; teams that run a lot of inbound through a middle layer or an integration platform that connects apps and APIs should test those paths explicitly, because a payload that worked against Standard Omni-Channel can land in a queue that no longer routes.
How to keep work routing during the switch
The risk during migration is a gap where new work is not assigned. Three things reduce it. First, migrate channel by channel rather than all at once, so a problem is contained to one channel instead of your whole support floor. Second, keep manual assignment as a temporary fallback: supervisors can hand out work by hand for an hour if routing hiccups, which is ugly but beats a silent stall. Third, monitor the assignment rate directly, not just presence, because presence can look healthy while nothing routes.
For a deeper look at why Standard Omni-Channel stops assigning and how to diagnose it, see our guide on Salesforce Omni-Channel not assigning work, and for the broader picture of how Omni-Channel routing fits together read Salesforce Omni-Channel routing.
Where a routing layer beside Salesforce fits
Migration is also a moment to ask what Omni-Channel does well and where it leaves gaps. Enhanced Omni-Channel routes work well inside Salesforce, but if you need fair round-robin weighted by workload and availability, or you route leads and ops tasks that live partly outside Salesforce, a routing layer beside your CRM covers that without waiting on a platform migration. Assigner sits beside Salesforce, routes by skill, workload, availability, and priority using rules you control, and shows why each assignment landed where it did. See how that works for round robin assignment beside Salesforce, and how the skill matching itself works under skills-based routing. It is a companion, not a live two-way sync, and it is designed to help you route fairly, not to guarantee an outcome.
Frequently asked questions
What is Enhanced Omni-Channel migration?
It is the process of moving your Salesforce org from Standard Omni-Channel to Enhanced Omni-Channel, which became mandatory when Salesforce retired the Standard version in Summer 26. Migration means meeting the prerequisites (Hyperforce, the SCRT2 domain allowlist, AWS terms), enabling Enhanced Omni-Channel, and re-pointing your channels, queues, and flows at the new routing so agents keep receiving work.
Why did Salesforce retire Standard Omni-Channel?
Salesforce moved routing onto its SCRT2 real-time infrastructure, the same backend behind Messaging and Voice, so Enhanced Omni-Channel could support more channels and richer presence and capacity handling. Standard Omni-Channel ran on the older model, so rather than maintain both, Salesforce retired Standard in Summer 26 and made Enhanced the single path forward.
What happens if you do not migrate to Enhanced Omni-Channel?
Work stops routing. On production orgs the retirement landed in mid-June 2026, and any org still on Standard Omni-Channel stopped having cases, chats, and other work pushed to agents. Presence can still look normal, which makes it confusing, but the routing engine is gone, so nothing gets assigned until you migrate to Enhanced.
How long does Enhanced Omni-Channel migration take?
It depends on how complex your routing is. A simple setup with a few queues can migrate in a day of sandbox testing plus a quiet production cutover. Orgs with many channels, heavy flow-based routing, and custom integrations should plan for more, because each channel and flow needs to be re-pointed and tested. Migrating channel by channel keeps any single problem contained.
Stop hand-sorting your incoming work
Route every ticket, lead, and request to the right available person by skill, workload, and availability, using rules you control, and every assignment shows why. Rules you control, no black box.