Migrate from openCRX to Microsoft Dynamics 365 Sales

openCRX LegalEntity records map directly to Dynamics 365 Account. The LegalEntity's primary address, phone numbers, industry classification, and multi-currency settings transfer to the corresponding Account fields. We use the LegalEntity's internal identifier as a cross-reference key during migration so that any Contact records linked to this LegalEntity can be updated with the correct AccountId after the Account insert completes.

openCRX Contact records (individual persons) map to Dynamics 365 Contact. Each Contact inherits its primary postal address and phone number from the Contact record directly, not from a parent LegalEntity. We set the parent AccountId by resolving the Contact's legal entity reference through the Account cross-reference table created during the LegalEntity import phase.

openCRX Opportunities inherit from the abstract contract class and carry deal fields, ratings, stage values, and associated notes as standard attributes. We map the openCRX opportunity stage to Dynamics 365 Opportunity StageName, and the openCRX currency code to the Dynamics 365 TransactionCurrencyId. Closed-Won and Closed-Lost outcomes and their timestamps migrate as standard stage fields. The parent AccountId and primary ContactId are resolved via the cross-reference tables created during the Account and Contact import.

openCRX Quotes inherit from the same contract hierarchy as Opportunities and Sales Orders. The Quote positions (contract positions in openCRX) map to Quote Details (quotedetail) in Dynamics 365. We preserve the quote header totals, pricing rules, currency context, and the Quote's status field. If the openCRX Quote has an expiration date, it maps to the Expirede field in Dynamics 365.

openCRX Sales Orders are contract objects that can be transformed from Quotes. Order positions (contract positions) map to SalesOrderDetail records in Dynamics 365, preserving quantity, unit price, and any discount applied at the line level. The order header total, currency, and status migrate as fields on the SalesOrder entity. We resolve the parent AccountId and ContactId from the cross-reference tables before inserting order records.

openCRX Invoices are terminal contract objects with header and position detail. Invoice headers migrate to Dynamics 365 Invoice with payment terms, billing address, and total amount; invoice line positions migrate to InvoiceDetail records. Payment status in openCRX maps to the Dynamics 365 Invoice Status field. We handle the one-to-one address mapping from openCRX's postal address model to Dynamics 365's address structure (separate address fields vs address composite fields).

openCRX Products (including bundles) map to Dynamics 365 Product2 records with the Product Type set to Product or Bundle as appropriate. openCRX price lists map to Dynamics 365 PriceList entities, and price list entries map to ProductPriceLevel records linked to the corresponding Product2 and PriceList. We resolve the pricing priority from openCRX's runtime pricing rules to the PriceListItem's amount field.

openCRX Activities with call disposition, duration, and outcome map to Dynamics 365 Task with TaskSubtype set to Call. openCRX meeting activities with start and end timestamps, location, and attendee data map to Dynamics 365 Appointment (Event). openCRX email activities with body content, sender, and recipients map to Dynamics 365 EmailMessage records linked to a Task activity entry. Activity Trackers in openCRX (which group related activities) are not a standard Dynamics entity; we document tracker groupings during discovery and advise the customer on manual re-grouping via Dynamics 365 visual pipelines or custom entities post-migration.

Custom fields added via openCRX DataBinding PropertySet are identified during scoping by inspecting the feature definition layer. Each custom CrxObject attribute maps to a custom column on the corresponding Dataverse table (e.g., custom attribute on Contract maps to a custom column on Opportunity). We create the custom column definition with the appropriate Dataverse column type before data load, and validate the attribute values during the sandbox migration pass. Active user-defined attributes are documented in the schema inventory delivered with the migration.

openCRX user records with their role-based security assignments are extracted and mapped to Dynamics 365 SystemUser records. We match by email address and create a user mapping table during scoping. The openCRX role definitions (which define what a user can access per segment) map to Dynamics 365 Security Roles and, where the customer's role model supports it, to Teams or Business Units for hierarchy-scoped permissions. Active users are migrated; inactive users are flagged for the customer's admin to provision or archive.

openCRX binary attachments linked to objects are extracted via the data export where file access is available. We migrate attachment metadata (filename, content type, creation date, linked object reference) as Annotation records in Dynamics 365 with the file content stored as base64-encoded body content or as a Note with an external file reference. If attachments are stored via openCRX WebDAV, we export on a Linux or macOS client to avoid the Windows WebDAV compatibility issues documented in the openCRX platform page. We flag any attachments that cannot be accessed during export for manual handling.