On 31 December 2025, Salesforce stopped supporting Workflow Rules and Process Builder. Nothing went dark. The automations ran the next morning as if nothing had happened, and that is exactly why so many of them are still running today, unsupported, in orgs where nobody has opened them in years.
Most articles on the subject still tell you to migrate before the deadline. That ship has left spacedock. If your org still runs old rules and processes, the useful question now is which ones to move first, and how to move them without breaking the parts of Salesforce your sales team relies on.
What end of support actually means
End of support doesn't mean switched off. Your existing Workflow Rules and processes still fire, and you can still activate, deactivate and edit them. What you can't get any more is help. Salesforce offers no customer support for either tool, and it won't fix bugs in them.
This has been coming for a while. Salesforce had already blocked the creation of new processes in Process Builder in an earlier release, and all new automation belongs in Flow Builder. The old tools are now a museum that still has the lights on.
Why it still works is the risky part
Six years without a complaint doesn't mean an automation is healthy. Usually it means nobody has had a reason to look. In that time the person who built it may have left and the field it updates may have been renamed twice, and the rule that assigns your inbound leads may depend on a picklist value someone tidied up last quarter.
While the tools were supported, a strange failure at least had somewhere to go. Now it doesn't. The failures that hurt most are rarely loud, either. A rule that stops assigning leads doesn't put an error on anyone's screen. The leads just sit there without an owner until someone wonders why the pipeline looks thin. We wrote about the same pattern in Salesforce data imports: the dangerous failures are the ones nobody notices.
Step 1: Find what you are actually running
Start with an inventory, not a migration. In Setup, go to Process Automation, then Workflow Rules, and sort by the Active column. Do the same in Process Builder, sorting by Status. Between them, the two lists show everything that is still live.
For each automation, write down the object it runs on, what triggers it, what it does, and who asked for it. That last column tends to be the revealing one. When nobody can answer it, you've found an automation that runs part of your business on behalf of someone who no longer works there.
Step 2: Retire, merge or migrate
You don't have to migrate everything one for one, and that alone saves a lot of time. Salesforce's own planning guide says the move from Workflow Rules and processes to flows isn't a one-to-one exercise, and you don't need a flow for every process you're replacing.
Sort your inventory into three piles:
- Retire the automations that update fields nobody uses, notify people who have left, or repeat something a newer flow already does. Deactivate them, note why, and move on.
- Merge the ones that pile up on the same object. Several rules and processes on one object make it hard to tell what fires first, and they're often better rebuilt as one well-documented record-triggered flow.
- Migrate everything that still does real work and needs to keep doing it.
If you're unsure which pile something belongs in, the questions in our automation audit guide help, especially the one about what breaks when a single person is out.
Step 3: What to migrate first
Old automations don't all carry the same risk. We'd work through the migrate pile in this order:
- Anything that touches revenue data. That means lead assignment and routing, opportunity stage updates, and anything that decides who owns a customer or what the pipeline says. If one of these fails silently, you find out from a forecast, which is the most expensive way to find out.
- Time-based actions. Scheduled actions in processes and time-dependent workflow actions are easy to forget because nothing happens while you're looking at them. In Flow, their equivalent is a scheduled path on a record-triggered flow.
- Anything without an owner or documentation. These may be harmless today. They become a problem the day something around them changes and nobody remembers they exist.
- Everything else. Cosmetic field updates and convenience rules can wait until the important ones are done.
We use the same order in CRM and revenue operations automation work: protect the flow of revenue first, tidy up second.
Step 4: Use the Migrate to Flow tool, then check its work
Salesforce provides a Migrate to Flow tool that converts Workflow Rules and processes into flows, including processes with scheduled actions. Use it as a starting point, then read what it produced. Some complex automations will still need rebuilding by hand.
Do the work in a sandbox first. Salesforce recommends migrating and testing there before anything reaches production, and warns that in a complex org the migration can take significant time and testing.
The new flow starts inactive. Test it in Flow Builder, activate it once it behaves, then deactivate the original rule or process. For migrated Workflow Rules, the tool has a Switch Activations button that activates the flow and deactivates the rule in one step. Migrated processes don't get that button, so switch those over yourself, in that order.
Test with real records, too. A flow that works on a perfect test record and fails on the account with three missing fields isn't finished. Use the messy data your org actually has.
Whatever you do, never leave both versions active on the same record. Two automations doing the same job isn't redundancy. It's a race condition with a support ticket at the end of it.
Where Flow fits with AI agents
There's a reason to do this properly beyond keeping the lights on. Flows are also how a lot of Salesforce's newer automation gets work done. An Agentforce agent, for example, can use a flow as one of its actions.
So whatever you migrate now may end up as something an agent runs. A clean, documented, tested flow gives it a reliable step to repeat. A rushed conversion of a six-year-old process gives it a mistake to repeat at scale. As we put it in our Agentforce guide, AI agents do not fix operations. They reflect them.
Conclusion
Nothing will break today because support ended, and that's what makes it easy to ignore. The old automations will keep running until the day one of them doesn't, and then you'll be debugging an unsupported tool built by someone who left in 2020.
The fix isn't dramatic. Spend an afternoon on the inventory, make one honest pass to retire and merge, then migrate the revenue-critical automations first, in a sandbox, tested on real data. The rest can follow at a sensible pace.
If you'd rather not spend that afternoon alone, CRM and revenue operations automation is what we do. Beam us a message, and we'll help you get the old automations off life support.