Migrating Workflow Rules and Process Builder to Flow: A Practical Guide

Salesforce stopped supporting new Workflow Rules and Process Builder automations back in 2023, and orgs still running legacy automation are accumulating risk with every release. If your org still has a mix of Workflow Rules, Process Builder, and Flow all firing on the same objects, this guide is for you.

Why migrate at all?

Beyond the deprecation clock, there are concrete engineering reasons:

One execution model. Mixed automation on a single object makes order of execution nearly impossible to reason about. Consolidating on Flow gives you one place to look.
Performance. Before-save record-triggered flows run roughly 10x faster than Process Builder for same-record field updates because they skip a full save cycle.
Debuggability. Flow's debug logs and error emails are imperfect, but they are far better than the silent failures Process Builder was famous for.

The migration playbook

1. Inventory before you touch anything

Run the Migrate to Flow tool's assessment first, but don't trust it blindly. Export a spreadsheet of every Workflow Rule, Process Builder process, and Apex trigger per object. For each, record: trigger conditions, field updates, and whether it can re-trigger other automation.

2. Group by object, not by automation type

The single biggest mistake we see is migrating rule-by-rule. Migrate object-by-object instead. The goal state for each object is:

One before-save flow for same-record updates
One after-save flow (or a small set, split by domain) for everything else
Apex only where Flow genuinely can't do the job

3. Respect the order of execution

Workflow Rules run after after-save flows in the save order. If a Workflow Rule field update currently re-triggers other automation, replicating its logic in a before-save flow changes when it happens. Test cross-object side effects explicitly — this is where migrations break.

4. Build a recursion guard

Process Builder quietly suppressed some recursion for you. Flow will happily loop until it hits limits. Entry conditions should check that the fields you care about actually changed — use ISCHANGED() formulas in entry criteria as a habit, not an afterthought.

5. Test with production-shaped data

Unit tests with one record prove nothing about bulk behavior. Load 200+ records through Data Loader in a full sandbox and watch debug logs for repeated flow interviews — that's your recursion and limits early-warning system.

What "done" looks like

You're finished when every object has a documented automation map, legacy automation is deactivated (not deleted — keep the rollback option for a release cycle), and your admin team can answer "what happens when this field changes?" from one diagram.

If your org has hundreds of legacy automations and nobody left who remembers why they exist, that's a solvable problem — it's exactly the kind of work our managed services team does every quarter. Get in touch if you'd like an assessment.