Migrate from Bloomr to Microsoft Dynamics 365 Sales

API exploration and data profiling

We begin every Bloomr engagement by probing the source system live. This step attempts to confirm authentication method (API key, OAuth, or basic auth), enumerate available endpoints for contacts, accounts, deals, activities and users, test pagination behavior, and measure rate limits. If an API is accessible, we profile the schema by querying a sample of records to identify field names, data types, custom field names, and any object relationships. If no API is accessible, we verify CSV export capability from the Bloomr UI and identify which fields are included in the export. The output is a written data profiling report that defines the migration path: API-driven or CSV-driven.

Schema design in Dynamics Sandbox

We design the destination schema in a Microsoft Dynamics 365 Sales Sandbox before touching production. This includes configuring Record Types and Sales Processes mapped from Bloomr pipeline and stage data, creating custom fields on Contact, Account, and Opportunity to receive Bloomr custom field data, designing the Lead-Contact split rule based on Bloomr record data signals, and provisioning SharePoint document locations if attachment migration is in scope. Schema is deployed via the Dataverse Web API (POST /api/data/v9.2/EntityDefinitions) and validated with a test import of a small record set before proceeding.

Owner reconciliation and User provisioning

We extract every distinct Bloomr Owner referenced on Contact, Account, Deal, and Activity records and match by email against the destination Dynamics User table. Owners without a matching Dynamics User go to a reconciliation queue. The customer's Dynamics admin provisions any missing Users and confirms whether provisioned Users should be Active (if the Bloomr owner is still active) or Inactive (for historical owners). Migration cannot proceed past this step because OwnerId references on Opportunity, Contact, and Activity must resolve at insert time. We validate the full user mapping before the first production import.

Sandbox migration and reconciliation

We run a full migration into the Dynamics Sandbox using production-representative data volume. The customer's RevOps lead reviews record counts (Contacts imported, Accounts imported, Opportunities imported, Activities imported), spot-checks 25-50 randomly sampled records against the Bloomr source for field accuracy, and validates that the Lead-Contact split rule applied correctly. Any mapping corrections, field type adjustments, or schema changes are made in the Sandbox and re-validated. We do not proceed to production migration until the Sandbox migration is signed off.

Production migration in dependency order

We run production migration in record-dependency order: Accounts (from Bloomr Companies), Leads and Contacts (with AccountId resolved and the split rule applied), Opportunities (with AccountId, OwnerId, and RecordTypeId resolved), and Activity history (Tasks, Events via Dataverse Bulk API with batch chunking and exponential backoff on rate limit responses). Each phase emits a row-count reconciliation report before the next phase begins. If CSV export is the migration path (no API), we use the Dataverse Bulk API file import endpoint with equivalent dependency ordering and field mapping applied during transform.

Cutover, validation, and automation handoff

We freeze Bloomr writes during the cutover window, run a final delta migration of any records modified during the migration period, then enable Microsoft Dynamics 365 Sales as the system of record. We deliver a written automation audit template listing every Bloomr workflow and sequence discovered (or documented from UI) with trigger, conditions, actions, and a recommended Power Automate or Dynamics Flow equivalent. We support a one-week post-cutover window for reconciliation issues. We do not rebuild Bloomr automations as Dynamics workflows inside the migration scope; that is a separate engagement or an internal admin task.