current interface-switching documentation<\/a> explains that users with the appropriate Lightning Experience permission can move between Lightning Experience and Salesforce Classic when their edition and administrator’s configuration allow it. Salesforce Starter and Starter Pro Suite are Lightning-only. Other restrictions can affect particular users, such as an administrator removing the interface switcher or an edition with limited access to Classic.<\/p>\nThat means two colleagues can report different experiences without either being mistaken. One person may still see \u201cSwitch to Salesforce Classic\u201d in the profile menu while another does not. A missing switcher is not, by itself, proof that Salesforce has globally retired the Classic interface. The administrator should identify the edition, profile and permission-set controls, the organization’s Lightning-only settings, and any special access restrictions before drawing a conclusion.<\/p>\n
Availability and strategic suitability are separate questions. Classic can remain accessible while newer products and workflows are designed primarily for Lightning. Conversely, choosing Lightning does not guarantee that every Classic customization will behave identically without testing. Migration planning should acknowledge both realities rather than relying on an unsupported end-of-life date.<\/p>\n
Start with business functions instead of page counts<\/h3>\n A useful discovery exercise begins with what people do, not with how many tabs or objects appear in Setup. Interview sales, service, operations, reporting, and administrative teams about workflows that must succeed every day. Typical examples include assigning leads, entering opportunities, approving discounts, creating cases, updating contract records, sending outbound notifications, and running month-end reports. Capture the actual user, input, output, permissions and failure consequences for each process.<\/p>\n
For each workflow, distinguish the interface component from the underlying platform capability. A lead-assignment rule may execute regardless of which interface is open, while a custom action on a Classic record page might need redesign. A report may have identical underlying data but a different navigation path or dashboard experience. A JavaScript button used from Classic might require replacement with a supported Lightning action, flow, or component. Treating all three situations as the same \u201cmigration task\u201d hides important technical and training differences.<\/p>\n
A practical inventory also records how frequently a workflow is used, the business owner who can validate it, the systems it depends on, and whether it can be postponed. That makes the eventual deployment plan defensible: the most heavily used or highest-consequence work is tested before less critical conveniences.<\/p>\n
Audit Classic customizations for Lightning compatibility<\/h3>\n Classic implementations often have years of accumulated customization. A system administrator may find Visualforce pages, custom links, buttons, workflows, approval paths, integrations, reports, and object layouts that were created at different times by different teams. Some continue to work in Lightning with minimal change, some work differently, and others need replacement. The assessment must be based on the actual component and current Salesforce support, not a blanket rule that every Classic customization is obsolete.<\/p>\n
Review custom buttons and JavaScript assumptions first. Older interface-specific scripts can depend on page structures and mechanisms that do not map directly to Lightning Experience. Identify the business outcome behind the script, then choose an appropriate supported method such as a quick action, Flow, Lightning component, or server-side logic when suitable. Do not mechanically rewrite a button without checking its security permissions, validation behavior, side effects, and error handling.<\/p>\n
Visualforce can still have a role, but the surrounding user experience matters. Test navigation, responsive behavior, styling, embedded applications, record context, and interaction with Lightning pages. Review integrations separately: an API integration is not necessarily affected by switching the interface, whereas a browser automation dependent on Classic’s rendered layout may be. The migration register should identify those dependencies explicitly.<\/p>\n
Plan access, permissions, and data behavior before launch<\/h3>\n Interface migration is not an excuse to redesign security silently. Salesforce objects, records and fields still have authorization controls. The move should preserve approved business access while checking that custom Lightning components, flows and actions respect the correct sharing and field-level permissions. A feature that renders successfully but exposes data to an unintended user is a release defect, not a cosmetic issue.<\/p>\n
Use representative test users rather than validating everything as a System Administrator. Create roles or approved test identities that model sales representatives, service agents, managers, analysts and restricted-access employees. Walk through record creation, editing, related lists, approvals, attachments, imports and exports according to each role. Record where the experience differs from Classic and whether those differences are acceptable.<\/p>\n
Data integrity needs its own checkpoint. Verify important calculated fields, validation rules, duplicate controls, automated notifications and reporting totals before and after the interface change. An interface switch should not cause unexplained changes to the business meaning of a report or the conditions under which a record is updated. When modernization includes Flow or other automation changes, test those changes as a separate scope with their own rollback strategy.<\/p>\n
Design a migration pilot that produces usable evidence<\/h3>\n A pilot should include people who perform high-frequency tasks and people who handle unusual but consequential exceptions. Choose a limited group with clear success criteria: complete defined workflows, find necessary information, respect permissions, and report blockers within an agreed support process. Avoid using only enthusiastic early adopters; they may not encounter the practical obstacles faced by the broader organization.<\/p>\n
Define test cases in language users recognize. A service agent should be able to locate a customer, create and categorize a case, attach the necessary context, route the case appropriately and confirm its status. A sales user should be able to progress an opportunity, complete the required approval and produce the expected forecast data. Each scenario should specify the expected outcome and a person authorized to accept it.<\/p>\n
Keep a prioritized defect list that separates missing capability, misunderstood navigation, permission failure, data mismatch and genuine performance problems. A training issue calls for guidance; an authorization or data problem requires technical correction. Treating both as \u201cusers dislike Lightning\u201d makes it difficult to target the fix or determine readiness.<\/p>\n
Manage adoption as an operational change<\/h3>\n Users do not experience a migration as an architecture diagram. They notice whether a customer record appears where expected, whether a familiar action has moved, and whether common work takes more steps. Therefore training should be task-specific. Short demonstrations built around the team’s actual day-to-day workflows usually provide more value than a broad feature tour with little relevance to their responsibilities.<\/p>\n
Provide a concise \u201cwhere did this move?\u201d reference for high-frequency actions, including record navigation, global search, related lists, reports, list views, activities and actions. Explain changes in terminology when relevant. Supervisors should understand which new procedures they are expected to reinforce, while administrators need a clear channel for collecting feedback and confirming whether a reported problem is reproducible.<\/p>\n
Salesforce adoption benefits from operational measurements, but those metrics should reflect business outcomes. Compare task completion, error rates, repeat support requests and actual use of approved workflows. Raw login counts or impressions of a new interface may look positive even when important work is still blocked. For an adjacent discussion of readiness signals, Lightning migration considerations<\/a> can help frame when additional preparation is worthwhile.<\/p>\nUse phased deployment and a realistic fallback<\/h3>\n A rollout does not need to change every department at once. Pilot results can guide a sequence by business unit, role or critical workflow, provided shared processes remain coordinated. Document the owner of each migration decision, the tested functionality, training completion and unresolved issues. A change window should account for busy operational periods, not just developer availability.<\/p>\n
The rollback plan must be specific about what can actually be reversed. Switching an eligible user back to Classic may be possible, but a newly deployed Flow, changed permission model, replaced component or modified integration will not necessarily revert merely because the interface changes. Make configuration backups, keep a tested deployment history and plan reversal steps for each material change. For processes touching finance, service obligations or regulated data, define the conditions under which rollout must stop.<\/p>\n
Keep the pilot support channel available during the first days of broader use. Monitor errors and business task results rather than relying on an absence of complaints. When a defect emerges, isolate its owner and whether it affects the interface, customization, data, access or an external integration. That categorization helps avoid unnecessary platform-wide rollback for a local problem.<\/p>\n
Decide what to modernize and what to preserve<\/h3>\n A strong migration is not a rewrite-everything program. Stable integrations or validated business rules can remain when they are supported and meet current needs. Interface-dependent customizations should be prioritized by risk and benefit, and unnecessary historical workarounds should be retired only after their business purpose has been checked. A legacy button that looks unused may still support an infrequent but critical month-end process.<\/p>\n
Prioritization can combine consequence of failure, frequency of use, maintenance burden, product compatibility, and business value. The order will differ across organizations. A service operation with heavy case volumes may focus first on agent experience, while a business with extensive custom sales approvals may need to address button and automation behavior before broad training. Product features should serve those outcomes rather than drive the plan by themselves.<\/p>\n
Salesforce Classic’s continued conditional availability does not remove the reasons to adopt Lightning Experience. It also does not justify inventing a universal Classic shutdown date or assuming every customer will realize the same efficiency improvement. The responsible decision is to verify edition and permissions, test actual workflows, address supported-component gaps, train people on their tasks, and release through a staged process with clear evidence and rollback controls.<\/p>\n","protected":false},"excerpt":{"rendered":"
Salesforce Lightning Experience is the primary interface for modern Salesforce administration and many newly developed features, but that does not mean Salesforce Classic has disappeared. Salesforce’s May 2026 support documentation confirms that authorized users in eligible editions can still switch between Lightning Experience and Classic. Some editions are Lightning-only, and administrators can restrict switching. For […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1094],"tags":[],"class_list":["post-4027","post","type-post","status-publish","format-standard","hentry","category-others"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t