How to Migrate Workflow Rules and Process Builder to Salesforce Flow
A step-by-step plan for retiring legacy Salesforce automation — inventory, consolidation, testing and cutover — without breaking live processes.
Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025, and points every org toward Flow. Existing rules keep running, but Salesforce no longer fixes bugs in them or supports them. For a lot of teams the automation still works, so the migration keeps slipping. The risk is that when something does break, nobody remembers what those old rules were for, and there's no vendor fix coming.
This guide lays out a controlled, step-by-step plan for moving legacy automation to Flow without breaking the processes that depend on it.
1. Inventory everything before you touch anything
Start with a complete list of active Workflow Rules and Process Builder processes, object by object. For each one, record:
- The object and trigger — on create, on create and edit, or when criteria are met.
- What it does — field updates, email alerts, tasks, outbound messages, or calls to Apex.
- Who depends on it — the team, report or integration that would notice if it stopped.
- Whether it still matters — inactive users, retired products and old picklist values are common.
You'll usually find automation that can simply be switched off. Retiring it is cheaper than migrating it.
2. Consolidate by object, not rule by rule
Salesforce's Migrate to Flow tool converts many Workflow Rules and some Process Builder processes one at a time. It's a useful starting point, but a one-to-one conversion keeps the original sprawl — five rules on Opportunity become five flows on Opportunity.
A better target is a small number of record-triggered flows per object:
| Timing | Use it for |
|---|---|
| Before-save flow | Field updates on the same record (fast, no extra DML) |
| After-save flow | Related records, emails, tasks, callouts |
| Scheduled paths | Time-based actions that used to be time-dependent workflow |
Group the old rules by object and timing, then design each flow as one readable decision tree.
3. Decide what stays in Flow — and what doesn't
Not everything belongs in a flow. Complex logic that loops over many records, heavy integrations, or anything that needs careful transaction control may be better in Apex. Simple validation is often better as a validation rule. Make the call deliberately, and write down why.
4. Test against real scenarios, not just the happy path
For each object, list the scenarios the old automation handled: new record, edit that meets criteria, edit that stops meeting criteria, bulk data loads, and records created by integrations. Run them in a full or partial sandbox with representative data, and compare the results with production behavior before switching anything off.
5. Cut over in a controlled order
- Deploy the new flows inactive.
- Activate a flow and deactivate the legacy rules it replaces in the same release window, so nothing runs twice.
- Watch for errors, duplicate emails and unexpected field changes for the first few days.
- Keep the legacy automation inactive, not deleted, until you're confident — then clean it up.
6. Document the result
Give every flow a description that says what it does and why, and keep a short automation map per object. The next admin — or the next migration — will thank you.
Where to start
If your org has years of layered automation, an inventory is the clearest first step: it shows what can be retired, what should be consolidated, and where the real risk sits. Our Salesforce org assessment covers this, reviewing Flows and legacy automation, overlap and order of execution before anything changes, and it's a natural lead-in to Salesforce automation and Flow work.