Salesforce Lightning in 2026: When to Retire Classic Access

Salesforce Lightning Experience is now the normal operating environment for most Salesforce organizations, but Salesforce Classic has not disappeared completely. Salesforce’s 2026 help documentation still explains how eligible users can switch between Lightning Experience and Classic, while some editions and organizations are Lightning-only.

That changes the migration question. In 2026, most teams are not deciding whether Lightning is the future. They are deciding whether any remaining Classic access still solves a real business requirement.

New Salesforce innovation is Lightning-first

Salesforce describes Lightning Experience as the current generation of the platform and states that new innovation is available there. That alone is a strong reason to design new workflows, automation, pages, and user experiences for Lightning rather than extending Classic.

If a team is investing in new development while keeping users in Classic by default, it should be able to explain the specific constraint that justifies that choice.

Classic still exists in some organizations

It is inaccurate to say Salesforce Classic was globally shut down. Current Salesforce help still documents the switcher, and administrators can allow or restrict access depending on edition and permissions.

That means migration planning should be evidence-based. Inventory the users who still enter Classic and identify exactly which workflow, page, package, or habit sends them there.

Migration tooling has already moved on

Salesforce retired Lightning Adoption apps—including the Transition Assistant, Configuration Converter, and Readiness Check—in January 2025. Salesforce cited 98.1% Lightning adoption across orgs when explaining the retirement.

For organizations still completing the transition, the work is therefore less about a dedicated migration program and more about normal platform governance: dependency discovery, testing, user enablement, and removal of old access where it is no longer required.

Signal 1: users enter Classic only for one legacy dependency

If a single Visualforce page, package, custom button, or administrative workflow is the only reason users switch interfaces, treat that dependency as a modernization backlog item. Measure how often it is used and whether a Lightning-compatible replacement exists.

Signal 2: new automation is difficult to expose cleanly

Flow, Lightning pages, component visibility, dynamic experiences, and modern platform capabilities are easier to design coherently when Lightning is the default environment. A mixed-interface operating model can make training and support more complex.

Signal 3: support documentation has doubled

If every procedure needs “Classic” and “Lightning” instructions, the organization is paying an ongoing operating cost for the old interface. That cost appears in training, screenshots, testing, help-desk scripts, and user confusion.

Signal 4: administrators cannot reproduce user problems easily

Interface differences can make troubleshooting harder. Standardizing the experience reduces the number of variables support teams need to consider when a page, permission, automation, or navigation flow behaves differently.

Signal 5: current certifications and skills assume Lightning-first work

The current Salesforce credential catalog emphasizes modern platform administration, development, automation, data, and Agentforce capabilities. The Salesforce certification path guide shows how those roles are organized in 2026.

Keeping teams primarily in Classic while training them on current platform skills creates unnecessary friction between learning and production work.

Signal 6: Classic access creates governance exceptions

Organizations can restrict or remove the option to switch to Salesforce Classic. If only a small group genuinely requires it, consider treating Classic access as an exception that has an owner, justification, and review date rather than as a universal option.

Signal 7: your modernization roadmap keeps postponing the same dependency

A legacy page or package that blocks Lightning year after year deserves an explicit decision: replace it, redesign the process, accept the long-term exception, or retire the capability. “We will migrate later” is not a strategy if no owner or date exists.

Retire Classic access carefully, not theatrically

Do not remove access simply to declare the migration complete. Identify dependencies, test critical workflows, communicate the change, monitor support volume, and keep a rollback path where your Salesforce edition and policy allow it.

The goal is a simpler operating environment, not a symbolic cutover. In 2026, Lightning is the platform direction; Classic should remain only where a documented requirement still outweighs the cost of maintaining two experiences.