Microsoft's pitch for dual-write is appealing: Finance and Operations and Customer Engagement share data in near real time through Dataverse, so sales sees true stock and pricing, finance sees real orders, and the two halves of Dynamics 365 behave like one product. Having implemented it several times, the honest summary is that the pitch is achievable, inside boundaries that are worth knowing before you commit.
Dual-write is at its best on the master data spine: customers, vendors, products, pricing. Synchronising these bidirectionally by hand is miserable, endless work, and dual-write does it with framework-level consistency, including initial sync for existing data. If the requirement is "the account team and the finance team should be looking at the same customer", dual-write is the shortest reliable path there.
It also fits the classic prospect-to-cash seam. A quote matures in CE, becomes an order in F&O, and the fulfilment status flows back to where the account manager lives. For organisations running both apps as intended, this is the pattern the feature was built for, and it works.
The pain arrives in three forms. Volume: dual-write is a synchronous, row-by-row mechanism, and pushing high-volume transactional data through it, telemetry, large order books, integration traffic that belongs in middleware, produces throttling and sync errors that take real effort to drain. The framework moves master data and business documents; it is not an integration bus, and estates that treat it as one regret it.
Error handling: when a row fails to sync, someone has to notice, diagnose and replay it, and out of the box that someone is whoever checks the queue. Any serious deployment needs monitoring and alerting built around sync health from day one, because a silent backlog of failed rows becomes a reconciliation problem with a delay fuse.
And customisation drift: dual-write maps assume the entities on both sides still look roughly standard. Estates that have customised heavily on either side spend their implementation budget on map surgery, and every future change to those entities carries a dual-write regression test with it.
The framing we use with clients is simple: dual-write for shared master data and the documents both systems genuinely co-own; Azure integration services for volume, for anything event-driven, and for every system that is not Dynamics; and reporting out of the lakehouse rather than either application. Most of the dual-write deployments that struggle are carrying loads that belonged to the second or third category.
Sequencing matters too. Get master data ownership decided first, one system is the source of truth per entity, however inconvenient that conversation is, because dual-write will faithfully synchronise a governance mess in both directions.
Integration architecture across the estate is part of what our Dynamics 365 practice designs, alongside the implementation work itself.
Marcel Rizzolo is Director of Coder Trove.