Salesforce Classic to Lightning migration:
guide
Last reviewed:
Salesforce states that the Classic interface "isn't going away yet, but all new Salesforce innovation is available in Lightning Experience only". Moving is a rollout project, not a data migration: review customisations, prepare Lightning, give users the Lightning Experience User permission in phases, and track adoption.
When does moving make sense?
These are the situations in which a move usually pays off:
- New Salesforce features, including Agentforce capabilities, are needed by the business.
- Users are still working in Classic while the rest of the org has moved on.
- Custom buttons, Visualforce pages or integrations were built for Classic and need review.
- A release or audit is a good moment to retire old customisations.
What Salesforce says about Classic
This is what Salesforce itself says about Classic and the move to Lightning Experience:
- Salesforce: "The Salesforce Classic user interface isn't going away yet, but all new Salesforce innovation is available in Lightning Experience only." No retirement date is given on that page. Source: Salesforce Help
- Salesforce recommends preparing the org, reviewing existing customisations so they work in Lightning Experience, and giving the right users access through the Lightning Experience User permission, in phases or all at once. Source: Salesforce Help
- Adoption can be tracked with the Lightning Usage App (daily active users and users switching back to Classic); access to Classic can optionally be removed for users who should stay in Lightning. Source: Salesforce Help
- Some Classic features "have been implemented differently or don't have a place in the new interface". Source: Salesforce Help
Where Classic customisations go
Classic customisations and where they go in Lightning Experience. Each row is reviewed in the readiness assessment before any build starts.
| In Classic | In Lightning Experience | What to do |
|---|---|---|
| Classic page layouts | Lightning record pages and compact layouts | Rebuild with Lightning App Builder; remove unused fields and sections while doing it. |
| Visualforce pages | Lightning Web Components, or Visualforce kept where supported | Review each page for use, performance and security before deciding. |
| Custom buttons and links | Lightning actions and Flow | Check each custom button against Lightning behaviour using Salesforce's readiness tools. |
| Console apps | Lightning console apps | Rebuild navigation and utility bar items. |
| Classic reports and dashboards | Lightning reports and dashboards | Retire unused reports first. |
| Email templates and letterheads | Lightning email templates | Review merge fields after conversion. |
| Mobile access | Salesforce mobile app | Review mobile layouts and actions with the Lightning pages. |
What does not move automatically
Some things cannot be copied across and are rebuilt, replaced or retired. These are agreed during the audit so that nothing surprises the business on go-live day:
- Custom buttons and links that depend on Classic behaviour
- Visualforce pages that need redesign
- Training: users need role-based training and tip sheets
- Third-party packages that are not Lightning-ready (check with each vendor)
The plan, phase by phase
A rollout in six steps. Data stays where it is; the work is configuration, customisation review and user adoption.
1. Assess readiness
- Run Salesforce's Lightning Experience Readiness Check
- Inventory customisations, packages and integrations
- Identify user groups and their daily tasks
Deliverable: Readiness report and scope
2. Plan the rollout
- Choose a phased or all-at-once rollout
- Pick pilot users from each team
- Plan training and communication
Deliverable: Rollout plan and success measures
3. Prepare Lightning
- Build Lightning record pages, apps and navigation
- Convert or replace customisations
- Test in a sandbox with real scenarios
Deliverable: Tested Lightning configuration
4. Pilot
- Grant the Lightning Experience User permission to the pilot group
- Collect feedback and fix issues
- Track usage in the Lightning Usage App
Deliverable: Pilot feedback and fix list
5. Roll out
- Grant access to the remaining users in waves
- Run training sessions and office hours
- Support users during the first weeks
Deliverable: All users in Lightning
6. Measure and retire Classic customisations
- Review adoption and switch-back counts
- Optionally remove access to Classic
- Retire unused Classic-only customisations
Deliverable: Adoption report and clean-up list
The audit in phase 1 produces the plan with dates, effort and owners for the specific case. Techila does not quote a duration before the audit, because record volumes, automation and integrations differ for every business.
Risks and how they are handled
Every migration has the same handful of risks. This is how each one is controlled:
| Risk | How it is handled |
|---|---|
| Custom buttons or pages fail in Lightning | Run the readiness tools early, test every custom button and page, and rebuild before the pilot. |
| Users revert to Classic | Measure switch-backs in the Lightning Usage App and address the reasons. |
| Third-party packages not ready | Ask each vendor for Lightning support status before rollout. |
| Training skipped | Role-based training and tip sheets before each wave. |
| Layouts copied unchanged | Use the move to remove unused fields and simplify pages. |
[ FAQ ]
Frequently asked questions
Is Salesforce Classic being retired?
Salesforce states that Classic "isn't going away yet", with all new innovation in Lightning Experience only. No retirement date is given on the page read.
Is this a data migration?
No. Data stays where it is. The work is configuration, customisation review and user adoption.
Can some users stay in Classic during the move?
Yes. Access is controlled by the Lightning Experience User permission, so rollout can be phased.
How long does it take?
It depends on the number of customisations, users and teams. A readiness check produces the scope.
[ Next step ]
Talk to a Salesforce architect
Techila reviews the org, runs the readiness assessment and plans the rollout by user group. Share the number of users, the customisations in use and the packages installed to get started.
[ Related ]
Related
[ Evidence ]
Sources
- Salesforce Help: transition from Classic to Lightning Experience
- Salesforce: Lightning Experience Readiness Check
Product names are trademarks of their owners. Salesforce, Lightning Experience and Classic are trademarks of Salesforce, Inc. Information on this page was checked on 26 October 2026; vendor limits and prices change, so confirm on the vendor pages linked in the sources.