Migrate from Customer.io to Microsoft Dynamics 365 Sales

Customer.io Profiles with a clear email address and business identity map to Dynamics 365 Contact. Anonymous Profiles (identified by anonymousId only with no email) map to Dynamics 365 Lead or are flagged for manual review. We compute the split using the presence of a valid email property in the Customer.io identify() payload and apply a minimum trait count threshold (e.g., more than two traits) as a secondary qualification signal. The original Customer.io userId is stored in a custom field cio_user_id__c on both Lead and Contact for cross-system reconciliation.

Customer.io Companies stored as object_type_id namespaces map to Dynamics 365 Account. The company name maps to Account Name; domain maps to Website; city and country map to Address fields. If the Customer.io Company has a relationship to a Person via the group() call, we create the Account first, then resolve the AccountId lookup when importing the Contact. If multiple Customer.io Persons reference the same Company object, we deduplicate on Company ID to create one Account.

Customer.io events created via track() have no direct Dynamics 365 equivalent because Sales does not have a native event store. We pre-create a Dataverse custom entity (e.g., cio_event) with fields for event_name, event_timestamp, user_id (lookup to Contact), and a properties JSON column or individual attribute fields for the most common event property keys. We export the full event schema during scoping, map property keys that appear in more than 10 percent of events to named columns, and store the remainder in a JSON properties field. Events are the highest-volume object in a Customer.io migration and are batched in chunks of 5,000 records during import.

Customer.io traits set via identify() migrate to typed Dynamics 365 Contact fields. String traits map to Single Line of Text, boolean traits to Two Options, date traits to Date and Time, numeric traits to Decimal or Whole Number, and array traits to Multiple Lines of Text (JSON serialized) or a custom multi-select field depending on the customer's preference. Traits with more than 10 unique values across the dataset map to Option Set fields. We flag any trait with a null rate above 80 percent so the customer can decide whether the field is worth migrating.

Customer.io Segments are dynamic audience definitions with rule-based inclusion criteria (trait conditions, event conditions, membership time). We export the full segment rule set as a structured JSON document and translate it into a Dynamics 365 Advanced Find fetchXML query or a Power Automate flow that rebuilds the segment membership on a schedule. Segments do not migrate as active audience data; they migrate as rule documentation for the customer's admin to implement in Dynamics 365.

Customer.io Journeys and Campaigns contain entry triggers, branching conditions, wait steps, and multi-channel message actions that have no direct Microsoft Dynamics 365 Sales equivalent. Sales Cloud has a Campaign object for tracking marketing campaign membership but no native Journey builder. We export the Journey structure as a written document including trigger type, step sequence, channel per step, and condition branches. The customer's admin rebuilds the campaign logic in Dynamics 365 Customer Insights - Journeys, Power Automate, or a third-party marketing tool.

Customer.io one-time Broadcasts map to Dynamics 365 Campaign records for tracking purposes. Broadcast name becomes Campaign Name; target segment is documented as Campaign Type and intended audience in a custom field. Active broadcast history (send timestamp, recipient count) migrates as Campaign Member records with Member Status set to Responder or Sent. Broadcast content does not migrate as a reusable template.

Customer.io arbitrary Custom Objects stored under object_type_id namespaces map to Dataverse custom entities. We pre-create the destination schema including all custom fields, attribute types, and lookup relationships to standard entities (Contact, Account, Opportunity) before data import. Custom object naming in Dynamics 365 uses the New_ prefix for custom entities; we preserve the original Customer.io object name in a custom field for reference. Lookup relationships between custom objects are resolved in dependency order during import.

Customer.io transactional message templates (receipts, password resets, order confirmations) migrate as documented email content rather than active templates because Dynamics 365 does not have a transactional messaging channel. We export template name, subject line, body content (HTML), and liquid variable mappings. The customer's admin uses this documentation to rebuild templates in Dynamics 365 Email Templates, Power Automate email actions, or the destination transactional email provider.

Customer.io delivery status data (sent, delivered, bounced, undeliverable) migrates to Dynamics 365 Campaign Member records with the corresponding Member Status value. Undeliverable statuses are stored in a custom field cio_delivery_status__c on the Campaign Member to preserve the full delivery state without overwriting the standard status field. Compliance and audit records from Customer.io message logs are flagged for the customer's legal team to review against their data retention policy.