Migrate from Dynamics 365 Field Service to Mailchimp

Dynamics contacts map to Mailchimp audience members one-to-one. Each contact with an email address creates one audience member, and its status (active, inactive) determines the initial Mailchimp subscription state. Contacts lacking an email address are flagged and excluded unless you specify an alternate email field. Duplicate email addresses are detected during export, and you can select a rule such as keep most recent or keep first before import.

Dynamics Account names become Mailchimp tags (e.g., tag = Account Name) or a custom merge field (ACCOUNTNAME) for segmentation. We apply tags by default because Mailchimp segments run faster on tags than on merge field values. During migration, each unique Account name generates a tag that is attached to all related contacts, and if you prefer a merge field, we can create ACCOUNTNAME as a custom field instead.

Dynamics contact type (customer, supplier, competitor) has no default Mailchimp merge field. We create a CONTACT_TYPE merge field in your Mailchimp audience and map the value directly, preserving the pick-list label. If a contact carries an unrecognized type value, we store it as-is so you can decide later whether to create additional tags or segmentation rules based on that data.

Dynamics address components merge into Mailchimp's structured address merge fields. If Dynamics stores a single address string instead of components, we parse it before loading so Mailchimp's geolocation features activate on the audience. The parser splits the string into city, state, zip, and country based on common delimiters and country patterns, and any unrecognizable portion is placed in the address line field to preserve as much detail as possible.

Dynamics telephone1 maps directly to Mailchimp PHONE merge field. Mobile numbers stored in telephone2 map to PHONE2 merge field if your Mailchimp plan supports it, otherwise they merge into a custom PHONE2__c field. Phone numbers are normalized to E.164 format during export, and duplicate phone entries are flagged so you can decide which record should keep the number.

Dynamics birthdate field maps to Mailchimp's BIRTHDAY merge field. Mailchimp requires MM/DD format; we transform the source date format during the export so birthday automations trigger correctly. If a contact lacks a birthdate, the field stays blank, and we preserve the original year even when the day or month is unknown to avoid losing age context.

Dynamics owner references (Bookable Resources, system users) have no Mailchimp equivalent. We surface owner email as a read-only merge field (ORIGINAL_OWNER) for reference but Mailchimp does not use it for routing or permissions. You can leverage ORIGINAL_OWNER in Mailchimp reports to see which owner created each contact, and you may tag contacts by owner name for internal tracking if your team prefers to use tags instead of the merge field.

Mailchimp sets member_since date at import time. Original Dynamics createdon date is preserved as ORIGINAL_CREATE_DATE so you can report on contact age without relying on Mailchimp's auto-set timestamp. You can use ORIGINAL_CREATE_DATE in Mailchimp segmentation to target contacts by tenure, such as “new contacts in the last 30 days” or “contacts older than one year.” If you run later imports, each retains the original createdon from Dynamics to maintain continuity.

Dynamics active contacts map to Mailchimp subscribed status. Inactive or archived contacts map to unsubscribed. Contacts flagged as do-not-email in Dynamics map to Mailchimp cleaned status to prevent bounce-risk re-engagement. You can customize these mappings during planning; for instance, contacts with a specific status reason can be set to pending instead of subscribed, enabling a re-confirmation flow. Contacts without a defined status default to subscribed unless you choose another rule.

Work orders, service tasks, and booking references have no Mailchimp counterpart. These records remain in Dynamics 365 Field Service and are not migrated. If you need to segment by service history, we can export work order summaries as tags on the contact record instead.

Field service technicians and dispatch resources exist only in Dynamics. Mailchimp does not have a resource or scheduling model. Technician contacts who are email recipients migrate as audience members — their work-order history is not carried forward. To identify these contacts in Mailchimp, we can apply a “FieldTech” tag to each contact whose owner is a Bookable Resource, allowing you to segment or exclude them from campaigns if needed.

Dynamics custom attributes attached to Contact via N:1 relationships migrate as custom merge fields in Mailchimp. Fields exceeding 255 characters are truncated with a marker. N:N custom relationship records require flattening into comma-separated values for a single merge field slot.