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 customizations, 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 customizations.
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 three steps. Prepare the org. Review existing customizations so they work in Lightning Experience. Then give users access through the Lightning Experience User permission, in phases or all at once. Source: Salesforce Help
- The Lightning Usage App tracks adoption: daily active users, and users switching back to Classic. You can also remove access to Classic 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
Salesforce Classic vs Lightning: what is the difference?
Salesforce Classic is the older Salesforce interface; Lightning Experience is the current one, and Salesforce says it is where all new Salesforce innovation happens. Both run on the same org and the same data, so the difference is in how pages are built, which features are available and how the interface performs. The table compares them as Salesforce Help and Trailhead describe them.
| Area | Salesforce Classic | Lightning Experience |
|---|---|---|
| New features | No new innovation; Salesforce says Classic isn't going away yet | Where all new Salesforce innovation happens, including Agentforce capabilities |
| How pages load | Pages are generated by the server, then shown in the browser | Pages load on the user's device progressively, component by component |
| Built for | Mainly data entry and record keeping | Sales and service work, with Lightning components that run JavaScript on the device and Apex on the server |
| Working views | Record pages and list views | Home with Assistant and Performance Chart, Path guidance, Kanban views, the highlights panel and Composer |
| Feature gaps | A few Classic features aren't yet supported in Lightning | Many Lightning enhancements aren't available in Classic |
| Performance | Less sensitive to the user's device | Sensitive to browser, device and network latency; pages with many fields or components render more slowly |
| Switching | Users can switch to Lightning with the Switcher | Access is granted with the Lightning Experience User permission |
Before you move, check the Classic-only features your teams rely on. For the rollout itself, the plan below runs from readiness check to adoption review; for Salesforce's wider product line, see what Salesforce is and what it does, or book a Lightning migration audit.
Where Classic customizations go
Classic customizations 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 behavior 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 behavior
- 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, customization review and user adoption.
Assess readiness
Deliverable: Readiness report and scope
What happens in this phase
- Run Salesforce's Lightning Experience Readiness Check
- Inventory customizations, packages and integrations
- Identify user groups and their daily tasks
Plan the rollout
Deliverable: Rollout plan and success measures
What happens in this phase
- Choose a phased or all-at-once rollout
- Pick pilot users from each team
- Plan training and communication
Prepare Lightning
Deliverable: Tested Lightning configuration
What happens in this phase
- Build Lightning record pages, apps and navigation
- Convert or replace customizations
- Test in a sandbox with real scenarios
Pilot
Deliverable: Pilot feedback and fix list
What happens in this phase
- Grant the Lightning Experience User permission to the pilot group
- Collect feedback and fix issues
- Track usage in the Lightning Usage App
Roll out
Deliverable: All users in Lightning
What happens in this phase
- Grant access to the remaining users in waves
- Run training sessions and office hours
- Support users during the first weeks
Measure and retire Classic customizations
Deliverable: Adoption report and clean-up list
What happens in this phase
- Review adoption and switch-back counts
- Optionally remove access to Classic
- Retire unused Classic-only customizations
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
What is the difference between Salesforce Classic and Lightning?
They are two interfaces on the same Salesforce org and data. Classic is the older one, built mainly for data entry and record keeping. Lightning Experience loads pages component by component, adds features such as Path, Kanban views and the highlights panel, and is where all new Salesforce innovation happens.
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, customization 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 customizations, users and teams. A readiness check produces the scope.
Next step
Let's plan your next Salesforce program.
Techila reviews the org, runs the readiness assessment and plans the rollout by user group. Share the number of users, the customizations 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
- Trailhead: compare Lightning Experience to Salesforce Classic (read 11 November 2026)
- Trailhead: Lightning Experience getting started guide (read 11 November 2026)
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.