Migrate from Pawa to Microsoft Dynamics 365 Sales

Discovery and Pawa API enumeration

We request Pawa API credentials and enumerate the live endpoints to validate which objects (Contacts, Companies, Deals, Users, Tags) are accessible and what custom fields exist on each. We export record counts per object and identify any Pawa-specific field types that require transformation at the destination. If a bulk export endpoint is not available, we work with the customer to extract data via any available CSV or report feature and validate the export against the live schema. The discovery output is a written migration scope document covering record counts, schema gaps, and a preliminary field map.

Dynamics 365 schema preparation

We configure the destination Dynamics 365 environment before any records are written. This includes creating custom fields discovered from Pawa (with correct field types matching Dynamics 365's Dataverse schema), setting up picklist values for any Pawa enumerated fields, and working with the customer's admin to ensure the migration user has the required Dataverse roles and permissions. If the customer uses a Sandbox environment, we deploy schema changes there first for validation.

Record dependency mapping and sequencing

We identify the dependency order for all migrating objects. Accounts (from Pawa Companies) must be written before Contacts because Contact requires a parentcustomerid lookup to Account. Owner resolution against Dynamics 365 Users must complete before Opportunities are imported because Opportunity requires an OwnerId. We build a sequencing plan and run a small test import (50-100 records per object) into the Sandbox to validate the dependency chain before the production migration begins.

Production migration with rate-limit handling

We run the production migration in the sequenced order: Accounts, Contacts, Deals (as Opportunities), Tags (as Notes), and Users (as User reconciliation). The Dynamics 365 Dataverse Web API handles writes with exponential backoff on 429 responses and batch chunking for sets exceeding 100 records. The migration user has application-user privileges to maximize per-license API allocation. Each phase emits a row-count reconciliation report showing records written, rejected, and pending before the next phase begins.

Cutover, validation, and automation inventory delivery

We freeze Pawa writes during the cutover window, run a final delta import of any records modified since the last extraction, then mark Dynamics 365 as the system of record. We validate a statistical sample of migrated records against the source and deliver the reconciliation report to the customer. We do not rebuild Pawa automations or workflows inside the migration scope; instead, we deliver a written inventory of each Pawa automation (name, trigger, actions) with a Microsoft Dynamics 365 Sales equivalent recommendation for the customer's admin or a Dynamics 365 partner to implement post-migration.

Attachment handoff and post-migration support

We provide the customer with a structured list of all attachment-bearing records in Pawa before migration, noting the record type, record ID, and attachment filename. The customer downloads and re-uploads files to Dynamics 365 manually or via a separate file migration tool. We remain available for a one-week hypercare window following go-live to resolve any data quality issues raised by the customer's team during the first business week in Microsoft Dynamics 365 Sales .