Migrate from AllClients to Microsoft Dynamics 365 Sales

Discovery and export scoping

We audit the AllClients account via the Data Migration menu export functions — pulling Contact.csv, Notes.csv, and any custom field exports. We cross-reference the contact count displayed in AllClients against the exported row count to identify any tier-limit suppression. We capture AllClients user list (Name and Email) for Owner mapping, list all active Workflows with their definition screenshots, and inventory email templates and campaign names. The discovery output is a written scope document covering record counts, custom field definitions, notes join health, and the workflow template inventory — plus a recommendation on the Microsoft Dynamics 365 Sales edition (Professional at $65/user/mo or Enterprise at $105/user/mo) suited to the migration complexity.

Notes join and data cleansing

We process the Notes.csv against Contact.csv using email address as the join key. Any notes with no matching contact email are extracted to an orphaned notes report for the customer's admin to reconcile. We also validate that all required fields for Microsoft Dynamics 365 Sales Contact (FirstName, LastName, Email) are populated in every row — AllClients allows contacts to be created without a last name or email, which will fail the Microsoft Dynamics 365 Sales mandatory field check on insert. Cleansed rows are flagged and corrected or held with a note in the migration report.

Dataverse schema provisioning

We create all required custom columns on the Dataverse Contact table before migration — one column per AllClients custom field, typed to match (nvarchar, integer, decimal, datetime2). We also pre-create the Account table entries for any AllClients company-level data (if the customer used the company field on contacts) and configure the Owner lookup mapping from AllClients user emails to Microsoft 365 User records in the destination tenant. The schema is deployed to a Microsoft Dynamics 365 Sales Sandbox for validation before production migration begins.

Sandbox migration and reconciliation

We run a full migration into a Microsoft Dynamics 365 Sales Sandbox using the complete exported dataset. The customer's admin validates 25-50 randomly sampled Contact records against the source AllClients data, checks that notes are visible on the correct Contact activity timelines, and confirms custom field values are populated. Any field mapping corrections, notes join failures, or Owner resolution gaps are corrected in the migration scripts before production migration. This step also validates that Dataverse validation rules, required-field rules, and column limits do not reject rows.

Production migration in dependency order

We run production migration in the following order: Contact records first (with OwnerId resolved and notes merged inline), followed by Task records (with OwnerId resolved and RegardingObjectId pointing to the parent Contact row ID from Phase 1), followed by Campaign records and email template imports. File attachments download from AllClients and re-upload as Annotation documents linked to the parent Contact. Custom field values populate via the Dataverse UpdateContact custom column endpoint after each Contact is inserted. Each phase emits a row-count reconciliation report comparing inserted row count to exported source row count before the next phase starts.

Cutover, validation, and workflow handoff

We freeze AllClients write access during the cutover window and run a final delta migration of any records created or modified after the initial export timestamp. We validate the Microsoft Dynamics 365 Sales production environment against the AllClients reconciliation checklist and deliver the workflow template inventory document to the customer's admin. We support a three-day hypercare window for reconciliation issues. Post-migration, the customer cancels or downgrades the AllClients account — we advise completing the cancellation only after the Microsoft Dynamics 365 Sales data has been validated and accepted. We do not rebuild AllClients workflows as Power Automate flows inside the migration scope; that work is a separate engagement.