Salesforce has ended support for Workflow Rules and Process Builder and directs the logic to Flow. Announcement day broke nothing — every process kept running — and that is exactly why estates still carry them years later. Retired-engine automation is migration work with a deadline attached, wearing the costume of a system that works fine.
What actually bites, and when
Three things. Support: when behavior goes wrong in a retired engine, there is no fix coming. Composition: new capability — including Agentforce actions — composes with Flow, so logic stranded in old engines becomes invisible to what you build next. And people: fewer admins each year can debug a Process Builder chain confidently.
Migrate per object, not per process
The subtle failure mode: migrating processes one at a time changes the execution order between the ones that shared an object’s save cycle. Workflow rules and processes on one object participate in that object’s order; moving them as a set into one record-triggered Flow preserves it, moving them piecemeal silently reshuffles it. Group the work by object, and check first whether each rule still does anything — a rule inert for years is a delete, not a migration, and that is the cheapest outcome available.
Horus Eye files retired-engine findings one per object for exactly this reason — and excludes managed-package rules from the count, because the vendor migrates those, not you.
Inventory before you migrate
Start with a truthful list: in Setup’s Flow console, filter by type to see every Workflow Rule and Process Builder still active, then group them by the object whose save cycle they share. For each, record three facts — when it last fired, what it touches, and whether a record-triggered Flow on the same object already overlaps it. Expect surprises in both directions: rules that have been inert for years (a delete, not a migration) and processes quietly doing work nobody documented.
Test the order, not just the logic
Most migration regressions are ordering regressions. A converted Flow can be logically identical and still misfire because it now runs before a rule it used to run after. So test at the object level: a save that used to traverse rule A, process B and flow C must produce the same field states after the migration collapses them. Salesforce’s own Migrate to Flow tool converts structure, not intent — the regression pass is still yours. Budget it per object, and do the riskiest object second, once the process has been rehearsed on a simple one.
The bottom line
Retirement deadlines reward the teams that treat migration as an inventory problem first and a conversion problem second. Count what you have, delete what is inert, group what remains by object, and rehearse the order-of-execution test before touching the object that runs your revenue. The conversion itself is the easy part; knowing what you converted — and proving the saves still land the same way — is the work.
