Process Builder Sunset, Part 2: Automating Flow Migrations with Kicksights

If you haven't read Part 1, read it first for the sunset timeline.

The actual migration problem

The common approach to migrating Process Builders is to review each one and rebuild it in Flow. This works for a handful of automations. It is harder at 200, which is not unusual in older orgs.

The volume is only part of the problem. Teams often have no one left who knows what each Process Builder does. In this example, the owner of "Opportunity_Stage_Update_v3_FINAL_v2" left two years ago, and the automation has no documentation. The name implies opportunity updates, but the logic also sends Slack notifications via custom Apex and may create tasks. It had not run in 8 months according to debug logs, so deletion required validation before changing dependencies.

This is what we kept seeing in client discovery sessions. We built tooling to reduce that risk and make migration manageable at scale.

How the extraction works

We connect to your org (OAuth or session token) and pull everything related to automation. The Metadata API gives us ProcessDefinition, FlowDefinition, WorkflowRule, and WorkflowAlert, which provide the graph of automation artifacts.

If you have Event Monitoring turned on, we can also pull execution logs to see which automations are actually running. Many Process Builders are enabled but effectively inactive; some fire only on a narrow schedule.

Once we have the metadata, we parse it into normalized JSON. Process Builder's internal format is verbose: criteria nodes, scheduled actions, field updates, all nested in XML. We flatten this into a practical form like "If field X changes to Y, then do Z."

This gives you a searchable inventory. Now you can actually answer questions like "which automations touch the Opportunity object?" without clicking through Setup pages.

Figuring out what things do

The raw inventory helps, but it is still structured metadata. We run additional parsing to add context:

We extract trigger semantics: when each automation runs, evaluation order, and recursion behavior. We classify business intent where possible, such as lead qualification, opportunity management, or compliance tracking. Domain-specific logic is still prone to model misses.

We also flag risk factors. Time-based actions are tricky to migrate. External callouts need special handling. Apex invocations can carry hidden dependencies. We use anti-patterns we have seen in actual migrations, such as redundant field updates that cause recursion and workflows that assume synchronous execution.

And we estimate migration effort using branches and dependencies, with heuristics for unusual patterns. It is approximate, but better than guessing. A Process Builder with 15 criteria branches and 3 Apex callouts usually takes longer than one that only updates two fields.

All of this is stored in a knowledge graph so logic links, risk findings, and build artifacts stay connected.

Generating Flow blueprints

For each Process Builder, we generate a Flow blueprint. It translates Process Builder logic into Flow primitives such as Decision, Assignment, and Apex Action nodes.

Where possible, we extract shared logic into subflows. Many orgs duplicate the same "notify manager" sequence across many Process Builders, which is usually easier to consolidate during migration.

We also generate an implementation checklist with the steps for building the Flow. We include test cases for input data, post-build validation, and behavior comparison against the original Process Builder.

This does not fully automate the migration. You still need someone who understands Flow to build and test the replacement. The tooling converts discovery, design, and execution planning into an ordered migration plan.

What a blueprint looks like

A typical opportunity automation looks like this:

Opportunity_Stage_Automation
├─ Entry Criteria: [StageName changed AND Amount > 50000]
├─ Decision:
│  ├─ Branch: "Executive Review Required"
│  │   ├─ Update Field: Opportunity.Owner = "Executive Queue"
│  │   ├─ Apex: KS_PostToSlack (Channel: #rev-ops)
│  └─ Branch: "Auto Proceed"
│      ├─ Subflow: Send_Internal_SLA_Reminder
├─ Scheduled Path (2 Hours After Stage Change)
│  └─ Email Alert (Template: SLA_Reminder)

The blueprint maps Process Builder logic to Flow while adding Flow variable names and API references. It also flags gaps, including missing Apex test coverage and original edge cases that were already present.

What you actually get

When we run this for a client org, they get:

• An automation catalog in CSV and a wiki-friendly export for Notion or Confluence, useful for planning migration order and executive visibility.
• Flow scaffolds as JSON exports and diagrams for each Process Builder. These are used directly when building replacement Flows.
• Risk briefs as PDFs for flagged concerns, including time-based behavior changes and external callouts that need error handling.
• Test scripts with suggested test cases and sample data, because most migration defects are introduced during validation.

The consultancies we work with have been packaging this as 4-6 week fixed-fee engagements. Roughly: week 1 for inventory, week 2 for blueprint delivery, weeks 3-4 for implementation and QA, week 5 for parallel runs, week 6 for cutover. Your mileage may vary depending on how many automations you have and how weird they are.

DIY option

If you want to try the inventory tooling yourself, we have a demo at /extraction that uses the same metadata hooks. The workflow is:

1. Connect to your org (sandbox or scratch org).
2. Filter for ProcessDefinition metadata.
3. Select the automations you want to analyze.
4. Run Analysis.

You get back structured JSON with all the nodes, conditions, and actions parsed out. You can export this and feed it into Salesforce's official migration tool, or use it as reference when manually rebuilding in Flow Builder.

The Migrate Automation to Flow trail on Trailhead is a practical starting point if you are new to Flow Builder. After cutover, run Salesforce Optimizer to confirm no Process Builders were left behind.

Selling this to clients

One thing we have seen work is not framing this as "mandatory technical debt work." That message often reads as a hard cost with no immediate return.

Instead, position it as automation modernization and operational value. Many teams pair it with Einstein CoPilot, Orchestration, or improved visibility into automation behavior. Include adjacent use cases (renewal alerts, CPQ coordination, etc.) so the project also supports active business outcomes.

Also: if you instrument new Flows with Platform Event monitoring, support teams get observability they did not have with Process Builders.

Next steps

If you want us to run the automation audit and generate blueprints, we can do a 30-minute architecture session to scope it. Or you can try the extraction demo in a sandbox and review the output.

Either way, if you are planning a migration, start soon. The sunset timeline is fixed, and edge cases often extend projects past early estimates.

Need help now? Our Flow migration packages include AI-generated blueprints, Apex remediation, and go-live support. Schedule an Automation Migration Audit ->