Migrate from Unim to Microsoft Dynamics 365 Sales

Schema discovery against live Unim API

We introspect the customer's live Unim instance via the custom-fields API endpoint, resolving ModelID references for every standard entity (Contacts, Companies, Activities) and cataloguing all active custom fields and their datatypes. For any bespoke object types defined at the application level, we inspect the entity definitions to capture the full schema. The discovery output is a written schema map (entity name, field name, datatype, nullable, lookup relationships) that the customer reviews and approves before migration code is written. This step cannot be skipped and cannot be estimated without live access.

Destination schema provisioning in Dynamics 365

We create the matching Dynamics 365 custom entities (tables) and custom fields using the Dataverse Web API or solution metadata deployment. Lookup relationships between custom entities and standard entities (Contact, Account) are defined at this stage. The schema is deployed into a Dynamics 365 Sandbox environment first for validation. We coordinate with the customer's Dynamics 365 admin on any required security roles, field-level security, and validation rules that may affect the migration user.

Sandbox migration and reconciliation

We run a full migration into the Dynamics 365 Sandbox using production-equivalent data volume. The customer's RevOps lead reconciles record counts (Contacts in, Accounts in, Activities in), spot-checks 25-50 records against the Unim source, and signs off the field map and datatype resolution before production migration begins. Any mapping corrections—wrong datatype, missed custom field, dropped relationship—happen in sandbox, not in production.

Owner reconciliation and User provisioning

We extract every distinct Unim Owner referenced across Contacts, Companies, Activities, and custom object records and match by email against the Dynamics 365 destination org's User table. Owners without a matching User go to a reconciliation queue. The customer's Dynamics 365 admin provisions any missing Users (active or inactive depending on whether the original Unim owner is still employed). Migration cannot proceed past this step because OwnerId is a required reference on most standard objects.

Production migration in dependency order

We run production migration in record-dependency order: Accounts (from Unim Companies), Contacts (with ParentAccountId resolved), Activities (Tasks, Events, EmailMessages via Dataverse Bulk API), custom objects (with their parent-record lookups resolved), and files (paginated extraction with retry logic). Each phase emits a row-count reconciliation report and error log before the next phase begins. We use exponential backoff on API rate-limit responses and batch chunking to maintain throughput without overwhelming either the Unim export API or the Dynamics 365 Dataverse API.

Cutover, validation, and workflow inventory handoff

We freeze Unim writes during cutover, run a final delta migration of any records modified during the migration window, then enable Dynamics 365 as the system of record. We deliver a written inventory of every active Unim workflow and automation for the customer's admin to rebuild in Dynamics 365 using Power Automate or Dynamics 365 workflows. We do not rebuild workflows as part of the migration scope. We support a one-week hypercare window where we resolve any reconciliation issues raised by the customer's team during the first days of live operation.