ChatGPT
Claude
Google AI
Copilot
Monday starts without the button. The weekend cutover made Lightning the only interface, because a slide had invented a date and the date arrived. The team that creates cases still uses a JavaScript button. It does not run in Lightning. The replacement was a sketch nobody had pressed. Attachments are still being added on the old related list, and the files the new page expects are empty. A page that only renders in Classic is how two people in operations open the day's work. They switch back, or they stop, and the queue waits. The project board will reconvene on Wednesday. The cases will not.
Some orgs still have Classic. Lightning is where new work should land. The move is finished when nothing the business still needs depends on Classic alone. There is no shutdown date to put on a slide. Inventing one forces a cutover you have not inventoried, and the business will meet the gap on Monday morning.
The list that is actually the project
JavaScript buttons. Attachments, the older kind, as distinct from Files. Pages that were never rebuilt and only render when the user is in Classic. Buttons and links that call those pages. Anything a user still reaches by switching the interface. That is the list. It is shorter than a programme plan and longer than a weekend, which is why the weekend fails.
Build the list from the org, not from memory. Layouts that still carry a JavaScript button. Buttons that were clicked in the last month, which you can see from the people who still switch interface to press them. Attachments still being added, which you can see from records that gained one recently, as distinct from Files. Users who still spend their day in Classic, and the pages they open. Ask them what they click before lunch. A button nobody remembers will be on that answer. A page that "should be fine" and has not been opened in Lightning by the person who uses it is not fine. It is an unlisted gap.
Each item gets an owner, a Lightning replacement, and a user who did the real task on the replacement. The owner is the person who can say the old path is no longer needed, because their team did the work the new way on a real record. A rewritten button nobody has pressed does not come off the list. A page reviewed by someone who does not do the job does not come off the list. Tried, by the person who used the old one, on a record that matters this week. Write the date they tried it. An item without that date is still open.
Spend the first week with the people who switch interface, not with a metadata list alone. The list shows buttons that exist. It does not show which of them create today's cases. The person who switches will. Write the button name, the page, and what they do with the result. If they paste the result into another system, that paste is part of the task the Lightning replacement has to cover. A button that only opens a record is a smaller replacement than a button that builds the case, fills three fields, and emails a queue. Replacing the first and calling the second done is how the list looks empty while Monday still breaks.
Attachments need the same hour. Open the related list with the person who adds them and ask what they attached last week. If the answer is a document the renewal will need, the Lightning page has to take that document as a File, and they have to add one, on a real record, before the item leaves the list. Copying old attachments in the background does not close the item if new ones are still landing on the old related list. The habit is the gap. The historical copy is a separate job.
Profiles and permission sets stay ordinary access work on both interfaces. People need the right rows and fields in Lightning, the same as they did before. That work is real, and it is not this inventory. It is not a retirement programme you can hide inside a user-interface project. Do not put "migrate profiles" on this list as if profiles were being withdrawn. They are not the gap. The gap is the button, the attachment, and the page that only works when the user is in Classic. Access design continues. It does not substitute for the list, and finishing the list does not retire a profile.
Two facts people collapse into one date
Workflow Rules and Process Builder reached end of support on 31 December 2025. That date is about those automation tools. Rebuild what still runs the business, in Flow, with tests, on its own plan. Do not bury it inside a user-interface weekend, and do not borrow the date and announce it as the day Classic disappears. End of support is not a day this guide will extend into a Classic shutdown. There is no Classic shutdown date to extend. End of support also does not, by itself, tell you the day those automations vanish from your org. If they still create the cases or move the stage, they are still the business until the Flow replacement has been tried. Put that rebuild on the automation owner's list. Keep it off the cutover slide that only talks about screens.
A different rename shows up in current help and is easy to misuse. Salesforce says: "Field Service is now Agentforce Field Service and Operations. In some cases, we still use Field Service to refer to this product area in Salesforce applications and documentation." The same help describes the product as a hub: "Agentforce Field Service and Operations (formerly known as Field Service) gives you a powerful, highly customizable, mobile-friendly field service hub in Salesforce." Read both as a name change inside one product area. They do not say older interface paths have been withdrawn. Quoting the rename in a steering pack as proof that Classic is over is a misread. The hub still has to be usable by the person on site. If their path is a Classic page, that page is an item on the list, whatever the product is now called.
Run both until the list is empty
Users do new work in Lightning while any named item still has people on it in Classic. New screens, new fields, new automation land in Lightning. You do not block Classic for a team that still has an open item, and you do not build the new item in Classic because "they are still there." The split is the point. Classic is the leftover list. Lightning is where the next change goes. When someone finds a JavaScript button that still creates cases, it goes on the list that week. It gets rebuilt. The people who used it try the replacement on a real case. You do not announce a cutover date for a gap that is not on the list yet. A date for an unlisted gap is how the button is discovered by the people who needed it, on the day they cannot press it.
When the list is empty, and a sample of users from each team has completed a real task in Lightning, you can make Lightning the default. The sample is not a champion who likes the new page. It is the person who used the JavaScript button, the person who added attachments, and the person who lived on the Classic-only page. They do the task. You watch. Then the item can close. Even then, know how someone gets help the same day. An unlisted button that still creates the team's cases is the business. It will not wait for the project board to reconvene. The help path is a named person and a way back, for a short window, not a hope that nothing was missed.
Keep a short log of what you turned off and what you left. The log is how the next person avoids rediscovering a Classic-only page in a quarter and treating it as a surprise outage. What you left, and why, is as important as what you removed. A page left because a monthly job still uses it is an open item with an owner and a date, not a forgotten tab. A page left because nobody was sure is an open item too. Uncertainty is not a reason to mark it done.
| On the list | How you know it is real | Off the list when |
|---|---|---|
| JavaScript button | Someone still switches interface to press it | The same person has done the task in Lightning on a real record |
| Attachments, not Files | New attachments are still being added | The layout they use takes Files, and they have added one |
| Classic-only page | It does not render for a Lightning user | The user who lived there has completed the task on the new page |
| Link or button to that page | It is still on a layout they open | The link goes to the Lightning replacement, and they have used it |
| Workflow Rules or Process Builder | They still run the business | Rebuilt in Flow, with tests, on their own plan, not on this weekend |
The last row is a different project that people keep stapling to this one. End of support was 31 December 2025. That row does not authorise a Classic cutover, and a Classic cutover does not finish that row.
What is cheap now, and what Monday costs
Cheap, while both interfaces are still available: adding a button to the list the week it is found, watching one user do the task, refusing a shutdown date that is not yours to set. The log takes an hour. The conversation with the person who clicks the button takes an afternoon. That afternoon is the migration.
Expensive, after a forced cutover: a queue that cannot create cases, files in the wrong store, and a page operations cannot open, discovered by the people who do the work rather than by the inventory. You will spend the week rebuilding in a hurry what the list would have shown you in advance. Run both until the list is empty. Then make Lightning the default. New work should already have been landing there.
A Classic-only page that survives because nobody put it on a removal list will sit there until it breaks a Monday. Put those pages on the removal list in the quarterly roadmap that names what you will turn off. A migration that only adds Lightning pages, and never takes the old ones off the layout, leaves the switch in place. The switch is the gap.
