The HubSpot Portal Migration Checklist: How to Audit Workflows Before You Move Anything
Migrating a HubSpot portal is one of the highest-risk operations a RevOps team can execute. Not because HubSpot makes it hard — but because most portals contain years of accumulated automation logic that nobody has fully documented. Workflows trigger other workflows. Properties feed enrollment conditions. Lists connect automations that were never meant to be connected.
Move the wrong thing first and you break enrollment chains silently. Nobody notices until leads stop receiving emails, deal stages stop updating, or a nurture sequence that was running perfectly just... stops.
This guide gives you the exact workflow audit process to run before a HubSpot migration — what to check, in what order, and how to catch the dependencies that will cause problems if you miss them.
What causes HubSpot migrations to break
Before the checklist, it helps to understand the failure modes.
Silent enrollment breaks are the most common. A workflow is deactivated or moved without checking whether another workflow depends on it for enrollment. The downstream workflow keeps running — it just stops receiving records. No error. No alert. Just a quiet drop in performance that surfaces weeks later.
Property rename cascades are the second most common. A property gets renamed or deprecated during cleanup. Three workflows were using it as a trigger condition. All three stop enrolling. Again, no error — just a gradual degradation that looks like a reporting problem until someone traces it back to the property change.
Re-enrollment logic conflicts occur when a workflow is rebuilt in a new portal without carrying over the re-enrollment settings. Records that should only pass through once now re-enroll repeatedly, or records that should re-enroll on property change no longer do.
Orphaned list dependencies are the hardest to find manually. Workflow A adds contacts to List B. Workflow C uses List B as an enrollment trigger. If you migrate Workflow A and C but not List B — or rebuild List B with a slightly different name — the chain breaks.
All four of these failure modes share a common cause: nobody had a complete picture of how the workflows connected before the migration started.
The pre-migration workflow audit: a step-by-step checklist
Work through this checklist in order. Each step builds on the one before it.
Step 1: Take a full inventory of every workflow in the portal
Before you touch anything, you need to know exactly what you are working with.
Pull a complete list of every workflow across all object types: Contacts, Companies, Deals, Tickets, and any custom objects. Note the following for each:
Workflow name
Object type
Status (active or inactive)
Last modified date
Enrollment count (if available)
This inventory is the foundation of the entire migration. Without it you are working from memory, which is how things get missed.
What to watch for: Workflows that are active but have not been modified in over six months are candidates for review before migration — they may be running on outdated logic. Workflows that are active but have zero enrolled records may have broken enrollment conditions already.
Step 2: Map every workflow connection
This is the step most teams skip, and it is the one that causes the most problems.
A HubSpot portal does not contain a collection of independent workflows. It contains a system of interconnected automations. Understanding the system requires mapping three types of connections:
Direct enrollments: Workflows that contain an "Enroll in workflow" action explicitly sending records into another workflow. These are the most obvious connections and the easiest to trace manually — but even they get missed in large portals.
List-based connections: Workflow A adds or removes records from a HubSpot list. Workflow B uses that list as an enrollment trigger. These connections are invisible unless you cross-reference every list used as a trigger against every workflow that modifies list membership. In a portal with 50+ workflows and dozens of active lists, doing this manually takes hours and is prone to error.
Property-based connections: Workflow A sets a contact property to a specific value. Workflow B is triggered when that property meets that condition. These are the hardest to find because they require tracing property values across the entire workflow system — not just looking at direct references.
Completing this step gives you a dependency map of your portal. Any workflow that appears in that map as a node with upstream or downstream connections needs to be migrated in the correct sequence, with its dependencies intact.
Step 3: Run an impact assessment on every property you plan to rename or deprecate
Most migrations involve some degree of property cleanup. Old fields get renamed, merged, or removed. This is necessary — but it is also where migrations most commonly go wrong.
Before renaming or deprecating any property, answer these questions:
Which workflows use this property as an enrollment trigger?
Which workflows evaluate this property in a branch condition?
Which workflows set or update this property as an action?
For a small portal this is manageable manually. For a portal with 75+ workflows and hundreds of active properties, it requires a systematic search across every workflow step.
The impact assessment should be completed before any property changes are made in either the source or destination portal.
Step 4: Identify and resolve structural issues before migrating them
Migrating a broken portal does not fix it — it moves the problems into a new environment where they are harder to diagnose.
Before migration, flag and resolve:
Empty workflows: Workflows with no actions. Records may be enrolling into them with nothing happening. Either add the missing logic or deactivate before migrating.
Orphaned workflows: Active workflows with no upstream or downstream connections that are not intentional standalone automations. Confirm whether each is still needed.
Stale workflows: Workflows that have not been modified in over six months and whose logic may no longer reflect current business processes. Review with the workflow owner before including in the migration scope.
Duplicate workflows: Workflows with identical or near-identical names or logic. Consolidate before migrating to avoid carrying technical debt into the new portal.
Resolving these issues before migration reduces the complexity of what you are moving and eliminates the risk of embedding known problems in the destination portal.
Step 5: Establish the migration sequence
With your dependency map complete and structural issues resolved, you can now define the order in which workflows should be migrated.
The rule is straightforward: upstream before downstream.
Workflows that feed records into other workflows must be migrated and validated before the workflows that depend on them. Migrating a downstream workflow before its upstream dependency is live in the destination portal means enrollment will fail from the moment it goes active.
For each connected workflow chain, document:
The full sequence from upstream to downstream
The connection type at each step (direct enrollment, list-based, or property-based)
The list names or property values that link each pair
The validation check that confirms each connection is working in the destination portal before moving to the next step
Step 6: Validate in the destination portal before going live
Rebuilding workflows in the destination portal is not the end of the migration — it is the midpoint. Validation is the step that confirms everything is working as intended.
For each migrated workflow, verify:
Enrollment triggers are configured correctly and matching records as expected
All branch conditions reference the correct properties and values in the new portal
All actions are pointing to the correct lists, emails, and downstream workflows
Re-enrollment settings match the source portal exactly
Active/inactive status is set correctly — do not activate workflows in the destination portal until all upstream dependencies are validated
Run a small batch of test records through connected workflow chains before enabling full enrollment. Confirm that records move through the sequence correctly and that property updates are firing as expected.
The fastest way to complete steps 1 through 3
Steps 1, 2, and 3 — inventory, connection mapping, and impact assessment — are the most time-consuming parts of a manual migration audit. In a portal with 100+ workflows, completing them manually can take a full day or more, and the risk of missing a connection is high.
Howly automates all three.
When you connect your HubSpot portal, Howly loads every workflow across every object type onto a single canvas and automatically detects all three connection types: direct enrollments, list-based connections, and property-based chains. You can see the full dependency map of your portal in under 30 seconds.
The Impact Analyzer handles step 3 directly. Search any property and Howly shows you every workflow that references it — as a trigger, in a branch condition, or as an action — so you can assess the full blast radius of a property change before making it.
For agencies and partners managing portal migrations on behalf of clients, the output is shareable: export the workflow map as a PDF, PNG, or Lucidchart file to align with your client before touching anything.
Pre-migration checklist: quick reference
Use this before every HubSpot portal migration.
Inventory
Full workflow list exported across all object types
Status, last modified date, and enrollment count noted for each
Stale workflows (no modification in 6+ months) flagged for review
Active workflows with zero enrolled records flagged for review
Connection mapping
Direct enrollment connections mapped
List-based connections mapped (workflows that add/remove from lists used as triggers)
Property-based connections mapped (workflows that set values triggering other workflows)
Full dependency chain documented for each connected workflow group
Impact assessment
Every property to be renamed or deprecated assessed for workflow references
Trigger references identified and documented
Branch condition references identified and documented
Action references identified and documented
Structural cleanup
Empty workflows resolved or deactivated
Orphaned workflows reviewed and confirmed necessary or deactivated
Duplicate workflows consolidated
Stale workflows reviewed with workflow owners
Migration sequence
Upstream-to-downstream order defined for all connected chains
Connection types and linking values documented at each step
Validation checks defined for each workflow before activation
Destination validation
Enrollment triggers verified
Branch conditions verified
Actions verified (lists, emails, downstream workflows)
Re-enrollment settings verified
Test records confirmed moving through chains correctly
Workflows activated in upstream-to-downstream order only
Frequently asked questions
How long does a HubSpot portal migration audit take?
For a small portal with fewer than 25 workflows, a manual audit typically takes two to four hours. For a medium portal with 25 to 75 workflows, expect a full day. For large portals with 75 or more workflows, a thorough manual audit can take two to three days. Using a workflow mapping tool like Howly reduces the inventory and connection-mapping phases to under an hour regardless of portal size.
What is the biggest mistake teams make during a HubSpot migration?
Migrating workflows without first mapping their dependencies. The most common consequence is a broken enrollment chain that goes undetected for days or weeks — downstream workflows are active in the new portal but never receive records because an upstream dependency was not migrated correctly or was activated out of sequence.
Should you clean up a portal before or after migrating it?
Before. Migrating a portal with structural issues — empty workflows, orphaned automations, duplicate logic — carries those problems into the new environment. Cleaning up first reduces migration complexity, makes the dependency map easier to read, and ensures you are not rebuilding logic that should be retired.
How do you migrate HubSpot workflows without breaking enrollment chains?
Map all three connection types before migrating: direct enrollments, list-based connections, and property-based chains. Then migrate and validate in upstream-to-downstream order. Do not activate a downstream workflow until every upstream dependency has been validated in the destination portal.
What HubSpot workflows are most likely to break during a migration?
Workflows that rely on property-based connections are the most fragile during migrations because the connection is implicit — it depends on a specific property value being set in one workflow and read in another. If the property is renamed, the value changes, or the trigger condition is configured slightly differently in the new portal, the chain breaks silently. Always document property names and values explicitly when mapping these connections.
Can you migrate HubSpot workflows between portals?
HubSpot does not have a native workflow export or cross-portal migration tool. Workflows must be rebuilt manually in the destination portal. This makes the pre-migration audit especially important — you need a precise record of every workflow's triggers, actions, and connections before rebuilding, because there is no automated way to verify that the rebuilt version matches the original.
Summary
A HubSpot portal migration does not fail because the rebuild is done wrong. It fails because the audit before the rebuild was incomplete. Missed connections, undocumented property dependencies, and unmapped enrollment chains are the root cause of almost every migration issue.
The checklist above gives you the structure to catch everything before it causes a problem. Run the inventory, map the connections, assess the impact of every property change, clean up structural issues, sequence the migration correctly, and validate in the destination portal before going live.
If you want to complete the inventory, connection mapping, and impact assessment phases in a fraction of the time, connect your HubSpot portal to Howly and see your full dependency map before your next migration.
Howly is a read-only HubSpot workflow mapping and audit tool. It maps workflow connections, flags structural issues, and shows the impact of property changes before you make them. Used by RevOps teams and HubSpot agencies managing complex portals at scale.
