Migrate from NEON-dX to Mailchimp

NEON-dX customer profiles compose demographic fields (name, email, phone, address), behavioral signals (open rate history, channel engagement), and digital footprint data. We map standard profile fields (email, first name, last name, phone, address) to Mailchimp audience member standard fields. Any behavioral attributes stored as structured fields in NEON-dX migrate to Mailchimp merge fields (FNAME, LNAME, PHONE, and custom MERGE fields). NEON-dX's digital footprint fields (web activity, channel-level engagement counts) may exceed Mailchimp's 255-character merge field limit for text fields; we flag these for tag-based storage or segmentation on the destination. Fields populated by NEON-dX's AI pipeline (churn scores, LTV predictions) are flagged as non-migratable and preserved in a customer-provided reference export for manual scoring rebuild.

NEON-dX behavioral segments are defined by rule criteria evaluated against customer event streams. We transfer the segment definition rules as written documentation (rule logic, criteria operators, event triggers) for the customer's admin to recreate in Mailchimp's Segment builder using Mailchimp's condition syntax (Subscriber Email contains, Merge Field equals, Activity in last X days, Tag is or is not). Segment membership is not static in NEON-dX and re-evaluates on the destination based on Mailchimp's event and engagement data. We do not attempt to export membership as a static list because Mailchimp segments are defined by criteria, not by enumerated member lists. The customer should expect different segment counts immediately post-migration as Mailchimp recalculates membership.

NEON-dX campaigns and their associated offer content migrate to Mailchimp Campaigns. We transfer campaign name, subject line, from name, reply-to address, and content blocks. HTML email body content migrates as Mailchimp template sections or drag-and-drop content blocks depending on whether the original NEON-dX campaign used structured templates or free-form HTML. Rich media assets (images, embedded video) require separate file transfer to Mailchimp's content studio. Channel-specific offer formats (SMS offer codes, push notification bodies) cannot migrate to Mailchimp's email-centric campaign model and are documented separately for the customer's channel team to re-create.

NEON-dX customer journeys are multi-step orchestration flows with branching logic, wait conditions, time delays, and channel assignments across email, SMS, push, and digital channels. Mailchimp's Customer Journey Builder supports trigger-based automations (welcome series, abandoned cart, birthday, date-based, API-triggered) but does not replicate NEON-dX's full omnichannel journey canvas. We document the complete journey structure including all steps, branching conditions, wait durations, and channel assignments in a written handoff document. The customer's Mailchimp admin rebuilds each journey in Mailchimp's automation builder using the documented logic. We do not migrate journey logic as executable code.

NEON-dX generates churn propensity, LTV, and propensity-to-buy scores using its proprietary ML pipeline and live training data. These are computed dynamically and are tightly coupled to NEON-dX's feature engineering environment. They cannot be meaningfully transferred as static values because they become stale immediately upon export and have no destination equivalent in Mailchimp's flat contact model. We do not migrate predictive scores. Instead, we preserve the model configuration documentation (feature inputs, scoring logic, refresh cadence) and recommend the customer rebuild scoring in their analytics layer post-migration. Customers should expect a scoring re-warming period after migration.

NEON-dX custom objects with standard, formula, and lookup field types are enumerated via API at migration time. Standard fields map to Mailchimp custom merge fields (MERGE1 through MERGE8, plus additional custom fields on Standard and Premium plans). Formula fields are computed fields and have no direct Mailchimp equivalent; we migrate the formula result as a static value at migration time, flagging it for the customer to decide whether to re-implement the formula in a connected BI tool. Lookup fields reference other NEON-dX objects; we resolve these to the nearest available Mailchimp merge field or tag. The dependency graph for formula fields with multiple upstream lookups is built during schema discovery before import sequencing begins.

SMS gateway credentials, email sending IPs, push notification keys, and channel API tokens are stored with environment-specific scoping in NEON-dX and cannot be exported as-is. We document all channel configuration schemas (provider name, key type, format) during the discovery phase and produce a re-authentication checklist for each channel type. For email sending specifically, the customer provisions their own Mailchimp-authenticated sending domain via Mailchimp's Domain Verification (SPF and DKIM records) before audience import begins. Without valid credentials, journey automation will fail silently in the destination environment.

NEON-dX pre-built dashboards and custom reports reference platform-native metric definitions (churn rate, LTV, engagement score) that do not map directly to Mailchimp's reporting schema. We document the structure and column configurations of custom reports as a written handoff for the customer's admin to rebuild in Mailchimp's Reports section (Campaign Reports, Audience Reports, E-commerce Reports). Destination metric data populates post-migration as Mailchimp collects new engagement data. Historical NEON-dX dashboard metrics are not transferable because they depend on the source platform's ML-computed values.