Migrate from CentraHub CRM to Microsoft Dynamics 365 Sales

Discovery and data export request

We audit the customer's CentraHub CRM instance for record counts across Leads, Accounts, Contacts, Deals, Tasks, Appointments, and Activities. We confirm the CentraHub edition tier, verify whether the account uses the Centra Hosted or cloud deployment (which affects database access), and request full CSV exports from the customer including all custom field columns. We also extract workflow definitions as JSON, capture the custom field schema per module, and inventory any file attachments stored via Dropbox or Box integrations. The discovery output is a written migration scope with record counts, a list of excluded data (attachments, activity logs not in base export), and a field map skeleton.

Lead-Contact split rule design and Dynamics 365 schema provisioning

We design the Lead-Contact qualification split rule based on the customer's CentraHub lead status values and any custom fields indicating deal readiness. We provision the Dynamics 365 destination environment: custom fields are created in Dataverse matching the CentraHub schema, option sets are defined for picklist fields, Sales Processes and Record Types are configured for each CentraHub pipeline, and custom fields centrahub_id__c are added to Lead, Account, Contact, and Opportunity for cross-system reconciliation. The schema is deployed to a Dynamics 365 Sandbox first for validation.

Data cleansing and transformation

We run a data quality pass on the exported CSV files: duplicate Account records are merged using domain-based deduping, incomplete Contact records with missing email or phone are flagged for customer review, and all custom field values are validated against the declared data type with mismatches written to a correction report. The Lead-Contact split is applied as a transform: for each CentraHub Lead record, we determine whether it qualifies as a Dynamics 365 Contact (already has an Account link) or remains a Dynamics 365 Lead. The output is a set of clean, typed CSV files ready for Dynamics 365 API ingestion.

Sandbox migration and reconciliation

We run a full migration into the Dynamics 365 Sandbox using production-like data volume. The customer's RevOps or IT lead spot-checks 25-50 records across each object against the source CentraHub data, validates that Account-Contact relationships resolved correctly, confirms that Deal stage names mapped to the correct Dynamics 365 StageName values, and reviews the activity timeline for any records that failed import. Any mapping corrections are documented and the sandbox migration is re-run until reconciliation passes. This step typically takes one to two weeks.

Owner reconciliation and User provisioning

We extract every distinct CentraHub user referenced on Leads, Accounts, Contacts, Deals, and Activities and match by email against the destination Dynamics 365 User table. Any CentraHub user without a matching Dynamics 365 User is held in a reconciliation queue. The customer's Dynamics 365 admin provisions missing Users before production migration begins. Owner resolution is required before record import can proceed because ownerid is a required reference on most standard objects in Dynamics 365.

Production migration and cutover

We run production migration in dependency order: Accounts first, then Leads, then Contacts with AccountId resolved, then Opportunities with AccountId, OwnerId, and RecordTypeId resolved, then Tasks and Appointments via Dataverse Web API. Each phase emits a row-count reconciliation report before the next phase begins. We freeze writes to CentraHub during the cutover window, run a final delta migration of any records modified during migration, re-attach file downloads from Dropbox and Box to the matching Dynamics 365 records, and enable Dynamics 365 as the system of record. We deliver the workflow inventory document to the customer's admin for Power Automate rebuild and offer a one-week hypercare window for reconciliation issues.