Migrate from SprintHub to Twenty CRM

SprintHub Lead records map to Twenty Person. The SprintHub API exposes Lead with name, contact info, status, and owner assignment as standard fields. We extract tags attached to Lead records and map them to Twenty Topic assignments or a custom multi-select field depending on the customer's segmentation strategy. The SprintHub lead status values map to a custom select field in Twenty since Twenty's Person object does not have a native lifecycle stage equivalent like HubSpot does.

SprintHub Contact records map to Twenty Person. Contact details, custom properties, and company association metadata extract via SprintHub's API and load into Twenty Person fields. SprintHub does not have a separate Lead and Contact split like HubSpot versus Salesforce; Contacts are the primary person records. We resolve company associations by matching the SprintHub company_id to a pre-created Twenty Company record. Tags on Contact records migrate as Topic assignments on the Person record.

SprintHub Company records map directly to Twenty Company. Company name, industry, size, and custom fields migrate without transformation. The Company record must exist in Twenty before Contact and Person imports to satisfy the domain-based lookup relationship. We extract the full custom field schema from SprintHub alongside each record value and declare matching fields in Twenty's Metadata API before migration begins.

SprintHub Deals map to Twenty Opportunity. Deal name, amount, currency, close date, and owner assignment migrate to the corresponding Twenty Opportunity fields. We resolve the SprintHub pipeline_id to a Twenty workspace pipeline configuration that we create via the Settings API before migration. Closed-won and closed-lost status from SprintHub map to Twenty's stage values, and any custom deal fields become custom Opportunity fields declared in Twenty's metadata.

SprintHub pipeline definitions extract as explicit key-value pairs including stage names, stage order, and win/loss probability percentages. We create corresponding pipelines in Twenty via the Settings API, mapping each SprintHub pipeline to a named Twenty pipeline with stages in the correct order and probability values set per stage. SprintHub instances with multiple pipelines map to multiple named pipelines in Twenty rather than using record types as a workaround.

Stage names and probability values extract as explicit pairs from SprintHub's pipeline configuration API response. We create matching stages in Twenty with the same display names and probability percentages rounded to whole numbers. Stage order is preserved from SprintHub's pipeline stage index. Any stage that exists only in SprintHub (such as a custom stage name unique to the instance) is created as a custom stage value in Twenty's pipeline definition.

SprintHub tags are global across the instance and attach to Leads, Contacts, and Deals. We extract the full tag list including color metadata and preserve tag associations on each record. In Twenty, tags map to Topic assignments (via TopicAssignment records) for segmentation use cases, or to a custom multi-select field on the relevant object for use cases where tags need to appear on the record layout without creating topic graph relationships. The customer chooses the strategy during scoping.

SprintHub custom field names, types, and picklist options vary per instance. We extract the full custom field schema alongside record values and declare matching custom fields in Twenty's Metadata API before any data import. Type conversion follows standard mappings: SprintHub text becomes Twenty Text, picklist becomes Select, date becomes Date, number becomes Number, checkbox becomes Boolean. Custom fields must exist in Twenty before records import; the Metadata API creates the field and computes the GraphQL schema before data load begins.

SprintHub's WhatsApp multi-account routing rules do not map to any Twenty CRM native object because Twenty has no built-in WhatsApp integration. We extract the account-to-team assignments, channel routing rules, and conversation-to-account mappings as a structured JSON document during migration discovery. This document serves as the configuration specification for rebuilding the routing logic in a third-party automation layer (n8n, WhatsApp Business API, or a custom webhook system) post-migration. We do not attempt to replicate WhatsApp routing inside Twenty since the platform does not support it natively.

SprintHub automation rules including trigger conditions, filter logic, and multi-step action sequences store in a proprietary format. We export workflow definitions as structured JSON including trigger events, condition branches, delay steps, and action types. Rebuilding equivalent automations in Twenty requires either the native Twenty workflow builder (still maturing as of 2026) or an external automation platform connected via webhooks and the REST API. We deliver the workflow inventory as a handoff document for the customer's admin or automation consultant.

SprintHub campaign data including post histories and performance metrics export as available from the social module. We import available campaign records into Twenty as a custom Campaign object (created via Metadata API) or as Opportunities tagged with a campaign type, depending on whether the customer wants campaign attribution tied to deals or tracked separately. Attribution settings (UTM parameters, source tracking) require manual reconfiguration in the destination analytics stack.

SprintHub Owners map to Twenty WorkspaceMembers. We resolve owners by email match against the Twenty workspace's member list. Any SprintHub owner without a matching WorkspaceMember goes to a reconciliation queue. The customer must provision all relevant WorkspaceMembers in Twenty before record import begins because owner assignments on Deals and Contacts require an active WorkspaceMember reference to satisfy the foreign key.