Built for RevOps leaving HubSpot with hundreds of custom properties

Your HubSpot custom property sprawl, mapped into Strkr fields in one pass.

HubSpot portals accumulate custom properties the way old laptops accumulate browser tabs. Fifteen pipelines later, you are staring at 480 contact properties, 220 company properties, and seventeen different definitions of lifecycle_stage_v4. Strkr imports every property, keeps the historical values, and renames the ones that have been dead since 2021.

What this audience is actually dealing with

The pains that bring buyers here.

HubSpot custom properties are the single biggest migration headache for RevOps teams moving to a new CRM. Every portal older than two years has a long tail of properties built for a campaign that ended, a sales play that got cut, or an ops leader who left. The default export writes a flat CSV with no indication of which properties are still populated, which are tied to active workflows, which feed calculated properties, or which drive conditional picklists. The team shows up on day one of migration staring at twelve hundred field names with no triage layer. Strkr handles the triage inside the import tool so the project does not stall for six weeks on field-mapping alone.

The sprawl census

A six year old HubSpot portal has roughly 1,200 properties.

Across contact, company, deal, and ticket objects, a well-used HubSpot portal built up over five or six years will carry 800 to 1,500 custom properties. Of those, roughly 30 to 40 percent are still populated on new records, 20 percent are referenced by active workflows, and the remainder are either stale or inherited from a sales play that got decommissioned. The import tool surfaces that triage before mapping.

Calculated properties break on export

HubSpot calculated fields do not show up in the CSV export.

Calculated properties (deal_age_days, days_in_stage, pipeline_velocity, custom scoring) resolve server side and the raw export writes the computed value, not the formula. Strkr reads the calculated property definitions through the HubSpot Properties API and recreates the equivalent calculation on the Strkr side so the number on the record stays current instead of frozen at migration time.

Dependent picklists lose structure

Country drives State drives City collapses to flat text.

HubSpot dependent picklists (where one dropdown filters the options in another) export as flat strings. Strkr rebuilds the dependency chain at import time by reading the metadata on the property definition and recreating the parent to child relationship in the Strkr picklist tree. The CSAT, country, state, city pattern survives the migration intact.

History gets truncated

Property change history before day one is gone.

A naive HubSpot export writes only the current value of each property. The audit trail (who changed lifecycle_stage from marketing_qualified_lead to sales_qualified_lead at 3:14 pm on April 11) stays trapped in the HubSpot activity log. Strkr pulls the Properties History API record for each tracked field so the historical timeline attaches to the record on the Strkr side.

Field type collisions

Number fields storing strings explode on strict schema.

HubSpot number properties are permissive and will accept the string unknown or a dollar sign prefix without complaint. Strkr field types are typed. The import tool surfaces every field with mixed types before migration so RevOps can decide: coerce to number and null the garbage, convert the field to text, or run a cleanup pass in HubSpot before the final cutover.

Workflow referenced properties

You cannot delete a property feeding a live workflow.

HubSpot refuses to delete a property that is referenced by an active workflow, which is the right behavior but leaves teams unable to clean up without reverse engineering every workflow. The Strkr import maps every property to the HubSpot workflows that consume it so the admin sees the dependency graph before deciding what to migrate, what to deprecate, and what to replace with a Strkr flow.

How the import tool runs

Discovery, triage, mapping, migration, verification.

The HubSpot property migration into Strkr runs as a five stage pipeline. Each stage has a human review gate so RevOps keeps control over what moves and what gets left behind.

Discovery scan

Read every property definition and its usage.

Strkr authenticates against HubSpot through a scoped Private App token with read access to properties, workflows, lists, and reports. The scan writes a full inventory: property name, label, type, options, created date, creator, last modified date, population rate, and workflow references. The scan completes in under thirty minutes for a portal under 1,500 properties.

Triage report

Rank every property by signal to noise.

Each property gets a score built from four signals: percent of records populated in the last 90 days, number of workflows referencing it, number of reports or lists filtering on it, and whether it is required at any lifecycle stage. The report sorts the properties into keep, review, archive, and delete buckets so the mapping stage starts with a clean list of 200 to 400 fields instead of the raw 1,200.

Mapping workbench

Drag HubSpot property to Strkr field with type conversion.

The mapping workbench shows HubSpot source on the left, Strkr destination on the right, and the type conversion in the middle. The admin can accept the recommended mapping, change the target field type, merge two HubSpot properties into one Strkr field, split one HubSpot property into two Strkr fields, or mark the property archive only. Mapping saves per object type.

Dry run and verification

Preview the first 500 records before committing.

Before the full migration runs, the dry run writes the first 500 contact records, 500 company records, and 500 deal records into a Strkr sandbox namespace. The admin spot checks the mapped values against the live HubSpot source and flags any field that landed wrong. The dry run is reversible: delete the sandbox namespace and re-run with corrected mapping.

Full migration

Batched writes with full audit log.

The full migration runs in batches of 10,000 records with retry on transient failures. Every write records the HubSpot source record id, the mapped Strkr record id, the field values written, and the timestamp. The audit log satisfies the common procurement question about data lineage during a vendor change. A 400,000 record migration completes in roughly six hours.

Workflow translation

HubSpot workflows ported to Strkr flows.

Workflows that referenced the migrated properties get a side by side translation suggestion. HubSpot triggers map to Strkr flow triggers, HubSpot actions map to Strkr flow actions, and the admin accepts, edits, or rebuilds each flow. Complex branching workflows get flagged for manual rebuild rather than auto translated so the behavior stays explicit.

Verification dashboard

Compare record counts and field population by object.

Post migration, the verification dashboard shows the source count and destination count per object type, the population rate per migrated field, and any records that failed to write with the failure reason. The reconciliation runs daily during the parallel run period so RevOps has evidence the two systems agree before cutover.

Delta sync during parallel run

Keep both systems in sync for the 30 day cutover window.

Teams typically run HubSpot and Strkr in parallel for 15 to 45 days before cutover. Strkr listens to HubSpot webhooks for property changes on the mapped records and replays them into Strkr so new activity in HubSpot during the parallel window stays reflected. The sync is one way, HubSpot to Strkr, during the cutover period.

Archive the stale fields

Keep the audit record without carrying the schema debt.

Properties marked archive at mapping time write to a Strkr archive namespace instead of the live schema. The historical values stay queryable through the open API for the retention window the admin configures, so a 2022 campaign attribution flag is still answerable without cluttering the current record layout.

Where the tool helps most

The portals that benefit from a structured migration.

The tool is most valuable for HubSpot portals carrying real schema complexity. For a 50 property portal, a CSV export and manual re-entry works fine. The patterns below are where the structured migration earns the week it saves.

Multi pipeline sales teams

Several deal pipelines with different custom stages.

Teams running three or more HubSpot deal pipelines (new business, expansion, services, partner-sourced) carry pipeline specific custom properties that only populate on that pipeline. The import maps those properties as pipeline conditional fields in Strkr so the record only shows the relevant fields to the rep, rather than cluttering every deal view.

Marketing operations with scoring

Lead scoring built across 40 to 60 input properties.

Mature marketing ops teams build lead scoring that reads from engagement, firmographics, product usage flags, and custom web events. The scoring formula lives in HubSpot calculated properties. The import translates the formula into a Strkr scoring rule that reads the same input fields and produces a comparable score, with a verification pass showing the delta between HubSpot and Strkr scores on 1,000 sample records.

Services businesses with project tracking

Deal properties doubling as project metadata.

Services firms often stretch deal properties to hold project context (statement_of_work_number, delivery_lead, kickoff_date, retainer_hours_remaining). The migration recognizes those as better suited to the Strkr Projects module and offers to split them: deal fields stay with deals, project fields move to project records that link to the originating deal.

B2B account based motion

Company properties feeding account tiering.

Account based teams build company properties for tier, strategic account flag, named account owner, cross-sell potential, renewal risk. The migration keeps all of those on the Strkr Account object and surfaces them in the account view, with the tier field driving sidebar grouping if the admin opts in.

Customer success operations

Ticket properties and NPS metadata.

Customer success teams running on HubSpot Service Hub carry ticket properties for sentiment, resolution_category, escalation_path, csm_assigned, product_area. The import maps those to Strkr Case fields and preserves the ticket history timeline so prior support conversations stay visible on the account.

E-commerce and transactional

Contact properties feeding transactional segmentation.

Teams running HubSpot alongside Shopify or BigCommerce carry contact properties for lifetime_value, last_order_date, average_order_value, favored_category. The migration preserves those as typed Strkr fields and the lifetime value fields plug into the Strkr segmentation builder for post migration marketing lists.

What the import will not do

Honest limits so you know what still needs hands on time.

The import tool automates the mechanical mapping. A few parts of a complex HubSpot migration remain manual by design so the team keeps control over the business logic.

Will not auto translate complex workflows

Multi branch workflows need manual rebuild.

HubSpot workflows with five or more branches, delay actions chained to custom conditions, or if-then logic that reads from calculated properties get flagged for manual rebuild in Strkr flows. The tool shows the full HubSpot workflow logic side by side with a blank Strkr flow canvas so the admin ports the behavior with full visibility rather than trusting an auto translation that might silently drop a branch.

Will not migrate HubSpot CMS content

Landing pages and blog posts stay in HubSpot CMS or move separately.

The import handles CRM data (contacts, companies, deals, tickets, custom objects and their properties). HubSpot CMS pages, blog posts, email templates, and the HubDB tables that back them stay in HubSpot CMS or require a separate CMS migration project. The two migrations run on different timelines so neither blocks the other.

Will not touch marketing email history

Email send history stays in HubSpot by design.

Marketing email send history (opens, clicks, bounces for emails sent through HubSpot) stays in HubSpot. The import pulls the engagement summary (lifetime opens, lifetime clicks) as a point in time snapshot onto the Strkr record but does not replicate the per-send event stream. For teams needing the per-send stream post cutover, a parallel BigQuery or data warehouse sync carries that data.

Will not rebuild complex calculated properties

Nested formula calculations get a human review.

Simple calculated properties (date math, number math, concat) auto translate. Deeply nested formulas (five or more property references, conditional branches, cross object references) get flagged for human review so the Strkr equivalent is validated against the HubSpot output on sample records before going live.

Will not migrate HubSpot operations hub custom code

Custom JavaScript workflow steps need a rewrite.

HubSpot Operations Hub custom code actions (JavaScript running inside workflows) do not auto translate. The tool exports the code with the context of which workflow it runs in so the admin or an engineer rewrites the equivalent logic in a Strkr flow custom action or in the open API webhook pattern.

Will not auto resolve naming conflicts

Property name clashes get a review step.

When two HubSpot properties should map to the same Strkr field (region and territory both carrying geography), the tool pauses for a human decision rather than silently merging. The admin picks: merge with a rule (coalesce the non null value, prefer the newer one), keep as separate Strkr fields, or route to a holding field for post migration cleanup.

Head-to-head

Strkr HubSpot import compared to raw CSV plus manual rebuild.

The alternative to a structured property migration is the manual path: export HubSpot to CSV, map in a spreadsheet, re-create fields in the new CRM, import, verify by hand. Here is the delta.

Feature Strkr CSV export plus manual rebuild
Property discovery time Automated scan completes in under 30 minutes Manual spreadsheet audit takes 3 to 5 days
Calculated property handling Reads formula and recreates on Strkr side Export writes frozen value, formula lost
Dependent picklist structure Parent child dependency preserved Flattens to independent dropdowns
Property history Pulls Properties History API for tracked fields Current value only, audit trail lost
Workflow dependency graph Shows which workflows reference each property Reverse engineered by hand workflow by workflow
Dry run on sample records First 500 per object into sandbox namespace All or nothing, errors found post migration
Parallel run delta sync Webhook based 30 day sync HubSpot to Strkr Hard cutover, no parallel window
Verification dashboard Record counts and field population reconciliation Spot check by eye, hope for the best
Archive policy for stale fields Archive namespace with retention window Keep everything or lose everything
Time to live on Strkr Two to six weeks typical for complex portal Three to six months including rework
How teams use Strkr

How teams run the HubSpot property migration.

The common thread across teams that bring the import tool in: they want the migration to finish without eating a quarter of RevOps capacity. The patterns below describe the shape of recent migrations.

B2B SaaS, 8 year HubSpot portal, 1,340 properties

From 1,340 fields to 287 fields in the triage pass.

A B2B SaaS company on HubSpot since 2018 ran the discovery scan and found 1,340 custom properties across contact, company, deal, and ticket objects. The triage ranked 287 as keep (populated in the last 90 days or referenced by an active workflow), 410 as archive (historical value with retention policy), and the rest as delete. The RevOps lead, Ingrid, scoped the mapping work at three weeks instead of the originally estimated two months.

Services firm with pipeline specific fields

Four deal pipelines kept their conditional field logic.

A professional services firm ran four HubSpot deal pipelines (new business, expansion, project services, retainer). Each pipeline carried 15 to 20 pipeline specific custom properties that only populated on that pipeline. The import mapped those as pipeline conditional fields in Strkr so a new business deal does not show the project services kickoff fields. Deal page clutter dropped meaningfully in the first week.

Marketing ops with 54 property lead score

Scoring parity achieved in the dry run phase.

A B2B marketing ops team scored leads using 54 input properties feeding a HubSpot calculated score. The dry run compared HubSpot score and Strkr score on 1,000 sample leads: 94 percent landed within two points, 5 percent within five points, and roughly 1 percent diverged more. The divergent cases traced to a date math nuance in HubSpot that the Strkr formula handled slightly differently. The admin accepted the small variance since the ranking order held.

Customer success team migrating tickets

Service Hub ticket history preserved on Strkr Cases.

A customer success team on HubSpot Service Hub migrated three years of tickets, including CSAT and sentiment custom properties. The import mapped tickets to Strkr Cases and preserved the ticket activity timeline (notes, status changes, assignments) alongside the account record. The CS director, Mira, reported that reps hit full context on day two instead of the typical six week ramp on a new tool.

E-commerce team with Shopify sync

Lifetime value fields kept their values and their refresh job.

A direct to consumer brand carried HubSpot contact properties for lifetime_value, last_order_date, favored_category synced from Shopify through a middleware. The import preserved the current values and the admin rebuilt the Shopify sync as a Strkr open API webhook that writes the same fields on each new order. The refresh cadence stayed daily and the segmentation lists that depended on those fields continued to work.

Scan your HubSpot portal, triage the sprawl, migrate the fields that matter.

Run the free discovery scan against your HubSpot portal to see the property inventory, the usage ranking, and the recommended mapping. No commitment to migrate until you see the triage report.

Common questions

What buyers in this bucket ask most.

How long does the HubSpot property migration typically take end to end?

For a portal with under 500 properties and under 100,000 records, two to three weeks including dry run and verification. For a portal with 500 to 1,500 properties and up to 500,000 records, four to six weeks. The time breakdown is roughly one week for discovery and triage, one to two weeks for mapping with admin review, one week for dry run and verification, and one to two weeks of parallel running before cutover. Teams carrying heavy custom workflows add one to two weeks for the workflow translation step.

Will the migration break my active HubSpot workflows while it runs?

No. The import reads from HubSpot through a scoped Private App token and writes nothing back during normal migration. HubSpot workflows continue to run as they always did. The one exception is the parallel run phase, where Strkr listens to HubSpot webhooks for property changes and replicates them one way (HubSpot to Strkr) so new activity during the cutover window stays visible on the Strkr side. HubSpot never receives writes from Strkr during the parallel run.

What happens to HubSpot calculated properties that use custom date logic?

Simple calculated properties (date math like deal_age_days, number math like weighted_amount, string concat like full_name) auto translate into Strkr formula fields. Complex calculated properties (nested conditionals, cross object references, Operations Hub custom code) get flagged for human review. The tool shows the HubSpot formula side by side with a blank Strkr formula editor so the admin writes the equivalent with full visibility. The verification step compares outputs on sample records.

How does the tool handle property change history for compliance evidence?

For properties flagged as tracked in HubSpot (lifecycle_stage, deal_stage, hs_lead_status, and any custom property set to track history), the tool pulls the Properties History API and attaches the full change log to the Strkr record. The migrated history includes who changed the value, what the prior value was, what the new value is, and when the change happened. The combined record satisfies the typical SOC 2 Type II (in progress through 2026-Q4) evidence request and HIPAA audit trail requirement for teams on the Strkr BAA.

Can we run HubSpot and Strkr in parallel during cutover without data drift?

Yes, through the webhook based delta sync. During the parallel run (typically 15 to 45 days), HubSpot stays authoritative and Strkr receives one way updates. Property changes on contacts, companies, deals, and tickets in HubSpot replicate to Strkr within seconds of the webhook firing. Users log into both systems during the window but only write to HubSpot. On cutover day, you flip the authority flag, point integrations at Strkr, and disable the HubSpot write path. The reverse flow (Strkr to HubSpot) is intentionally not supported to prevent accidental two way drift.

What is the compliance posture of the Strkr import tool for regulated industries?

The import runs inside the Strkr production environment, which is HIPAA compliant with a BAA available for covered entities and business associates. SOC 2 Type II is in progress with completion targeted for 2026-Q4. GDPR and CCPA compliant posture extends to the import pipeline: data in transit is encrypted, data at rest is encrypted, and the import audit log records every record read from HubSpot and written to Strkr for lineage evidence. For healthcare teams moving from HubSpot (which lacks a HIPAA BAA), the migration itself completes under the Strkr BAA.

Try it free. Bring your team next week.

No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.