Migrate from Wetroo to Microsoft Dynamics 365 Sales

Discovery and Wetroo API scoping

We audit the source Wetroo account via API to capture all Contacts, Leads, Deals, pipeline definitions, custom field definitions, and owner records. We assess the export scope against the customer's requirements, confirm which custom fields exist on each object, and identify any pipeline stages with non-standard names that require a mapping decision. We also document which Wetroo automation playbooks are active so they can be inventoried for the rebuild handoff. We flag the WhatsApp conversation limitation during this step and advise the customer to export critical chat history from WhatsApp directly if it is required for records.

Schema design and Microsoft Dynamics 365 Sales configuration

We design the destination schema in Microsoft Dynamics 365 Sales . This includes provisioning custom fields on Contact, Lead, and Opportunity (matched to Wetroo custom field types), configuring Sales Processes and Record Types for each Wetroo pipeline, and creating the stage value mappings with probabilities. We create the wetroo_record_id__c custom field on Contact, Lead, and Opportunity to preserve the source Wetroo record identifier for cross-reference during validation. Schema is validated in a Dynamics 365 sandbox environment before 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 reconciles record counts across all objects, spot-checks 20-30 records against the Wetroo source for field-level accuracy, and confirms the pipeline stage mapping covers all active Wetroo stages. Any mapping corrections, missing custom fields, or stage mapping gaps are resolved here. Sandbox sign-off is required before production migration begins.

Owner and user reconciliation

We extract every distinct Wetroo Owner referenced on Deal and Lead records and match by email against the Microsoft Dynamics 365 Sales 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 Wetroo user is still active in the organization). Migration cannot proceed past this step because OwnerId references are required on Opportunity and Lead records.

Production migration in dependency order

We run production migration in record-dependency order: Contacts (with custom fields), Leads (with owner resolved), Opportunities (with Contact lookup via wetroo_record_id__c, Owner resolved, and Record Type set per pipeline mapping), custom field values for all objects. Each phase emits a row-count reconciliation report before the next phase begins. We apply dynamic exponential backoff during API extraction from Wetroo to handle any undocumented throttling responses.

Cutover, validation, and automation handoff

We freeze Wetroo writes during cutover, run a final delta migration of any records modified during the migration window, then enable Microsoft Dynamics 365 Sales as the system of record. We deliver the automation playbook inventory document to the customer's admin team for rebuild in Microsoft Dynamics 365 Sales or Power Automate. We support a five-business-day hypercare window where we resolve any reconciliation issues raised by the sales team. We do not rebuild Wetroo automation playbooks as Dynamics 365 workflows inside the migration scope; that is a separate engagement.