Migrate to Flow
Migrate to Flow is the Salesforce-supplied Setup tool that converts legacy Workflow Rules and Process Builder processes into record-triggered flows in Flow Builder.
Definition
Migrate to Flow is the Salesforce-supplied Setup tool that converts legacy Workflow Rules and Process Builder processes into record-triggered flows in Flow Builder. It reads a source automation, generates an equivalent flow, and lets an admin test the result before switching the live automation over. The tool exists because Salesforce stopped supporting Workflow Rules and Process Builder on December 31, 2025, and Flow is now the single supported point-and-click automation engine.
You reach it from Setup by typing "Migrate to Flow" in Quick Find, or from the Workflow Rules page by clicking "Migrate your workflow rules to flows." The tool lists your existing rules and processes, converts the ones you select, and produces a flow you can inspect in Flow Builder. Conversion is assisted, not blind: you review the generated flow, fix anything the tool could not translate, then deactivate the old automation and activate the new flow.
How the tool converts old automation into flows
Why this tool exists now
Salesforce stopped supporting Workflow Rules and Process Builder on December 31, 2025. The wording matters. The features did not switch off on that date. Existing rules and processes keep running, and you can still activate, deactivate, and edit the ones you already have. What ended is official support: Salesforce no longer fixes bugs or builds new capabilities for either tool. Flow Builder is the supported replacement, and it covers what both old tools did inside one designer. Migrate to Flow is the bridge between the old world and the new one. Without it, every legacy rule and process would need to be rebuilt by hand in Flow, element by element, which is slow and error-prone across a large org. The tool reduces that effort by generating a working first draft of each flow from the source automation. You still own the review, but you do not start from a blank canvas. Treat the December 2025 date as a planning trigger rather than a panic button. The risk is not sudden failure; it is accumulating automation that nobody supports anymore.
Migrating a Workflow Rule
Workflow Rules are the simpler case, so start there. Open the tool, choose the Workflow Rules tab, pick a single rule, and click Migrate to Flow. The tool builds a record-triggered flow and shows a Migration details window. That window has two important buttons. Test in Flow Builder opens the generated flow so you can read the logic and run it against sample records. Switch Activations does the cutover in one move: it deactivates the original Workflow Rule and activates the new flow together. That single-button cutover is the feature that prevents the most common migration mistake, which is leaving both automations active at once. The generated flow mirrors the rule's structure. The rule criteria becomes the flow's entry condition. A Field Update becomes an Update Records element. An Email Alert becomes a Send Email Alert action. Outbound Messages and time-dependent actions are supported too. Read the flow before you switch. The shape is right, but field references and edge cases deserve a human check.
Migrating a Process Builder process
Process Builder migration works differently because a process can hold several criteria nodes, the diamond shapes that branch the logic. Open Migrate to Flow, select the Processes tab, choose a process, and click Migrate to Flow. You then pick which criteria you want to migrate. You can send every criterion into one combined flow, or split criteria into separate flows, which is often cleaner when the branches handle unrelated work. The tool supports partial migration, so you do not have to convert an entire complex process in a single pass. That flexibility is useful because real processes accumulate years of additions, and some branches convert cleanly while others need rework. Migrating in slices lets you verify each piece before moving on. As the tool has matured, its coverage has grown. Newer releases handle scheduled actions and even processes that reference custom metadata in formulas. After such a migration the custom metadata reference still works inside the flow formula, though you cannot edit it through the resource picker.
What converts cleanly and what does not
The tool handles the common building blocks well. Field Updates, Email Alerts, Outbound Messages, Task creation, and time-dependent or scheduled actions all have direct equivalents in Flow, and the tool maps them. Straightforward rule criteria translate into entry conditions without fuss. The cases that need attention tend to involve logic that does not have a one-to-one Flow element. A cross-object Field Update may need extra Get Records and Update Records steps to reach the related record. A dense formula with nested conditions can migrate but may read awkwardly and benefit from being rebuilt with cleaner Flow logic. Some older or unusual action types are not supported and are flagged rather than silently dropped. The practical rule is simple: assume every automatic migration needs a review pass. The tool is a strong head start, not a finished deliverable. Plan time to inspect each generated flow, confirm the field references, and rework anything that the converter could only approximate. Skipping that step is how subtle bugs reach production.
Test in a sandbox first
Salesforce's stated best practice is to migrate and test in a sandbox before touching production, and that advice is worth following literally. A migrated flow is structurally similar to its source automation but not byte-for-byte identical, so behavior can shift in ways that only surface against real data. In the sandbox, create or update records that match the original rule or process criteria and confirm the flow produces the same outcome. Check the obvious results, like whether the right field changed or the email actually sent, and the quieter ones, like whether a related record updated correctly. Watch for double effects that hint a legacy rule is still firing alongside the new flow. Once a flow passes in the sandbox, deploy it to production using your normal change set or metadata pipeline, and perform the cutover there. Testing first also gives you a safe place to rework the migrations that did not convert cleanly. You can iterate on the flow, break it, and fix it without any risk to live users or customer-facing automation.
Coordinating the cutover
The single biggest operational risk in any migration is running the old automation and the new flow at the same time. When both are active, both fire on the same record change. Users get two emails instead of one. A counter increments twice. A field gets updated, then updated again. For Workflow Rules the tool's Switch Activations button removes this risk by deactivating the rule and activating the flow in one action. For processes, and whenever you migrate outside the assisted button flow, you have to manage the swap yourself. Deactivate the source automation at the exact moment you activate the replacement, and bundle that change into one deployment so there is no window where both run. Keep a written map of which rule or process became which flow. That record is not bureaucracy. The person who maintains this automation next year, possibly you, needs to know where each piece of logic moved. Migrate in planned batches rather than all at once, and verify each batch in production before starting the next.
Convert a Workflow Rule with the Migrate to Flow tool
Use the Migrate to Flow tool in Setup to convert a Workflow Rule into a record-triggered flow, test it, and switch the live automation over. The steps below follow the assisted Workflow Rule path; Process Builder works similarly but adds a step to choose which criteria to migrate.
- Open the tool
From Setup, type "Migrate to Flow" in Quick Find and select it, or open the Workflow Rules page and click "Migrate your workflow rules to flows." The tool lists your existing rules and processes on separate tabs.
- Select and convert one item
On the Workflow Rules tab, pick a single rule and click Migrate to Flow. The tool generates an equivalent record-triggered flow and opens a Migration details window. Convert one rule at a time so each conversion is easy to review.
- Test in Flow Builder
Click Test in Flow Builder to open the generated flow. Read the entry condition and elements, then run it against sample records in a sandbox to confirm it reproduces the rule's behavior before you change anything live.
- Switch activations
When the flow checks out, click Switch Activations. This deactivates the original Workflow Rule and activates the new flow in one action, so both automations never run at the same time.
Lists the org's Workflow Rules. Select one rule per migration and use Migrate to Flow to generate its record-triggered flow.
Lists Process Builder processes. After selecting a process you choose which criteria nodes to migrate, into one flow or several.
Opens the generated flow so you can inspect the logic and run it against records before activating it.
Performs the cutover for a Workflow Rule by deactivating the rule and activating the flow together.
- Migrate and test in a sandbox before doing the cutover in production; a converted flow is structurally similar but not identical to its source.
- Never leave the old rule and the new flow active at once. Both fire on the same record change and cause doubled emails or field updates.
- Cross-object Field Updates and complex nested formulas may not convert cleanly and need manual rework with extra Flow elements.
- Some older or unusual action types are not supported. Review every generated flow rather than trusting the output blindly.
- Keep a written map of which rule or process became which flow so future maintenance knows where each piece of logic moved.
Prefer this walkthrough as its own page? How to Migrate to Flow in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Migrate to Flow.
Hands-on resources to go deeper on Migrate to Flow.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does the Migrate to Flow tool convert legacy automation into?
Q2. Why did Salesforce introduce the Migrate to Flow assistant?
Q3. What is the status of creating brand-new Workflow Rules in Summer 25 and later?
Discussion
Loading discussion…