Migrate from Brokerkit to Twenty CRM

Brokerkit agents map to Twenty's People object. Name, email, and phone migrate directly. Brokerkit's agent-status field (e.g., active, inactive, prospect) becomes a custom select field in Twenty — created in Settings → Data Model before the import batch runs so the field exists at load time.

Brokerkit brokerage companies map to Twenty's Companies object. Name, domain, address, and industry fields migrate directly. Brokerkit allows multiple contacts per company (N:1); Twenty enforces a primary CompanyId on People — the most-recently-modified contact's company is set as primary; additional associations surface as Company Relations if needed.

Brokerkit recruiting deals map to Twenty's Opportunities object. Deal name, amount, stage, close date, and owner migrate directly. Brokerkit's recruiting pipeline stages (e.g., Contacted, Interviewing, Offer Extended) map to Opportunity Stage pick-list values — these must be defined in Twenty's Settings → Data Model as select options before the import batch references them.

Brokerkit pipelines become sets of Stage pick-list values on the Opportunity object. Each Brokerkit pipeline maps to a distinct Stage option group in Twenty — not a separate object. If Brokerkit uses multiple pipelines (e.g., Agent Recruiting vs. Retention), these can be modeled as separate Opportunity records with a Pipeline__c custom select field in Twenty.

Brokerkit activity records (calls, emails, meetings, notes) map to Twenty's Tasks and Notes objects. Original timestamps and activity owners (resolved by email match against Twenty workspace members) are preserved. Tasks inherit the linked People or Opportunity record via the targetId field.

Brokerkit owner assignments resolve by email match against Twenty workspace members. All team members who appear as owners must accept their Twenty invitation before migration so their email is registered — otherwise records land assigned to a fallback owner or an unassigned state.

Brokerkit tags applied to agents are mapped to a custom multi-select or single-select field on the People object. We create a Tags__c custom field in Twenty's Settings → Data Model and configure each Brokerkit tag value as a corresponding select option. This preserves the full tag taxonomy from Brokerkit within Twenty's structured data model.

Brokerkit tracks how agents entered the funnel (referral, job board, inbound). This field has no native equivalent in Twenty's People object — we create a Source__c custom select field in Twenty's data model and map each Brokerkit source value one-to-one.

Brokerkit drip sequences, automated SMS campaigns, and recruiting alerts are workflow constructs with no data-layer equivalent. These do not migrate. We export Brokerkit's sequence configuration (step order, delay days, message templates) as a structured JSON reference for your Twenty admin to rebuild using Twenty's Workflows module.

Any Brokerkit custom objects (e.g., licensing records tied to agents, cohort groups for training batches) map 1:1 to Twenty custom objects. Custom object creation is done in Twenty's Settings → Data Model before import. N:N relationships between custom objects use Twenty's Relation field type.

Files attached to Brokerkit records (e.g., agent resumes, offer letters, licensing documents) are re-uploaded to Twenty as Note attachments on the corresponding People, Company, or Opportunity record. Inline images embedded in Brokerkit note bodies are extracted, downloaded, and re-hosted as Note attachments in Twenty. File size limits in Twenty's current release apply and are flagged in the pre-flight report.

Brokerkit internal record IDs are preserved as a Source_System_ID__c custom field on each Twenty object for traceability and delta-run de-duplication. Original create dates are preserved as Created_At__c custom datetime fields on each record since Twenty's native CreatedDate timestamp reflects migration execution time rather than the source record's original creation date.