Migrating from Workflow Rules & Process Builder to Salesforce Flow: The 2026 Playbook
Workflow Rules and Process Builder are retired. Migrating to Flow is no longer optional. Here is the pragmatic playbook to migrate without breaking your org, and without spending nine months on it.
Workflow Rules and Process Builder are officially retired. Every automation you have on them is now on borrowed time. Migration to Salesforce Flow is not a "when we get to it" project, it is a hard deadline. Here is the pragmatic playbook we use to migrate a mid-size org in 6–10 weeks without breaking production.
Why the Migration Cannot Wait
Salesforce has stopped feature investment on both older tools. Bugs are not fixed. New objects and features are Flow-only. Meanwhile, every day you leave old automation in production, you accumulate debt that a new admin cannot maintain.
Step 1: Inventory Everything
Use Salesforce Optimizer or a metadata query to list every active Workflow Rule and Process Builder. Categorize by object and by "what does it actually do":
- Field updates (easy migration)
- Email alerts (medium)
- Outbound messages (medium)
- Cross-object updates (harder)
- Recursion or chained processes (audit before touching)
Step 2: Consolidate Before Migrating
The temptation is to rebuild every legacy automation as a Flow. Do not. Most orgs have 3–5 automations doing the same job. Consolidate into one Flow per object, per trigger event. You will finish the migration with 40% fewer automations than you started with, a healthy side effect.
Step 3: Use the Migration Tool, but Verify
Salesforce ships the "Migrate to Flow" tool. It handles the mechanical work but produces messy Flows with generic names, no comments, and no error handling. Always: rename, comment, add fault paths.
Step 4: Test in a Full Sandbox
Do not migrate in developer sandboxes. A partial or full sandbox is required to catch the interaction bugs that a lightweight sandbox will not surface.
Step 5: Deploy Wave-by-Wave, Not Big-Bang
Migrate by object: leads first (usually lowest risk), then opportunities, then service objects. Never all at once. If something breaks, it breaks in one wave, not your whole business.
What About Apex Triggers?
Flow is fast enough for most use cases in 2026. Reserve Apex for high-volume batch operations, complex logic that Flow cannot express cleanly, or performance-sensitive processes. See our guide on Salesforce technical debt for the broader picture.
Regional Notes
- EU markets: if your automations touch employee records, a DPO impact review is standard before migration. See GDPR guide.
- US & Canada: if migration ships during quarter-end, plan a release freeze.
Frequently Asked Questions
How long does the migration take?
Small org: 2–4 weeks. Mid-market: 6–10 weeks. Large complex org: 3–6 months.
Can we DIY this?
Yes if you have a senior admin. Ninety percent of migrations we rescue were technically DIY-able, the issue was skipping consolidation and testing.
Do we need Flow licenses?
No, Flow is included in all Salesforce editions. Flow Orchestrator (multi-user flows) is a paid add-on.
What if my Process Builder calls Apex?
Migrate the Process Builder to Flow; the Apex call stays the same. Test that the new Flow passes the same context.
Get a Fixed-Price Flow Migration
Our migration package covers audit, consolidation, migration and testing in 6–10 weeks. Book a 30-minute call.
If this sounds like your CRM, let's look at it together.
Thirty minutes, no deck, no pitch. You leave with a diagnosis either way.