Migrate from ELMA365 to Mailchimp

Contacts stored in ELMA365 custom applications map directly to Mailchimp Audience Members. The primary email address field becomes the subscriber email. First name, last name, and any structured properties map to Mailchimp merge fields. We extract the custom application schema during discovery, reverse-engineering field names and types from ELMA365's configuration export, and create corresponding merge field definitions in Mailchimp before import. Subscriber status defaults to subscribed on import unless the customer's ELMA365 instance tracked an explicit unsubscribed flag that must be preserved.

Company or organization names stored in ELMA365 custom applications typically map to Mailchimp merge fields (COMPANY type) attached to the Audience Member. If company data is stored in a separate custom application with a one-to-many relationship to contacts (one company, many contacts), we flatten during import by writing the company name into each contact record's merge field. Tags are an alternative mapping strategy if the customer prefers to segment by company via Mailchimp Tags rather than a merge field filter.

ELMA365 Users and Employees stored in the directory are not marketing recipients and do not map directly to Mailchimp Audience Members. However, if the migration scope includes notifying ELMA365 users of the transition, we can generate a contact list from the user directory with an opt-in status of not-subscribed or export as a separate audience for internal communication. This is a configuration decision made during scoping.

If ELMA365 Projects are used to organize contacts (for example, a project named after a customer cohort or campaign), we map the project name to a Mailchimp Tag applied to all contacts within that project. This preserves segmentation logic built in ELMA365 as Mailchimp Tags for use in Customer Journey segmentation.

ELMA365 Tasks are internal work items with no direct Mailchimp equivalent. Task assignments, statuses, and due dates do not map to Mailchimp. We document any task-based segmentation logic present in ELMA365 (for example, contacts associated with tasks in a particular status) as a written note recommending Mailchimp Tags or segments as the equivalent approach.

BPM workflow definitions and process instance state in ELMA365 use proprietary automation logic that does not transfer to Mailchimp Customer Journeys. We do not migrate workflow definitions. We deliver a written inventory of every ELMA365 workflow that touches contacts or sends communications, with a recommendation for rebuilding equivalent logic in Mailchimp Customer Journeys post-migration.

ELMA365 RPA robots that automate data entry or communication tasks are proprietary to ELMA365's RPA engine and cannot migrate to Mailchimp. We flag any RPA configurations that interact with contacts or email sending during discovery and present options: rebuild in Mailchimp automations, retain ELMA365 for automation-only use, or accept manual re-entry.

Documents attached to ELMA365 contacts or process instances do not map to Mailchimp. Mailchimp supports attachment to campaigns but not attachment to individual audience members. We extract document metadata (file names, types, and attachment counts) and present options: link to a document store in the migration handoff, or attach manually post-migration.