Migrate from Spiro to Mailchimp

Spiro Contacts migrate to Mailchimp Subscribers as the primary record. Email address is the dedupe key. First name, last name, phone, and title migrate to standard Mailchimp merge fields (FNAME, LNAME, PHONE, COMPANY). The original Spiro lifecycle stage migrates as a text merge field spiro_lifecycle_stage__c so the customer's admin can segment by original acquisition source in Mailchimp without rebuilding the classification logic.

Spiro custom Contact fields are extracted from Spiro's schema (confirmed via CSM or UI export) and recreated as Mailchimp Merge Fields before the subscriber import. Field types map as follows: text to Text merge field, number to Number merge field, date to Date merge field, dropdown to Dropdown merge field, checkbox to Radio merge field. Merge Fields must exist in Mailchimp before the CSV import runs or the data is dropped at import time.

Spiro Company records do not have a direct Mailchimp equivalent since Mailchimp has no Organizations object. We create a Mailchimp Tag for each unique Spiro Company name (normalized to lowercase with underscores) and apply those tags to all Subscribers who are associated with that Company in Spiro. The result is a subscriber segmented by Company that the customer's admin can use for segment-based campaigns. Company address and domain data is stored as a text merge field company_info__c.

Spiro Opportunities with deal value, stage, and close date have no Mailchimp equivalent. We extract the top 10 Opportunities by value as a written inventory with the Contact name, deal value, stage, and expected close date. This is handed to the customer's admin to recreate in a CRM or to annotate in Mailchimp as contact notes if no CRM replacement is implemented.

Spiro pipeline stages (for example: Prospecting, Qualification, Proposal, Negotiation, Closed Won, Closed Lost) map to Mailchimp Segments. Each stage becomes a saved segment based on the Spiro opportunity stage stored in a merge field. The customer uses these segments to send stage-appropriate email campaigns (for example: a proposal-sent nurture sequence). This is configuration, not data migration.

Spiro activity records (calls, emails, meetings, tasks) have no native representation in Mailchimp's contact record. We extract the most recent three activities per Contact as a text annotation stored in a merge field last_activity__c formatted as: date, type, summary. The full activity history is exported as a separate CSV file (contact_email, activity_type, activity_date, notes) for the customer's admin to reference or import into a separate CRM if one is adopted.

Spiro Users who own records are tagged on the corresponding Mailchimp Subscribers as a merge field owner__c. This preserves the sales-owner attribution from Spiro so the customer's admin can assign Mailchimp campaigns to the correct owner or build segments by owner territory. Owner tags do not imply Mailchimp seat access; they are data annotations only.

Spiro does not expose a per-contact email consent flag in its standard schema. We ask the customer to verify whether contacts have an explicit opt-in source documented in Spiro (for example: imported from a web form with consent, or added manually by a rep). Contacts with documented consent are imported as Subscribed; contacts without documented consent are imported as Cleaned or Unsubscribed in Mailchimp per Mailchimp's migration guidance. This step is critical because importing unconsented contacts into Mailchimp as Subscribed risks deliverability penalties.