Migrating HubSpot workflows between portals is one of the highest-risk operations in the HubSpot ecosystem. A single missed dependency can break an enrollment trigger. A mismatched property type can route contacts down the wrong branch. An overlooked suppression list can flood your customers with emails they should never have received.
This checklist exists to prevent those failures. It is built from hundreds of real workflow migrations and captures every step, verification point, and safeguard that separates a clean migration from a chaotic one. Print it, share it with your team, and check off every item before you call the migration complete.
Phase 1: Pre-Migration Assessment
Before touching a single workflow, you need to understand the scope of what you are moving and the state of what you are moving it from.
Scope Definition
List, prioritize, and classify every workflow. Identify what migrates, what stays, and what gets retired.
Source Audit
Verify every workflow is functional before migration. Migrating broken automations just moves the problem.
Stakeholder Alignment
Notify affected teams, confirm migration windows, and define success criteria before work begins.
1.1 Define the Migration Scope
- ✓List every workflow to be migrated by name, type (contact, company, deal, ticket, custom object), and current status (active, paused, draft)
- ✓Prioritize workflows into migration waves: critical business processes first, nice-to-have automations later
- ✓Identify workflows that should NOT migrate: outdated automations, deprecated campaigns, one-time event workflows, and anything that references systems you are retiring
- ✓Document the migration timeline with specific dates for each wave and a hard deadline for completion
- ✓Assign an owner for each workflow migration, someone accountable for its successful transfer and validation
Taking the time to scope properly prevents the single biggest migration mistake: trying to move everything at once. A phased approach limits blast radius if something goes wrong.
1.2 Audit Source Workflows
Before migrating a workflow, verify it is actually working correctly in the source portal. Migrating a broken workflow just moves the problem.
- ✓Review enrollment numbers: Is the workflow actively enrolling contacts? If enrollment has been zero for 90+ days, question whether it needs to migrate
- ✓Check for errors: Open each workflow and look for red warning icons indicating broken actions, missing emails, or invalid property references
- ✓Review performance data: Note conversion rates, email engagement metrics, and goal completion rates — these become the benchmark for validating the migrated version
- ✓Identify unused branches: If/then branches with zero historical entries may indicate logic errors or deprecated segments
- ✓Document any known issues: Workarounds, quirks, and "do not touch" actions that the team knows about but has not fixed
For a comprehensive source portal review, use our ultimate HubSpot portal audit checklist. If your workflows have accumulated technical debt, our workflow audit guide covers how to find and fix broken automations before migration.
1.3 Stakeholder Alignment
- ✓Notify all teams that use or are affected by the workflows being migrated: marketing, sales, service, and operations
- ✓Confirm the migration window: Identify low-traffic periods when briefly pausing workflows will have minimal impact
- ✓Establish a communication plan: Who gets notified when migration starts, when it completes, and if issues arise
- ✓Define success criteria: What does "migration complete" look like? Is it identical behavior, or are improvements being bundled with the migration?
- ✓Get sign-off from workflow owners that their automation is ready to move
Phase 2: Dependency Inventory
Dependencies are the hidden complexity of every workflow migration. A workflow that looks simple in the visual editor may reference dozens of portal-specific objects. Miss one, and the workflow fails.
| Dependency Type | Where It Appears | Risk If Missed | Migration Complexity |
|---|---|---|---|
| Custom Properties | Triggers, branches, actions | Workflow breaks | Low |
| Lists | Enrollment, suppression, filters | Wrong audience | Medium |
| Forms | Enrollment triggers | No enrollments | Medium |
| Marketing Emails | Send actions | Failed sends | High |
| Pipelines | Deal workflows | Stage errors | Low |
| Integrations | Custom actions, webhooks | Silent failures | High |
| Users & Teams | Assignments, notifications | Wrong routing | Low |
2.1 Properties
- ✓List every custom property referenced in enrollment triggers, actions, branches, and goal criteria
- ✓Record the internal name (not the label) of each property, since HubSpot matches on internal names, which may differ from what you see in the UI
- ✓Document the field type for each property: single-line text, dropdown, number, date, checkbox, etc.
- ✓Record all dropdown/checkbox options exactly as they appear, including capitalization and special characters
- ✓Note property group assignments for organizational consistency in the target portal
- ✓Identify calculated properties that depend on other properties or workflow outputs
- ✓Check for properties used in lead scoring models that affect workflow enrollment
HubSpot matches properties by internal name, not display label. Two properties with the same label but different internal names will cause silent mapping failures during migration.
2.2 Lists
- ✓Inventory every list referenced as an enrollment trigger, suppression list, or branch filter
- ✓Classify each list as active (filter-based) or static (manually populated)
- ✓Document the filter criteria for every active list, noting which properties and values are used
- ✓Record the member count of each list as a validation benchmark
- ✓Identify lists that reference other lists (nested list membership criteria)
- ✓Note any lists shared across multiple workflows, since these need to be migrated once and referenced by all dependent workflows
2.3 Forms
- ✓List every form referenced in "submitted a form" enrollment triggers or branch criteria
- ✓Document form fields and their mapping to contact properties
- ✓Note form-specific settings: redirect URLs, notification recipients, and connected workflows
- ✓Record submission counts as a validation benchmark
- ✓Identify forms embedded on external pages that will need updated embed codes in the target portal
2.4 Marketing Emails
- ✓Catalog every marketing email sent by any workflow being migrated
- ✓Document the email type: regular, automated, A/B test
- ✓Record personalization tokens used in subject lines and body content
- ✓Note smart content rules that dynamically change email content based on contact properties
- ✓Document CTA buttons within emails and their destination URLs
- ✓Record sender information: from name, from address, reply-to address
For a complete guide to moving email assets, see our email template transfer guide.
2.5 Pipelines and Deal Stages
- ✓List every pipeline referenced in deal-based workflows
- ✓Document all deal stages within each pipeline, including stage names, display order, and win probability percentages
- ✓Note deal properties used in stage-change triggers or actions
- ✓Identify automation tied to pipeline stage changes that may overlap with workflows being migrated
2.6 Connected Integrations
- ✓Identify all integration-dependent actions within workflows: Slack messages, Salesforce syncs, Zoom registrations, webhook calls, etc.
- ✓Document API endpoints and credentials used in webhook or custom code actions
- ✓Determine which integrations are available in the target portal
- ✓Plan for integration gaps: If an integration exists in the source but not the target, decide whether to install it, replace it, or remove the action
2.7 Teams and Users
- ✓List all users referenced in owner assignment, task creation, and notification actions
- ✓Map source portal users to their equivalents in the target portal
- ✓Identify team references used in rotation or routing actions
- ✓Verify user permissions in the target portal are sufficient for workflow-assigned tasks
Phase 3: Target Portal Preparation
With the dependency inventory complete, prepare the target portal to receive the workflows. This phase must be finished before any workflow recreation begins.
Create Missing Properties
Match internal names exactly, verify field types, replicate dropdown options in identical order.
Recreate Lists
Build every active list using documented filter criteria. Create and populate static lists.
Set Up Forms
Create or verify forms required by workflow enrollment triggers. Test submissions.
Prepare Marketing Emails
Create all emails needed by send actions. Verify tokens, smart content, and CTA links.
Configure Pipelines
Create deal pipelines with matching stage names, probabilities, and display order.
Install Integrations
Install required integrations, configure authentication, and test connectivity.
3.1 Create Missing Properties
- ✓Create every custom property that does not already exist in the target portal
- ✓Match internal names exactly: If the source property internal name is
lead_score_tier, the target must use the same internal name - ✓Verify field types match: A dropdown in the source must be a dropdown in the target, not a text field
- ✓Replicate dropdown options in the exact same order with identical values
- ✓Assign properties to appropriate groups for team usability
- ✓Test each property by updating a test contact to confirm it accepts values correctly
3.2 Recreate Lists
- ✓Build every active list using the filter criteria documented in Phase 2
- ✓Verify list membership counts are in the expected range (accounting for differences in the target portal's contact database)
- ✓Create static lists and populate them with the appropriate contacts from the target database
- ✓Test list criteria by checking that known contacts appear or do not appear as expected
3.3 Set Up Forms
- ✓Create or verify forms required by workflow enrollment triggers
- ✓Map form fields to the correct properties in the target portal
- ✓Configure notification settings with target portal team members
- ✓Test form submissions to confirm data flows to the correct properties
3.4 Prepare Marketing Emails
- ✓Create all marketing emails needed by workflow send-email actions
- ✓Verify personalization tokens resolve correctly in the target portal
- ✓Test smart content rules against the target portal's contact data
- ✓Update CTA destination URLs if they differ between source and target
- ✓Send test emails to verify rendering, links, and personalization
3.5 Configure Pipelines
- ✓Create deal pipelines with matching stage names and probabilities
- ✓Verify stage order matches the source portal exactly
- ✓Set up stage-change notifications if required by the workflow
3.6 Install and Configure Integrations
- ✓Install required integrations in the target portal
- ✓Configure authentication for each connected app
- ✓Test integration connectivity independently of workflows
- ✓Update webhook URLs and API keys for custom code actions
Phase 4: Workflow Recreation
With all dependencies in place, you can now recreate the workflows. This phase is where the actual migration happens.
Always migrate workflows in dependency order. If Workflow B enrolls contacts who complete Workflow A, migrate A first. Start with simpler workflows to build confidence before tackling complex ones.
4.1 Execution Order
- ✓Migrate workflows in dependency order: If Workflow B enrolls contacts who complete Workflow A, migrate A first
- ✓Start with simpler workflows to build confidence and refine your process before tackling complex ones
- ✓Process one workflow at a time to maintain focus and prevent cross-contamination of errors
- ✓Keep the source workflow running in the source portal until the target version is fully validated
4.2 Build Each Workflow
For each workflow in the migration plan:
- ✓Create the workflow in the target portal with the correct object type (contact, company, deal, etc.)
- ✓Configure enrollment triggers using target-portal properties, lists, and forms
- ✓Set re-enrollment rules to match the source configuration
- ✓Recreate each action in sequence: emails, property updates, delays, tasks, notifications
- ✓Build if/then branches with exact filter criteria, testing each branch's logic
- ✓Configure suppression lists using target-portal lists
- ✓Set goal criteria using target-portal properties
- ✓Add workflow notes documenting the source portal, original workflow name, and migration date
- ✓Leave the workflow in draft state until testing is complete
If you are using tooling instead of manual recreation, our guide to copying workflows between portals covers how Jetstack automates this process.
4.3 Quality Checks During Recreation
| Check | What to Compare | Common Mistake |
|---|---|---|
| Action Counts | Source vs. target action count | Skipping a delay or notification |
| Branch Structure | Same paths with same criteria | Missing a branch condition |
| Delay Durations | Calendar days vs. business days | Confusing day types |
| Email References | Published email in target portal | Linking to draft or missing email |
| Notification Recipients | Correct team members in target | Using source portal user IDs |
Phase 5: Testing Strategy
Testing is the most important phase of any workflow migration. Shortcuts here lead to production failures that affect real contacts.
Unit Testing
Test each workflow independently with test contacts for every branch path, suppression rule, and re-enrollment scenario.
Integration Testing
Test connected workflow chains end-to-end, verifying timing, handoffs, and duplicate prevention at each transition.
Load Considerations
Estimate enrollment volumes, check sending limits, stagger high-volume activations, and monitor API rate limits.
5.1 Unit Testing (Individual Workflows)
For each migrated workflow:
- ✓Create test contacts that meet enrollment criteria for every branch path
- ✓Create test contacts that should be suppressed and verify they are excluded
- ✓Manually enroll test contacts into the workflow
- ✓Monitor each step execution in the workflow history view
- ✓Verify email delivery by checking test contact inboxes (use real email addresses you control)
- ✓Confirm property updates by inspecting test contact records after each action fires
- ✓Validate branch routing by confirming each test contact followed the expected path
- ✓Check task creation and ownership assignment
- ✓Test goal completion by updating a test contact to meet goal criteria and verifying removal from the workflow
- ✓Test re-enrollment if applicable by modifying test contact properties to trigger re-entry
5.2 Integration Testing (Workflow Chains)
If workflows are connected in a chain (one workflow’s completion triggers enrollment in another):
- ✓Test the full chain end-to-end with a single test contact
- ✓Verify timing between workflows: Ensure contacts enroll in the next workflow within the expected timeframe
- ✓Confirm no duplicate enrollments occur at handoff points
- ✓Test the chain with edge cases: What happens if a contact meets the goal of Workflow A but does not meet the enrollment criteria of Workflow B?
5.3 Load Considerations
- ✓Estimate enrollment volume for the first 24 hours after activation
- ✓Check HubSpot's daily email sending limits to ensure batch enrollment will not hit caps
- ✓Stagger activation of high-volume workflows to avoid overwhelming the target portal's sending infrastructure
- ✓Monitor API rate limits if workflows trigger webhook or custom code actions
Activating multiple high-volume workflows simultaneously can hit HubSpot's daily email sending limits. Stagger activation across days and start with your most engaged contact segments first.
Phase 6: Rollback Plan
Every migration needs an escape route. Define your rollback plan before you start, not after something breaks.
6.1 Pre-Migration Snapshots
- ✓Export a list of all contacts currently enrolled in source workflows (for re-enrollment if needed)
- ✓Screenshot or export the source workflow configuration as a reference backup
- ✓Document the current state of every property, list, and form that will be referenced by migrated workflows
- ✓Record activation timestamps for each source workflow
6.2 Rollback Triggers
Define specific conditions that trigger a rollback:
| Trigger | Threshold | Action |
|---|---|---|
| Enrollment Anomaly | 10x more or fewer contacts than expected | Pause and investigate |
| Error Rate | More than 5% of enrolled contacts with errors | Immediate rollback |
| Email Delivery | Bounce rates exceeding 3% | Pause email sends |
| Customer Complaints | Any report of unexpected communication | Immediate rollback |
6.3 Rollback Procedure
If a rollback is triggered:
Pause Target Workflow
Immediately pause the affected workflow in the target portal to stop further enrollments.
Re-activate Source
Re-activate the corresponding workflow in the source portal if it was paused during cutover.
Unenroll Contacts
Unenroll all contacts from the target workflow to prevent further actions.
Root Cause Analysis
Review error logs to identify the root cause before attempting migration again.
Notify Stakeholders
Communicate the rollback, root cause, and estimated timeline for resolution to all affected teams.
Phase 7: Go-Live and Cutover
The cutover is the moment where you switch from the source workflow to the target. Timing and coordination are everything.
7.1 Pre-Cutover Final Checks
- ✓Verify all test results have been reviewed and approved by workflow owners
- ✓Confirm all stakeholders have been notified of the go-live schedule
- ✓Ensure rollback procedures are documented and accessible to the migration team
- ✓Verify monitoring dashboards or alerts are configured for the target workflows
7.2 Cutover Execution
- ✓Pause the source workflow in the source portal (do not delete it yet)
- ✓Note the current enrollment count and last enrollment timestamp in the source portal
- ✓Activate the target workflow in the target portal
- ✓Monitor initial enrollments for the first 15-30 minutes
- ✓Verify the first batch of actions fires correctly (emails sent, properties updated, tasks created)
- ✓Confirm suppression is working by checking that excluded contacts are not enrolling
Never delete source workflows at cutover. Pause them instead. You need them for rollback, reference documentation, and historical performance comparison for at least 90 days.
7.3 Handling In-Flight Contacts
Contacts that were mid-workflow in the source portal at cutover time need special handling:
Let Them Complete
Let in-flight contacts finish their journey in the source workflow before fully pausing it. Cleanest for the contact experience.
Manual Re-enrollment
Manually enroll in-flight contacts in the target workflow at the appropriate step. Requires careful tracking.
Accept the Gap
Some contacts may receive a truncated experience during transition. Document this and communicate to affected team members.
Phase 8: Post-Migration Validation
Migration is not done when the workflows are active. Post-migration validation over the following 1-2 weeks confirms long-term stability.
8.1 First 24 Hours
- ✓Compare enrollment rates between source and target: They should be within 10-15% of each other (accounting for database differences)
- ✓Monitor email delivery metrics: Bounce rates, open rates, and click rates should be consistent with source benchmarks
- ✓Check for error notifications in the workflow history
- ✓Verify branch distribution: The percentage of contacts following each path should approximate historical patterns
- ✓Confirm external integrations are receiving data from workflow actions
8.2 First Week
- ✓Review goal completion rates against source benchmarks
- ✓Check for contacts stuck at specific workflow steps (indicating a broken action or unresolvable delay)
- ✓Monitor email unsubscribe rates: A spike may indicate the wrong audience is being enrolled
- ✓Validate reporting: Confirm that dashboards and reports referencing workflow data are populating correctly
- ✓Collect feedback from sales and service teams on task quality and timeliness
8.3 First Two Weeks
- ✓Run a full comparison of source and target workflow performance metrics
- ✓Identify and resolve any remaining discrepancies
- ✓Deactivate source workflows permanently (but do not delete for at least 90 days, in case of audit needs)
- ✓Update internal documentation to reference the target portal workflows
- ✓Conduct a post-mortem covering what went well, what broke, and what to improve for the next migration
- ✓Archive migration artifacts: dependency maps, test results, rollback logs, and communication records
The post-migration validation period is not bureaucratic overhead — it is the safety net that catches the issues testing missed. Budget the full two weeks and resist the temptation to declare victory early.
Tools and Resources for Workflow Migration
Jetstack’s Migration Tooling
Jetstack’s Marketplace includes workflow migration packages that automate Phases 2-4 of this checklist. Dependency detection, ID translation, and target portal preparation are handled programmatically, reducing a multi-day manual effort to hours. For complex migrations, our implementation services provide hands-on guidance through every phase.
- Days of dependency mapping
- Manual property recreation
- Error-prone workflow rebuilding
- Higher risk of missed dependencies
- Automated dependency detection
- Programmatic property creation
- ID translation built in
- Validation framework included
Complementary Checklists
This workflow migration checklist works alongside other resources in the Jetstack library:
- Pre-migration portal audit: Ensure the source portal is clean before migration begins
- HubSpot workflow dependencies guide: Deep dive into mapping the full dependency tree
- Tools for copying HubSpot assets: Compare the available tooling for asset transfer
- HubSpot data migration: what you lose: Understand what does not survive a migration
HubSpot Native Resources
- HubSpot Knowledge Base articles on workflow creation and management
- HubSpot’s Automation API documentation for programmatic workflow access
- HubSpot Community forums for peer advice on migration challenges
Frequently Asked Questions
How long does a typical workflow migration take?
For a mid-size migration of 10-20 workflows with moderate complexity, plan for 2-4 weeks from assessment through post-migration validation. Simple migrations with 2-5 straightforward workflows can be completed in 3-5 business days. Enterprise migrations with 50+ workflows may take 6-12 weeks. Using Jetstack’s tooling can compress these timelines by 50-70%.
Should I migrate all workflows at once or in phases?
Always use a phased approach. Group workflows by business function (marketing nurtures, sales routing, service automation) and migrate one group at a time. This limits the blast radius of any issues and allows your team to learn and improve the process between phases.
What is the biggest risk in a workflow migration?
Broken enrollment triggers due to unresolved dependencies are the single biggest risk. A workflow that enrolls the wrong contacts or fails to enroll the right ones causes immediate business impact. The dependency inventory in Phase 2 of this checklist exists specifically to prevent this failure mode.
Can I migrate workflows from HubSpot Marketing Hub Starter?
HubSpot Marketing Hub Starter includes limited workflow functionality (form follow-up emails only). These simple automations can be recreated in any tier that supports workflows. Full workflow migration is most relevant for Professional and Enterprise tiers, where complex, multi-step automations are common.
Do I need to migrate workflows if I am consolidating two portals?
Yes. Portal consolidation involves choosing a surviving portal and migrating assets from the retiring portal into it. Workflows are among the most complex assets to migrate and should be prioritized after properties, lists, and email templates are in place. See our portal consolidation guide and merge two HubSpot portals guide for the full process.
What happens to contacts enrolled in a workflow during migration?
Contacts in the source workflow continue their journey until the workflow is paused. They are not automatically transferred to the target workflow. You must decide whether to let them complete in the source, manually re-enroll them in the target, or accept a transition gap. Phase 7.3 of this checklist addresses this directly.
How do I handle workflow IDs that change during migration?
Every workflow in HubSpot has a unique numeric ID that changes when the workflow is recreated in a different portal. If other systems reference workflows by ID (such as API integrations, external tools, or webhook endpoints), update those references to point to the new workflow IDs in the target portal.
Should I delete source workflows after migration?
Do not delete source workflows immediately. Deactivate them and retain them for at least 90 days. They serve as reference documentation, provide historical performance data for comparison, and act as a safety net if you need to understand the original configuration for troubleshooting.
Planning a workflow migration and need expert guidance? Contact Jetstack to discuss your migration scope, or explore our Marketplace for migration tooling that automates the heavy lifting.