Migrate from erxes to Microsoft Dynamics 365 Sales

erxes Contact records map directly to Dynamics 365 Contact. Standard fields (firstname, lastname, email, phone, address) transfer 1:1. Custom fields on erxes Contacts map to typed Dataverse columns that we provision before migration, but erxes enforces no field type at ingest, so we validate date formats, numeric strings, and picklist values against the erxes field schema before writing to Dynamics 365 and flag any mismatches for customer resolution.

erxes Company maps to Dynamics 365 Account, not a custom object. The HubSpot-era naming convention (Company = Account) differs from erxes but the Dataverse schema uses Account as the standard business-entity record. We use the erxes company domain as the Account Website field and apply a case-insensitive dedupe key on company name and domain to prevent duplicate Account creation during import. The erxes companyId becomes a custom field erxes_company_id__c for source-reference auditing.

erxes Deal maps to Dynamics 365 Opportunity. Deal amount, close date, and stage assignment transfer directly. The erxes pipelineId maps to a Microsoft Dynamics 365 Sales Process (Record Type-scoped stage whitelist) that we configure before migration. If erxes Deals are attached to Companies, we resolve the AccountId from the prior Account import phase before inserting Opportunities. Closed-won and closed-lost reasons from erxes custom fields become Dynamics custom fields for loss reason and win reason.

erxes Pipelines define Deal workflow stages and map to Dynamics 365 Record Types on Opportunity, each paired with a Sales Process that restricts StageName picklist values to the stages in that pipeline. Stage probabilities migrate from erxes to Dynamics StageProbability. Teams that use erxes pipeline branching (e.g., different stages per product line) map to separate Record Types in Dynamics. We configure these in a Sandbox org before production migration.

erxes Tasks migrate to Dynamics 365 Task with Status, Priority, and ActivityDate preserved. Task titles and descriptions transfer as Subject and Description. Owner assignment resolves by matching erxes userId to the Dynamics User ID via the User lookup table created during the owner reconciliation phase. Tasks without a resolvable owner land in a held queue for admin review before insert.

erxes multi-channel Conversations require a split: email messages migrate to Dynamics 365 EmailMessage records linked to the parent Contact or Account via the Regarding (object) lookup; SMS, chat, and WhatsApp messages migrate as Task records with custom TaskType values since Dynamics 365 lacks a native SMS/chat message object. Conversation metadata (channel, timestamp, customer reference) preserves in custom fields on both the EmailMessage and Task. Message ordering depends on the erxes server-side createdAt timestamp, which we carry forward to maintain chronological sequence.

erxes Users map to Dynamics 365 Users for owner assignment resolution. We extract all erxes users referenced on Contacts, Companies, Deals, and Tasks and match by email address against the Dynamics User table. Any erxes user without a matching Dynamics User goes to a reconciliation queue; the customer's admin provisions the missing User before record migration resumes. Role and permission structures are documented separately as they require manual rebuild in Dynamics security roles.

erxes custom fields on any supported object map to typed Dataverse columns on the corresponding Dynamics entity. We provision the Dataverse column schema (name, type, required flag, picklist values) before data migration begins. erxes custom fields have no type enforcement at ingest, so we validate values against the erxes field type definition and flag mismatches rather than allowing Dynamics to reject the record. The migration is blocked on custom field provisioning; columns must exist in Dataverse before any mapped records insert.

erxes Automation Workflows (trigger-action sequences defined in the plugin modules) do not migrate as code. The trigger logic, conditions, and actions are documented in a written inventory that we deliver to the customer's Dynamics administrator. This inventory includes the automation name, the object it operates on, the trigger type, all conditions and branches, and a recommended Power Automate or model-driven Flow equivalent. Rebuild is outside standard migration scope.