Migrate from Evatic to Mailchimp

Evatic Customer maps directly to a Mailchimp Contact. Email address is the unique key — contacts with duplicate emails across Evatic records are flagged for resolution before migration. First name, last name, phone, and company map to Mailchimp's native contact fields.

Email is the primary identifier in Mailchimp and the deduplication key for migration. If Evatic stores multiple email addresses per customer, the primary email maps to the contact and secondary addresses surface as a custom merge field for reference. This approach ensures each contact remains unique and traceable across the Audience.

Evatic custom fields on Customer records (e.g., service_tier, contract_type, region) map to Mailchimp merge fields. We create merge fields matching the Evatic field type — text, date, number, or dropdown. Mailchimp allows up to 80 merge fields per Audience, and we prioritize the most relevant fields to stay within that limit.

Evatic contracts do not map to a native Mailchimp object. Each active contract generates a tag on the linked customer contact (e.g., 'Contract-Type: Preventive-Maintenance', 'Contract-Status: Active'). Contract end date migrates as a date merge field for renewal-triggered segmentation, and the nearest future end date is stored in the CONTRACTEND field.

Service tickets are represented as tags on the contact record (e.g., 'Ticket-Open-HVAC', 'Ticket-Closed-2024Q4'). Ticket status, priority, and category map to separate tag prefixes so Mailchimp segments can filter by ticket state. The full ticket body is not preserved in Mailchimp — raw ticket data is exported as a JSON reference file.

Equipment and asset records attached to a customer become tags on the contact (e.g., 'Asset-Type: Generator', 'Asset-Model: XYZ-5000'). Asset serial number and install date migrate as merge fields if they exist on the Evatic record. When multiple assets are present, each asset contributes its own set of tags and the serial numbers are concatenated in the merge field for completeness.

Evatic's Company or Organization object maps to the COMPANY merge field on the Mailchimp contact. If the customer is an individual without a company, the field is left blank. Mailchimp does not have a separate Company object — company-level data lives as a field on the contact.

Evatic technician and employee records have no Mailchimp equivalent. Internal service staff are not email‑marketing contacts, and Mailchimp's platform is designed for external audience engagement rather than internal workforce management. Consequently, we do not migrate technician objects — only customer‑facing contact records are imported into Mailchimp to preserve a clean marketing‑focused audience.

Evatic customer address fields (street, city, state/province, postal code, country) map to Mailchimp's built‑in address merge fields (ADDR, CITY, STATE, ZIP, COUNTRY). Structured address components enable Mailchimp's geolocation segmentation, allowing you to target contacts by region or run location‑based campaign triggers without additional data processing.

Evatic's own tag or label taxonomy maps directly to Mailchimp Tags. Tags are additive — a contact can carry multiple tags from Evatic. We preserve the original tag names and apply them at the contact level during migration. Duplicate tag names from different Evatic object types are prefixed (e.g., 'Contract:', 'Ticket:', 'Asset:').

Evatic's marketing‑consent flag maps to Mailchimp contact status: subscribed contacts enter as 'subscribed', opted‑out contacts enter as 'unsubscribed' (preserving suppression), and pending‑confirmation contacts enter as 'pending' to trigger double opt‑in. This mapping ensures GDPR and CAN‑SPAM compliance at cutover, protecting your sender reputation and legal standing.