Migrate from XMPie to Salesforce Sales Cloud

XMPie recipient records map directly to Salesforce Contacts when recipients include full name, email, phone, and address fields. Personalization variable columns beyond standard fields require custom fields on the Contact object. Recipients without email route to Leads instead. All custom fields are defined in the Salesforce schema plan before migration, and field types are inferred from sample data to ensure compatibility.

XMPie recipients that lack a valid email address or complete contact information route to Salesforce Leads rather than Contacts. The split ensures Salesforce data-quality standards are met — your admin configures which missing fields trigger Lead vs. Contact assignment. Lead records retain the original recipient identifier in a custom field for traceability, and any missing contact details are logged for downstream enrichment.

When XMPie recipients include an associated company or organization field, we map it to Salesforce Account. Accounts are resolved first so Contact records can link via AccountId. Recipient records sharing the same company value consolidate under one Account. The Account mapping also captures the original organization name and any external ID as custom fields, preserving source references for future synchronization.

XMPie audiences (named groups of recipients with filtering rules) become Salesforce Campaigns. The audience name maps to Campaign Name. Recipient-filter rules do not migrate — they must be manually rebuilt in Salesforce using reports or a segmentation tool. Each recipient in the audience becomes a Campaign Member linked to the corresponding Contact or Lead.

XMPie campaign records (name, type, start/end dates, status) map to Salesforce Campaigns. Campaign response data (opens, clicks, conversions) migrates as Campaign custom fields because Salesforce's native Campaign model tracks member status but not granular response metrics for all campaign types.

XMPie product configurations (name, SKU, description, pricing tier, personalization options) have no Salesforce standard equivalent. We create a custom object with fields mirroring the XMPie product schema. The external product ID is stored as Source_Product_ID__c for traceability. Custom validation rules on the object enforce pricing tier consistency, and lookup relationships to the XMPie_Order__c object enable order-to-product linking for accurate reporting.

XMPie order data (order ID, total amount, status, fulfillment state, line items) merges into two destination objects: order header and summary fields land in a custom XMPie_Order__c object, while the monetary value and close date merge into a Salesforce Opportunity if the order represents a revenue-generating event. The mapping plan clarifies which orders create Opportunities based on your revenue-recording policy.

Each unique personalization variable field in XMPie (any column beyond standard recipient fields) requires a corresponding Salesforce custom field. Field type is inferred from XMPie data: text strings become Text fields, dates become Date/Datetime, numeric values become Number. We inventory all unique variable names across all campaigns before migration to avoid duplicate field creation.

XMPie tracks recipient responses (email opens, link clicks, print fulfillment, survey completions). These become Salesforce Tasks (for discrete actions) or Events (for scheduled interactions) linked to the Contact record, with response type stored as a custom pick-list field. Historical response timestamps are preserved as Activity Date.

XMPie stores print-asset references (InDesign documents, template IDs, variable-data print configurations) that have no direct Salesforce equivalent. We preserve these as text references in a custom Notes_and_Attachments_description__c field on the related Contact or Campaign. The actual print assets remain in XMPie or your DAM system — they are not migrated.

XMPie uStore portal configurations (store name, branding settings, shipping rules, payment configuration) have no Salesforce equivalent. We preserve the store configuration as a custom object with reference fields. Operational settings (shipping, payment) must be reconfigured in your commerce platform post-migration.

XMPie supports SAML-based SSO with Salesforce — user accounts in XMPie that reference Salesforce users map by email match to Salesforce User records. Owner resolution happens before migration so all records have a valid Salesforce OwnerId. Unmatched XMPie users are flagged for manual Salesforce user creation.