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

If you haven't read Part 1, you might want to check that out first for context on the sunset timeline.

The actual migration problem

The obvious approach to migrating Process Builders is to just... look at each one and rebuild it in Flow. This works fine if you have 5 Process Builders. It's terrible if you have 200, which is not uncommon in orgs that have been around for a while.

The problem isn't just the volume. It's that nobody actually knows what all these Process Builders do. The person who built "Opportunity_Stage_Update_v3_FINAL_v2" left the company two years ago. There's no documentation. The name suggests it updates opportunity stages, but when you open it up, it's also sending emails to a Slack channel via some custom Apex, and also maybe creating tasks? And it hasn't run in 8 months according to the debug logs, so can we just delete it, or will someone's critical workflow break?

This is what we kept running into when talking to consultancies. So we built tooling to make the problem less awful.

How the extraction works

We connect to your org (OAuth or session token, whatever works) and pull everything related to automation. The Metadata API gives us ProcessDefinition, FlowDefinition, WorkflowRule, WorkflowAlert - basically the full graph of "things that run automatically."

If you have Event Monitoring turned on, we can also pull execution logs to figure out which automations actually run. This is useful because it turns out a lot of Process Builders are just... there. Enabled but never triggered. Or triggered once a month at 3am for reasons lost to time.

Once we have the metadata, we parse it into normalized JSON. Process Builder's internal format is kind of a mess - criteria nodes, scheduled actions, field updates, all nested in XML that's clearly optimized for Salesforce's internal rendering rather than human comprehension. We flatten it into something more reasonable: "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's still just structured metadata. We run it through some additional parsing to add context:

We extract trigger semantics (when does this run, what's the evaluation order, does it recursively trigger itself). We try to classify business intent - is this automation about lead qualification? Opportunity management? Compliance tracking? This uses some domain-trained models, though honestly the results are hit-or-miss for weird industry-specific logic.

We also flag risk factors. Time-based actions are tricky to migrate. External callouts need special handling. Apex invocations might have hidden dependencies. We've built up a list of known anti-patterns from actual migrations (things like redundant field updates that cause recursion, or workflows that assume synchronous execution).

And we estimate migration effort. Not perfectly - we're basically counting branches and dependencies and applying heuristics - but it's better than guessing. Turns out a Process Builder with 15 criteria branches and 3 Apex callouts takes longer to migrate than one that just updates two fields. Shocking, I know.

All of this gets stored in what we're calling a "knowledge graph," which is maybe a pretentious name for a database with relationships, but here we are.

Generating Flow blueprints

For each Process Builder, we generate a Flow blueprint. This is basically a translation of the Process Builder logic into Flow's mental model - Decision nodes, Assignment nodes, Apex Action nodes.

Where possible, we extract shared logic into subflows. A lot of orgs have copied and pasted the same "notify manager" logic into 20 different Process Builders. No judgment, we've all done it. But when migrating, you might as well consolidate.

We also generate an implementation checklist. This is the step-by-step "click here, set this variable to X, map this field to Y" instructions for actually building the Flow. And we suggest test cases - what data to create, what to check afterwards, how to verify it matches the old Process Builder behavior.

Does this fully automate the migration? No. You still need someone who understands Flow to actually build and test it. But it turns "figure out what this Process Builder does and reimplement it" into "follow these instructions."

What a blueprint looks like

Here's an example for a fairly typical opportunity automation:

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 tries to match Process Builder logic 1:1, but also includes Flow-specific details like variable names and API references. It flags gaps too - like if the Apex class doesn't have test coverage, or if there's some weird edge case the original Process Builder probably doesn't handle correctly either.

What you actually get

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

• An automation catalog (CSV plus whatever format syncs to their wiki - Notion, Confluence, whatever). Mostly useful for executive visibility and planning which order to tackle things.
• Flow scaffolds - JSON exports and diagrams for each Process Builder. These are what you'd actually use to build the Flows.
• Risk briefs - PDF summaries of anything we flagged as potentially problematic. Time-based actions that might behave differently, external callouts that need error handling, that kind of thing.
• Test scripts - suggested test cases and sample data. This is useful because testing is usually where migrations go wrong.

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 (works with sandbox or scratch orgs).
2. Filter for ProcessDefinition metadata.
3. Select the automations you want to analyze.
4. Hit "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 decent for learning the Flow Builder mechanics if you're not already familiar. And after you've cut over, run Salesforce Optimizer to confirm you didn't miss any Process Builders.

Selling this to clients

One thing we've seen work: don't frame this as "mandatory technical debt work." That's a tough sell even when it's true.

Instead, position it as automation modernization that unlocks other stuff they actually want - like Einstein CoPilot, or better Orchestration capabilities, or just visibility into what their automations are doing. Bundle some new use cases into the migration (renewal alerts, CPQ coordination, whatever makes sense for their business) so the project drives new value instead of just keeping the lights on.

Also: if you instrument the new Flows with Platform Event monitoring, support teams get observability they never had with Process Builders. That's usually worth something.

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 out. Or you can try the extraction demo yourself on a sandbox and see what the output looks like.

Either way, if you're planning a migration, you probably want to start soon. The sunset timeline isn't flexible, and these projects tend to take longer than expected once you get into the weird edge cases.

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