Migrate from Splio to Mailchimp

Splio Contacts map to Mailchimp Audience Members. A critical Splio behavior: contacts without list membership are silently excluded from standard exports. We run a list-membership audit before extraction, flag orphan contacts, and assign them to a catch-all segment before export. Email address is the primary key; we validate email syntax and reject malformed addresses during the import step per Mailchimp's import validation rules. Status (subscribed, unsubscribed, bounced) maps directly from Splio contact status. We preserve original subscription timestamps as merge fields if available.

Splio loyalty data (card_code, nq_points, q_points, tier, membership date) has no native Mailchimp equivalent. We map point balances and tier to Mailchimp merge fields (e.g., LOYALTY_TIER, POINTS_BALANCE, CARD_CODE). If Splio's program uses fractional point values, we store them as decimal-formatted strings. Mailchimp merge fields are capped at 255 characters; long-form loyalty notes exceed this and are truncated or stored as Contact notes instead. We document the customer's loyalty program structure during scoping so the admin can decide whether to rebuild loyalty logic in a third-party loyalty app post-migration.

Splio rewards (defined at the program level) and attributions (which contact received which reward) have no Mailchimp object equivalent. We export reward attribution history and append it to the contact record as a dated note or as structured merge fields if the volume is small. For high-volume loyalty programs, we recommend the customer rebuild the rewards logic in a dedicated loyalty platform (e.g., Smile.io, Yotpo) and integrate it with Mailchimp via Zapier or a native integration. We do not migrate rewards as functional data; we deliver a written rewards program inventory for the admin to use in rebuilding.

Splio Orders link to contacts and contain order items referencing products. Mailchimp has no native Order object; purchase history is tracked either through Mailchimp's e-commerce integration (Shopify, WooCommerce, BigCommerce, Magento) or as activity entries appended to the contact record. We export order data (order ID, order date, total, status) and map it to the customer's e-commerce platform if they have one, or store it as structured merge fields or contact notes if they do not. Splio's duplicate-order-ID replacement behavior (replacing existing orders on re-import) is noted; Mailchimp does not have this behavior and may create duplicate purchase records if order IDs collide.

Splio order items are tied to a parent order via a required link. Mailchimp does not store line items natively; if the customer uses a supported e-commerce platform, order items sync through Mailchimp's native e-commerce integration and appear as purchase activity on the contact. We export order items with the parent order reference and map product references to the destination e-commerce catalog. If no e-commerce integration exists, we document the order item structure for the customer to configure post-migration.

Splio Products are standalone items referenced by order items. With Mailchimp's e-commerce integration enabled, products appear in Mailchimp's product catalog and can be referenced in automation triggers. Without an e-commerce integration, we export product attributes and map them to structured notes on the contact or store them as reference data for the admin to build into a product lookup sheet. Mailchimp's product catalog does not support the same custom field scopes as Splio; we document the gap for the customer during scoping.

Splio Stores represent physical retail locations and e-commerce sites. Mailchimp has no native Store object. We map store data to Mailchimp Tags (e.g., TAG_STORE_PARIS, TAG_STORE_BERLIN) or Groups (Store Location) applied to contacts based on the customer's reporting needs. Store-level custom fields export as additional merge fields on the contact or as structured note content. We recommend a consistent tagging convention during scoping to preserve store-level segmentation for campaign targeting.

Splio Interactions are custom events sent via API to trigger loyalty point credits, in-store visit acknowledgments, and other real-time use cases. Mailchimp does not have a native event ingestion API for arbitrary interaction types. We export interaction event logs as dated notes on the contact record or as tagged events in Mailchimp's activity timeline if the event type fits Mailchimp's supported activity model. High-volume interaction data (e.g., daily foot traffic events) may exceed practical contact note limits and are documented as a gap for the customer to address with a separate event-tracking system.

Splio Lists drive contact segmentation and export eligibility. We preserve list memberships as Mailchimp Tags applied to contacts during import. Splio blocklists map directly to Mailchimp suppression lists, which we import before the contact migration to ensure bounced, unsubscribed, and cleaned contacts are honored at import time. Mailchimp requires suppression lists to be imported per audience; multi-audience Splio accounts require separate suppression list imports per audience.