Migration is mostly a profile flip plus a Lightning record page redesign. The fiddly parts are translating any Classic Console JavaScript customisations to Lightning Components and validating Omni-Channel routing in the new surface.
- Inventory the current Agent Console setup
Document the Classic Console app, the page layouts used by each profile, the mini-view configurations, and any Console.js customisations. The inventory is the migration scope.
- Create a Lightning Service Console app
App Manager, New Lightning App, choose Console navigation, add the relevant items to the navigation bar. Save as a Lightning Service Console app.
- Design Lightning record pages per object
Use App Builder to recreate the high-density layout: tab sections, related lists, knowledge sidebar, custom Lightning Components. Aim for parity with the Classic mini-view, not exact replication.
- Translate Classic Console JavaScript customisations
Console.js calls have to be rewritten as Lightning Component events or workspace API calls. Common patterns (open new sub-tab, refresh primary tab, set tab label) have direct Lightning equivalents.
- Flip profiles and validate
Update profiles to default to the new Lightning Service Console app. Pilot with a small group, validate Omni-Channel routing, Macros, and Knowledge access, then roll out to the rest of service.
- Console.js does not run in the Lightning Service Console. Any Classic Console customisations need to be rewritten against the Workspace API.
- Omni-Channel works only in the Lightning Service Console. Staying on Classic forfeits native routing.
- Mini-view configurations do not migrate automatically. Admins recreate them as compact layouts or sidebar components in App Builder.
- Profile defaults control the landing app. Users will keep seeing Classic if their profile default is not updated.
Keep the related term in your library so you can find this topic again.