Migrate from Adobe Campaign to Microsoft Dynamics 365 Sales

Adobe Campaign Recipients with a known account relationship and engagement history map to Microsoft Dynamics 365 Sales Contact attached to an Account. Recipients that are purely marketing list entries with no sales touch history map to Lead for initial qualification routing. We compute the split using the Recipient's last delivery date, subscription status, and any custom lifecycle field, and preserve the original recipient ID in a custom field ac_recipient_id__c for audit. Extended nms:recipient schema fields migrate as custom Contact or Lead fields; we parse the schema XML to derive the underlying column name before mapping.

Adobe Campaign Organization records map directly to Microsoft Dynamics 365 Sales Account. Organization name becomes Account Name, and the organization's country or industry sector maps to standard Account fields. The Account is created before any Contact import so that the CustomerId lookup is satisfied at the moment of Contact insert. If the source uses only Recipients without a separate Organization table, we extract the domain from each Recipient email address to group them into Account records during migration.

Adobe Campaign Deliveries have no direct equivalent in Microsoft Dynamics 365 Sales . We create a Microsoft Dynamics 365 Sales Campaign record for each Adobe Campaign delivery, storing the delivery label as Campaign Name, the send date as Start Date, and the delivery status as a custom ac_delivery_status__c picklist field. Total sent count, total opened count, and total clicked count migrate as numeric custom fields on the Campaign. Delivery content (email body, subject line, personalisation tokens) is not migratable; we document the content inventory for the customer's marketing team to rebuild in their chosen campaign execution tool.

BroadLog records track every message sent per Recipient per delivery. We migrate these as Microsoft Dynamics 365 Sales CampaignMember records linked to the Contact or Lead and the Campaign, with delivery status (Sent, SoftBounce, HardBounce, Delivered) mapped to CampaignMember Status values. v8's FFDA dual-database architecture means BroadLogs may exist in both the local and cloud database; we query both and deduplicate by Recipient ID and delivery ID before inserting into Dynamics. Aggregate open and click rates recalculate in Dynamics from the migrated tracking log data.

Adobe Campaign Services represent opt-in subscription lists with double-opt-in confirmation flows. Microsoft Dynamics 365 Sales has no native subscription management object. We create a custom ac_subscription entity in Dataverse with fields for service name, subscription status (Subscribed, Unsubscribed, Pending), subscription date, and confirmation date, linked to the Contact via a lookup. The customer chooses between a custom entity approach or a Marketing List approach during scoping based on their downstream marketing tool plan.

Adobe Campaign Standard and v8 Programs are hierarchical containers for campaigns, workflows, and targeting logic. Microsoft Dynamics 365 Sales Campaigns are flat; no native hierarchy exists. We map top-level Programs to a custom ac_program__c field on Campaign, and if multi-level hierarchy is required, we create a self-referencing lookup on Campaign to model the parent-child structure. Program-specific permissions do not migrate and must be reconfigured in Microsoft Dynamics 365 Sales security roles.

Adobe Campaign custom schemas built via schema extension or FDA connectors to external SQL databases require custom extraction logic. We inspect the schema XML during the pre-migration audit to derive the underlying table structure and column types, then design a corresponding custom entity in Microsoft Dynamics 365 Sales Dataverse with matching field types, lookups, and optionsets. Custom entity naming follows the source schema name with a prefix to avoid naming collisions with standard Dynamics objects.

Adobe Campaign tracking logs store open events, click events, and URL click-throughs per Recipient per delivery. Microsoft Dynamics 365 Sales has no native tracking log object. We create a custom ac_tracking_log Dataverse entity with fields for Recipient (lookup to Contact), Campaign (lookup to Campaign), event type (Open, Click, Bounce), URL clicked, and timestamp. Click-through URLs and timestamped events migrate for reporting continuity; aggregate open and click rates recalculate in the destination from these individual event records.

Adobe Campaign enumerations defined in schema XML (such as deliveryStatus, gender, format preference) use internal integer values that differ from Microsoft Dynamics 365 Sales optionset labels. We maintain a value-mapping table keyed by enumeration name and map the integer value to the corresponding Dynamics optionset label before insert. Format preference (HTML vs Plain Text) maps to the Contact's email format field if Dynamics supports it, or to a custom ac_email_format__c optionset field.

Adobe Campaign targeting workflows, campaign workflows, and technical workflows are not migratable. Workflow XML packages contain dynamic content blocks, queryDef expressions, and delivery activities that do not map to Microsoft Dynamics 365 Sales or Power Automate equivalents. We deliver a written inventory of every active workflow during scoping, documenting the workflow name, trigger type, query criteria, segmentation logic, delivery actions, and approval gates. The customer's admin or a Dynamics 365 partner rebuilds the workflow logic in Power Automate, Microsoft Dynamics 365 Sales Playbooks, or a dedicated marketing automation tool.