Moving from Salesforce Classic to Lightning isn't optional—it's mandatory for continued support, security updates, and productivity. I've led 12+ enterprise migrations (retail, healthcare, manufacturing) across 10+ orgs, and skipping proper planning turns "30-day" into "120-day" nightmares. Here’s how to do it right—no fluff, just executable steps.
Phase 1: Audit & Prioritize (Days 1-5)
Start by identifying what actually needs migration. Don’t touch everything at once. Use this checklist:
Scan for custom components:
SELECT Id, Name FROM Component WHERE IsLightningEnabled = false(run in Developer Console)Flag deprecated APIs: Check
Schema.getGlobalDescribe()for old methodsPrioritize by usage:
SELECT Id, Label, LastModifiedDate FROM Layout WHERE LayoutType = 'Detail'(sort by LastModifiedDate)
Example: At a global pharmaceutical org, we discovered 87% of custom Visualforce pages were unused. We killed those first—saving 3 weeks of rework. Never migrate a page with zero active users.
Phase 2: Build & Test (Days 6-20)
Focus on user-impacting areas first. My rule: Fix what your sales team screams about daily.
For standard objects (Accounts, Opportunities), use Setup > Lightning Experience Configuration to toggle. For custom objects:
Create Lightning components for key flows (e.g., a "Quote Approval" component replacing a complex VF page)
Test with real data: Run
SELECT Id, Name FROM Opportunity WHERE StageName = 'Proposal'and validate Lightning UI behaviorUse
lightning:containerto wrap legacy VF pages temporarily (only if absolutely necessary)
Example: A retail client’s "Inventory Replenishment" custom object had 120+ field dependencies. We rebuilt it as a Lightning component using Lightning Web Components (LWC) with a single Apex method. Result: 40% faster load times, no data loss.
Phase 3: Deploy & Train (Days 21-30)
Roll out in waves, not all at once. Start with power users (sales ops, service leads), not the whole org.
Key steps:
Enable Lightning for 20% of users first. Monitor
EventLogFilefor errorsRun
SELECT Id, Name FROM User WHERE isActive = true AND hasSetupLogin = falseto track adoptionHost 15-minute "Lunch & Learn" sessions for each department (sales, service, marketing)
Common pitfall: Forgetting to update permission sets. At a manufacturing client, 30% of users couldn’t access Lightning because we missed adding the "Lightning Experience" permission to their profiles. Always verify with SELECT Id, Name FROM PermissionSet WHERE Name LIKE '%Lightning%'.
One Critical Check You’ll Miss
Most admins assume "if it works in Classic, it works in Lightning." Wrong. Lightning breaks legacy JavaScript. Example: A healthcare client’s custom "Patient Dashboard" used jQuery to manipulate DOM. In Lightning, it crashed. Fix: Replace with Aura components and lightning:container wrappers.
// BAD: Classic VF page with jQuery
$('div#dashboard').css('background', 'red');
// GOOD: Lightning LWC
import { api, track } from 'lwc';
export default class Dashboard extends LightningElement {
@track backgroundColor = 'red';
}
Stick to this plan. No exceptions. If you’re juggling 300+ custom objects, skip the "perfect" migration—prioritize user impact. I’ve seen orgs spend weeks trying to fix a custom report that nobody used. Focus on the 20% of features that drive 80% of productivity.
Still unsure if your org is Lightning-ready? Run a free health scan to uncover hidden risks—before they derail your 30-day timeline. Get your Org Scanner scan here.
📚 Recommended Resource: Salesforce for Dummies — great for anyone learning Salesforce.
📚 Recommended Resource: The Phoenix Project — great for anyone IT management.
📚 Recommended Resource: NIST Cybersecurity Framework Guide — great for anyone security frameworks.
Need a second opinion on your Salesforce org? Request a diagnostic.
Top comments (0)