Migrate from OneHash CRM to Mailchimp

OneHash Contact records map directly to Mailchimp Audience Members. We use the email address as the dedupe key (Mailchimp requires email uniqueness per Audience). Standard fields (first_name, last_name, phone, primary_address) map to Mailchimp merge fields FNAME, LNAME, PHONE, and ADDRESS. Organization linkage from OneHash's Contact-to-Customer relationship is stored as the merge field COMPANY. Any Contact-level custom fields discovered in the DocType schema map to additional merge fields (up to Mailchimp's 40-merge-field limit per audience). Opt-in status for email marketing is derived from the Contact's unsubscribe flag or a dedicated email_consent field if present in the DocType.

OneHash Lead records migrate to Mailchimp Members with a Lead-specific tag (e.g., 'source:lead') applied for segmentation. If the Lead has been converted to a Contact in OneHash, we skip the duplicate by email match; if not yet converted, we import the Lead as a Member and tag it with the lead source field value (e.g., 'source:website', 'source:referral'). Status fields (status, lead_stage) migrate as Tags for filtering in Mailchimp Segments. Migrations with large Lead volumes may choose to create a separate Audience for Leads versus Customers to keep audience sizes manageable on Free or Essentials plans.

OneHash Customer records (organization-level) are not a separate object in Mailchimp. The organization name, billing address, and shipping address from the Customer DocType are merged into the corresponding Contact record's merge fields (COMPANY, ADDRESS). If a Contact has no linked Contact record in OneHash but has a Customer record, we create the Mailchimp Member using the Customer's primary email (from its contact_person link) and populate company fields from the Customer DocType. This requires a pre-migration join across the DocType linkage table to avoid orphaned Members.

OneHash Opportunities have no direct Mailchimp equivalent. Deal stage, amount, probability, and expected close date do not map to any Mailchimp object. We document the Opportunity records in a migration inventory CSV that the customer retains for reference. If the customer requires deal context in Mailchimp, we can store Opportunity amount as a merge field and stage as a Tag, but this is advisory only and does not constitute a functional pipeline in Mailchimp. Pipeline stage configurations are documented for the customer's admin to rebuild in any third-party CRM if needed.

OneHash Quotations (with line items, tax templates, and terms) have no Mailchimp equivalent. We do not migrate Quotation records. During scoping we confirm whether the customer needs a written Quotation inventory (record count, total value, date range, associated Contact) for compliance or reference purposes; if so, we deliver this as a CSV alongside the migration rather than as a Mailchimp-imported artifact.

OneHash DocType custom fields are discovered via pre-migration schema introspection of the Contact and Lead DocTypes. Each custom field's data type is mapped to the closest Mailchimp field type: text fields become Merge Fields of type text, multi-select fields become Groups, and date fields become Merge Fields of type date. We respect Mailchimp's 40-merge-field limit per Audience; if the migration exceeds this, we prioritize business-critical fields and document remaining fields in a custom-field inventory CSV. Custom fields on other DocTypes (Opportunity, Quotation) are not migrated because those objects have no Mailchimp equivalent.

Documents attached to Contact or Lead records in OneHash (such as PDFs, contracts, or images) have no equivalent storage in Mailchimp's contact record. We document the attachment count and linkage in the migration inventory. If the customer needs these files accessible post-migration, we recommend a separate document migration to a cloud storage solution (Google Drive, SharePoint, Dropbox) with the OneHash record ID cross-referenced in the filename.

If OneHash uses any tagging or labeling system on Contacts or Leads for internal segmentation, these values migrate as Mailchimp Tags. Tags are applied at import time via the Mailchimp Tags API. Groups (Mailchimp's subscriber-grouping feature) are an alternative for multi-select classification; we recommend Groups for taxonomy that changes infrequently (e.g., industry, region) and Tags for dynamic labels (e.g., campaign source, lifecycle stage).