The migration is mandatory for any org on Lightning. Plan a sprint per non-trivial S-Control.
- Inventory existing S-Controls
Setup, Custom S-Controls. List every S-Control with its name, type, where it''s referenced (buttons, links, custom Visualforce includes), and what it does.
- Pick the target framework
Visualforce for simple ports; Lightning Web Component for any UI that should work in Lightning Experience; Lightning App Builder for dashboard-style pages.
- Rewrite the logic
Translate the S-Control HTML and JavaScript into the target framework. Push business logic into Apex methods; render UI with the framework''s component library.
- Update references
Find every custom button, link, or page that referenced the old S-Control. Update each to point to the new Visualforce page or LWC component.
- Test in both Classic and Lightning
Verify the migration works in both UIs during transition. Deactivate the old S-Control once the new component is fully cut over.
- Delete the S-Control
After confirming nothing depends on it, delete the S-Control. The metadata sticks around until explicitly removed, which clutters package deployments.
- S-Controls do not render in Lightning Experience. Any org still on Classic with S-Controls cannot complete a Lightning cutover until they migrate.
- The S-Control editor was removed years ago. Existing S-Controls cannot be edited even in Classic; they can only be deleted or referenced.
- S-Control JavaScript often relies on the AJAX Toolkit. The Toolkit itself is deprecated and may stop working in future releases.
- AppExchange packages built on S-Controls are end-of-life. Replace any such package as part of the migration, not as a separate project.