Migrate from Comarch Field Service Management to Mailchimp

Comarch customer contacts (individuals with names and email addresses) map directly to Mailchimp audience members. The email address serves as the unique identifier in Mailchimp's system. Each contact from Comarch lands as one subscriber row in the target audience, preserving the email address, first name, and last name as the core identifier fields.

Comarch company records map to a COMPANY merge field on each Mailchimp contact. This is a denormalized string field — the company name is attached directly to the contact record rather than stored as a related object. Contacts without a company receive an empty COMPANY field.

Work orders, service requests, and service history records have no Mailchimp equivalent — Mailchimp has no object model for work orders, service tickets, or job records. We export work order reference data as a separate CSV for your records. If you want work order context preserved on the contact, we can create custom merge fields (e.g., last_service_date) and tag contacts based on recent service activity.

Technician records (names, skills, certifications, availability) have no Mailchimp equivalent — Mailchimp is a customer-contact platform, not an employee management system. Technician data is exported as a reference file. If you need to tag contacts by assigned technician, we create a TECHNICIAN_TAG custom merge field populated from Comarch.

Comarch asset records (equipment IDs, maintenance schedules, location, status) have no Mailchimp equivalent. Asset-to-customer linkage (which customer owns which equipment) can be preserved as tags on the customer contact — for example, TAG: Asset-ID-12345 or TAG: Equipment-Maintenance-Contract — enabling segmented campaigns based on asset ownership.

Parts inventory and stock records have no Mailchimp equivalent. We export inventory reference data separately. Inventory-linked customer data (e.g., parts on subscription or service contracts) can be surfaced as tags or merge fields on the customer contact if Comarch exposes that relationship.

Invoice and billing records in Comarch do not map to Mailchimp. However, if Comarch stores account status (Active, Suspended, Trial) or customer tier information, those values can migrate as tags or a STATUS merge field for segmentation and re-engagement campaigns.

Comarch custom fields attached to customer records map to Mailchimp merge fields. Mailchimp allows up to 40 merge fields per audience with specific naming rules (all uppercase, no spaces, alphanumeric). We create merge fields in Mailchimp before import and map each Comarch custom field. Text, date, and number fields translate directly; pick-list values require value-mapping if the allowed values differ.

Comarch contact categories or customer type classifications map to Mailchimp tags applied per contact. Tags are flat strings — we normalize the source values and apply them as individual tags. Contacts can receive multiple tags. Tags enable segmentation for targeted campaigns.

Comarch customer address fields map to Mailchimp's pre-defined ADDRESS merge field group. This group contains ADDR1, ADDR2, CITY, STATE, ZIP, and COUNTRY sub-fields. All contacts must have a country value for Mailchimp compliance requirements — we flag records missing country during validation.

Comarch's internal record identifiers are preserved as a SOURCE_SYSTEM_ID merge field on each Mailchimp contact. This enables full traceability back to the source system, supports delta-run de-duplication processes, and allows records to be re-imported or reconciled accurately if needed during future sync operations.

Comarch create and last-modified timestamps on customer records can be preserved as custom date merge fields (e.g., COMARCH_CREATED_DATE, COMARCH_MODIFIED_DATE). Mailchimp stores a system-level Created At timestamp but does not expose it in merge fields — original timestamps are preserved via custom fields for reporting continuity.