Lightning Experience Transition
This skill activates when a practitioner is planning, sequencing, or troubleshooting the org-wide program to move users from Salesforce Classic to Lightning Experience. It does not duplicate piece-skills for individual asset migrations (Visualforce, JavaScript buttons, Knowledge, email templates) — it sits above them and provides the orchestration layer: readiness scoring, asset triage, wave sequencing, adoption telemetry, and cutover gates. Use it when the question is "how do we run this program," not "how do I migrate this one asset."
Before Starting
Gather this context before working on anything in this domain:
- The Lightning Experience Transition Assistant lives at Setup → Lightning Experience Transition Assistant. The Readiness Check it runs is the canonical starting point — every program plan should reference its scored output, not opinions about "what's blocking us."
- Lightning is on by default for orgs created after Winter '20. The transition program is therefore mostly about (a) the long tail of legacy orgs that still have Classic users and (b) ensuring assets render correctly in LEX. Confirm which case applies before proposing a plan.
- The number-one cause of failed transitions is users switching back to Classic because a workflow they rely on (a JavaScript button, a custom VF page in a related list, a print-friendly Console layout) does not work in LEX. Plan asset triage before turning Lightning on at the profile level.
- JavaScript buttons are not supported in Lightning Experience and are not auto-migrated. They must be replaced with Quick Actions, Lightning Component actions, headless flows, or
invocable Apex actions before users can rely on them in LEX.
- Permission Set-based gradual rollout is the safest sequencing strategy: assign the Lightning Experience User permission via permission sets keyed to user cohorts, rather than flipping the org-wide switch.
Core Concepts
The Readiness Check Is The Plan's Backbone
The Lightning Experience Transition Assistant runs a Readiness Check that scans the org for assets and configurations that affect LEX rollout: Visualforce pages with <apex:page> features incompatible with LEX rendering, JavaScript buttons (always flagged because they cannot run in LEX), Lightning-incompatible AppExchange packages, custom Console apps, hard pinning to Classic via UserPreferencesLightningExperiencePreferred, and unmigrated Knowledge articles.
The output ships as a PDF and is also surfaced in the Transition Assistant UI. Treat the Readiness Check report as the single source of truth for asset count and LEX-blocker classification. Do not start the program by inventorying assets manually — let the Readiness Check do that scan and use its output as the input to triage.
Asset Triage: Replace / Rebuild / Retain / Retire
Every legacy asset surfaced by the Readiness Check must be sorted into one of four buckets:
| Bucket |
When it applies |
What to do |
| Replace |
A Lightning-native equivalent exists (JS button → Quick Action; Classic email template → Lightning HEML) |
Build the replacement, validate, then disable the old asset |
| Rebuild |
Needed but cannot be 1:1 replaced (VF + JS Console layout → LWC + flow + utility-bar combo) |
Re-architect; ship before the wave that uses it |
| Retain |
Asset already works in LEX (most page layouts, validation rules, workflow rules, standard Apex) |
Confirm in Readiness Check; no change required |
| Retire |
Asset is dead (Last Used > 12 months; not in any active workflow) |
Delete; do not migrate dead assets |
The triage matrix is the program's working artifact. It enumerates every asset, its bucket, owner, target wave, and acceptance criteria.
Wave-Based Rollout Via Permission Sets
Flipping the org-wide "Make Lightning Experience the only experience" toggle is the final cutover, not the first move. The supported gradual approach uses two permission sets:
- Lightning Experience User (or a copy named for your program) — grants
Lightning Experience User permission, which lets users opt into LEX.
- Lightning Experience Hides Classic Switcher (or your equivalent) — removes the "Switch to Salesforce Classic" link from the user menu, locking the cohort into LEX.
A typical wave plan: Wave 0 (pilot — IT, super-users, internal volunteers) → Wave 1 (a low-risk business unit with no JS buttons or VF dependencies) → Wave N (the high-customization unit with the most legacy assets) → Cutover (org-wide switch + remove Classic). Each wave has go/no-go criteria measured against adoption telemetry.
Adoption Telemetry Is Object-Backed
The platform exposes adoption metrics via standard objects, not just dashboards:
LightningUsageByAppTypeMetrics — daily user counts of LEX vs Classic switches, broken down by app typeLightningUsageByPageMetrics — page-level performance and usage data for LEXLightningExitByPageMetrics — pages from which users switch back to Classic — the single most actionable signal in the program
LightningExitByPageMetrics is the program's leading indicator. A page with a high switch-back rate identifies an asset triage miss (a JS button or VF page that didn't get migrated). Investigate every page above your wave's switch-back threshold before promoting the next wave.
The Switch-Back Trap
Users who have ever clicked "Switch to Salesforce Classic" persist that preference in UserPreferencesLightningExperiencePreferred = false. Even after a profile-level rollout, those users will land in Classic on next login until you reset their preference (DML on the User record) or remove the switcher entirely. A migration program that doesn't track switch-back preference at the user level will report a higher LEX adoption rate than reality.
Common Patterns
Pattern 1: Readiness-Check-Driven Wave Plan
When to use: First-time Lightning Experience Transition program for an org with > 100 users still on Classic.
How it works:
- Run the Readiness Check from Setup → Lightning Experience Transition Assistant → Discover phase. Export the PDF; archive a copy in the program folder so you have a baseline.
- Build the asset triage matrix from the Readiness Check output. Assign every asset a bucket (Replace / Rebuild / Retain / Retire) and an owner.
- Segment users by profile and business unit. Identify Wave 0 candidates (IT, super-users), Wave 1 (low-customization business unit), Wave N (high-customization).
- Map each wave's user cohort to a permission set (e.g.,
LEX_Wave1_Sales). Migration of in-scope assets must complete before the wave's permission set is assigned.
- Establish go/no-go telemetry: switch-back rate < 5% from
LightningExitByPageMetrics, no Sev-1 incidents in 7 days, and active LEX users / total cohort > 90% from LightningUsageByAppTypeMetrics.
- Run the cutover after the final wave: assign the "Hides Classic Switcher" permission set to all production users and (optionally) flip the org-wide setting.
Why not the alternative: A profile-level org-wide flip without wave validation surfaces every triage miss simultaneously and floods the help desk. Permission-set-driven waves contain blast radius and let you fix asset gaps wave by wave.
Pattern 2: JavaScript Button Triage Sub-Program
When to use: The Readiness Check flags > 20 JavaScript buttons. Buttons cannot run in LEX, so this is always blocking work.
How it works:
- Pull the JavaScript button inventory from the Readiness Check output and from a
WebLink linkType = 'javascript' query against the org.
- For each button, classify the action: simple field update → Quick Action; navigation → standard Lightning navigation or Web Link; bulk record action → headless flow with
invocable Apex; complex multi-record orchestration → LWC + Apex action.
- Build the replacement, deploy to sandbox, validate side-by-side with the JS button. Mark the button "deprecated" by removing it from page layouts after the Lightning equivalent ships.
- The
admin/custom-button-to-action-migration skill is the asset-level playbook for each button. This program-level skill ensures buttons are sequenced before the wave that needs them.
Why not the alternative: Carrying JavaScript buttons into LEX cutover guarantees user-visible breakage and switch-back. Triage them before any wave that uses them.
Pattern 3: AppExchange Package LEX-Compatibility Audit
When to use: Org has 5+ installed managed packages and the Readiness Check shows mixed compatibility status.
How it works:
- Pull the package inventory from Setup → Installed Packages. Cross-reference against the Readiness Check's LEX-Ready flag for each package.
- For each non-Lightning-Ready package: contact the partner for the LEX-ready version, plan a managed-package upgrade, and validate post-upgrade in a dev/UAT sandbox.
- For deprecated packages with no LEX-ready upgrade path: triage as Replace (find a LEX-ready alternative) or Retire (the package's functionality is not actually used).
- Sequence package upgrades before the wave that depends on them, treating each upgrade as its own change with regression testing.
Why not the alternative: A non-LEX-ready managed package can break Lightning rendering for the entire app it ships in. Don't roll a wave forward until every package the wave's users touch is on a Lightning-Ready version.
Decision Guidance
| Situation |
Recommended Approach |
Reason |
| Greenfield org created after Winter '20, all users already in LEX |
No transition program needed; verify via LightningUsageByAppTypeMetrics and document compliance |
Lightning is default-on; no Readiness Check action required |
| 50–500 Classic users, mixed profiles, low custom-asset count |
Single-wave rollout via permission set after asset triage |
Risk is low; multi-wave overhead exceeds benefit |
| > 500 Classic users, high custom-asset count, multiple BUs |
Wave-based rollout (3–5 waves), each gated on switch-back-rate telemetry |
Contains blast radius; lets you fix gaps wave-by-wave |
| Heavy Visualforce + JS-button customization |
Asset-triage-first program — do not assign LEX User permission until replacements ship |
JS buttons silently fail in LEX; users switch back |
| Highly regulated industry with audit requirements |
Add a paper "user attestation" step before each wave; record LoginHistory showing LEX-only sessions post-cutover |
Auditors require evidence that the migration was a controlled change |
| Org with > 50 installed packages |
Run package-compatibility audit as Phase 0 before wave 1 |
A single non-LEX-ready package can break the wave's apps |
Users with UserPreferencesLightningExperiencePreferred = false on a Classic-disabled profile |
Use the Lightning Experience Hides Classic Switcher permission set (or User-record DML) to reset preference |
Profile-level flip alone leaves the per-user preference dominant |
Recommended Workflow
Step-by-step instructions for an AI agent or practitioner working on this task:
- Verify scope: confirm the org has Classic users (
SELECT COUNT() FROM User WHERE UserPreferencesLightningExperiencePreferred = false AND IsActive = true). If 0, no program is needed — exit with a one-line confirmation.
- Run the Lightning Experience Transition Assistant Readiness Check. Capture the PDF and the asset counts as the baseline. If the customer cannot run the Readiness Check, build the triage matrix manually but call it out as an estimate.
- Build the asset triage matrix. Classify every asset (Visualforce pages, JS buttons, AppExchange packages, page layouts, Knowledge, email templates) into Replace / Rebuild / Retain / Retire. Cite the asset-level skill for each Replace/Rebuild row (
lwc/visualforce-to-lwc-migration, admin/custom-button-to-action-migration, etc.).
- Define waves. Map each user cohort to a permission set, list the in-scope assets that must be migrated before the wave, and write the go/no-go telemetry threshold (typically: switch-back rate < 5%, support tickets < N per 100 users, active LEX users > 90% of cohort).
- Execute Wave 0 (pilot). Monitor
LightningExitByPageMetrics daily. Investigate every page above the switch-back threshold. Do not promote to Wave 1 until Wave 0 holds telemetry for 7 days.
- Iterate waves. After every wave, refresh the asset triage matrix — usage data exposes assets that the Readiness Check missed (e.g., a VF page surfaced only by a niche workflow).
- Cutover. Assign the "Hides Classic Switcher" permission set to all production users; optionally flip the org-default setting. Document the change in the change-management log; archive the program artifacts for audit.
Review Checklist
Run through these before marking work in this area complete:
Salesforce-Specific Gotchas
(Detailed entries live in references/gotchas.md.)
- JavaScript buttons fail silently in LEX — if not replaced, users click and nothing happens; they switch back to Classic to finish the workflow.
- The user-level Classic preference outranks profile flips — a profile-level rollout still lands legacy users in Classic until preference is reset.
- Console apps require explicit Lightning Console rebuild — Classic Service Console layouts do not auto-translate; primary tabs and subtabs must be re-modeled in the Lightning Console app.
- Some VF pages render in LEX but with degraded behavior —
<apex:page> features like custom JavaScript that manipulates the surrounding Classic chrome silently misbehave inside the LEX iframe.
- The Readiness Check is a snapshot, not a continuous scan — re-run before each wave because new assets get added during the program.
Output Artifacts
| Artifact |
Description |
| Readiness Check baseline PDF |
Snapshot of org's LEX readiness scan; the program's input |
| Asset triage matrix |
Rows = legacy assets; cols = bucket, owner, target wave, replacement skill, acceptance criteria |
| Wave plan |
Per-wave: cohort permission set, in-scope assets, go/no-go telemetry thresholds, rollback trigger |
| Cutover playbook |
Final-wave runbook including LightningExitByPageMetrics monitoring, support staffing, rollback steps |
| Adoption telemetry queries |
SOQL against LightningUsageByAppTypeMetrics, LightningUsageByPageMetrics, LightningExitByPageMetrics with thresholds |
Related Skills
lwc/visualforce-to-lwc-migration — asset-level playbook for migrating individual Visualforce pages to LWCadmin/custom-button-to-action-migration — asset-level playbook for replacing JavaScript buttons with Lightning Quick Actionsadmin/knowledge-classic-to-lightning — Knowledge article migration (Classic Knowledge → Lightning Knowledge)admin/classic-email-template-migration — email template migration (Classic templates → Lightning HEML)admin/dynamic-forms-migration — page-layout-to-dynamic-form migration once the org is on LEXadmin/change-management-and-training — adoption / training workstream that rides alongside this programlwc/lwc-locker-to-lws-migration — the parallel LWS migration program if the org has LWC components on Locker
1---2name: lightning-experience-transition3description: Use when planning, sequencing, or troubleshooting an org-wide migration from Salesforce Classic to Lightning Experience. Covers the LEX Transition Assistant Readiness Check, asset triage matrix (Visualforce, JavaScript buttons, page layouts, Knowledge, email templates, list views, AppExchange), pilot/wave rollout sequencing, end-user adoption telemetry, and cutover criteria. Triggers: 'lightning experience transition', 'classic to lightning migration plan', 'LEX readiness check', 'why are some users still on Classic', 'turning on Lightning for everyone'. NOT for individual asset migrations like a single VF page (use lwc/visualforce-to-lwc-migration), a single JavaScript button (use admin/custom-button-to-action-migration), or Knowledge article migration (use admin/knowledge-classic-to-lightning) — this skill orchestrates the program. NOT for Lightning App Builder page design (use admin/lightning-app-builder-advanced).4---56# Lightning Experience Transition78This skill activates when a practitioner is planning, sequencing, or troubleshooting the **org-wide program** to move users from Salesforce Classic to Lightning Experience. It does not duplicate piece-skills for individual asset migrations (Visualforce, JavaScript buttons, Knowledge, email templates) — it sits above them and provides the orchestration layer: readiness scoring, asset triage, wave sequencing, adoption telemetry, and cutover gates. Use it when the question is "how do we run this program," not "how do I migrate this one asset."910---1112## Before Starting1314Gather this context before working on anything in this domain:1516- The Lightning Experience Transition Assistant lives at **Setup → Lightning Experience Transition Assistant**. The Readiness Check it runs is the canonical starting point — every program plan should reference its scored output, not opinions about "what's blocking us."17- Lightning is **on by default** for orgs created after Winter '20. The transition program is therefore mostly about (a) the long tail of legacy orgs that still have Classic users and (b) ensuring assets render correctly in LEX. Confirm which case applies before proposing a plan.18- The number-one cause of failed transitions is users **switching back to Classic** because a workflow they rely on (a JavaScript button, a custom VF page in a related list, a print-friendly Console layout) does not work in LEX. Plan asset triage **before** turning Lightning on at the profile level.19- JavaScript buttons are not supported in Lightning Experience and are not auto-migrated. They must be replaced with Quick Actions, Lightning Component actions, headless flows, or `invocable` Apex actions before users can rely on them in LEX.20- Permission Set-based gradual rollout is the safest sequencing strategy: assign the **Lightning Experience User** permission via permission sets keyed to user cohorts, rather than flipping the org-wide switch.2122---2324## Core Concepts2526### The Readiness Check Is The Plan's Backbone2728The Lightning Experience Transition Assistant runs a **Readiness Check** that scans the org for assets and configurations that affect LEX rollout: Visualforce pages with `<apex:page>` features incompatible with LEX rendering, JavaScript buttons (always flagged because they cannot run in LEX), Lightning-incompatible AppExchange packages, custom Console apps, hard pinning to Classic via `UserPreferencesLightningExperiencePreferred`, and unmigrated Knowledge articles.2930The output ships as a PDF and is also surfaced in the Transition Assistant UI. **Treat the Readiness Check report as the single source of truth for asset count and LEX-blocker classification.** Do not start the program by inventorying assets manually — let the Readiness Check do that scan and use its output as the input to triage.3132### Asset Triage: Replace / Rebuild / Retain / Retire3334Every legacy asset surfaced by the Readiness Check must be sorted into one of four buckets:3536| Bucket | When it applies | What to do |37|---|---|---|38| Replace | A Lightning-native equivalent exists (JS button → Quick Action; Classic email template → Lightning HEML) | Build the replacement, validate, then disable the old asset |39| Rebuild | Needed but cannot be 1:1 replaced (VF + JS Console layout → LWC + flow + utility-bar combo) | Re-architect; ship before the wave that uses it |40| Retain | Asset already works in LEX (most page layouts, validation rules, workflow rules, standard Apex) | Confirm in Readiness Check; no change required |41| Retire | Asset is dead (Last Used > 12 months; not in any active workflow) | Delete; do not migrate dead assets |4243The triage matrix is the program's working artifact. It enumerates every asset, its bucket, owner, target wave, and acceptance criteria.4445### Wave-Based Rollout Via Permission Sets4647Flipping the org-wide "Make Lightning Experience the only experience" toggle is the final cutover, not the first move. The supported gradual approach uses two permission sets:4849- **Lightning Experience User** (or a copy named for your program) — grants `Lightning Experience User` permission, which lets users opt into LEX.50- **Lightning Experience Hides Classic Switcher** (or your equivalent) — removes the "Switch to Salesforce Classic" link from the user menu, locking the cohort into LEX.5152A typical wave plan: Wave 0 (pilot — IT, super-users, internal volunteers) → Wave 1 (a low-risk business unit with no JS buttons or VF dependencies) → Wave N (the high-customization unit with the most legacy assets) → Cutover (org-wide switch + remove Classic). Each wave has go/no-go criteria measured against adoption telemetry.5354### Adoption Telemetry Is Object-Backed5556The platform exposes adoption metrics via standard objects, not just dashboards:5758- `LightningUsageByAppTypeMetrics` — daily user counts of LEX vs Classic switches, broken down by app type59- `LightningUsageByPageMetrics` — page-level performance and usage data for LEX60- `LightningExitByPageMetrics` — pages from which users switch back to Classic — the single most actionable signal in the program6162`LightningExitByPageMetrics` is the program's leading indicator. A page with a high switch-back rate identifies an asset triage miss (a JS button or VF page that didn't get migrated). Investigate every page above your wave's switch-back threshold before promoting the next wave.6364### The Switch-Back Trap6566Users who have ever clicked "Switch to Salesforce Classic" persist that preference in `UserPreferencesLightningExperiencePreferred = false`. Even after a profile-level rollout, those users will land in Classic on next login until you reset their preference (DML on the User record) or remove the switcher entirely. A migration program that doesn't track switch-back preference at the user level will report a higher LEX adoption rate than reality.6768---6970## Common Patterns7172### Pattern 1: Readiness-Check-Driven Wave Plan7374**When to use:** First-time Lightning Experience Transition program for an org with > 100 users still on Classic.7576**How it works:**77781. Run the Readiness Check from **Setup → Lightning Experience Transition Assistant → Discover phase**. Export the PDF; archive a copy in the program folder so you have a baseline.792. Build the asset triage matrix from the Readiness Check output. Assign every asset a bucket (Replace / Rebuild / Retain / Retire) and an owner.803. Segment users by profile and business unit. Identify Wave 0 candidates (IT, super-users), Wave 1 (low-customization business unit), Wave N (high-customization).814. Map each wave's user cohort to a permission set (e.g., `LEX_Wave1_Sales`). Migration of in-scope assets must complete before the wave's permission set is assigned.825. Establish go/no-go telemetry: switch-back rate < 5% from `LightningExitByPageMetrics`, no Sev-1 incidents in 7 days, and active LEX users / total cohort > 90% from `LightningUsageByAppTypeMetrics`.836. Run the cutover after the final wave: assign the "Hides Classic Switcher" permission set to all production users and (optionally) flip the org-wide setting.8485**Why not the alternative:** A profile-level org-wide flip without wave validation surfaces every triage miss simultaneously and floods the help desk. Permission-set-driven waves contain blast radius and let you fix asset gaps wave by wave.8687### Pattern 2: JavaScript Button Triage Sub-Program8889**When to use:** The Readiness Check flags > 20 JavaScript buttons. Buttons cannot run in LEX, so this is always blocking work.9091**How it works:**92931. Pull the JavaScript button inventory from the Readiness Check output and from a `WebLink` `linkType = 'javascript'` query against the org.942. For each button, classify the action: simple field update → Quick Action; navigation → standard Lightning navigation or Web Link; bulk record action → headless flow with `invocable` Apex; complex multi-record orchestration → LWC + Apex action.953. Build the replacement, deploy to sandbox, validate side-by-side with the JS button. Mark the button "deprecated" by removing it from page layouts after the Lightning equivalent ships.964. The `admin/custom-button-to-action-migration` skill is the asset-level playbook for each button. This program-level skill ensures buttons are sequenced before the wave that needs them.9798**Why not the alternative:** Carrying JavaScript buttons into LEX cutover guarantees user-visible breakage and switch-back. Triage them before any wave that uses them.99100### Pattern 3: AppExchange Package LEX-Compatibility Audit101102**When to use:** Org has 5+ installed managed packages and the Readiness Check shows mixed compatibility status.103104**How it works:**1051061. Pull the package inventory from Setup → Installed Packages. Cross-reference against the Readiness Check's LEX-Ready flag for each package.1072. For each non-Lightning-Ready package: contact the partner for the LEX-ready version, plan a managed-package upgrade, and validate post-upgrade in a dev/UAT sandbox.1083. For deprecated packages with no LEX-ready upgrade path: triage as Replace (find a LEX-ready alternative) or Retire (the package's functionality is not actually used).1094. Sequence package upgrades **before** the wave that depends on them, treating each upgrade as its own change with regression testing.110111**Why not the alternative:** A non-LEX-ready managed package can break Lightning rendering for the entire app it ships in. Don't roll a wave forward until every package the wave's users touch is on a Lightning-Ready version.112113---114115## Decision Guidance116117| Situation | Recommended Approach | Reason |118|---|---|---|119| Greenfield org created after Winter '20, all users already in LEX | No transition program needed; verify via `LightningUsageByAppTypeMetrics` and document compliance | Lightning is default-on; no Readiness Check action required |120| 50–500 Classic users, mixed profiles, low custom-asset count | Single-wave rollout via permission set after asset triage | Risk is low; multi-wave overhead exceeds benefit |121| > 500 Classic users, high custom-asset count, multiple BUs | Wave-based rollout (3–5 waves), each gated on switch-back-rate telemetry | Contains blast radius; lets you fix gaps wave-by-wave |122| Heavy Visualforce + JS-button customization | Asset-triage-first program — do not assign LEX User permission until replacements ship | JS buttons silently fail in LEX; users switch back |123| Highly regulated industry with audit requirements | Add a paper "user attestation" step before each wave; record `LoginHistory` showing LEX-only sessions post-cutover | Auditors require evidence that the migration was a controlled change |124| Org with > 50 installed packages | Run package-compatibility audit as Phase 0 before wave 1 | A single non-LEX-ready package can break the wave's apps |125| Users with `UserPreferencesLightningExperiencePreferred = false` on a Classic-disabled profile | Use the **Lightning Experience Hides Classic Switcher** permission set (or User-record DML) to reset preference | Profile-level flip alone leaves the per-user preference dominant |126127---128129## Recommended Workflow130131Step-by-step instructions for an AI agent or practitioner working on this task:1321331. Verify scope: confirm the org has Classic users (`SELECT COUNT() FROM User WHERE UserPreferencesLightningExperiencePreferred = false AND IsActive = true`). If 0, no program is needed — exit with a one-line confirmation.1342. Run the Lightning Experience Transition Assistant Readiness Check. Capture the PDF and the asset counts as the baseline. If the customer cannot run the Readiness Check, build the triage matrix manually but call it out as an estimate.1353. Build the asset triage matrix. Classify every asset (Visualforce pages, JS buttons, AppExchange packages, page layouts, Knowledge, email templates) into Replace / Rebuild / Retain / Retire. Cite the asset-level skill for each Replace/Rebuild row (`lwc/visualforce-to-lwc-migration`, `admin/custom-button-to-action-migration`, etc.).1364. Define waves. Map each user cohort to a permission set, list the in-scope assets that must be migrated before the wave, and write the go/no-go telemetry threshold (typically: switch-back rate < 5%, support tickets < N per 100 users, active LEX users > 90% of cohort).1375. Execute Wave 0 (pilot). Monitor `LightningExitByPageMetrics` daily. Investigate every page above the switch-back threshold. Do not promote to Wave 1 until Wave 0 holds telemetry for 7 days.1386. Iterate waves. After every wave, refresh the asset triage matrix — usage data exposes assets that the Readiness Check missed (e.g., a VF page surfaced only by a niche workflow).1397. Cutover. Assign the "Hides Classic Switcher" permission set to all production users; optionally flip the org-default setting. Document the change in the change-management log; archive the program artifacts for audit.140141---142143## Review Checklist144145Run through these before marking work in this area complete:146147- [ ] Lightning Experience Transition Assistant Readiness Check has been run and the PDF is archived148- [ ] Asset triage matrix exists, every asset has a bucket, every Replace/Rebuild row has an owner and target wave149- [ ] JavaScript-button inventory is fully classified and replacements are scoped (no JS button left as "TBD" entering the wave that uses it)150- [ ] AppExchange packages are confirmed LEX-Ready or have an upgrade plan in the wave preceding their use151- [ ] Permission-set-based wave plan is defined; each wave has go/no-go telemetry with explicit thresholds152- [ ] `LightningExitByPageMetrics` is being monitored and a page-by-page action plan exists for any page above the switch-back threshold153- [ ] Switch-back-preference reset plan is in place (User-record DML or "Hides Classic Switcher" permission set per cohort)154- [ ] Cutover playbook exists with go/no-go gates and a documented rollback path155- [ ] Audit log capture is configured (LoginHistory, Setup audit trail) for post-cutover compliance evidence156157---158159## Salesforce-Specific Gotchas160161(Detailed entries live in `references/gotchas.md`.)1621631. **JavaScript buttons fail silently in LEX** — if not replaced, users click and nothing happens; they switch back to Classic to finish the workflow.1642. **The user-level Classic preference outranks profile flips** — a profile-level rollout still lands legacy users in Classic until preference is reset.1653. **Console apps require explicit Lightning Console rebuild** — Classic Service Console layouts do not auto-translate; primary tabs and subtabs must be re-modeled in the Lightning Console app.1664. **Some VF pages render in LEX but with degraded behavior** — `<apex:page>` features like custom JavaScript that manipulates the surrounding Classic chrome silently misbehave inside the LEX iframe.1675. **The Readiness Check is a snapshot, not a continuous scan** — re-run before each wave because new assets get added during the program.168169---170171## Output Artifacts172173| Artifact | Description |174|---|---|175| Readiness Check baseline PDF | Snapshot of org's LEX readiness scan; the program's input |176| Asset triage matrix | Rows = legacy assets; cols = bucket, owner, target wave, replacement skill, acceptance criteria |177| Wave plan | Per-wave: cohort permission set, in-scope assets, go/no-go telemetry thresholds, rollback trigger |178| Cutover playbook | Final-wave runbook including LightningExitByPageMetrics monitoring, support staffing, rollback steps |179| Adoption telemetry queries | SOQL against LightningUsageByAppTypeMetrics, LightningUsageByPageMetrics, LightningExitByPageMetrics with thresholds |180181---182183## Related Skills184185- `lwc/visualforce-to-lwc-migration` — asset-level playbook for migrating individual Visualforce pages to LWC186- `admin/custom-button-to-action-migration` — asset-level playbook for replacing JavaScript buttons with Lightning Quick Actions187- `admin/knowledge-classic-to-lightning` — Knowledge article migration (Classic Knowledge → Lightning Knowledge)188- `admin/classic-email-template-migration` — email template migration (Classic templates → Lightning HEML)189- `admin/dynamic-forms-migration` — page-layout-to-dynamic-form migration once the org is on LEX190- `admin/change-management-and-training` — adoption / training workstream that rides alongside this program191- `lwc/lwc-locker-to-lws-migration` — the parallel LWS migration program if the org has LWC components on Locker
PranavNagrecha