Migrate from Mobile Service App to Mailchimp

Mobile Service App contacts map directly to Mailchimp contacts within the primary audience. Email address is the unique identifier — contacts without email addresses are flagged for manual review before migration since Mailchimp requires an email for subscription. Primary company association migrates as a merge field (COMPANY_NAME) rather than a relationship.

Mobile Service App company records merge into contact records as a set of company-related merge fields (COMPANY_NAME, COMPANY_DOMAIN, COMPANY_INDUSTRY, COMPANY_ADDRESS). Mailchimp does not have a native Company object — parent-child company hierarchies collapse to the primary company name stored on the contact record.

Mailchimp has no native work-order or job object. Jobs migrate as structured notes attached to the contact record and custom merge fields capturing the most recent job date, job type, and job status. Historical job counts may be stored as a merge field (JOB_COUNT). Scheduling and technician assignment data has no Mailchimp equivalent.

Estimates store proposal amounts and status (Pending, Accepted, Declined). These migrate as custom merge fields (ESTIMATE_AMOUNT, ESTIMATE_STATUS) on the contact record. Mailchimp cannot generate or manage proposals — the data serves as reference history only. Estimate metadata enables segmentation by proposal stage (e.g., contacts with pending estimates) but does not provide Mailchimp with proposal creation or management capabilities.

Invoice records (amount, status, paid date) migrate as merge fields (LAST_INVOICE_AMOUNT, LAST_INVOICE_STATUS, LAST_PAYMENT_DATE). Mailchimp's invoicing capabilities are minimal — these fields support segmentation (e.g., 'has unpaid invoice') but not payment processing. Invoice data on the contact record enables personalized email content referencing account balance and overdue status without triggering actual payment collection through Mailchimp.

Each Mobile Service App custom field on Contact creates a corresponding Mailchimp merge field in the audience. Merge field types must match: text fields to text, date fields to date, number fields to number, dropdowns to radio-button merge fields. Phone-type fields use Mailchimp's phone merge field type for SMS-opt-in compatibility.

Mobile Service App owner IDs resolve by email to Mailchimp subscriber records. The owner assignment itself cannot migrate — Mailchimp contacts have no owner field. Owner information that matters for segmentation (e.g., 'assigned technician') creates a merge field (ASSIGNED_TECHNICIAN) instead.

Mobile Service App segment memberships and tags map to Mailchimp tags on the contact record. Tags are preserved exactly as they appear in the source — tag names with special characters are normalized to Mailchimp's tag format (alphanumeric with hyphens). Multiple tags per contact are supported natively in Mailchimp.

Mailchimp's native subscriber timestamp records when a contact was added to Mailchimp, not when they became a customer in Mobile Service App. Original create dates from the source system are stored as a custom merge field (ORIGINAL_CREATE_DATE) for segmentation and reporting continuity.

Mobile Service App consent flags map to Mailchimp member statuses: active consent → Subscribed, explicit unsubscribe → Unsubscribed, bounced or invalid → Cleaned. GDPR consent sources (form, API, POS) are stored as merge field (OPT_IN_SOURCE) for compliance documentation. This mapping ensures your Mailchimp audience reflects each contact's current communication preferences and maintains an audit trail of how and when consent was obtained.