Migrate from Xpressdocs to Odoo CRM

Xpressdocs stores contacts within Storefront-scoped contact lists. Each contact list becomes a set of tags on Odoo res.partner records. We extract all contacts with their list memberships, flatten the list-name-to-tag mapping, and apply tags during import. Email addresses serve as the dedupe key. Any contacts appearing in multiple lists receive all relevant tags. Contacts without email addresses are migrated with a warning flag and a manual review flag for the customer admin.

Xpressdocs agents and company records in the Listing Feed are mapped to either res.partner records with is_company=True (for brokerage firms) or individual res.partner records (for agent contacts) linked to the brokerage parent. The mapping choice is made during scoping based on whether the customer treats agents as individual CRM contacts or as organizational nodes.

Xpressdocs storefronts have no direct Odoo CRM equivalent. We map each storefront to a crm.team for pipeline and sales routing, apply the storefront name as a tag on all contacts and leads from that storefront, and preserve the storefront address as a separate res.partner record if the storefront has a physical location. Storefront-level user roles (Admin, Designer, Orderer) are mapped to Odoo access groups during the user import phase.

Xpressdocs print products (postcards, brochures, door hangers, business cards) map to Odoo product.product records. Paper type, coating, size, and base pricing are stored in custom fields on product.product since Odoo CRM core lacks print-specific attributes. We export product definitions via the Xpressdocs API, create product records in Odoo with the product type set to storable or consumable based on the customer's inventory approach, and preserve the original Xpressdocs SKU in a reference field.

Xpressdocs order history with fulfillment status, delivery method, quantity, and line items maps to Odoo sale.order and sale.order.line records. The order date and status are preserved, and each line item references the mapped product.product. We resolve the partner (recipient) by email against the migrated Contact records. Orders with a fulfillment_status of fulfilled are imported with the sale order in done state; pending orders are imported in sale_order state for further processing.

The JSON Listing Feed API property records (address, price, bedrooms, bathrooms, MLS number, listing status) transform into Odoo crm.lead records with a custom lead_type field set to property_listing. The responsible agent contact is linked via partner_id on the lead. Property photos are downloaded as binary attachments and linked to the lead via ir.attachment records. Open house dates and buyer/seller fields map to custom crm.lead fields or the lead description field as structured text.

Agent-to-listing associations in the Xpressdocs Listing Feed are resolved by matching the agent's email or MLS ID against the migrated res.partner records. We build a lookup table during the mapping phase and attach each listing lead to the correct agent Contact. Listings without a matching agent are flagged and assigned to a default agent queue for manual resolution.

AmazingMail trigger rules are event-based direct mail automations that reference external CRM events. These do not migrate as code because the trigger logic references Xpressdocs-specific event hooks that do not exist in Odoo CRM. We extract every trigger definition (trigger name, event type, delay, contact segment, mailer template) into a written inventory document that maps each AmazingMail trigger to a recommended Odoo Automated Action or Server Action. The customer's Odoo admin rebuilds the automations post-migration using this document.

Xpressdocs storefront users (Admin, Designer, Orderer) map to Odoo res.users records. Role naming differs between platforms, so we map by permission level: Admin maps to Odoo group_system_internal or a custom internal group; Designer maps to a group with product template edit access; Orderer maps to a sales-related group with portal-facing access. We export all users and their role assignments, then provision Odoo users in parallel with data migration.

Xpressdocs custom print templates with variable-data fields do not migrate as binary assets or code. We export the template metadata (name, field placeholder definitions, print specifications) into a written template inventory. The customer recreates the print template in Odoo's report designer or in the external design tool of their choice, using the exported placeholder field map as a reference. The template rebuild is out of scope for the data migration but is documented as a prerequisite for ongoing print operations.

Brand-specific image galleries in Xpressdocs store logos, brand color assets, and approved photography as platform-hosted files rather than structured database records. We export the asset metadata and URL references into a written file inventory. The actual image binaries require a separate file transfer step (direct download or Xpressdocs bulk download) and re-upload to Odoo's database or the customer's chosen file storage. This step is flagged separately from the data migration and requires customer action.

Xpressdocs optional modules (Automated Property Marketing, XpressConnection Lead Nurturing, eProcurement) carry configuration state that is not exposed in standard API exports. We identify which modules are active in the source account during discovery and produce a written module-by-module inventory with current settings, integration points, and recommended Odoo equivalents. Module rebuild in Odoo requires a separate configuration engagement or Odoo partner work and is not part of the data migration scope.

Contact segmentation tags within Xpressdocs contact lists are extracted as label strings and mapped to Odoo res.partner.category records. Multi-tag contacts in Xpressdocs receive multiple tag assignments in Odoo. The tag name is preserved as-is where it matches Odoo's category naming conventions, or normalized during the transform phase if the source tag names contain characters not allowed in Odoo category labels.