The migration pattern is consistent across orgs: inventory, classify, replace, retire. Each step has tooling support but requires manual decisions per button.
- Run the Lightning Experience Migration Assistant
Setup, Quick Find, Lightning Experience Transition Assistant. Open the JavaScript Button Migration step. The tool scans every active onClick JavaScript button, lists source code, and suggests Lightning replacement patterns.
- Classify each button by replacement type
Group buttons into four buckets. Simple field updates go to Quick Action. Multi-step logic goes to Flow. Custom UI goes to Lightning Web Component. Server-side processing goes to Apex called from Flow or LWC.
- Build the Lightning equivalent
Implement each replacement in the appropriate tool. For Quick Actions, configure the action object, fields, and default values. For Flows, build the flow and add as an Action element on the page layout.
- Add the new action to the Lightning record page
App Builder, open the record page, add the action to the Highlights Panel or to the Actions component. Configure the action visibility per record type or per user profile if the original button had access restrictions.
- Deactivate and remove the old button
Once the Lightning equivalent is verified working in Lightning, deactivate the original onClick JavaScript button. Delete fully only after a release cycle to allow rollback if the new action has bugs.
Quick Action (simple field update), Flow (multi-step logic), Lightning Web Component (custom UI), Apex Action (server-side processing). Pick per button based on what the original JavaScript did.
Lightning Experience Migration Assistant scans buttons. Third-party tools like Elements.cloud provide deeper button-by-button analysis with proposed Lightning equivalents.
Migrate buttons feature by feature, not all at once. Pair each button replacement with end-user training and a one-release rollback window.
Specific user groups may stay on Classic during the migration. Buttons can coexist in Classic and Lightning, with Lightning users seeing the new action and Classic users seeing the old button.
- onClick JavaScript buttons do not work in Lightning Experience. Users who switch from Classic without a migration find their daily-used buttons silently disabled.
- The AJAX Toolkit (sforce.connection) is retired in Lightning. Even Visualforce pages calling it break in Lightning rendering.
- Quick Actions support single-object field updates only. Multi-object or cross-record logic needs a flow or LWC; a Quick Action will not cover the case.
- Lightning CSP blocks arbitrary script execution. Embedding JavaScript directly in a Lightning page (via a custom Visualforce page in an iframe) often fails on security review even if it technically works.
- Buttons with sharing rule logic (the user only sees the button if they meet criteria) need their visibility logic moved into the Lightning page action criteria, which uses a different rule syntax than the legacy URL-driven visibility.