Moving a Salesforce organization from Classic to Lightning Experience is not simply a matter of showing users a different navigation menu. Organizations can depend on legacy page layouts, custom buttons, Visualforce components, integrations and work habits that behave differently in Lightning. A successful rollout preserves critical business processes while taking advantage of modern page composition, automation and user experience. The work begins with an inventory of what people actually do, not an assumption that every feature should be migrated at once.
Salesforce Classic has not been universally retired. Salesforce’s May 2026 help documentation confirms that users in eligible organizations can still switch between Classic and Lightning, although access varies with edition and administrator permissions. Lightning-only editions and organization policies can remove the switcher. This distinction changes migration planning: an organization may choose to reduce Classic reliance or enforce a Lightning-only experience, but it should not present that operational choice as a vendor-announced universal end-of-life date.
Decide what success looks like before moving users
Define concrete business outcomes. Sales staff may need faster account and opportunity updates; service teams may need a consistent case workspace; administrators may seek to reduce reliance on custom code that is hard to maintain. Choose a small set of measures that can be observed before and after rollout, such as task-completion time, error and escalation rates, data-quality exceptions, or support volume. These are not universal productivity guarantees: they are hypotheses that the organization must test in its own workflows.
Write down who owns the decision and who must participate. A migration can involve operations, information security, administrators, developers, integration owners, service desk staff and business-unit representatives. A design is not ready simply because the application administrator has demonstrated a Lightning page in a sandbox. It is ready when the business owner can explain how the new workflow preserves required approvals, data integrity and auditability.
Inventory Classic-dependent workflows and customizations
Map the highest-value tasks users perform: record creation and updates, search, dashboards, case handling, approvals, activity tracking, integrations and reporting. For each task identify the current Classic page, objects and fields, user permissions, automation, custom links, JavaScript buttons, Visualforce pages and related applications. Some functionality will work unchanged; other interactions may need redesign or validation in Lightning.
Pay particular attention to custom JavaScript buttons and older page-level assumptions, which may not translate directly to modern interfaces. A custom control might rely on an unsupported DOM structure or an implicit redirect sequence; copying its label into a Lightning page does not make it equivalent. Document the user intention, security requirements and expected result, then implement the appropriate supported mechanism. Avoid changing controls solely because a migration checklist lists them as legacy.
An inventory is also a chance to retire obsolete work. Ask whether a workflow still has a business owner, whether its output is still consumed and whether a simpler supported pattern would be preferable. Removing a dormant field or button can reduce maintenance risk, but deletion must be separately governed and tested—migration should not silently change the data model or break integrations.
Design Lightning pages around tasks and access boundaries
Lightning App Builder and supported component patterns provide more flexibility than simply mirroring a Classic page layout. Start with the information a user needs to make a decision, then group related actions and fields to reduce navigation. A manager may need case priority, SLA context and escalation status; a seller may need recent engagement, account relationships and pipeline data. The same record type can support different page experiences without changing its underlying meaning.
Access is part of page design. Test profiles, permission sets, sharing, record types and field-level security with representative users rather than relying on administrator-level preview. If a field is absent in Lightning, the cause may be security, dynamic component visibility, layout configuration or an unsupported customization. Do not “fix” a missing field by widening access before identifying which control is responsible.
Accessibility and mobile behavior should be tested in the actual Salesforce organization rather than assumed from documentation or a generic demonstration. In a permitted test environment, inspect keyboard navigation, labels, focus order, readable errors and high-priority tasks on the devices employees actually use.
Test data, automation and integration behavior
A page that looks correct can still change the meaning of data. Test validation rules, record defaults, picklist dependencies, required fields, assignment behavior, formulas and approval paths. Examine how Flow automations and legacy processes respond when a different UI sequence updates the same record. If a user now saves a partial record more often, automation designed around a single complete save may need investigation.
Test integrations independently of the interface. External systems may consume field values, status transitions or events rather than know which Salesforce experience the user opened. A Lightning migration should not change that contract without versioned documentation and agreement from the integration owner. Use test data with realistic relationships and failure cases; a happy-path demo will not expose issues with sharing restrictions, duplicate prevention or missing required values.
Preserve audit evidence. For a key business process, record the starting state, who performed an action, the resulting record changes and the expected downstream effects. If an integration or automation fails, the test should make it possible to distinguish an interface defect from a pre-existing data-quality problem.
Run a realistic pilot and compare workflows
Choose a pilot group that represents different roles and experience levels, not only volunteers comfortable with new software. Give participants scenario-based tasks with clear success criteria. A service agent might triage, update and resolve a case with an escalation; a sales representative might qualify a lead and update an opportunity forecast; an administrator might audit a field permission or report issue.
Observe where users hesitate, how often they abandon a task, which customizations fail, and how much support is needed. Collect specific feedback tied to steps, roles and records. Comments such as “Lightning feels slower” are useful as investigation signals, but a performance decision should distinguish network latency, client resource load, page-component design and unfamiliar workflow from true application response-time problems.
Use a short issue register: affected user group, reproducible steps, current result, desired result, severity, owner and retest evidence. Do not dismiss low-frequency failures if they affect a regulated action, financial approval or important customer workflow. Conversely, a cosmetic preference should not automatically block a technically safe rollout when users have a workable alternative.
Plan adoption without claiming Classic has disappeared
Training should explain what changes in a real task, not merely where the old menu moved. Provide short role-specific walkthroughs and supported instructions for exceptions. Some editions and organizations allow switching between interfaces; others are Lightning-only or have administrator-enforced restrictions. Salesforce’s official interface-switching guidance describes these differences. Check the actual organization’s settings before promising a Classic fallback to users.
Where a Classic fallback is permitted, define when it is appropriate, how support will track its use, and whether continued reliance reveals a missing Lightning capability. If policy requires a Lightning-only rollout, test every critical task before disabling Classic access. A rollback plan should be realistic: some changes to automation, layouts or permissions may require a separately tested reversal even when a user can switch interfaces.
Organizations considering whether to migrate now or later may also compare the Salesforce Classic versus Lightning decision factors. That strategic question is distinct from the operational steps of testing and deploying the migration described here.
Release in stages and verify the operating result
A safe rollout usually moves through inventory, sandbox testing, a pilot, remediations, training, staged deployment and post-release observation. Before rollout, record the configuration baseline, export approved change metadata using supported tools, and establish who can revert specific layouts or permission changes. Avoid treating a user-interface toggle as a database restore. It cannot automatically reverse an automation update, data correction or integration configuration made during deployment. Rehearse the rollback only in a sandbox or authorized staging environment, and preserve a record of which changes would need manual intervention if the production cutover failed. Specify success thresholds, a responsible decision-maker and a stop condition before each expansion. A help-desk spike or broken integration should prompt investigation rather than an unplanned blanket return to Classic.
After release, review actual workflow completion, user-support trends, permission incidents, automation failures and integration health against the baseline. Where an improvement is claimed, ensure the measurement uses comparable populations and tasks. Where a problem remains, assign ownership and a correction date; do not relabel an unfinished workflow as user resistance. Migration is complete when critical work is supported reliably, responsibilities and support paths are documented, and the organization knows how to maintain the new experience.
Lightning can deliver substantial product and interface benefits, but that outcome is earned through sound design, realistic testing and accountable operations. Classic’s continued availability in eligible organizations should be described accurately, without treating it as a reason to avoid modernization or pretending that a universal retirement date has been announced. The practical goal is to improve how people work with Salesforce while protecting the data, access and services on which their work depends.
