Migrate from Taguchi to Salesforce Sales Cloud

Taguchi Subscribers are the primary contact object and map directly to Salesforce Contact. The Subscriber email becomes Contact.Email, the Subscriber status (active/bounced/unsubscribed) maps to a combination of HasOptedOutOfEmail and a custom field taguchi_status__c. Subscriber read-only metadata fields (campaign source, import source) preserve as custom Contact fields. We resolve the Taguchi Organization reference to an AccountId on Contact during migration. Bounced Subscribers are imported with a suppression flag and quarantined from active sends on the destination.

Taguchi key-value custom fields per Subscriber map to Salesforce custom fields on Contact with equivalent data types. If a custom field was deleted from the Taguchi UI but still carries values on Subscriber records, we reconstruct it as an archived custom field (taguchi_archived_field__c) during migration to preserve data integrity. We snapshot the full custom field schema during discovery to handle any schema drift from soft-deleted fields. Field keys that exceed Salesforce field name length limits are truncated per Salesforce naming conventions.

Taguchi Organizations are parent entities linked to Subscribers. Each unique Organization record migrates to a Salesforce Account, with the Organization name as Account.Name and any available metadata as custom Account fields. Subscribers reference their parent Organization via a lookup field that we resolve to AccountId at Contact migration time. Organization-to-Account migration runs before Subscriber migration so that the AccountId foreign key is satisfied on Contact insert.

Taguchi Clusters identify the subscriber segment a Contact is most strongly associated with. We map Clusters as a custom Contact field (taguchi_cluster__c) or as Salesforce Contact tags depending on the customer's segmentation strategy. The customer confirms the preferred approach during scoping. Clusters with high cardinality (more than 200 unique values) are mapped to tags rather than picklist fields to avoid Salesforce picklist limits.

Taguchi List memberships are append-only and cannot be deleted via API. We extract the full list of memberships per Subscriber and map them to Salesforce Contact tags (preferred for low-to-medium cardinality) or a custom multi-select picklist field (taguchi_lists__c) for up to 150 list values. We document all list names and membership counts during discovery and flag the append-only constraint in the handoff so the customer's admin understands that Salesforce tags are fully deletable post-import, creating a one-way schema difference from Taguchi's model.

Taguchi open events are per-Subscriber behavioral records with a timestamp and campaign reference. We map these to Salesforce Task records with a custom field task_type__c = 'Email Open', activity_date set to the original Taguchi timestamp, and campaign association stored in a custom WhoId or CampaignName field. Opens attach to the Contact record via the standard WhoId relationship. Multiple opens from the same Subscriber are written as individual Task records preserving the full timeline.

Taguchi click events record the URL clicked, the campaign, and the Subscriber. We map these to Salesforce Task with task_type__c = 'Email Click', the clicked URL preserved in a custom URL field, and the original timestamp as ActivityDate. Click events attach to the Contact record via WhoId and link to the related Campaign record via the campaign association stored in a custom field. Click-through rate calculations are preserved as a count of click Tasks per campaign.

Taguchi custom events are behavioral triggers defined by the customer (purchase, webinar attendance, form submission, etc.). We map these to Salesforce Task records with task_type__c = 'Custom Event', the event name stored in a custom event_name__c field, event metadata preserved as a custom event_data__c field, and the original timestamp as ActivityDate. Custom event classification is preserved so that automation triggers can be rebuilt in Salesforce Flow using the task_type__c and event_name__c values.

Taguchi SMS send history (phone number, message content, send timestamp, delivery status) migrates as Salesforce Task records with TaskSubtype = SMS and IsVisibleInSelfService = true. The Contact's Phone or MobilePhone field must be present and validated during migration to enable SMS routing. SMS content preserves as Task.Description. Delivery status maps to a custom field taguchi_sms_status__c. We document the Twilio or Salesforce MobileConnect integration path for the customer's admin to configure post-migration for ongoing SMS sends.

Taguchi one-time broadcast sends (name, send date, recipient count) are mapped to Salesforce Campaign records rather than imported as standalone objects. Each Campaign record carries the broadcast name, start date as CampaignStartDate, and recipient count as a custom field taguchi_recipients__c. Individual subscriber broadcast receipts are preserved as CampaignMember records linked to the Contact and Campaign. Broadcast content is not migrated as a Salesforce email template; we document the content for manual rebuild if needed.

Taguchi subscriber-to-campaign associations are mapped to Salesforce CampaignMember records linking the migrated Contact to the corresponding Campaign. The CampaignMember Status maps from Taguchi's send status (sent, delivered, bounced, opened, clicked) to Salesforce Status values. This preserves the subscriber's full campaign engagement history against the Contact record via the Campaign and CampaignMember objects.

Taguchi's permanent bounced subscriber flag is extracted during discovery and written to Salesforce as HasOptedOutOfEmail = true and a custom field taguchi_bounced__c = true with the original bounced timestamp and reason preserved for audit. Bounced records are quarantined during migration and not re-activated on the destination platform. This prevents the customer's new sending domain from immediately landing on blocklists due to re-activation of suppressed addresses. The admin receives a bounced subscriber report during handoff.

Taguchi unsubscribed status maps directly to Salesforce HasOptedOutOfEmail = true. We extract the unsubscription timestamp as a custom field taguchi_unsubscribed_date__c for audit and compliance purposes. Unsubscribed records are imported as Contacts with HasOptedOutOfEmail set so they are immediately excluded from all Salesforce email sends. The unsubscribe audit trail is preserved in compliance with CAN-SPAM and GDPR requirements.

Taguchi Subscriber read-only metadata fields (import source, campaign source, cluster, creation date, last modified date) are preserved as custom Contact fields (taguchi_import_source__c, taguchi_campaign_source__c, taguchi_created_date__c, taguchi_last_modified__c). These fields are informational and do not drive Salesforce automation, but they preserve the full provenance of each contact record from the Taguchi source system for audit and historical reference.