Migrate from Acoustic Campaign to Microsoft Dynamics 365 Sales

Acoustic Contacts within each Database map directly to Dynamics 365 Contact records. The Acoustic contact unique identifier (typically email) becomes the dedupe key for import. We resolve each Contact's Database membership and preserve it in a custom field db_source__c for audit. If the same email appears in multiple Acoustic Databases, we select the record with the most recent modification date as the canonical import and flag the duplicate for the customer's review.

Each Acoustic Database may have a unique field schema. We map each Database to the Contact entity, applying Database-specific field transforms. If Databases share field names with different types or formats, we document the conflict and apply a normalisation rule during migration rather than collapsing the schemas blindly.

Acoustic Suppression Lists hold opt-outs, bounces, and Do Not Email markers. We export the suppression entries and set HasOptedOutOfEmail = true on the matching Dynamics Contact record. Where Acoustic tracks consent type (email, SMS, push), we create Consent records in Dataverse with the appropriate consent channel. Suppression Lists import before any Contact load to prevent re-mailing opted-out addresses.

Relational Tables hold transactional or behavioural data joined to Contacts via a key field. We export each Relational Table as a separate Dataverse custom entity with a 1:N lookup relationship back to Contact. The key field from the Relational Table (customer ID, email, or Acoustic contact ID) resolves to the Dynamics Contact GUID during import. Simple Relational Tables with 1-3 frequently-queried fields are denormalised onto the Contact record instead to reduce join complexity in the destination.

Acoustic Queries are saved filter definitions over Contacts plus Relational Table joins evaluated at send time. We export the current Contact membership of each Query as a snapshot list (CSV of Contact IDs) and document the Query's filter logic, conditions, and join structure. The snapshot becomes an exported segment for re-import into Dynamics 365 Customer Insights (Journeys) or a filtered view in Dataverse. The Query logic itself does not migrate; the customer rebuilds the segment in the destination using the documented logic.

Acoustic Programs are multi-step automated message sequences with branching, timers, and conditional logic. We export the Program definition (steps, triggers, conditions, timer offsets, branch paths) as a written inventory document with screen-annotated walkthroughs. We do not migrate Programs as automation code. The inventory document enables the customer's admin or a Dynamics partner to rebuild equivalent journeys in Power Automate or Dynamics 365 Customer Insights (Journeys). Active Program enrollment state is exported as a snapshot list; the new journey starts fresh in Dynamics.

Acoustic Mailings (autoresponders, recurring sends, one-off campaigns) migrate as Campaign records in Dynamics 365 with the send date, subject, and sender preserved. Contact send history (opened, clicked, bounced) migrates as CampaignMember records with custom activity status fields. We do not migrate the full HTML email content unless the customer explicitly requests it; the HTML is documented as a content reference for rebuild in Dynamics email templates.

Acoustic email templates and content blocks export as HTML. Acoustic personalisation tags ($contact.field$ syntax) are translated to Liquid or the destination's equivalent syntax. Templates are documented as HTML assets for rebuild in Dynamics 365 email designer or Customer Insights email templates; the migration deliverable is a content audit spreadsheet mapping each Acoustic template to a recommended Dynamics template replacement.