Phased D365 cutover: dual-write for legacy-system coexistence

Enterprise D365 implementations rarely happen as a single weekend cutover. Real programs phase out legacy systems in stages - module by module, or business unit by business unit - with users on both systems during transition. The architecture has to support both systems seeing the same master data in near real-time, without users caring which one they're in.

The pattern teams sometimes reach for fails. Another one is exactly what Microsoft shipped for this scenario.

Two approaches that don't scale

Power Automate manual daily sync. Scheduled flows that pull from legacy each morning and push into D365. Works for dozens of records, fails for the real volume enterprises carry. Runs overnight; users see stale data during the day; transactions edited in legacy after the sync are invisible to D365 until tomorrow.

DMF Excel files on a schedule. Same failure mode with more steps. Excel as the intermediate layer makes debugging hard and adds a manual handoff.

Custom .NET service to a common data warehouse. A new application to maintain for the duration of the phased rollout. Teams building this discover they've created a third system to keep in sync, and the "common data warehouse" becomes the new source-of-truth debate.

The pattern that ships with the platform

Dual-write between D365 F&O and Dataverse, with the legacy system integrating into Dataverse rather than F&O directly.

Why this works:

• Dual-write provides near real-time bi-directional sync between F&O and Dataverse (latency measured in seconds, not hours)
• Dataverse is an easier integration target for legacy systems than F&O (simpler APIs, more connector options, faster writes)
• Legacy integrates into Dataverse via its preferred method (REST APIs, Power Automate cloud flows, custom connectors, direct SQL for on-prem systems via Data Gateway)
• Users on either system see the same data within seconds
• As each legacy module retires, the integration into Dataverse for that module turns off; no change to F&O needed

How the pattern plays out during transition

Consider a phased cutover rolling out F&O module by module:

Month 1-3: HR and Finance modules live in F&O. Supply Chain still on legacy. Dual-write active for customer, vendor, product, employee tables. Legacy Supply Chain writes inventory updates into Dataverse via Power Automate; dual-write syncs to F&O. F&O writes financial postings; dual-write syncs back to Dataverse where legacy Supply Chain can read them for downstream reporting.

Month 4-6: Supply Chain migrates to F&O. The legacy Supply Chain integration into Dataverse retires. Dual-write continues for whatever still lives on the Customer Engagement side (Sales, Customer Service).

Month 7+: Only Customer Engagement apps remain on the non-F&O side. Dual-write is permanent at this stage because it's the supported integration between F&O and CE, not a transitional artifact.

Data consistency during cutover

During the overlap period, conflicts happen. Dual-write conflict resolution rules matter more than they do in steady state:

• Per-table source of truth during transition. For accounts (customers), F&O might be master while legacy is still writing too - decide which side wins and document per-table.
• Cutover order matters. Migrate tables in an order that reduces conflict - master data first (customers, vendors, products), transactional data follows once master is stable.
• Initial sync strategy for each table follows the full documented playbook (snapshot + reconcile, or DMF + delta).
• Monitoring during transition is non-negotiable. Dual-write error queue watched hourly, not weekly.

Exception handling for the gap cases

Some tables won't have dual-write maps out of the box. Two options:

Extend dual-write with custom table maps. Microsoft supports authoring custom maps for custom tables. The catch: your legacy integration has to build for the Dataverse schema, not a custom F&O schema.

Bypass dual-write for specific tables. For high-volume operational data (inventory transactions, time entries), direct F&O integration via data entities may be cleaner. Dual-write isn't mandatory for every table.

Mix and match per-table based on volume and frequency.

Governance during the overlap

A few disciplines carry projects through the messy middle:

• One program owner for the integration layer. Disputes about "which system is master for X" escalate here, not to individual module teams.
• Cutover calendar published and visible. Every retirement date communicated to downstream consumers.
• Legacy freeze plan. For each legacy module, publish the date after which writes go into F&O only and legacy becomes read-only until decommission.
• Data quality metrics. Sample 100 random records from each side daily, compare, alert on drift.

What ships with the architecture

A working phased cutover using dual-write has: dual-write table maps active for shared master data, legacy-to-Dataverse integrations for tables not yet owned by F&O, conflict resolution rules documented per table, initial-sync plans executed per table transition, monitoring dashboard tracking dual-write error queue and reconciliation metrics, and a cutover runbook owned by the program.

The pattern uses what the platform ships. That's the recommendation: don't build a data warehouse to solve a transition problem that dual-write already solves.