Migrate your Taguchi data

The primary contact object in Taguchi. Contains email, status (active/bounced/unsubscribed), organization link, and read-only metadata fields (campaign source, import source, cluster). We migrate all standard subscriber fields and explicitly map the status flag to suppress bounced records on the destination.

Taguchi stores arbitrary key-value pairs per subscriber. Field keys are unique per subscriber and fields cannot be deleted once created (they persist with null values). We preserve all field keys and values, flagging any nulls explicitly so the destination schema can accommodate optional fields.

Subscribers belong to Lists. List memberships can be created and updated via API but can never be deleted. We map list memberships to tag equivalents on the destination. Customers should confirm their target system's tag model before scoping the import.

Campaigns link subscribers and activities. We migrate campaign associations as metadata on subscriber records rather than as standalone objects, since most destination CRMs do not have a native Campaign object equivalent in the contact model.

One-time email sends to subscriber segments. We preserve broadcast metadata (name, send date, recipient count) as a linked activity log against each subscriber record rather than as a top-level object.

Taguchi logs per-subscriber events (opens, clicks, custom events) used to drive automation triggers. We extract activity history and write it as engagement records on the destination Contact, preserving the event type and timestamp.

Each subscriber is linked to an owning Organization. We map this as a Company or Account association on the destination CRM contact record.

Clusters identify the subscriber segment a contact is most strongly associated with. We map clusters as a custom Contact property or tag on the destination system.

Taguchi automation workflows and journey logic are rule-driven configurations that do not map cleanly to other platforms. We do not migrate automation workflows. We preserve the underlying data (subscribers, activities, triggers) that would allow workflows to be rebuilt on the destination.

SMS send history is migrated as a message activity record on the subscriber. Content and scheduling metadata are preserved. Note that phone number fields must be present and validated on the subscriber record for SMS data to be meaningful.