Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

Use Setup, Migrate to Flow to convert each process, then rebuild what it produces rather than shipping it. The tool gets the logic across accurately and the design badly, and the thing that will actually bite you is neither: it is the order of execution changing, because record-triggered flows run earlier in the save than Process Builder did.

Process Builder is finished

Salesforce blocked the creation of new processes and new workflow rules some releases ago, and has been clear that existing ones stop running eventually. Treat every remaining process as an outage with a date on it that you do not control. The migration is not optional work you can defer indefinitely.

Start with an inventory. Setup, Process Automation lists the processes. Flow Trigger Explorer shows what already exists on each object.

What the migration tool does well, and where it stops

The tool converts one process at a time into a new, inactive flow. It preserves criteria as Decision elements and actions as their flow equivalents, and it tells you when it could not convert something rather than converting it wrongly.

Where the output is poor:

  • Everything becomes an after-save flow. Process Builder had no other option, so the tool has no other option. A process whose only job was setting fields on the triggering record becomes an after-save flow with an Update Records element, which is a second save where a before-save assignment would be no save at all.
  • Element names are generated, not written. You get names derived from criteria labels, in a diagram nobody can read six months later.
  • One flow per process. If three processes ran on Opportunity, you get three flows, and you have kept the fragmentation that made Process Builder painful.
  • Unsupported actions are skipped. Read the report. A clean run is not a complete run.

My recommendation: run the tool, read the flow it produces as documentation of what the process actually did, and then build the real flow. Same-record field updates go into a before-save flow. Everything else goes into a single after-save flow per object, using the migrated version as the spec.

The order of execution moves, and this is the real risk

In the order of execution, after-save record-triggered flows run before processes. So the moment you migrate, that logic happens earlier than it used to, relative to everything you did not migrate. If one process depended on a field another process had already set, migrating one of them reverses the sequence and the dependency breaks silently.

Before-save flows move further still. They run before validation rules, and they do not cause a second pass through triggers the way a Process Builder field update did. That last part is worth checking against your Apex: a trigger written to expect a second execution after the field update may now run once.

The upside is that flow gives you control Process Builder never did. Set the Trigger Order value on each flow version, between 1 and 2000, and Flow Trigger Explorer shows you the resulting sequence on the object. Set it explicitly during migration rather than letting it default. Ordering that depends on nothing is ordering that changes when someone deploys.

A test plan that finds the breakage

Do this in a sandbox with real-shaped data, one object at a time.

  1. Record the current behaviour before you touch anything. Create and update a record through the UI, capture the field values, the emails, the tasks, and the related records produced.
  2. Migrate, rebuild, and activate the flow in the same deployment that deactivates the process. Both active means everything happens twice.
  3. Repeat step 1 and compare, field by field. Include the paths nobody remembers, like the rejection branch and the record type nobody uses.
  4. Load 200 records with Data Loader. Process Builder and Flow consume limits differently, and a query inside a loop that survived one record at a time will not survive a bulk load.
  5. Check Setup, Paused and Failed Flow Interviews afterwards, then check the debug log for the number of times the trigger ran.

Frequently asked

Can I migrate several processes into one flow? Not with the tool. It handles one at a time, so consolidation is manual work that is usually worth doing anyway.

Does the tool migrate scheduled actions? Scheduled actions map onto scheduled paths, but check the converted output carefully. The timing semantics are not identical and the report will flag what it could not carry across.

Should I migrate workflow rules the same way? Yes, the same tool covers them, and workflow field updates on the same record are the clearest candidates for a before-save flow.

What about processes that call other processes? Convert the called one first, so the subflow exists and is active when you reference it.