Salesforce Classic is deprecated; orgs still on it must migrate. The challenges scale with org complexity.
Phase 1: Assessment
- Lightning Experience Readiness Check (Setup -> Lightning Experience) — automated tool that scans the org and flags blockers. Run it; review every flag.
- Inventory: VF pages, custom buttons (especially JavaScript Buttons — Classic-only), custom Apps, custom Tabs, integrations using Classic-specific URLs.
- Estimate effort: simple orgs ~3 months, complex orgs 12+ months.
Phase 2: Plan
- Decide: phased rollout (group by group) or big-bang.
- Train the team on Lightning concepts (App Builder, Lightning Pages vs page layouts, Quick Actions).
- Set up sandboxes for the Lightning build.
Phase 3: Build
- Lightning Apps for each persona (Sales Console, Service Console, etc.).
- Lightning Record Pages in App Builder per object — replaces Classic page layouts as the primary UX.
- Quick Actions to replace JavaScript Buttons (which don't run in Lightning).
- Custom Lightning Components or LWCs to replace any Classic-specific Visualforce pages.
- Compact Layouts for highlights panels.
Phase 4: Test
- UAT in sandbox with real users.
- Compare feature-by-feature: does the user have the same capabilities? Is anything missing?
- Performance test — Lightning has different render performance than Classic.
Phase 5: Roll out
- Enable Lightning in Production for a pilot group.
- Train users (Trailhead's Lightning Experience modules, recorded walkthroughs).
- Monitor adoption and pain points.
- Expand to more groups as confidence grows.
- Eventually disable Classic for everyone.
Common challenges:
- JavaScript Buttons — must be rewritten as Quick Actions (declarative) or LWC (custom).
- Visualforce pages — work in Lightning but feel dated; long-term migration to LWC.
- Custom Settings UI — Classic UI exists; Lightning doesn't have full UI for Custom Settings management. Often requires a custom LWC.
- User resistance — long-time Classic users find Lightning unfamiliar. Change management critical.
- Custom domain (My Domain) — required for Lightning. If not deployed, must do that first.
- Performance perception — early Lightning was slower than Classic. Modern Lightning is competitive but tune carefully.
- Email Templates, Letterheads — many orgs migrate to Lightning Email Templates as part of this.
Tools:
- Lightning Experience Configuration Converter — semi-automatic migration of certain components.
- Optimizer — flags performance issues.
Senior consultants treat Classic-to-Lightning as a transformation, not just a UI change. Done right, it's an opportunity to clean up technical debt accumulated during Classic-era. Done wrong, it just shifts the pain to a new UI.