Migrate from Taguchi to Microsoft Dynamics 365 Sales

Taguchi Subscribers map directly to Microsoft Dynamics 365 Sales Contacts. The Subscriber email address becomes the Contact email1 field and serves as the dedupe key during import. Status (active, bounced, unsubscribed) maps to a custom contact property hstg_status__c, with bounced and unsubscribed values also setting the native EmailOptOut field to true so Dynamics respects the suppression without requiring a separate flag. Read-only metadata fields (campaign source, import source, cluster) migrate as custom text fields to preserve the full subscriber profile.

Taguchi key-value custom fields map to typed Microsoft Dynamics 365 Sales Contact custom fields. We snapshot the full custom field schema during discovery. Fields deleted from Taguchi UI that still carry values are reconstructed as inactive custom fields on the Contact with an archived prefix so that data is preserved but the field does not appear in active form workflows. Field types are inferred from Taguchi value patterns (numeric, boolean, date, string) and mapped to the equivalent Dynamics 365 field type at migration time.

Taguchi Organizations map to Microsoft Dynamics 365 Sales Accounts. The Organization name becomes the Account name field and is used as the dedupe key for Account creation. We link each Contact to its parent Account via the accountid lookup so that Dynamics 365's standard Account-Contact hierarchy is established at migration time rather than requiring post-migration linking.

Taguchi Clusters identify the subscriber segment most strongly associated with a contact. We map Clusters as a custom Contact text field (hstg_cluster__c) or as a Contact Tag depending on the customer's segmentation strategy. The customer chooses during scoping whether to preserve Clusters as searchable text fields or as tags for use in Microsoft Dynamics 365 Sales views and reports.

Taguchi List memberships are append-only and cannot be deleted via API, making them a one-way transfer to Dynamics 365. We map each List name to a Contact Tag so that the customer can filter Contacts by original Taguchi list membership in Microsoft Dynamics 365 Sales views and reports. List membership count per subscriber is preserved as a custom integer field (hstg_list_count__c) for segmentation and cleanup decisions post-migration.

Taguchi behavioral activities (open events, click events, custom events) migrate as Dynamics 365 Task records with a custom Task Type field (hstg_activity_type__c) carrying the event name and a custom description field (hstg_activity_detail__c) carrying the URL, campaign reference, or custom event payload. Activity timestamps map to the Task ActivityDate field for chronological ordering on the Contact timeline. We chunk activity writes to avoid Dynamics 365 API throttling on high-volume activity histories.

Taguchi campaign associations link subscribers to email campaigns. We map these as Campaign Member records in Microsoft Dynamics 365 Sales , creating Campaign records for each named Taguchi campaign with Campaign Type set to Email and the original send date preserved. Each Contact's campaign membership is logged as a CampaignMember with Status set to Responded to indicate engagement. Broadcast metadata (send date, recipient count) is preserved as Campaign fields.

Taguchi SMS send history migrates as Task records with Task Type set to SMS and the original send timestamp preserved. Phone number validation is performed during the Subscriber extract phase; any record missing a valid phone number is flagged and quarantined so it does not import a null phone into Dynamics 365 and cause formatting issues on the Contact record. SMS content is preserved in the Task Description field.

Taguchi automation workflows and journey logic are rule-driven configurations that do not map to Microsoft Dynamics 365 Sales native objects or Power Automate without a rebuild. We do not migrate automation workflows. We extract a written inventory of every active Taguchi workflow with its trigger conditions, subscriber filters, delay actions, and CRM action steps, organized by workflow name and last-modified date, so that the customer's admin can evaluate which workflows to rebuild as Microsoft Dynamics 365 Sales templates or Power Automate flows post-migration.