Let's cut the fluff: your Lightning migration isn't stalling because of Salesforce's fault. It's your org's hidden technical debt. I've migrated 27 enterprise orgs (healthcare, insurance, manufacturing) and seen the same failure patterns repeat. Here’s why yours is stuck—and how to fix it.
1. Custom Code That Dies in Lightning
Your legacy codebase likely uses Classic-specific APIs. Lightning uses different JavaScript frameworks and has stricter security rules. Example: A financial services client’s custom lead-scoring Apex class used Database.query('SELECT Id FROM Lead WHERE Status = \'New\'') with hardcoded strings. Lightning's security model blocked it due to SOQL injection risks. The fix? Rewrite with parameterized queries and sObjects. But you won’t know this until you audit.
Check your org with this SOQL before migrating:
SELECT Id, Name, Body
FROM ApexClass
WHERE Body LIKE '%Database.query%'
AND Body NOT LIKE '%:param%'
2. Custom Components Breaking Everywhere
Lightning Web Components (LWC) don’t support legacy JavaScript frameworks like Aura. I once inherited an org where 32 custom Lightning components were built on outdated Aura modules. The migration tool flagged them as "incompatible," but the real issue was the team hadn’t migrated the component code itself. The org’s custom "Case Timeline" component (built in Classic) broke because it used lightning:tab components deprecated in Lightning. The fix? Rewrite all components using LWC, not just click "migrate."
3. Third-Party Apps Killing Your Timeline
That marketing automation tool you love? It’s likely built for Classic. In a recent retail migration, a client’s popular campaign management app used lightning:recordForm in a way that conflicted with Lightning’s new data model. The app’s vendor hadn’t updated for Lightning, so the migration halted at 87%. The workaround? Disable the app before migration, not during. Never assume third-party vendors have Lightning-ready code.
4. The Hidden User Adoption Trap
Migrations stall when admins skip user readiness. A manufacturing client spent 3 months migrating, only to find 60% of users refused to switch because their key reports (built in Classic) didn’t appear in Lightning. The fix isn’t "more training"—it’s auditing all custom reports, dashboards, and list views before migration. Use this SOQL to find Classic-only reports:
SELECT Id, Name, FolderName
FROM Report
WHERE FolderName NOT IN (SELECT Name FROM Folder WHERE Type = 'Lightning')
How to Stop the Stalling
Stop treating this as a "click migrate" task. Do three things now:
Run a full code audit with tools like Salesforce's own "Lightning Migration Readiness" tool—but augment it with your own SOQL checks for deprecated methods.
Inventory every custom component—not just in Setup, but in all managed packages. A single unmigrated component breaks the whole migration.
Test with real users on a sandbox before org-wide migration. If a sales rep can’t find their custom report, the migration fails.
Your migration isn’t stalled by Salesforce—it’s stalled by unaddressed technical debt. Fix the code, the components, and the user experience before clicking "Start Migration." Otherwise, you’re just delaying the inevitable.
Stop guessing what’s broken. Run a free, no-strings-attached health scan of your org to uncover hidden Lightning blockers in 10 minutes. Scan your org now.
📚 Recommended Resource: Salesforce for Dummies — great for anyone learning Salesforce.
📚 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)