Migrate from Brokerkit to Mailchimp

Every Brokerkit contact with a valid email address migrates to a Mailchimp subscriber. Email address is the primary key — if a Brokerkit contact has no email, it cannot become a Mailchimp subscriber and is surfaced as an exclusion in the migration report. The contact's full name, phone, and address fields map directly to Mailchimp's standard subscriber fields.

Mailchimp has no Company or Account object. Brokerkit company affiliations for each contact are preserved as a custom merge field (COMPANY or BROKERAGE) on the subscriber record. If multiple companies per contact exist, we tag each contact with company names and store the primary company as the merge field value. Company-level reporting requires Mailchimp segments filtered by the COMPANY merge field.

Brokerkit deal pipelines, stages, and amounts have no Mailchimp equivalent. We export deal data (pipeline name, stage, amount, close date) as a separate JSON reference file. The pipeline-to-email-marketing logic must be rebuilt in Mailchimp's automation builder using subscriber tags and merge-field conditions. Any deal-related follow-up sequences become manual automation rebuilds.

Brokerkit stores call logs, meeting notes, and task completions as activities tied to agent records. Mailchimp tracks email engagement (opens, clicks, unsubscribes) but has no native call or meeting log. We export activity history as a separate reference JSON. Email engagement data generated post-migration lives in Mailchimp's campaign reporting — it does not merge with pre-migration Brokerkit call logs.

Brokerkit custom properties on agents — such as recruitment_source, license_number, market_area, agent_status, and team_leader — map to Mailchimp merge fields (MERGE0–MERGE7 or named fields like SOURCE, LICENSE, MARKET). Field type (text, number, date) is matched to Mailchimp's supported merge field types. Each property requires a corresponding merge field to exist in the Mailchimp audience before data loads.

Brokerkit company-level custom properties (e.g., brokerage_brand, office_location, commission_split) are stored as merge fields on the primary contact subscriber or as tags on all contacts associated with that company. We map one-to-one where the property is single-valued; multi-valued properties become a tag per value applied to all associated subscribers.

If Brokerkit applies internal labels or tags to contacts (e.g., 'top_recruit', 'inactive_agent', 'new_hire'), those labels migrate as Mailchimp subscriber tags. Tags are preserved exactly as written — the tag name in Brokerkit becomes the tag name in Mailchimp. Tags apply to the subscriber record and can be used to build segments post-migration.

Brokerkit attachments on agent profiles or deal records (e.g., license PDFs, contract documents) cannot be stored in Mailchimp — Mailchimp has no attachment object. We export all attachments as a separate structured ZIP download keyed by Brokerkit contact ID. The team references the download post-migration to locate original documents associated with each subscriber.

Brokerkit agent status values (Active, Inactive, Onboarding, Released) map to Mailchimp subscriber tags. The mapping is value-by-value: each Brokerkit status string becomes a corresponding tag string in Mailchimp. Post-migration, agent lifecycle management requires updating tags manually or via Mailchimp's API as agent status changes in Brokerkit.

Brokerages with multiple offices must decide between one Mailchimp audience (using OFFICE tags for segmentation) or separate audiences per office. Single-audience with tags is simpler to migrate; multi-audience preserves independent list hygiene per office but requires managing contacts across audiences. We surface this decision point in the migration plan before data moves.