Migrate from Evam to Mailchimp

Evam Customer records map to Mailchimp Contacts with a subset of fields mapped to standard Mailchimp merge fields (FNAME, LNAME, EMAIL, PHONE, ADDRESS). Custom properties on Evam Customers are flagged for field-level assessment against Mailchimp's 30-field limit on standard plans or 80-field limit on Premium. Any custom property exceeding the limit or with an unsupported data type is held in a supplemental CSV or flagged for re-creation as a note field.

Evam Segments define customer groupings via rule sets (behavioral conditions, demographic filters, journey-stage membership). Mailchimp does not replicate segment definitions from Evam directly; instead, we document the segment membership criteria (rules, conditions, filter logic) as a written specification so the customer's admin can rebuild segments in Mailchimp using Tags, Groups, or the segment builder. The segment-to-tag migration is a configuration handoff, not an automated transfer.

Evam Campaign metadata (name, status, date range, channel assignments) migrates to Mailchimp Campaign records. Campaign performance metrics (open rates, click rates, conversion attribution) are derived post-migration from Mailchimp's native reporting. Campaign content (email templates, creative assets) does not migrate automatically; we document the template structure from Evam and provide a design reference for rebuild in Mailchimp's template editor.

Evam Events (behavioral and transactional touchpoints) are numerous — billions per day at enterprise scale — and have no direct Mailchimp equivalent. We scope event export to a defined time window (typically the last 90-180 days) and represent significant events as Mailchimp Tags on the Contact record (e.g., tag 'purchased_item_2025Q4' for a transaction event). We do not attempt to export the full event stream; we preserve a representative sample for journey reconstruction documentation. Event payload schemas are captured in the migration artifact for the admin to use when rebuilding automations.

SMS sender IDs, push notification credentials, and in-app notification configurations are bound to Evam's registered application environment and cannot be transferred to Mailchimp. We document the full channel configuration during discovery (provider, credentials, sender ID, template IDs) and provide a re-setup checklist so the customer's operations team can re-register credentials in Mailchimp SMS or a third-party SMS provider before cutover. Mailchimp's native SMS requires the Mailchimp SMS add-on; push notifications require a separate third-party integration.

Evam's AI-based propensity scores are computed in Evam's runtime environment and are not accessible via a documented export endpoint. We cannot migrate these scores. Customers relying on AI-driven routing in Evam journeys should plan to re-run scoring in the destination platform post-migration, use Mailchimp's Predictive Sending feature (Premium tier) as a partial replacement, or accept a scoring-free reset on day one.

Evam Journey definitions encode step sequences, branch conditions, wait timers, and entry/exit rules. These are not exposed via a documented export endpoint. We use API snapshots and manual documentation during discovery to capture journey topology as a written specification with step-by-step logic, trigger conditions, and channel assignments. The customer's admin uses this specification to rebuild journeys as Mailchimp Automation Flows post-migration. We do not reverse-engineer journey logic from event data alone.

Evam custom fields on Customers or Events beyond the standard schema are assessed against Mailchimp's merge field limits (30 standard, 80 Premium). Standard-type fields (text, number, date, phone) map directly to Mailchimp merge fields. Complex data types or arrays are flagged and either stored as comma-separated text in a merge field or converted to Tags on the Contact record. The customer chooses the strategy during scoping.