Migrate from Talisma to Microsoft Dynamics 365 Sales

Discovery and Talisma configuration export coordination

We coordinate with the Talisma administrator to produce a configuration export that enumerates all entities, standard fields, and custom field definitions. We audit Talisma's object structure, active workflows, interaction log volume, attachment count, and product catalog. We also identify the Talisma attachment storage backend (file system path, blob, or object store) so that we can plan for file extraction and re-encoding. Discovery produces a written scope with record counts per entity, a custom field inventory, and the workflow documentation list. We begin the two-week discovery window before any data extraction begins.

Destination schema design in Microsoft Dynamics 365 Sales

We design the Microsoft Dynamics 365 Sales destination schema in a Sandbox environment. This includes creating custom fields to match unmapped Talisma custom fields, configuring Lead and Contact Record Types for the enrollment-split rule, setting up Case Record Types per Talisma case type, configuring Option Set fields with integer values that match the Talisma source data, and creating Product2 records and Standard Price Book entries. Schema is validated against the Talisma configuration export before any production migration begins.

Sandbox migration and reconciliation

We run a full migration into a Dynamics 365 Sandbox using production-like data volume. The customer's RevOps lead reviews record counts in Dynamics 365 against the Talisma source extract, spot-checks 25-50 records per entity for field-level accuracy, and validates that parent-record lookups (AccountId on Contact, ContactId on Case, OwnerId across all entities) resolve correctly. Any mapping corrections, dropped custom fields, or option-set mismatches are resolved in Sandbox before production migration begins.

User provisioning and owner reconciliation

We match Talisma user records to Dynamics 365 Users by email address. Any Talisma user without a matching Dynamics 365 User is placed in a reconciliation queue for the customer's admin to provision. Migration cannot proceed past user reconciliation because OwnerId references are required on Cases, Contacts, and Leads. We provide a user mapping spreadsheet listing every Talisma user, their matched or unmatched Dynamics 365 User, and their Talisma role for the admin to use when provisioning missing accounts.

Production migration in dependency order

We run production migration in record-dependency order: Accounts first (from Talisma Organizations), then Contacts and Leads with the enrollment-split rule applied and AccountId resolved, then Cases with ContactId and AccountId resolved, then Products and Price Book entries, then Interaction Logs via Dataverse API with batch chunking and exponential backoff, then Attachments with file re-encoding and exception logging, then Chat and Cobrowse session data as structured Note records. Each phase emits a row-count reconciliation report before the next phase begins. We freeze Talisma writes during cutover and run a final delta migration of any records modified during the migration window.

Cutover validation and workflow rebuild handoff

We enable Microsoft Dynamics 365 Sales as the system of record after the final delta migration confirms zero record divergence. We deliver the Talisma workflow inventory document, the custom field mapping reference, the option-set value translation table, and the attachment exception log. We support a one-week hypercare window where we resolve any record-level reconciliation issues. We do not rebuild Talisma workflows as Power Automate or Dataverse workflows inside the migration scope; that is a separate engagement for the customer's admin team or a Dynamics 365 implementation partner.