Migrate from BlinQ to HubSpot

Blinq flat tag structure does not match HubSpot's three-tag model

Blinq exports three tag types — Contact tags, Workspace tags, and Campaign tags — as a single flat list per contact. HubSpot splits these into native Contact properties, Campaign membership, and Workspace associations, which are structurally distinct. If your team used Blinq tags for multiple purposes (segmenting by team, by event, by contact type), those distinctions are invisible in Blinq's flat export. We preserve all three tag types as separate custom properties (Blinq_Contact_Tags__c, Blinq_Workspace_Tags__c, Blinq_Campaign__c) so the raw data is intact, but your HubSpot admin will need to decide whether to parse them into HubSpot's native association model or keep them as reference fields. Failure to restructure tags before building HubSpot workflows will cause contact segmentation to misfire.

Company conversion requires deduplication before contact linkage

Blinq stores company as a free-text field on every contact — the same company may appear as 'Acme Corp', 'Acme Corporation', and 'acmecorp.com' across different contacts. HubSpot requires a Company record to exist before a contact can associate to it via the associatedcompanyid field. If FlitStack creates HubSpot Company records without first deduplicating the source company names, contacts that should share a company will be linked to separate, duplicate Company records, fragmenting your HubSpot company data. We deduplicate Blinq company text using normalized name matching and domain extraction where present, but any ambiguous company entries are flagged for admin confirmation before company records are created.

Blinq personal contacts do not export unless shared with the team

Blinq's export integration documentation is explicit: personal contacts that have not been shared with the organization are not included in the export. If your team's Blinq setup relies on individual personal contact storage — a common pattern for solo networkers using Blinq's free plan — those records will not appear in the migration unless each user manually shares them with the team workspace before the export runs. We include a pre-migration check to count personal vs. team contacts and surface the gap before the migration plan is finalized.

HubSpot lifecyclestage must be set manually for all migrated contacts

Blinq has no concept of a contact lifecycle stage — it does not track whether a contact is a prospect, marketing-qualified lead, sales-qualified lead, or customer. HubSpot's lifecyclestage property is the core property that drives HubSpot's automation, list segmentation, and reporting. If FlitStack sets all migrated contacts to the same default value (subscriber or lead), any automation that gates on lifecyclestage will not differentiate between your historical Blinq contacts. We surface this as a mandatory post-migration step and can provide a spreadsheet for bulk lifecyclestage enrichment based on other contact signals (tags, campaign attribution, last activity date) to help your admin set values consistently.

Blinq owner/creator reference is not a HubSpot owner and cannot be auto-assigned

Blinq records which Blinq user created or owns each contact as a user reference, but Blinq users are not HubSpot users and there is no automatic sync between Blinq user identity and HubSpot owner records. The creator reference may include email addresses that match HubSpot users — we attempt email matching — but any unmatched creator references land as a custom property (Blinq_Created_By__c), not as a HubSpot Owner assignment. Contacts without a matched HubSpot owner default to the migration service account or your specified fallback owner. If you need proper owner assignment for reporting, your HubSpot admin will need to map the creator list to HubSpot users after migration.