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.