Migrate from XMPie to Zoho CRM

Each XMPie Audience becomes a record in a custom module named Audience, created in Zoho CRM's Module Builder before any data import. We capture the Audience name, the original data source identifier, the Circle workspace, and the recipient count as fields on the custom module. Zoho's standard Campaign module is reserved for the Circle Campaign itself, so the Audience custom module preserves the historical grouping for reporting. Audience-to-Contact is modeled as a lookup field on Contact pointing at the Audience custom module record. Custom modules are available on Enterprise and Ultimate tiers; we confirm the destination tier in scoping.

Each recipient row in an XMPie Data Source becomes a Zoho record. Recipients who have received at least one Touchpoint send become Contacts and are linked to an Account if a company-level field exists. Recipients in the data source who have not received any Touchpoint (provisioning or test rows) become Leads. Dedupe runs on email primary, then first name plus last name plus postal code as fallback. The XMPie data source primary key migrates to a custom Contact field xmpie_recipient_id for audit. Standard XMPie variables (firstName, lastName, email, phone, address, city, state, postalCode, country) map directly to Zoho Contact fields.

XMPie Segments are parameter-based rules with precedence ordering inside an Audience. Zoho's closest equivalent is the Tag field on Contact, plus saved Custom Views with multi-criteria filters. We migrate Segment membership as multi-value Tags (one tag per Segment a Contact belongs to) and re-express the rule logic as a saved Custom View on the Contacts module. Precedence ordering is not enforced by Zoho the way Circle enforces it; the team applies precedence at query time using sorted Custom Views. We deliver a written inventory of any Segment whose rule depends on an XMPie-only computed variable that did not migrate.

Each XMPie Campaign maps to a Zoho Campaign record. Campaign Name, Start Date, End Date, Status (Planning, Active, Completed, Cancelled), and Type (Direct Mail, Email, Multi-Channel) migrate as Zoho Campaign fields. The Owner field is set from the Circle workspace owner via email match to a Zoho User. Zoho Campaigns have a Member Status concept (Sent, Received, Responded) that we populate from XMPie Touchpoint delivery status. Campaign-level automation, scheduling, and Circle workflow configuration do not migrate; we deliver a written inventory of these for rebuild in Zoho's workflow rules, Zoho Marketing Automation, or a separate marketing tool.

Each Touchpoint in Circle is a one-to-many fan-out to recipients. We migrate each per-recipient Touchpoint event as a Zoho Activity (Task for print and SMS, Email for email sends, Note for web personalization views), with the Contact as Who_Id and the parent Campaign as What_Id. We also create a Campaign Member entry linking the Contact to the parent Campaign with the appropriate Member Status. Delivery status, send timestamp, channel, and Touchpoint name go to custom Activity fields. The Bulk Write API is used to load Activities in chunks of 25,000 with retry on the documented per-org rate limits.

Print Touchpoint events become Zoho Tasks with Subject set to the Touchpoint name, Due Date set to the production date, Status set to Completed, and a custom field touchpoint_channel = Print. A linked Note carries the printed-piece SKU, the InDesign template name, and the proof URL or PDF attachment if exported from the XMPie package. Per-recipient rendered PDFs are not migrated by default; sample proofs only, to keep the org storage manageable inside Zoho's tier limits.

Email Touchpoint events become Zoho Email activity records on the Contact with Subject, From Address, Send Timestamp, and Delivery Status preserved. The email HTML body is not re-created as a Zoho Email Template; we deliver a written inventory of the email templates referenced by each Touchpoint so the team can rebuild them in Zoho Campaigns or Zoho Marketing Automation. Open and click tracking are summarized at the Campaign Member level as Status (Sent, Opened, Clicked, Bounced) rather than re-created as discrete Activity records.

SMS Touchpoint events become Zoho Tasks with custom field touchpoint_channel = SMS, with the message body preserved in the Description field and Send Timestamp on the Due Date. SMS integration provider details (whether XMPie used Twilio, Plivo, or another gateway) do not migrate; we deliver the historical send history only. The team uses Zoho SMS Notification or a Zoho Marketplace SMS extension if ongoing SMS sending continues from Zoho.

Each XMPie Variable that resolves to a recipient-level data point becomes a custom field on Zoho Contact. We create the custom field through Module Layout in Setup before import, with the field type matched to the Zoho equivalent (Single Line, Multi Line, Number, Currency, Date, Date/Time, Pick List). Variables that compute from server-side logic (Qlingo expressions, multi-source joins) do not migrate as live computations; we materialize the last-evaluated value as a static field and document the underlying rule for rebuild as a Zoho Function or workflow rule if business logic is needed live in Zoho.

XMPie Data Sources (Excel, CSV, database exports linked to Campaigns) are the source of truth for recipient data. We export each Data Source to CSV, normalize columns to match the Zoho schema built in steps 1-9, and load through the Bulk Write API in chunks of up to 25,000 records per file. The Bulk Write API is asynchronous; we poll the job status and reconcile failed rows. The connection configuration from XMPie to the original database does not migrate; if ongoing sync is needed, the team uses Zoho's native Data Sync or a separate integration tool.

uStore Products map to Zoho's standard Products module. SKU (Product Code), Product Name, Product Active, and Product Category migrate where available. Pricing and delivery configuration are not exported by XMPie's package export, so the Unit Price field defaults to zero with a flag for manual review. Static, kit, upload-driven, and dynamic product types from XMPie become a custom pick-list field xmpie_product_type on Zoho Product for reference. Inventory and order routing are not migrated; the Zoho Products module here is catalog reference, not transactional inventory.

Each uStore storefront becomes a record in a Zoho custom module named Store so Products and Campaigns can attach to the storefront context. Storefront design assets, payment integrations, and order routing rules do not migrate. We attach the Store package export (.dpkg) to the Store record for archival, but the destination team must rebuild storefront ordering in a different tool because Zoho is not a web-to-print engine. Custom module Store is created in Module Builder during the schema build step.

Each Circle workspace user with admin or campaign-management privileges becomes a Zoho User, provisioned in Setup > Users with the appropriate profile and role. We resolve owners by email match. Any Circle Owner without a matching Zoho User must be provisioned by the customer's admin before the production import runs, otherwise the Owner field on Contact, Account, Deal, Campaign, and custom module records falls back to the migration service account. We hold unresolved owners in a reconciliation queue.

Content Objects in uCreate Print (Text, Graphic, Table, Visibility, Style, Link, Multi-Page PDF Table) encode per-recipient rendering logic against InDesign documents. These rules do not migrate to Zoho because Zoho has no rendering engine. We deliver a written inventory of each Content Object's rule expression, the variables it references, and the visibility conditions, so the team can rebuild equivalent logic in the downstream design or email tool. Where the logic is simple enough (Visibility on a known field), we replicate it as a Zoho workflow rule or Function, but we do not promise rendering parity.