Conditional Properties: Manual Migration Reality

You’ve just been asked to migrate 395 conditional properties from a sandbox to production. You search for migration tools. You find Supered, Hammerstone, and various HubSpot ecosystem apps. You configure them, run the export, and discover the uncomfortable truth:

No tool can migrate conditional property logic.

This article explains why, documents what you’re actually facing, and provides strategies to make the manual work as efficient as possible.

What Are Conditional Properties?

Conditional properties in HubSpot show or hide form fields based on previous answers. If a user selects “Enterprise” as their company size, additional questions about their tech stack appear. If they select “Small Business”, those fields stay hidden.

The logic lives in HubSpot’s form editor:

If [Company Size] equals [Enterprise]
  Then show [Current CRM System]
  And show [Annual IT Budget]
  And show [Decision Timeline]

This creates a better user experience by keeping forms focused and relevant.

Why Migration Tools Can’t Help

The API Limitation

HubSpot’s Properties API allows you to:

• ✅ Create, read, update, delete properties
• ✅ Set property options (dropdown values)
• ✅ Configure property groups
• ❌ Access conditional display logic

The conditional logic is stored in the form definition, not the property definition. And forms API access doesn’t include conditional rules in a format that can be exported and reimported.

What Tools Like Supered Actually Do

Supered and similar tools are excellent for:

• Migrating property definitions
• Copying workflows
• Transferring email templates
• Moving custom objects

But they hit the same API limitations. They can copy the properties themselves, but the conditional relationships between them don’t come along.

The Form Embed Problem

Conditional logic is tied to specific forms. Even if you could export the rules, they reference property names, form IDs, and option values that differ between portals. A migration tool would need to:

1. Export conditional rules
2. Map property names between source and destination
3. Map form IDs between portals
4. Recreate the exact rule structure

HubSpot hasn’t exposed APIs to make this possible.

Estimating the Manual Effort

Based on real-world migration projects, here’s what 395 conditional properties actually means:

Complexity Tiers

Simple Conditionals (show one field based on one selection)

• Time per rule: 2-3 minutes
• Example: If Country = UK, show VAT Number

Medium Conditionals (show multiple fields based on one selection)

• Time per rule: 5-7 minutes
• Example: If Product Interest = Enterprise, show [Budget], [Timeline], [Decision Maker]

Complex Conditionals (nested logic, multiple triggers)

• Time per rule: 10-15 minutes
• Example: If Country = US AND Company Size = Enterprise AND Industry = Healthcare, show [HIPAA Compliance], [Security Contact]

Time Calculation

Assuming a distribution of:

• 60% Simple (237 rules × 2.5 min = 593 min)
• 30% Medium (119 rules × 6 min = 714 min)
• 10% Complex (39 rules × 12 min = 468 min)

Total: ~30 hours per portal

For sandbox AND production: ~60 hours of manual work.

Hidden Time Costs

The 30-hour estimate doesn’t include:

• Documenting source portal logic before starting
• Testing each conditional rule works correctly
• Fixing typos in dropdown values that break matching
• Troubleshooting “why isn’t this field showing?”
• Stakeholder review cycles

Realistically, budget 40-50 hours per portal including documentation and testing.

Strategies to Minimise Pain

Strategy 1: Document Everything First

Before touching the destination portal, create a comprehensive spreadsheet:

This becomes your checklist for recreation.

Strategy 2: Use Property Internal Names

HubSpot’s UI shows display names, but conditional logic uses internal names. When recreating rules, ensure internal names match:

Source portal:

Property: "Annual Revenue"
Internal Name: annual_revenue
Options: "$0-1M", "$1M-10M", "$10M+"

Destination portal must match exactly, including option values and internal names.

Strategy 3: Create Properties First

Before configuring conditionals:

1. Migrate all properties using Supered or similar
2. Verify internal names match between portals
3. Verify dropdown options match exactly
4. Then build conditional rules

If properties don’t match, conditional rules referencing them will silently fail.

Strategy 4: Template Similar Forms

If you have 20 forms with similar conditional logic, create one template:

1. Build the first form with all conditionals
2. Clone it for similar forms
3. Modify only the unique fields

This is faster than building from scratch each time.

Strategy 5: Batch by Complexity

Don’t mix simple and complex rules in the same work session:

• Morning block: Simple conditionals (high volume, low cognitive load)
• Afternoon block: Complex conditionals (lower volume, requires focus)

Context-switching between complexity levels slows you down.

The Documentation Template

Create a spreadsheet with these columns:

Export Process

For each form in the source portal:

1. Open form editor
2. Navigate to each field
3. Check if conditional logic exists
4. Document in spreadsheet
5. Screenshot complex rules for reference

Import Process

For each row in your spreadsheet:

1. Open corresponding form in destination
2. Navigate to relevant field
3. Add conditional logic per documentation
4. Mark row as complete
5. Test the form to verify

Testing Conditional Rules

After recreation, test every rule:

Basic Test

1. Preview the form
2. Select trigger value
3. Verify correct fields appear/hide
4. Select different trigger value
5. Verify behaviour changes appropriately

Edge Case Tests

• What happens with no selection?
• What happens if dependent property has no value?
• Do nested conditionals trigger in correct order?

Production Validation

After go-live, monitor form submissions:

• Are expected fields being submitted?
• Are fields that should be hidden occasionally appearing?
• Are users abandoning at conditional fields?

When to Push Back

Sometimes the right answer is to reduce conditional complexity:

Questions to Ask

• Do we really need 395 conditional rules?
• Can some rules be consolidated?
• Are there rules that no longer serve a business purpose?
• Would simpler forms with fewer conditionals work?

Migration as Cleanup Opportunity

Present the migration as a chance to audit and optimise:

“Migrating 395 rules will take ~50 hours. If we review and potentially consolidate to 200 essential rules, we can reduce migration time to ~30 hours AND simplify ongoing maintenance.”

Stakeholders often accept reduced complexity when presented with time/cost tradeoffs.

Alternative: Rebuild Instead of Migrate

For extreme cases, consider:

1. Export form submission data from source
2. Recreate forms fresh in destination with simplified logic
3. Focus on business requirements rather than replicating legacy complexity

This takes courage to propose but often results in better outcomes than 1:1 recreation of accumulated cruft.

Key Takeaways

1. No tool migrates conditional logic - the API doesn’t expose it
2. Budget 40-50 hours per portal for comprehensive conditional property migration
3. Document before recreating - a spreadsheet saves time over constant source-checking
4. Ensure property names match exactly - conditionals fail silently on mismatches
5. Use migration as cleanup opportunity - question whether all rules are needed
6. Test every rule - broken conditionals create terrible user experiences

The manual reality isn’t pleasant, but with proper documentation and systematic execution, it’s manageable. Just set accurate expectations with stakeholders before you start.

Facing a complex HubSpot migration? Connect with me on LinkedIn to discuss strategies.