Migrate from VBOUT to Mailchimp

VBOUT Contacts map to Mailchimp Members within a target Audience. Standard fields (email, first name, last name, phone) map directly to Mailchimp email_address, FNAME, LNAME, and PHONE merge fields. We resolve duplicates using email as the dedupe key. Custom fields from VBOUT with text values under 255 characters map to Mailchimp Merge Fields by API field name; fields exceeding 255 characters require truncation or splitting across multiple merge fields, which we flag during scoping.

VBOUT Smart Audiences are dynamic segmented lists built on behavioral and demographic filter rules. The segmentation rules themselves are proprietary and do not export directly. We export the current snapshot of audience membership (which contacts belong to which Smart Audience at migration time) and apply those contacts as static Tags in Mailchimp (e.g., Tag: 'Smart Audience - High-Value Prospects'). Segments in Mailchimp are rebuilt as static or dynamic segments using Mailchimp's segment builder based on the customer's segmentation logic documented during discovery.

VBOUT Tags export as a flat list per Contact and re-apply directly to Mailchimp Members as Tags. Tags carrying pipeline stage or lead status context (e.g., 'Stage - Sales Qualified', 'Source - Webinar') are preserved verbatim. Mailchimp supports unlimited Tags per Member, matching VBOUT's tagging model. We batch Tag application during migration to avoid rate-limit pressure on the Mailchimp Members API.

VBOUT custom fields map to Mailchimp Merge Fields with type mapping: text fields map to Mailchimp text merge fields, number fields map to number merge fields, date fields map to date merge fields. Dropdown and conditional field types from VBOUT may require mapping to Mailchimp radio or dropdown merge field types if the value set is small; large conditional fields are flattened to text. All merge field names are derived from the VBOUT field label with spaces removed and characters sanitized to Mailchimp's API naming convention.

VBOUT Lead Scores migrate as a Mailchimp number merge field (e.g., LEADSCORE). The raw numeric value transfers directly. We do not replicate VBOUT's lead scoring algorithm in Mailchimp because Mailchimp does not have a native behavioral lead scoring engine; if predictive scoring is needed, the customer should evaluate Mailchimp's paid AI features or a third-party scoring integration post-migration.

VBOUT sent campaign history exports as a structured CSV with subject line, send date, open rate, click rate, and bounce data. We import campaign metadata into a Mailchimp-compatible audit log rather than as native Mailchimp campaigns (Mailchimp campaigns are created at send time and are not back-populated). Template bodies from VBOUT exports are HTML fragments that must be manually rebuilt in Mailchimp's template editor or copied into a Mailchimp template; visual layouts do not transfer automatically.

VBOUT automation workflows store in a proprietary JSON schema incompatible with Mailchimp Customer Journeys. We do not migrate automation logic as code. We export each workflow definition as a structured JSON artifact and produce a written rebuild guide mapped to Mailchimp's Customer Journey builder, documenting trigger conditions, delay durations, action types, and filter branches for the customer's admin to replicate. Multi-step nurture sequences require manual reconstruction in Mailchimp.

VBOUT landing pages store as platform-specific page definitions with drag-and-drop layouts and dynamic content rules. We export page metadata, form field configurations, and redirect rules. The visual page layout cannot be transferred. Mailchimp's landing page builder supports basic templates; complex VBOUT pages with dynamic content, conditional displays, or custom code require rebuild in Mailchimp or a third-party landing page tool.

VBOUT forms (standard, multi-step, conditional, payment) export with field definitions and conditional logic preserved as structured data. We map field labels and types to Mailchimp's embedded form or landing page form fields. Payment form transaction records export with metadata; actual payment processing configuration does not transfer and must be reconnected to the customer's payment processor post-migration.