Migrate from Lime Go to Mailchimp

Lime Go Contacts map directly to Mailchimp Members within a single consolidated Audience. Each Contact's email address becomes the Member email, first name and last name map to FNAME and LNAME merge fields, and phone numbers map to a custom PHONE merge field. We preserve the original Lime Go contact ID in a custom lime_contact_id__c merge field for reconciliation. Owner assignments from Lime Go map to a custom owner_tag__c tag rather than a user record because Mailchimp does not have a user management model. Any Lime Go contacts with no email address are held in a reconciliation queue for the customer to resolve before import.

Lime Go Customers store company-level data that does not have a standalone Mailchimp equivalent. We treat the Customer as organizational context attached to the Contact. The Customer name becomes the COMPANY merge field, Customer industry becomes a custom industry_tag, and Customer custom properties map to Mailchimp merge fields or Tags. If a Lime Go Contact has no linked Customer, we create the Member without a COMPANY merge field value. The Customer-Consumer relationship is resolved via lookup at import time to ensure the correct COMPANY value is attached to each Member.

Lime Go's built-in Nordic company database of 3.7 million businesses is read-only enrichment data, not user-owned CRM records. It does not migrate as Audience Members. We flag these records separately during scoping and document them as a retention consideration: if the customer relies on Lime Go's enrichment for prospecting, they should retain a Lime Go seat or a dedicated enrichment provider (Clearbit, ZoomInfo) post-migration. In Mailchimp, we configure enrichment via the Mailchimp Connect ecosystem or third-party enrichment tools as a post-migration step.

Lime Go Deals do not map to a native Mailchimp object. We translate Deals into Tags on the associated Member with the naming convention deal_[pipeline]_[stage] (e.g., deal_main_won). Deal value migrates as a custom deal_value__c merge field (numeric). Expected close date migrates as a custom close_date__c merge field. If a Contact is linked to multiple Deals, we create one tag per Deal. The customer chooses whether to apply deal-stage tags as marketing segmentation criteria during scoping. This translation preserves pipeline context but does not replicate Lime Go's pipeline management UI.

Each Lime Go Pipeline maps to a tag namespace that prefixes all deal-stage tags for that pipeline (e.g., main_, enterprise_, smb_). We document the pipeline-to-namespace mapping during scoping and apply it consistently across all Deal tag creation. If the customer has more than three pipelines, we recommend a Mailchimp Segment strategy using tag prefixes rather than a flat tag taxonomy to avoid tag count inflation.

Lime Go Activity records (calls, emails, meetings, notes) have no native Mailchimp equivalent in the Member timeline. We migrate the most recent 50 activities per Contact as a consolidated Note entry with the original timestamp, activity type, and body preserved in a single note record. Older activities migrate as a summary count in a custom activities_total__c merge field. This approach avoids flooding Mailchimp with thousands of granular activity records that would degrade audience performance without providing comparable timeline visibility to a CRM. The customer is advised that full activity history retention requires a separate CRM platform if needed post-migration.

Lime Go Tasks map to Notes on the associated Contact. Open tasks with due dates migrate as a note with a [TASK: pending] prefix and the due date. Completed tasks migrate with a [TASK: completed] prefix. Task ownership is noted within the note body. We consolidate multiple tasks from the same Contact into a single summary note to avoid creating dozens of individual note entries. The customer receives a task migration summary at the contact level rather than individual task records.

Lime Go custom fields on Customers and Contacts map to Mailchimp merge fields using type-aware translation: text fields become TEXT merge fields (subject to the 255-character limit and flagged for truncation during scoping), number fields become NUMBER merge fields, date fields become DATE merge fields, and picklist fields become either RADIO or dropdown merge fields. We validate each field against Mailchimp's 40-character merge field name limit and 255-character text length limit before creating the destination schema. Any Lime Go custom fields that exceed these constraints are flagged as a scoping item and mapped to Tags as an alternative.

Lime Go Tags apply across Customers, Contacts, and Deals and map directly to Mailchimp Tags on the Member record. We extract all unique tag names from Lime Go, normalize them (trim whitespace, lowercase), and create them as Mailchimp Tags during audience setup. Tags used for deal segmentation receive the deal_ prefix as described in the Deal mapping. Tags with fewer than 10 associated records in Lime Go are flagged as low-utility tags and may be excluded from migration to reduce Mailchimp tag noise.

Lime Go consent history migrates to Mailchimp as the EMAILINGS_CONSENT and MARKETING_CONSENT boolean merge fields (0/1). The original consent grant timestamp and withdrawal timestamp migrate as DATE merge fields consent_granted__c and consent_withdrawn__c. For Members without any consent record in Lime Go, we set consent status to 0 and recommend the customer sends a re-confirmation campaign through Mailchimp after migration to establish explicit opt-in for GDPR compliance. This is aligned with Mailchimp's own migration guidance on ensuring contacts have opted in before first send.