Migrate from TOTUS Marketing to Microsoft Dynamics 365 Sales

TOTUS Contact records require a split decision during scoping because Dynamics 365 separates unqualified prospects (Lead) from qualified business relationships (Contact attached to Account). We use the customer's TOTUS contact records to infer a qualification rule from available properties (status field, account association flag, or deal attachment count) and apply it during migration. Unqualified contacts land on Lead; qualified contacts land on Contact with AccountId resolved. The original TOTUS contact identifier is preserved in a custom field totus_contact_id__c on both Lead and Contact for reconciliation.

TOTUS Company records map to Dynamics 365 Account. If the TOTUS schema exposes a domain or website field, it becomes the Account Website and the dedupe key during import. Account is inserted before any Contact or Opportunity migration to satisfy the required AccountId Lookup on Contact. If TOTUS stores multiple address types (billing, shipping), the primary address migrates to Address1 and secondary addresses to Address2 or custom address fields configured in the destination org.

TOTUS Deal records map to Dynamics 365 Opportunity. The TOTUS deal stage property maps to the Dynamics 365 StageName using a stage-mapping table created during discovery. Closed-Won and Closed-Lost outcomes migrate with CloseDate and the Dynamics 365 standard stage set (not the TOTUS stage values). Amount fields migrate to Amount; if TOTUS uses separate estimated and actual amount fields, both migrate to Amount with a note to the admin to update actual after close.

TOTUS deal pipelines map to Microsoft Dynamics 365 Sales Processes and stage values. During discovery, we enumerate every distinct pipeline and stage in TOTUS and create a corresponding Microsoft Dynamics 365 Sales Process with stage values that match the customer's business process names. Probability percentages are computed from TOTUS stage data where available and set on each stage. If TOTUS supports pipeline-specific stages, each pipeline becomes a separate Sales Process.

TOTUS custom fields on Contact, Company, and Deal map to Dynamics 365 custom fields (schema name ends in __c) of the closest matching Dataverse type: text fields map to Text, numeric fields map to Decimal or Whole Number, dates map to DateTime, and picklists map to Option Sets. Option Set values are enumerated from TOTUS data during discovery and recreated as Option Set Option values in Dynamics 365 with the same label and integer value.

TOTUS owner records map to Dynamics 365 User by email address. The customer provisions matching User records (active or inactive status matches the TOTUS owner status) before migration begins. Any TOTUS owner without a matching Dynamics 365 User is placed in a reconciliation queue and flagged in the pre-migration report. OwnerId on Contact, Account, and Opportunity is set by resolving the email address at migration time.

TOTUS engagement records (calls, emails, meetings, tasks) map to Dynamics 365 Task, Event, and EmailMessage objects. Call engagements become Task with TaskSubtype = Call and CallDurationInSeconds in a custom field. Email engagements become Task (activity timeline entry) plus EmailMessage (email body and headers). Meeting engagements become Event with StartDateTime and EndDateTime preserved and attendee resolution against migrated Leads and Contacts. WhoId on Task points to the migrated Lead or Contact; WhatId points to the related Account or Opportunity.

TOTUS product or item records map to Dynamics 365 Product2. If TOTUS exposes a SKU field, it maps to ProductCode. Standard Price Book entries are created during import so that Line Items reference the correct price list. Product is migrated before Line Items to satisfy the Product2Id lookup.

If TOTUS API exploration during discovery reveals proprietary or custom objects beyond the standard Contact-Company-Deal model, we pre-create corresponding custom entities in Dynamics 365 (via the Dataverse SDK) before data migration begins. Custom entity schema, including all attributes and lookup relationships, is validated in a Sandbox before production migration. The customer reviews and approves the discovered custom object inventory in the pre-migration report.