Migrate from Vortex Field Software to Mailchimp

Vortex Contact records map directly to Mailchimp audience members. Email address is the required key field — contacts without a valid email address are excluded from the Mailchimp audience and flagged in the migration report. First name, last name, phone, and address fields map to Mailchimp merge fields (FNAME, LNAME, PHONE, ADDRESS).

Vortex company or account name stored on a contact maps to a custom Mailchimp merge field (COMPANYNAME). Mailchimp has no separate Account object — the company name lives as a property on the audience member record. Multiple Vortex contacts sharing the same company map to separate audience members, each tagged with the same company merge-field value.

Vortex service-site or location data maps to a custom merge field (SITEADDRESS) on the audience member and optionally as a Mailchimp tag (site: {location_name}) for segment filtering. Sites tied to multiple contacts are tagged on each contact record independently since Mailchimp has no N:N relationship model.

Vortex work orders (job type, status, date, technician assigned) have no structural equivalent in Mailchimp. We map work order status as a tag on the contact record (e.g., wo: completed, wo: scheduled, wo: urgent) and store the last work order ID in a custom merge field. Full work order history requires a separate FSM rebuild in a destination tool.

Vortex service-history records (date of visit, service type, technician notes) are translated to tags on the contact — one tag per service event (e.g., svc: hvac-repair-2024, svc: preventive-maintenance-2023). We preserve the service type and year as a structured tag format. Detailed notes are stored as a custom merge field (SERVICENOTES) truncated to Mailchimp's 255-character limit.

Vortex asset records (equipment type, serial number, install date) tied to a contact are mapped as tags (asset: {type}) and a custom merge field (ASSETID). Multiple assets per contact generate multiple tags. Mailchimp has no asset-management object, so this data is reference-only after migration.

Vortex contract or license records tied to a customer site are translated to tags (contract: active, contract: expired) and a contract-end-date custom merge field. Contract terms and pricing tiers are stored as custom merge fields — they do not drive Mailchimp behavior natively.

Vortex technician and staff records have no Mailchimp equivalent. If a technician is also a customer contact (e.g., they receive service reminders), they migrate as an audience member with their technician role stored as a tag (role: technician). Vortex scheduling and dispatch data is not migratable.

Vortex quotes and estimates (line items, pricing, status) have no Mailchimp counterpart. We do not migrate quotes — they are excluded from the contact-focused audience export and flagged in the migration report for manual handling or FSM-system export. Quote data requires a separate export from Vortex and should be managed in a quoting or ERP system post-migration.

Vortex inventory and parts-tracking records map to no Mailchimp object. Inventory data is excluded from the Mailchimp migration. Teams needing this data must maintain it in a dedicated inventory or ERP system after the migration. The Mailchimp audience record is designed for contact and campaign data, not product or stock information.

Vortex work order photos, electronic signatures, and parts-list attachments have no Mailchimp storage target. We export a manifest of attachment IDs and URLs from Vortex as a custom merge field (ATTACHMENTIDS) so the team can cross-reference original files if needed. No file content migrates.

Vortex payment records and invoice history are excluded from the Mailchimp audience migration. These require a separate financial-system export or manual reconciliation. Mailchimp's audience model has no concept of invoice status or payment terms. Financial records should remain in your accounting or billing system and can be referenced separately from the contact record.