Most orgs do not write new AJAX Toolkit code, but they do hold surviving Visualforce pages that still call it. Retiring those pages is the operational task.
- Inventory remaining toolkit usage
Grep the metadata for sforce.connection and sforce.apex references across Visualforce pages and Static Resources. Document each page, the calls it makes, and the users who land on it.
- Classify each page by complexity
Read-only pages can move to UI API or Lightning Record View Form. Pages with custom server-side logic need an Apex web service method to be replaced with an @AuraEnabled method.
- Build the Lightning replacement
Create a Lightning Web Component or Aura component that performs the equivalent operation. Use @AuraEnabled or imperative Apex for server calls and the modern fetch or UI API for direct record work.
- Route users to the new surface
Update navigation, list view buttons, and any direct URL links so users land on the Lightning page instead of the Visualforce page. Keep the Visualforce page accessible for one release in case rollback is needed.
- Delete the retired metadata
Once the Lightning replacement is stable, remove the Visualforce page, the Static Resource holding connection.js, and any related Apex web service classes that no other code uses.
- The legacy webService keyword on Apex methods is separate from @AuraEnabled. They support different callers; do not remove the keyword on a class still called by an AJAX Toolkit page.
- Toolkit calls inside Static Resources are easy to miss in code search. Look for connection.js references and any inline script blocks that import it.
- Synchronous AJAX Toolkit calls trigger modern browser warnings. Migration removes the noise as a side benefit; do not ignore the warnings until then.
- Sessions obtained via sforce.connection.login require username and password. Refactor to OAuth flows during migration; do not port the password-based code as is.