Migrate from Cirqll to Microsoft Dynamics 365 Sales

Discovery and scoping

We audit the Cirqll account by querying all accessible API endpoints to build a complete inventory of Customers, Leads, Tasks, Activities, Notes, Calendar Events, and Users. We confirm the data volume for each object, identify any Cirqll plan storage limits that affect document scope, and probe undocumented fields via trial exports. We also confirm the destination Microsoft Dynamics 365 Sales edition, verify the target Dataverse environment URL, and collect any existing Account or User provisioning that the customer has already completed in the destination. The discovery output is a written migration scope with record counts, a field-probing report on the Cirqll schema, and a confirmation of which Cirqll objects will migrate and which will be handed off as admin rebuild tasks.

Schema design and Account-Contact split planning

We design the destination Dynamics 365 schema before any data moves. This includes provisioning any custom fields needed to capture Cirqll properties that do not map to standard Dynamics 365 fields, configuring Account-Contact lookup requirements, and setting up Lead fields to receive Cirqll Lead data. We also plan the Owner mapping strategy (User lookup by email) and identify any Dynamics 365 validation rules that could reject Cirqll records. Schema is deployed to a Sandbox environment first for validation against a sample import before production migration begins.

Sandbox migration and reconciliation

We run a full migration into a Dynamics 365 Sandbox using a representative subset of Cirqll data. The customer's admin or RevOps lead reconciles record counts across all objects, spot-checks 25-50 records against the Cirqll source, and reviews the mapping for Contacts, Leads, Tasks, and Activities. Any field mapping corrections, validation rule adjustments, or custom field additions happen in this phase. We do not proceed to production migration until the sandbox run is signed off. This step also surfaces any data quality issues (duplicates, missing required fields, malformed data) that require a pre-migration cleansing pass.

Owner reconciliation and User provisioning

We extract every distinct Cirqll owner referenced on Leads, Tasks, and Activities and match by email against the Dynamics 365 User table in the destination org. Any Cirqll owner without a matching Dynamics 365 User enters a reconciliation queue. The customer's admin provisions missing Users in Dynamics 365 before the production migration begins. This step is mandatory because Dynamics 365 Tasks and Events require an OwnerId reference that cannot be nulled or defaulted during import.

Production migration in dependency order

We run production migration in the correct dependency sequence: Accounts first (from Cirqll Customers), then Contacts with AccountId lookups resolved, then Leads, then Tasks and Events with OwnerId references resolved, then Notes. Each phase emits a row-count reconciliation report before the next phase begins. We pace all Cirqll API calls to stay under the 100 requests per minute limit, monitor for HTTP 429 responses, and back off dynamically if throttling occurs. Documents migrate in a secondary pass after the primary migration completes, using the download-and-reupload workflow scoped during discovery.

Cutover, validation, and automation handoff

We freeze writes to Cirqll during the cutover window, run a final delta migration for any records modified during the migration run, then confirm Dynamics 365 as the system of record. We deliver a written inventory of all Cirqll automations, tasks, and reminders requiring rebuild in Power Automate or Dynamics 365 workflows. We support a one-week hypercare window to resolve any reconciliation issues raised by the sales team after go-live. We do not rebuild Cirqll automations or workflows as Power Automate flows inside the migration scope; that is a separate engagement for your admin team or a Dynamics 365 partner.