March 9, 2023
Moving from Salesforce Classic to Lightning Experience gives your teams a faster, modern workspace and access to every new feature Salesforce ships. The move changes the interface and the building blocks behind it, not your data. A smooth Salesforce Classic to Lightning migration comes down to one habit. Find the pieces that behave differently in Lightning, and fix them before users feel it. Most of those pieces are well known, and each one has a clear fix.
Picture a service director at a regional insurance firm on launch day. Lightning goes live, and within an hour the calls start. A custom button that created renewal quotes does nothing. A Visualforce page looks out of place. Two agents have already switched back to Classic because the record page loads slowly. None of these issues were hard to fix. They were simply found too late. With a clear challenge list and a fix for each one, that same launch day is quiet.
This guide walks you through the real challenges teams hit during the move and the engineering fix for each one. You will also see how to use the migration to clean up your org for good.
A Salesforce Classic to Lightning migration swaps the user interface and the component model. Your records, fields, objects, and security settings stay where they are. There is no data to move, because both interfaces read from the same database.
What changes is how screens, buttons, and custom code behave. Lightning is built on reusable components, record pages you design in Lightning App Builder, and modern automation in Flow. Anything built only for Classic, such as JavaScript buttons or S-controls, needs a new home.
That is why the hard part of a migration is rarely the switch itself. It is the long tail of Classic-only customizations. For the full step-by-step plan, with the Readiness Check and a sample timeline, see our Salesforce Classic to Lightning migration guide for 2026. This post goes deep on the challenges and how to solve them.
These are the issues we see most often across Salesforce orgs of every size. Each one comes with a fix you can plan for.
Classic orgs often rely on JavaScript buttons to create records, call Apex, or prefill forms. Lightning does not run JavaScript buttons, and it never supported S-controls. Many teams also used "URL hacks" to prefill fields, and those do not behave the same way in Lightning.
The fix: Replace each button with a quick action, a Flow, or a Lightning web component. For prefilled forms, use predefined field values on quick actions. The free App Customization Lite module on Trailhead shows how actions work in Lightning Experience.
Most Visualforce pages still run in Lightning, but they can look dated next to Lightning pages. Some break when they rely on Classic-only navigation or styling.
The fix: Sort your Visualforce pages into three groups. Keep low-traffic pages and turn on Lightning styling for them. Adjust pages that use Classic navigation. Rebuild high-traffic or complex pages as Lightning web components. During a phased rebuild, Visualforce and Lightning components can share data through Lightning Message Service. This guide to event handling between Aura, Lightning web components, and Visualforce shows how. For larger rebuilds, our Salesforce customization services team can plan and deliver the component work. See our work on Lightning Web Component development for a growing Visualforce app.
Many Classic orgs still run Workflow Rules and Process Builder. Salesforce ended support for both tools at the end of 2025, and all new automation features now land in Flow.
The fix: Treat automation as part of the migration, not a separate project. Use Salesforce's Migrate to Flow tool to convert simple rules, then rebuild complex processes by hand. Combine overlapping rules on the same object into fewer, cleaner flows.
Lightning is built around Files and Enhanced Notes. Old Classic attachments and notes still exist, but users may struggle to find or share them. Custom HTML home page components from Classic do not carry over at all.
The fix: Convert old notes and attachments with a tool such as Magic Mover from Salesforce Labs. Rebuild home pages in Lightning App Builder, with the reports, lists, and actions each team needs.
Older AppExchange packages may have been built for Classic. Some work only in part, and some not at all.
The fix: List every installed package and check its Lightning support with the vendor. Upgrade to the current version, replace it with a Lightning-ready option, or retire it if no one uses it. Custom components must also follow today's security model. Review this breakdown of Lightning Locker vs Lightning Web Security before you ship new code.
Lightning pages can feel slow when they carry too much. Too many related lists, components, or fields all add load time. Users notice right away, and slow pages are a top reason people switch back.
The fix: Track page load times in the Lightning Usage App. Move less-used details into tabs, trim related lists, and show fields only when they matter using Dynamic Forms. Test the slowest pages with real users before launch.
Most API integrations keep working. They do not depend on the interface. Problems show up in custom code that builds Classic URLs, opens Classic pages, or assumes Classic navigation.
The fix: Search your Apex, Visualforce, and email templates for hard-coded Classic links. Update them to Lightning navigation. Test every integration in a full sandbox before launch. Our Salesforce integration services team can review your connections and custom code for Classic-only patterns.
If users can switch back to Classic, many will, especially in the first weeks. That splits your team across two interfaces and slows adoption.
The fix: Train by role before launch. Show each team the few features that make their day easier, and gather feedback in the first weeks. Once a team is ready, remove the option to switch back to Classic for that group.
Use this table to scope your Classic to Lightning migration. It lists each challenge, what tends to break, and the fix to plan for.
| Challenge | What Tends to Break | Fix to Plan For |
|---|---|---|
| JavaScript buttons and S-controls | Custom actions do nothing in Lightning | Rebuild as quick actions, Flow, or Lightning web components |
| URL hacks | Prefilled forms stop filling fields | Use predefined field values on quick actions |
| Visualforce pages | Dated look or broken Classic navigation | Add Lightning styling, update navigation, or rebuild as a Lightning web component |
| Workflow Rules and Process Builder | Tools past end of support | Convert to Flow with Migrate to Flow, then refine |
| Notes, attachments, and home page components | Content is hard to find, custom home pages are missing | Convert to Files and Enhanced Notes, rebuild home pages |
| AppExchange packages | Partial or no Lightning support | Upgrade, replace, or retire the package |
| Heavy record pages | Slow load times, users switch back | Use tabs, trim related lists, and apply Dynamic Forms |
| Custom code with Classic links | Links open Classic pages or fail | Update to Lightning navigation and test in a full sandbox |
| User habits | Users keep switching back to Classic | Role-based training, then remove the switch option |
Many Classic features have a direct Lightning replacement. Knowing the match ahead of time makes planning faster. For a closer look at what the new tools can do, see our guide to the standout features of Salesforce Lightning.
| Classic Feature | Lightning Replacement |
|---|---|
| JavaScript buttons | Quick actions, Flow, or Lightning web components |
| S-controls | Lightning web components |
| Custom HTML home page components | Lightning home pages built in Lightning App Builder |
| Workflow Rules and Process Builder | Flow |
| Notes and Attachments | Enhanced Notes and Files |
| Classic Console | Lightning Console apps |
| Page layouts alone | Lightning record pages with Dynamic Forms |
| Visualforce pages | Visualforce with Lightning styling, or a Lightning web component rebuild |
A Lightning migration in Salesforce is the best chance you will get to clear years of tech debt. You are already touching buttons, pages, and automation, so fix what is broken while you are there.
Before you rebuild anything, check whether people still use it. Old reports, unused fields, and forgotten Visualforce pages often make up a large share of a Classic org. Retiring them shrinks the project and makes Lightning faster.
When a page or button needs a rebuild, build it once, the right way. Lightning web components are built on web standards and run fast, as this introduction to Lightning Web Components explains. Reusable components also cut future maintenance.
Migrations touch hundreds of small items. Without version control and a clear release path, changes collide and break each other. Track every change in source control, test in sandboxes, and release in small batches. That DevOps discipline keeps the migration safe and gives you an easy way to roll back.
No. Both interfaces use the same database, so your records, fields, and security stay in place. The work is in updating screens, buttons, automation, and custom code.
It depends on how many Classic-only customizations you have. An org with few custom buttons and Visualforce pages can move fast. A heavily customized org needs more time for rebuilds and testing.
Most do. Many need styling updates, and pages that rely on Classic navigation need changes. High-traffic pages are often worth rebuilding as Lightning web components.
Admins can control this. During rollout, you may allow switching. Once a team is ready, you can remove the option so everyone works in Lightning.
Finding Classic-only customizations too late. A full inventory of buttons, pages, automation, packages, and custom code before launch removes most of the risk.
Salesforce Classic to Lightning migration challenges are well known, and each one has a clear fix. When you inventory Classic-only buttons, pages, automation, and packages early, you can plan the right fix for each. Your users then get a faster workspace on day one, not a list of broken tools.
Minuscule Technologies helps companies make the move the engineering way. Our Accelerators and Starter Packs give you a tested starting point for org assessments, Flow conversions, and component rebuilds. Our certified team pairs this with DevOps discipline, so every change is tracked, tested, and easy to roll back.
Ready to plan your move to Lightning? Book a strategy call with our team. We will review your Classic org and share a clear path to a calm launch day.
You've seen what's possible. Now, let's make it happen for your business. Whether you need an end-to-end Salesforce solution, a complex integration, or ongoing managed services, our team is ready to deliver.
Schedule a Free Strategic Call
Plot No. 4, Sridevi Amman Street, Perumal Nagar Extension, Old Pallavaram, Chennai, Tamil Nadu 600117, India.
