Migrate from Spiro to Microsoft Dynamics 365 Sales

Discovery and email sync status verification

We audit the Spiro workspace for record counts (Companies, Contacts, Opportunities, Activities), custom field inventory (extracted from UI or confirmed via CSM), Data Collector configuration and Dropbox folder status, email integration health at the time of scoping, and active user count for Dynamics 365 license planning. We also verify which Spiro Workflows or AI-task automations are active so we can document them for rebuild handoff. The discovery output is a written migration scope with record counts, a preliminary object mapping, and a Microsoft Dynamics 365 Sales edition recommendation based on user count and custom field complexity.

Destination schema design in Dataverse

We create the destination schema in the customer's Dynamics 365 environment. This includes provisioning custom attributes on Account, Contact, and Opportunity (with type-mapped Dataverse attribute types matching the extracted Spiro field definitions), configuring a Sales Process with stage values mapped from Spiro Opportunity stages, setting up the SharePoint document management connection for attachment re-linking, and assigning form and view customizations for the migrated custom fields. Schema work happens in the production Dynamics 365 org or a designated Sandbox depending on the customer's change-control requirements.

Attachment URL verification and remediation

We run a pre-migration verification pass against all Spiro attachment URLs to confirm reachability. URLs that return 200 are queued for re-linking in SharePoint during migration. URLs that return 404, 403, or timeout are flagged in a separate inventory with the original Spiro URL, file name, and parent record reference. The customer decides whether to download flagged files manually before the migration window closes or accept them as unrecoverable orphaned attachments in the post-migration report.

Sandbox migration and reconciliation

We run a full migration into a Dynamics 365 Sandbox using production-equivalent record volumes. The customer's admin reconciles record counts across all objects, spot-checks 20-40 random records against the Spiro source for field-level accuracy, and validates that Account-Contact lookup resolution is correct. Any mapping corrections (particularly around stage names, address handling, or custom field type mismatches) are applied before the production migration begins. This step typically takes three to five business days for the customer review cycle.

Production migration in dependency order

We run production migration in record-dependency order: Accounts (from Spiro Companies, with address disambiguation), Contacts (with AccountId resolved), Opportunities (with AccountId, OwnerId, and the StageName mapping applied), Activity history (PhoneCall, Email, Appointment, Task via Dataverse API with batch chunking and exponential backoff), and Attachment re-links (with SharePoint Document Location records created per verified URL). Each phase emits a row-count reconciliation report before the next phase begins. Owner orphaned records are held in a queue until the admin provisions the corresponding Dynamics 365 User.

Cutover, validation, and automation handoff

We freeze Spiro writes during the cutover window, run a final delta migration of any records modified during the window, then enable Dynamics 365 as the system of record. We deliver the Spiro Workflow and AI-task automation inventory document to the customer's admin for rebuild in Microsoft Dynamics 365 Sales or Power Automate. We support a three-day hypercare window for reconciliation issues. We do not rebuild Spiro automations as Power Automate flows inside the migration scope; that is a separate engagement.