Migrate from ContactDB to HubSpot

ContactDB contact records map directly to HubSpot Contacts. Email address serves as the primary deduplication key during import. Records without email are flagged for manual review before migration commits. During the load phase, each incoming record is matched by email to HubSpot contacts; duplicates trigger an update instead of a new record, preserving property values. Name, phone, job title, and address transfer, while custom properties are populated from ContactDB attributes.

ContactDB company names map to HubSpot Company Name. When multiple contacts share a company, HubSpot creates one Company record and associates all related Contacts via the company_id foreign key. Circular references are resolved in load order. Company names are normalized (trimmed, case‑adjusted) before insertion to reduce duplicates from formatting differences. Similar names with variations are matched using fuzzy logic on name and domain, with any conflicts flagged for manual review.

ContactDB list membership (e.g., 'Healthcare Execs', 'Q4 Target List') migrates as a custom multi-select property on HubSpot Contacts named ContactDB_List_Segment__c. Multiple list memberships per contact are preserved as comma-separated values in the multi-select field. The property is created in HubSpot before migration, with pick‑list values sourced from segment names in ContactDB. Contacts with memberships exceeding the 255‑character limit overflow into a secondary property (ContactDB_List_Segment_2__c), with split noted in migration report.

HubSpot has no native SIC code field on Companies. We create a custom text property (SIC_Code__c) and map ContactDB's SIC code values directly. Teams using NAICS codes store those in a separate custom field (NAICS_Code__c). Prior to migration, these custom properties are provisioned in HubSpot. During data load, each company record receives its SIC code in the custom field; missing values remain empty.

ContactDB's credit rating field maps to a custom select property (Credit_Rating__c) on HubSpot Companies. Pick-list values are created based on ContactDB's rating scale before migration runs. During mapping, each unique rating from ContactDB is added as a HubSpot pick‑list option, preserving the source vocabulary. If a company record lacks a rating, the custom property is left blank.

HubSpot's standard numberofemployees field maps directly from ContactDB's employee count. Ranges (e.g., '51-200') are transformed to the midpoint value or kept as‑is if HubSpot's field is configured as a text field. During mapping, numeric values pass unchanged, while range strings are parsed and converted to a midpoint. If ContactDB stores counts as descriptive text (e.g., '500+ employees'), the value is stored as‑is in the HubSpot field, preserving the original description.

HubSpot's standard annualrevenue field accepts numeric values. ContactDB revenue-band fields (e.g., '$1M-$5M') are transformed to numeric midpoints before mapping. During transformation, currency symbols and commas are stripped, the range is parsed, and the midpoint is calculated. If ContactDB already stores a single numeric revenue figure, it passes through unchanged. The resulting revenue values are loaded into HubSpot's annualrevenue property for reporting and filtering.

ContactDB tracks email deliverability status. We map this to a custom select property (Email_Verification_Source__c) on HubSpot Contacts. Status values are preserved as pick‑list options. The custom property is created in HubSpot before migration, with pick‑list values sourced from ContactDB's distinct status set. During data load, each contact receives its original verification status as the corresponding pick‑list value; missing statuses remain blank.

ContactDB owner assignments map to HubSpot Owner by email match. If a ContactDB owner has no corresponding HubSpot user, the contact is assigned to a fallback owner for reassignment review. The mapping table is built by matching ContactDB owner emails to HubSpot user emails. Unmatched owners are stored in a custom property (Original_Owner_Email__c) on each contact, allowing reassignment post‑migration. This preserves owner assignment and prevents contacts from being orphaned during transfer.

HubSpot's CreatedDate reflects the import timestamp. Original ContactDB create dates are preserved in a custom datetime property (Original_Create_Date__c) for reporting continuity. During migration, HubSpot's CreatedDate is set to the import moment, while the original ContactDB creation timestamp is extracted from the source record and written into the custom datetime field. This enables reports to reference the original contact creation date without affecting HubSpot's audit trail.

ContactDB's internal record ID is stored as Source_Record_ID__c on HubSpot Contacts. This enables delta-run de-duplication and traceability back to the original ContactDB entry. During later migration runs, the Source_Record_ID__c field matches incoming ContactDB records against existing HubSpot contacts, ensuring only new or updated records are inserted while duplicates are ignored. The field also supports audit workflows, allowing teams to reference the original ContactDB identifier when investigating data discrepancies.

ContactDB has no deal or opportunity records. If deal context is available (from another system or spreadsheet), we can create HubSpot Deals during migration, mapping fields such as name, amount, close date, pipeline, and stage. If no deal data exists, deals are configured post‑migration in HubSpot, using the imported contacts as the base for new opportunities.

ContactDB does not model support tickets. If case data exists in another system, we can migrate it to HubSpot Tickets. ContactDB contact records do not include ticket history. When migrating ticket data, we map fields such as subject, description, status, priority, and owner to HubSpot Ticket properties. If no ticket system is available, the team creates ticket pipelines and statuses in HubSpot after migration to begin tracking support cases.

ContactDB stores static contact records only — no engagement activity (calls, emails, meetings, notes). HubSpot engagement history is built post‑migration through ongoing usage or imported from a system that tracks activity. If engagement data exists in another platform, FlitStack AI can import it, mapping date, type, owner, and notes to HubSpot engagement objects. This provides a timeline of past interactions for each contact, supporting sales and service teams after migration.

ContactDB has no workflow or automation engine. HubSpot workflows must be designed and built post‑migration based on the team's sales process. We provide a workflow requirements questionnaire as a rebuild reference. The questionnaire covers trigger types (lifecycle changes, property updates), actions (email sends, task creations), and enrollment criteria, helping the HubSpot admin rebuild automation sequences efficiently and align them with the current sales motion.