How to Audit HubSpot Workflows Before a CRM Migration

Migrating your CRM is one of the highest-stakes projects a RevOps team will run. The data gets most of the attention - deduplication, field mapping, historical records - but workflows are where the real landmines hide. Automated sequences, lead routing logic, lifecycle stage updates, internal notifications: if any of these break or duplicate during the migration window, the business impact is immediate and often invisible until a deal slips or a lead goes cold.

This guide walks through a structured workflow audit you can run before any major migration, whether you are moving off HubSpot, migrating into HubSpot, or restructuring a heavily customized HubSpot instance. The principles apply across platforms; the HubSpot specifics are called out where they matter.

Step 1 - Build a Complete Workflow Inventory

Before you can audit anything, you need a full list of what exists. This sounds obvious, but in most mature HubSpot portals there are workflows created by multiple people over multiple years, many of them turned off but not deleted, and some running on test enrollments that accidentally became production logic.

Start by exporting your full workflow list. In HubSpot, the Workflows index lets you filter by status (active, inactive, draft) and by object type (contact, company, deal, ticket). Do not ignore inactive workflows - they often contain enrollment criteria or branch logic that was copied into newer workflows, and deleting them without checking can break dependencies you did not know existed.

For each workflow, capture at minimum:

• Workflow name and ID
• Object type
• Status (active/inactive/draft)
• Enrollment trigger type (form submission, property change, list membership, manual)
• Last modified date and by whom
• Estimated enrollment volume (how many records have passed through)
• Actions taken (emails sent, properties updated, notifications, webhooks)

A visual dependency map makes this inventory step significantly faster by surfacing connections between workflows that would take hours to trace manually through the interface.

Step 2 - Classify Workflows by Migration Risk

Not every workflow carries the same risk. A workflow that sends a single internal Slack notification when a deal reaches Closed Won is low risk. A workflow that assigns leads to reps based on territory, updates lifecycle stage, enrolls contacts into sequences, and fires a webhook to your billing system is high risk. Treating them the same wastes time and misses the critical ones.

Apply a simple risk tier to each workflow:

Tier 1 - Critical: Directly affects revenue or customer experience. Lead routing, lifecycle stage updates, SLA management, billing or system integrations, sales handoff logic.

Tier 2 - Operational: Affects internal processes but has recovery paths. Internal notifications, task creation, deal property updates, reporting fields.

Tier 3 - Informational: Adds data or sends non-critical comms. Contact scoring updates, newsletter re-engagement, event follow-ups with no downstream automation.

Every Tier 1 workflow needs a documented owner, a pre-migration off-switch plan, and a post-migration validation checklist. Tier 2 workflows need review but can tolerate a brief outage. Tier 3 workflows can often be paused for the migration window without business impact.

Step 3 - Audit Logic, Conflicts, and Technical Debt

Once you have your inventory and risk classification, it is time to get into the actual logic. This is where most audits fail because reviewers skim action steps without checking the enrollment criteria that feed into them.

For each Tier 1 and Tier 2 workflow, review the following:

Enrollment triggers and re-enrollment settings

Are records re-enrolling when they should not be? Is the trigger based on a property that will be remapped or renamed during migration? Any trigger tied to a specific list, form, or property value needs to be flagged if that object is changing.

Branch logic and property dependencies

Workflows that branch on property values are particularly vulnerable. If your migration involves renaming properties, changing picklist values, or merging fields, any workflow branch that references those properties will either fire incorrectly or not fire at all. A property impact analysis can surface all the workflows and other automation that depend on a given property before you change it.

Conflicting workflows

Conflict happens when two or more workflows update the same property on the same object at the same time, or in rapid succession, with different values. Common examples include lead status workflows that race each other or lifecycle stage logic that conflicts across marketing and sales automations. Document every property that is written by more than one workflow and verify the intended priority order.

Orphaned and redundant workflows

Workflows with zero enrollments in the past six months, or workflows with identical trigger conditions and overlapping actions, are candidates for consolidation or deletion before migration - not after. Cleaning this up beforehand reduces what you need to rebuild or validate on the other side.

Step 4 - Document the Pre-Migration State and Create a Go-Live Plan

An audit without documentation is just discovery. Before migration day, you need a record of the pre-migration workflow state that you can reference for validation and rollback decisions.

For each Tier 1 workflow, create a one-page spec that includes the enrollment trigger, the branching logic in plain English, the properties written (and to what values), the downstream systems or workflows triggered, and the business process it supports. Store these in a shared location where both the migration team and the business owners can access them.

For RevOps teams managing complex portals, maintaining living documentation of workflow logic is a long-term asset that pays off far beyond migration day - during audits, onboarding, and when debugging a broken automation six months down the line.

Your go-live plan should include:

1. A sequenced list of workflows to pause before migration starts, in dependency order
2. A validation test for each Tier 1 workflow after migration (what record to enroll, what outcome to expect, who checks it)
3. A rollback trigger - what metric or failure condition causes you to pause and revert
4. A timeline for reactivating workflows post-migration, starting with Tier 1 and working down

One detail that catches teams off guard: workflows that fire on enrollment do not retroactively re-enroll records that met the criteria during the migration window. If your lead routing workflow was paused for four hours, any lead that came in during that window needs to be manually reviewed or batch-enrolled after reactivation. Build this cleanup step into your post-migration runbook explicitly.

Putting It Together

A workflow audit before a CRM migration is not a one-afternoon task, but it does not need to be a month-long project either. With a structured inventory, a risk classification, a logic review focused on property dependencies and conflicts, and solid pre-migration documentation, most teams can complete a rigorous audit in one to two focused sprints.

The goal is to arrive at migration day knowing exactly which automations are running, what they depend on, and what you will do if something breaks. That preparation is what separates migrations that go smoothly from ones that generate six weeks of post-launch incident tickets.