Migrate from OPEX 365 CRM to Nutshell

Schema discovery and custom entity enumeration

We connect to the OPEX 365 CRM Dataverse environment via the Dataverse Web API and run a schema discovery scan against the EntityDefinitions endpoint. This enumerates all standard and custom entities, their attribute metadata (data types, required flags, picklist values), and lookup relationships. We cross-reference this with the customer's Nutshell instance to identify which custom entities have direct Nutshell equivalents and which require custom field or note block mapping. The discovery output is a written entity inventory and field mapping document that serves as the basis for the migration specification.

Data quality assessment and cleansing

We run a data quality report against the extracted OPEX 365 CRM records, identifying incomplete records, duplicate Contacts and Accounts, inconsistent address formats, and missing required fields. We deliver a data quality summary to the customer with row counts for each issue category. Data cleansing (deduplication, format normalization, missing field completion) is performed in the source before export. Post-migration cleanup costs 3-5x more in labor than pre-migration cleansing because the team is learning Nutshell while simultaneously fixing data quality issues, so we flag this as a required phase rather than optional.

Nutshell target schema configuration and sandbox validation

We configure the Nutshell target schema based on the discovery output. This includes provisioning custom fields to match OPEX 365 CRM custom entity fields, configuring deal stages to match the documented OPEX 365 CRM pipeline structure, and setting up Account-Contact and Account-Deal relationship layouts. The migration runs first in a Nutshell sandbox or a temporary test environment so the customer's admin can validate record counts, field mappings, and activity associations before production migration begins. Any mapping corrections are documented and applied to the production migration specification.

Owner reconciliation and User provisioning

We extract every distinct OPEX 365 CRM owner referenced on Contacts, Accounts, Deals, Cases, and Activities and match by email against the Nutshell User table. Owners without a matching Nutshell User are placed in a reconciliation queue for the customer's admin to provision before record import resumes. Migration cannot proceed past the main object import phase until all Owner references are resolved, because owner_id is required on standard Nutshell objects.

Production migration in dependency order

We run production migration in record-dependency order: Accounts (from OPEX 365 CRM Accounts) are created first so that the parent relationship is available for Contacts. Contacts follow with owner_id and parent Account resolved. Deals are imported with AccountId, OwnerId, and close_date mapped. Cases migrate with originating Contact and Account resolved. Activity history (calls, emails, tasks, meetings) migrates after parent records are confirmed, with activityparty resolution applied. Annotations (notes and attachments) are extracted separately and uploaded as a distinct final phase. Each phase emits a row-count reconciliation report before the next phase begins.

Cutover, validation, and workflow inventory handoff

We freeze OPEX 365 CRM writes during cutover, run a final delta migration of any records modified during the migration window, then enable Nutshell as the system of record. We deliver a written inventory of OPEX 365 CRM workflows, automations, and pipeline configurations with recommended Nutshell equivalents for the customer's admin to rebuild. We support a one-week hypercare window where we resolve reconciliation issues raised during initial Nutshell use. We do not rebuild OPEX 365 CRM workflows as Nutshell automations inside the migration scope; that work is a separate engagement.