How do you migrate a Salesforce instance from Classic to Lightning when half the AE team has 5 years of muscle memory in Classic in 2027?

The org where the quoting button died on a Tuesday

Picture the shape of the problem concretely, because the abstract version ("change management is hard") produces abstract plans that fail. A 60-seat sales org, Salesforce instance stood up in 2018, heavily customized by three successive admins. Thirty-one of the AEs joined before 2021 and have five years of Classic muscle memory. Nine of them are the top of the leaderboard. The RevOps lead flips on Lightning Experience for the sales profile on a Tuesday morning after a weekend of testing, sends a Loom, and goes to a leadership offsite.

By 10:40 a.m. the first message hits the sales channel: the "Create Renewal Quote" button is gone. It is not gone — it is a JavaScript button, and JavaScript buttons do not execute in Lightning Experience, so it renders and does nothing. By 11:15 three more reps have posted. By lunch a tenured AE has written the sentence that kills migrations: "I've lost an hour of selling time and it's not even noon." By 2 p.m. the RevOps lead is on a call from the offsite hallway toggling the sales profile back to Classic, and the migration is now radioactive for at least two quarters. Nobody's config was wrong in a way that couldn't have been caught. The readiness assessment was skipped, and the org discovered its technical backlog live, in production, in front of the exact population least inclined to be forgiving.

The diagnostic detail that matters: the AEs in that story were not resisting change. They were reporting a real defect. Distinguishing those two things is the whole job. Muscle memory is a genuine cost — a rep who has offloaded record navigation into procedural memory does a forty-second version of an eight-second task for the first ten to fourteen days, and that dip is real whether or not your config is clean. But a dead button is not a dip; it is a blocker, and blockers are what convert a survivable dip into a revolt. When you plan this migration, you are managing two separate curves at once: a temporary competence dip you can only shorten and warn about, and a defect count you can drive to zero before anyone sees it.

The second detail: half the team hating change is often a polite translation of "leadership never committed." Before you spend a quarter on elaborate change-management theater, check whether your CRO will personally run Monday pipeline review from a Lightning Kanban board. If the answer is no, that is your actual problem, and no amount of champion recruitment fixes it. A sales team reads leadership behavior with forensic precision; a CRO who has an ops analyst pull reports so they never touch the new UI is broadcasting that the migration is optional, and the tenured reps will hear it inside a week.

The third detail worth naming: Classic is end-of-life, and this is not a discretionary modernization project. Salesforce has not shipped meaningful new Classic functionality in years. Dynamic Forms, Dynamic Actions, the Lightning App Builder, In-App Guidance, Einstein Activity Capture, Einstein Opportunity Scoring, Revenue Intelligence, the Agentforce stack, and the overwhelming majority of current AppExchange packages are Lightning-only by design. Salesforce has spent multiple release cycles auto-enabling Lightning Experience in orgs that had not turned it on. That is leverage, and most RevOps leads forget to use it — the deadline is the vendor's, not yours, which means resistance has nowhere personal to land.

How the migration mechanism actually works

The mechanism has four moving parts that have to fire in order: assessment produces a backlog, remediation burns the backlog to zero blockers, page design converts the interface from slower-than-Classic to faster-than-Classic, and the pilot manufactures social proof before the skeptical majority is ever exposed. Skip any one and the next one degrades.

Assessment. Start with the Lightning Experience Readiness Report, run from Setup — Salesforce emails back a personalized PDF estimating org readiness and flagging features that behave differently or are unsupported. It is the right free starting inventory and it is not sufficient. Layer four hand-built inventories on top. First, every JavaScript button and link in the instance, because these are the single highest-risk item: they silently do nothing in Lightning, and each one is a rep hitting a dead end. Second, every Visualforce page — most keep functioning but render inside Lightning chrome, and older VF styling frequently looks broken or misaligned. Third, every list view, because tenured orgs are graveyards of "Q3 Pipeline copy" and "My Open Opps (OLD)" created by reps who left in 2020, and Lightning surfaces list views far more prominently than Classic did. Fourth, every managed package and integration.

Rate each finding blocker, friction, or cosmetic. A blocker means a rep cannot do their job. Friction means it works but worse. Cosmetic means it looks wrong. That severity rating is the whole scheduling logic for the rest of the project: blockers are 100% dead before any user migrates, friction items get folded into the pilot-and-iterate loop, cosmetic items trail the rollout.

Remediation. JavaScript button conversion is the centerpiece, and the replacement pattern follows what the button did. A button that created a related record with pre-populated fields becomes a Quick Action or a screen Flow. A button that applied field logic becomes an autolaunched or record-triggered Flow. A button that hit an external endpoint becomes a Flow with an HTTP callout or an invocable Apex action. Genuinely complex behavior becomes a Lightning web component with an Apex controller. Modern Flow is dramatically more capable than it was three years ago, and most historical JS buttons rebuild declaratively. The discipline that saves the most time: audit usage before you rebuild. In a seven-year-old instance a large share of JS buttons are vestigial, and retiring one is faster and safer than porting it.

Page design. This is where the "Lightning is slower" complaint is either confirmed or inverted, covered in its own section below.

Pilot. The cohort is a casting decision, and two failure modes dominate. Stacking the pilot with eager early adopters produces a feel-good result that proves nothing about the skeptical majority. Throwing the loudest complainers in first turns the pilot into a referendum and hands them a megaphone. The correct composition is a deliberate cross-section: two or three genuinely enthusiastic reps, several middle-of-the-distribution reps who are the real test, coverage across selling motions or segments so you catch role-specific gaps, and one or two respected, tenured, change-skeptical AEs who are not the loudest voices but whose opinion the floor trusts. That last category is the strategic heart of it. You are recruiting a witness, not converting a critic for its own sake — a respected skeptic's quiet "yeah, this is actually fine" outperforms every executive endorsement you can buy.

Making Lightning measurably faster than Classic

The number one AE complaint about Lightning is that it is slower, and out of the box that complaint is usually accurate. When you enable Lightning Experience, Salesforce auto-generates a record page that crams in everything — the full detail block, every related list, the complete activity timeline — all loading on initial render, each component a potential server round-trip. If your admin migrated by clicking enable and accepting defaults, your reps are genuinely working in a heavier interface and "Lightning is slow" is a bug report, not an attitude. Do not gaslight them about it.

This is also the single highest-leverage change-management lever you own, because you can invert it. A skeptic who experiences "wait, this is actually quicker than my old screen" converts more durably than any training deck reaches them. Speed is a first-class deliverable. In rough order of impact:

Adopt Dynamic Forms. Dynamic Forms break the monolithic Details panel into individual field sections and fields you can place anywhere and show or hide conditionally. Instead of rendering a sixty-field detail block on every Opportunity, render the ten or twelve fields that matter at this record's stage and reveal the rest conditionally. Biggest single lever for both perceived speed and screen clarity, and it lets you build pages that match the rep's workflow instead of dumping the data model on them.

Put every record page on a strict component diet. Every component carries a load cost. Ask honestly whether the AE uses this related list on this object. If it is referenced monthly, it does not belong on the default view. Be ruthless — the landing view of an Opportunity should be the fields that drive the next action, the Path, the activity composer, and very little else.

Use tabs structurally. Components on non-active tabs do not load until the tab is opened. Putting high-frequency content on the default tab and everything else behind secondary tabs is one structural decision that can cut initial page load substantially, with no code.

Trim the activity timeline and reconsider whether the full history needs to be expanded by default.

Fix list-view defaults. Reps live in list views. Delete the dead ones, rename the survivors in plain language, and define a clean default set per object and per profile, so the first thing a migrated rep sees is useful rather than the accumulated debris of seven years.

Profile custom components. One badly written Lightning component with an unindexed SOQL query in its controller can make an entire record page feel sluggish, and it will get blamed on Lightning rather than on the component.

Instrument with the Lightning Usage App. It reports page-load performance, including EPT (Experienced Page Time), so you can find the actual slow pages instead of guessing. Optimize the worst offenders first, and re-measure after each change.

The mindset shift is the point: do not migrate the Classic layout. Design the Lightning record page backward from the rep's workflow. What does an AE need in the first half-second on an Opportunity? Put exactly that on the default tab and push the rest behind tabs and conditional visibility.

Real numbers, ranges, and benchmarks

Enthusiasm is not evidence, and a change-resistant team does not run on enthusiasm. Generate hard numbers during the pilot, because that is the only window where you can measure the same task in both interfaces with the same people.

The timeline. Realistically 8 to 16 weeks end to end for a change-resistant team, with variance driven almost entirely by the size of the JavaScript-button and Visualforce backlog and by headcount. Compressing below eight weeks in a customized instance means skipping remediation or skipping the pilot, and both are fatal. Stretching much past sixteen risks the two-system limbo. The rough shape, with deliberate overlap:

• Weeks 1–2, assess. Readiness Report, feature-gap audit, the four inventories, prioritized backlog. Lock visible executive sponsorship. Set the hard Classic sunset date now and start saying it out loud.
• Weeks 2–6, remediate. Burn the backlog. Convert JS buttons, rebuild or wrap high-traffic VF pages, clean list views, design the record pages for speed, verify every integration in a sandbox. Recruit and pre-train champions. Build role-specific training and In-App Guidance.
• Weeks 5–8, pilot. Representative cohort moves. White-glove support, fast feedback channel, visible fixes, before/after task studies.
• Weeks 7–9, iterate. Fold pilot feedback into config, re-test, finalize training against what reps actually struggled with, lock the wave schedule.
• Weeks 8–14, wave rollout. Migrate by team, pod, or region. Just-in-time training per wave, champion support per wave, dashboard watched wave by wave.
• Weeks 13–15, Classic sunset. On the pre-announced date, remove the permission and close the toggle.
• Weeks 14–16+, reinforcement. 30/60/90 follow-up, office hours, advanced training, ongoing optimization.

The muscle-memory dip. Plan for one to two weeks of reduced speed per rep, with most crossing back to parity around week two and above their old speed by week three, assuming the page design work was done. Run the pilot two to four weeks precisely so it spans the dip — a pilot that ends in week one captures all of the pain and none of the payoff, and gives you testimony you cannot use.

Task-time studies. Pick five to eight high-frequency tasks — log a call, advance a stage, create a quote, update a forecast field, build a list view — and time them in Classic before the pilot and in Lightning after the dip. Report them as concrete sentences: "logging a call went from X seconds to Y." That format works because every rep does the task dozens of times daily and does the multiplication themselves. Do not publish the numbers if they favor Classic; that means your page design is not done, and you go back to the previous section rather than shipping a slower instance.

Cohort sizing. Keep the pilot large enough to be representative and small enough that every participant gets white-glove support — in a 60-rep org, roughly 8 to 12 people. One champion per team or pod is plenty; you do not need many, you need credible ones.

Resourcing. Admin hours are the core cost and, through the heaviest remediation weeks, this is effectively a full-time job for at least one capable admin. If your single admin is also keeping daily operations running, you are under-resourced — either dedicate them and backfill ops, or add hands. A lightly customized 30-rep instance can plausibly be done by one dedicated admin over eight to ten weeks with no external spend. A 100-rep instance with a heavy JS-button and Visualforce backlog often warrants an implementation partner and a four-month calendar, because complex button conversion and VF rebuilds are specialized work a good partner compresses significantly. Lightning Experience itself is included with the platform, so licensing is usually not a migration line item — unless you are also switching on Einstein or Agentforce to sweeten the pitch, in which case those costs belong in a separate line, not buried in the migration budget.

Adoption metrics that mean something. Percentage of users on Lightning is presence, not adoption. Track it, but treat it as necessary and insufficient. The Lightning Usage App also reports who is switching back to Classic — that metric is an early-warning system, and a rep flipping back repeatedly has hit something the new interface is not doing for them, which is a signal to investigate rather than scold. The numbers that actually indicate adoption are feature-level: Kanban usage, deals advanced through the Path, activity-logging rate compared with the Classic baseline, split-view usage, In-App Guidance completion. If reps are present but not using the features, you bought compliance, not adoption, and the migration has not delivered its value. Layer short sentiment pulse surveys — two or three questions every couple of weeks — because sentiment craters before feature adoption does, and catching one pod's dip in week three lets you intervene before resentment hardens.

Trade-offs: big-bang versus phased, and when each is right

There are two migration philosophies, and picking the wrong one for your team is the most consequential strategic decision in the project.

Big-bang flips the whole instance on one date. Everyone wakes up Monday in Lightning; Classic is disabled. The advantages are real and frequently undersold: no prolonged dual-system limbo, no "which UI are you in?" support confusion, one hard finish line that forces focus, concentrated training, perfectly consistent process definitions because only one interface is ever live, and — importantly — no "switch back to Classic" escape hatch quietly undermining adoption. For a small org with light customization, a clean config, and a team that is neutral about change, big-bang is often correct, and elaborate phased change-management is wasted motion.

Phased opt-in moves users in controlled waves over weeks, with Classic available via permission set until a defined sunset. Risk is contained per wave, problems surface at pilot scale rather than org scale, and early waves manufacture champions who evangelize later ones.

For a team where half the AEs have five years of Classic muscle memory, phased almost always wins — for a psychological reason more than a risk one. Resistance feeds on the narrative "this is being done *to* us," and a big-bang cutover, however well executed, confirms it: a date was set, a switch was flipped, you had no say. Phased lets you build the opposite story: we piloted, we listened, we fixed what the pilot reps complained about, your colleagues helped design the Opportunity page, and here are the task times. It buys you the one thing big-bang cannot — time to manufacture social proof before the skeptics are exposed.

Phased has one severe failure mode you must design against: the rollout that never ends. Nine months of two live interfaces with no forcing function is worse than either pure state — split documentation, split training, split support, inconsistent process, and a permanent holdout population. The discipline that makes phased work is a hard Classic sunset date set in week one and repeated relentlessly. Phased means time-boxed, not indefinite.

The timing of closing the escape hatch is its own trade-off. Leave the toggle open forever and a meaningful slice of the team uses it as a pressure-release valve, never building new muscle memory, always one click from the old world. Close it too early — before blockers are dead and reps are through the dip — and you yanked away a safety net you had promised, which costs you more credibility than the toggle was worth. The correct sequence: keep Classic genuinely available through pilot and waves, communicate the sunset date from day one, ensure every rep is migrated, trained, and past the dip by that date, then actually close it on the date.

Champions, training, and the WIIFM that actually lands

The center of gravity in a change-resistant migration is the champion model, and it rests on one behavioral fact: AEs trust other AEs far more than they trust admins, RevOps, or leadership. When an admin says Lightning is better, a skeptical rep hears a vendor pitch. When a respected peer says "I was dreading this and it turned out fine, here's the one thing that made it click," the rep hears the truth.

Recruit deliberately. A good champion is a credible AE with tenure and quota performance the floor respects, who came through the pilot converted and is willing to help. Not the most technical rep, not the most enthusiastic — the one whose opinion carries weight. Give them extra training, a direct line to the admin, and explicit recognition. Champions do three jobs: co-deliver training (a rep demonstrating "here's how I log a call now, here's where the renewal action went" carries the implicit message that a real seller figured this out), field the small "where did X go" questions reps will never bring to an admin, and translate the WIIFM into peer language.

That WIIFM must be per-persona. For the AE: Kanban for dragging opportunities across stages visually, the Path component putting stage requirements and guidance on screen so advancing a deal stops being tribal knowledge, the activity timeline giving one scrollable relationship history so they walk into a call briefed, split view for ripping through a list without bouncing back and forth, Einstein Activity Capture taking manual email and meeting logging off their plate, and genuine mobile parity so a deal updates from the parking lot. For the sales manager: real-time pipeline, better dashboards, coaching from the same screen the rep uses. For the CRO: forecast accuracy, AI-driven insight, a platform actually on the roadmap. The pitch is not "please comply." It is "we are taking work off your plate," and it is true.

Training fails the same way in most migrations: one ninety-minute admin-led webinar covering everything, delivered weeks before anyone needs it. Effective training inverts that on every axis. Role-specific — an AE never needs to see Case management. Scenario-based — teach "log a call after a discovery meeting," not "here is the activity component," because reps learn workflows, not features. Short — five-to-fifteen-minute modules, not a firehose. In the flow of work — In-App Guidance and in-app walkthroughs placed on the exact pages where questions arise are worth more than any recording, because the rep learns while doing the real task. Timed — deliver the day before and the week of that rep's wave, never three weeks ahead. Trailhead is a good supplement for reps who want depth; it is not the spine.

One more principle that costs nothing and saves the rollout: train for the dip. Tell reps explicitly that weeks one and two will feel slower because muscle memory has to rebuild, that this is normal and temporary, and that by week three they should be at or above their old pace. A rep warned about the dip rides through it. A rep surprised by it concludes the tool is broken and starts campaigning.

Common pitfalls and how to avoid them

Migrations fail in recognizable, repeatable ways, and each one inverts something above.

Unremediated JavaScript buttons. The most common and most preventable failure. Reps hit dead ends within hours, the broken-Lightning narrative spreads on the team channel by lunch, and the project spends the rest of its life defending itself. Avoid it by treating "zero blockers before any user migrates" as non-negotiable and by testing the actual button, not the page it sits on.

Accepting default record pages. Skip the speed work and Lightning genuinely is slower for everyday tasks. You have then handed the skeptics an accurate complaint you cannot rebut, and squandered the best conversion asset you had. Avoid it by treating page design as a deliverable with a measured before/after, not an afterthought.

Untested integrations. A rep does not experience Salesforce in isolation; they experience Salesforce and everything bolted to it. If CPQ does not work in Lightning, the migration broke quoting. Inventory and sandbox-test every managed package and integration — CPQ, conversation intelligence like Gong or Chorus, sales engagement like Outreach or Salesloft, document generation and e-signature like DocuSign or Conga, marketing automation connectors, enrichment, forecasting, and any custom middleware. Test the *workflow*, not the connection: "CPQ loads" is not the test; "a rep builds, finalizes, and sends a quote end to end" is. Where a vendor's Lightning support needs a version upgrade, schedule it into remediation. The audit doubles as cleanup — tenured instances carry managed packages nobody uses, and uninstalling a dead one is one less thing to test and break.

Admin-led webinar training. Reps tune out a non-peer explaining their own job, retention is near zero, and the org confuses "training was delivered" with "the team learned." Avoid with the champion model and in-app guidance.

No pilot. Every problem is discovered at full scale simultaneously, support drowns, skeptics are exposed before any social proof exists, and there is no "we listened and fixed it" story because there was no listening phase.

Handling the vocal minority in group settings. Never do this — they perform for an audience and you both entrench. Take it to a 1:1 and listen for real, because underneath the noise there is usually a specific fixable defect: "Lightning is terrible" decodes to "the page I open forty times a day takes four seconds and my renewal button is gone." That is a bug list, and a bug list is a gift. The strongest available move is co-design: put your loudest credible skeptic on the design team and ask them what belongs on the default tab of the Opportunity page. A person cannot simultaneously campaign against a thing and be a co-author of it, and the resulting page is genuinely better. Know when to hold firm, too — after you have piloted, listened, optimized speed, remediated blockers, and shown the data, the answer to "I just don't want to" is a calm, immovable "Classic retires on this date; here is all the support you need." Hold firm too early and you confirm the done-to-us narrative; too late and one rep holds the instance hostage. Infinite flexibility on *how* you land Lightning; zero on *whether*.

No executive modeling. Covered above, and it is the one that silently invalidates everything else.

No sunset date. "Phased" with no deadline ossifies into permanent limbo. There is always a reason to extend, and the holdouts simply wait you out.

Letting reinforcement lapse. The riskiest window for backsliding is the weeks after the final wave, when the project team's attention moves on. Run a deliberate 30/60/90: at 30 days check adoption and sentiment data and hold office hours against the friction real work has surfaced; at 60 days introduce the advanced features reps had no bandwidth for during initial training; at 90 days review team-wide before/after metrics and publicize the wins. Keep drop-in office hours running, because the questions reps will not file a ticket for they will happily ask in a casual slot, and keep the feedback loop alive so the behavior the pilot taught — feedback gets acted on — does not die the week the project closes.

Related questions

Should we run the migration during a quarter-end?

No. The muscle-memory dip costs each rep one to two weeks of reduced speed, and imposing that during the highest-stakes selling window guarantees the migration gets blamed for every missed number. Schedule waves early in a quarter, and never move a wave the week a forecast locks.

Can we migrate managers before reps?

Yes, and it is often smart. Sales leaders in Lightning first means they can model it, coach from the same screens, and answer wave-one questions credibly. It also surfaces reporting and dashboard gaps before the rep population hits them. Keep the gap short — two weeks, not two months.

What if a top producer refuses entirely?

Run the full playbook first: 1:1, listen for the real defect, fix it, co-design with them, show the task-time data. If genuine refusal persists after all of that and they are actively poisoning the team, it becomes a performance and management conversation, not a Salesforce one. This should be genuinely rare.

Do we need an implementation partner?

Only if the readiness assessment reveals a large, complex JavaScript-button and Visualforce backlog. Lightly customized instances rarely need one. When the backlog is heavy, partner cost is usually less than a blown timeline or a botched remediation that triggers a revolt.

FAQ

Why do JavaScript buttons stop working in Lightning?

Lightning Experience does not execute the browser-side JavaScript that Classic custom buttons and links relied on. The button still renders, so it looks functional and simply does nothing — which is why it produces such damaging first impressions. Replace each one with a Quick Action, a Flow, or a Lightning component before anyone migrates.

Is Lightning actually slower than Classic?

Out of the box, often yes — the auto-generated record page loads every related list, the full detail block, and the complete activity timeline at once. Configured well, with Dynamic Forms, a strict component diet, and tabbed secondary content, Lightning is typically faster than Classic for high-frequency tasks. The difference is entirely in the page design.

How long should we keep the Classic toggle available?

Through the pilot and the full wave rollout, as a genuine safety net, with a hard sunset date announced from week one — commonly landing around weeks 13 to 15 of an 8-to-16-week plan. Close it on the announced date, after every rep is migrated, trained, and past the muscle-memory dip.

Do Visualforce pages survive the migration?

Mostly they keep functioning, but they render inside the Lightning chrome and older VF styling frequently looks misaligned or broken. Triage per page: leave low-traffic functional ones, rebuild high-traffic workflow-critical ones as Lightning components, or wrap them in a Lightning page so they at least live in the right context.

What is the single highest-leverage thing we can do?

Design lean Lightning record pages before anyone sees them. It removes the only technically accurate objection the skeptics have, and a rep who experiences the new interface as measurably faster converts more durably than any training session or executive mandate will manage.

How do we know adoption is real and not just compliance?

Look past login percentage at feature-level metrics: Kanban usage, deals advanced through the Path, activity-logging rate versus the Classic baseline, and how often users switch back to Classic while the toggle exists. Pair those with short, frequent sentiment surveys, since sentiment drops before usage metrics do.

Sources

• https://help.salesforce.com/s/articleView?id=sf.lex_roadmap.htm
• https://trailhead.salesforce.com/en/content/learn/trails/lex_admin_migration
• https://help.salesforce.com/s/articleView?id=sf.lex_readiness_check.htm
• https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/migration_intro.htm
• https://help.salesforce.com/s/articleView?id=sf.dynamic_forms_overview.htm
• https://help.salesforce.com/s/articleView?id=sf.adoption_lightning_usage_app.htm
• https://help.salesforce.com/s/articleView?id=sf.lex_gaps_limitations_setup.htm
• https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/faq_general_javascript_buttons.htm
• https://help.salesforce.com/s/articleView?id=sf.in_app_guidance_overview.htm
• https://architect.salesforce.com/

Related on PULSE

• How do you build a Salesforce adoption dashboard that measures real usage, not logins?
• When should RevOps convert Salesforce workflow rules and process builders to Flow?
• How do you run a CRM pilot cohort that actually predicts full-team rollout results?
• What belongs on an Opportunity record page for a quota-carrying AE?
• How do you sunset a legacy sales tool without triggering a rep revolt?
• How do you audit AppExchange packages and integrations before a CRM migration?