Process Builder is being retired. Migrating to Flow is mandatory for any org with active processes.
The approach:
- Inventory. Run a full audit. Setup -> Process Builder lists all processes per object. Export the list (object, name, status, last modified). For an enterprise org you may have hundreds.
- Categorise. For each process: simple (single update, no async), medium (multiple actions, branching), complex (calls Apex, async paths, custom UI). Treat each category differently.
- Use Migrate to Flow — Salesforce's built-in tool. From Setup -> Process Builder, click Migrate to Flow on an individual process. It generates a Record-Triggered Flow equivalent. Output is a draft flow you review and clean up. The tool handles the simple cases well; complex ones need manual rework.
- Decide on before-save vs after-save for each migrated flow. Field updates on the same record should be before-save (much faster). Anything that creates other records or calls Apex must be after-save.
- Test in sandbox. Run the same trigger conditions through both the Process and the migrated Flow side-by-side. Compare outcomes. Common failure: subtle differences in null-handling between PB and Flow (PB treated null as false in some predicates; Flow doesn't).
- Activate the Flow, deactivate the Process. Don't run both simultaneously — duplicate field updates and double-fire side effects.
- Consolidate. Multi-criteria PBs often migrate to one flow per criteria branch; you may want to consolidate into a single record-triggered flow with internal Decision elements for cleanliness.
- Repeat for each object. Track progress in a sheet: % objects migrated, % processes deactivated, count of legacy PBs still active.
Common pitfalls:
- Order of execution differs slightly between PB and Flow. A PB and a Workflow Rule on the same object firing in a specific order may not produce identical results in Flow. Test field-update sequences carefully.
- Async PB invocations to Apex — these are common and often overlooked. The migration tool may not preserve the exact same async semantic.
- PBs that call other PBs — chained processes need to be migrated in dependency order.
- Active scheduled actions on existing PB processes — these continue to fire even after the PB is deactivated until they're cancelled or processed. Audit and cancel.
Recommended cadence: migrate the lowest-risk processes first to build team experience, save the most complex for last when you have a track record.