Migrate from InTouch to Microsoft Dynamics 365 Sales

Custom field creation required before data loads

Dynamics 365 Sales is built on Dataverse, which requires explicit custom field creation via the solution designer or API before data can be written to those attributes. InTouch matter-template custom fields have no automatic Dataverse equivalent—each field's data type (text, integer, date, pick-list) must be matched to a corresponding Dataverse attribute type and created as a new_ prefixed column in the target table. FlitStack generates the full custom field creation manifest from your InTouch custom field export, but those fields must exist in the Dynamics 365 environment before the bulk load phase begins. This is a pre-requisite step that adds 1–3 hours of schema setup time to the migration window.

N:N contact-to-company associations collapse to primary AccountId

InTouch allows a single contact to be associated with multiple companies natively. Dynamics 365 Contact records have a single primary AccountId lookup plus Account Contact Relationships for secondary associations. When a contact has more than one InTouch company association, FlitStack selects the most-recently-modified company as the primary AccountId and surfaces the others as Account Contact Relationship records. This means the primary AccountId on the Dynamics 365 Contact may differ from what your InTouch data shows if the most-recently-modified rule does not match your business expectation—your team should review the selection rule before the migration commits.

InTouch activity history requires type-splitting across Dynamics 365 entities

InTouch stores calls, emails, meetings, and notes as flat engagement logs. Dynamics 365 splits these across Task (calls and emails), Appointment (meetings), and Annotation (notes)—each with a different entity structure, API payload, and activity-party linking model. FlitStack parses the InTouch engagement type field and routes each record to the correct Dynamics 365 entity during the load. The key risk is that ActivityParty records (which link an activity to its Contact or Account) must be created as separate records after the parent activity, which adds API round-trips and can extend the activity-migration phase for large engagement volumes.

Owner resolution by email match can leave records unassigned

InTouch owner_id maps to Dynamics 365 OwnerId, which requires a matching SystemUser record. FlitStack resolves owners by email address against the Azure Active Directory-synced user list in your Dynamics 365 tenant. Any InTouch owner whose email does not match an existing Dynamics 365 user is flagged as unmatched before the migration begins. If unresolved, those records land under the designated fallback owner or remain unassigned. This risk is highest for InTouch setups with external contractors, legacy users, or deactivated accounts still assigned as record owners—your admin should audit the owner list before migration kicks off.

Sales Professional custom-table limit can force Enterprise upgrade

Dynamics 365 Sales Professional licenses cap custom tables at 15. InTouch implementations with more than 15 custom fields (counted as custom tables in Dataverse) or custom objects require a Sales Enterprise license to accommodate the full schema after migration. FlitStack counts the unique custom field tables in your InTouch export during the assessment phase and alerts you if your target license tier needs adjustment. This is a licensing cost impact, not a data loss risk—FlitStack can migrate the data regardless of license tier, but Dynamics 365 will enforce the custom-table ceiling on the environment post-migration.