Migrate from Xpressdocs to Salesforce Sales Cloud

Xpressdocs contacts migrate to Salesforce Contact records. List membership and segmentation tags map to Salesforce Campaigns (one per Xpressdocs contact list) with CampaignMember records linking each Contact to its source list. The original list name, segment tags, and subscription status preserve as custom fields on Contact and CampaignMember. This design allows the customer's admin to use standard Salesforce Campaign reports to recreate the audience segments that previously drove AmazingMail campaigns.

Xpressdocs contacts who represent unqualified prospects (no purchase history, no open order) map to Salesforce Lead rather than Contact. We apply a scoring rule during scoping that evaluates order history, storefront role, and segment tags to determine whether a record qualifies as a Lead or Contact. Prospects without an associated Account on the destination side are staged as Leads for the sales team to work through the standard Salesforce Lead conversion flow.

Xpressdocs Storefronts are top-level brand containers containing product catalogs, template libraries, and user permissions. We map the storefront name and configuration metadata to a Salesforce Account (representing the brand entity) and a custom Storefront__c object carrying storefront-specific settings such as storefront URL, product count, and tier level. SSO configuration from the Xpressdocs Starter or Enterprise tier does not migrate; we document the SSO requirements for the customer to configure in Salesforce Identity.

Xpressdocs print products (postcards, brochures, door hangers, business cards) map to Salesforce Product2 records with Standard Price Book entries. Paper type, coating options, and size variants migrate as product attributes. ProductCode maps from the Xpressdocs SKU field. Product2 must be created and Pricebook2 entries configured in Salesforce before any associated order records are imported.

Xpressdocs print order history does not map to any Salesforce standard object. We create a custom Print_Order__c object with fields for order number, order date, fulfillment status, delivery method, quantity, and recipient contact lookup. Line-item references to Xpressdocs Products resolve to Salesforce Product2 IDs during migration. Historical orders carry a closed status by default unless the order's fulfillment date falls within an active reporting window the customer specifies.

The JSON Listing Feed API maintains a separate Agent schema with fields for agent name, brokerage, contact information, and MLS ID. Agent records migrate to Salesforce Contact with custom fields agent_id__c, mls_id__c, and brokerage__c. The Agent-to-Property association (which agent owns which listing) migrates as a lookup relationship on the Property custom object rather than on Contact.

Property records from the Xpressdocs JSON Listing Feed API (address, listing price, property type, status, photos, MLS data) migrate to a Salesforce Property__c custom object with custom fields matching the listing schema. The Agent lookup on Property__c resolves to the migrated Contact record for the listing's agent. Photo references from the listing feed migrate as URL fields on Property__c; actual image binaries require a separate file transfer step documented in the handoff package.

Open house records from the listing feed (date, time, property association, agent association) migrate to an Open_House__c custom object with a lookup to Property__c and a lookup to the agent Contact. Start time, end time, and status map to equivalent custom fields on Open_House__c.

Buyer and seller records from the Xpressdocs JSON Listing Feed schema migrate to Buyer_Seller__c custom objects with contact information, transaction type, property interest, and agent association. These records do not have a direct Salesforce standard object equivalent and require custom object schema design before migration.

Xpressdocs marketing templates are brand-approved designs stored per-storefront with variable-data placeholder fields. We export template assets and placeholder field definitions as ContentDocument records in Salesforce, and create a custom Template__c object with fields for template name, storefront association, variable fields (as a text area), and asset URL. Custom templates with variable-data fields require field-level mapping review against the destination Salesforce object's custom fields.

AmazingMail automated direct mail campaigns are event-triggered rules tied to external CRM hooks (service reminders, birthdays, appointment completions). These do not migrate as automation code. We export each trigger definition including the trigger event, contact segment criteria, mailer template, frequency, and duration, and deliver them as a written Flow Inventory document. The customer's admin or a Salesforce consultant rebuilds each trigger in Salesforce Flow using the documented specification.

Xpressdocs storefront users (Admin, Designer, Orderer roles) map to Salesforce User records. Role naming conventions differ between Xpressdocs tiers and Salesforce profiles, so we map roles by permission level rather than by name. Users without matching Salesforce accounts enter a reconciliation queue for the customer's admin to provision. Active Xpressdocs users become active Salesforce Users; inactive users become inactive Salesforce Users to preserve historical order attribution.

Brand-specific image galleries in Xpressdocs store logos, brand colors, and approved photography as platform assets. We export the asset metadata (file name, URL reference, gallery association) and create ContentDocumentLink records in Salesforce. Actual image binary files require a separate file transfer step; we document the asset URLs and gallery groupings so the customer's admin can re-upload to Salesforce Files, Experience Cloud, or a connected DAM.

Automated Property Marketing module configuration is not exposed in standard API exports. We identify active APM setups during discovery, document the module's trigger rules, listing feed associations, and contact segment definitions, and deliver them as a module-specific handoff document. The destination implementation requires custom object schema design and Flow configuration in Salesforce, which is scoped as a separate configuration engagement.

XpressConnection Lead Nurturing manages pre-scheduled direct mail campaign enrollment and frequency. Campaign enrollment lists, schedule definitions, and frequency rules export as a written handoff document. Re-implementation in Salesforce requires Flow builder configuration and is documented as a separate rebuild task in the migration package.