Short answer: The integration work created by an ERP or CRM migration is almost never owned by the ERP implementer. The system integrator brings the new platform up; the pressure lands on whoever owns the interfaces between it and the forty other things in your estate that still have to reconcile every night. In most enterprises nobody owns that seam, which is why integration is where migration budgets go to die. i3solutions takes that seam as a named deliverable, with the interfaces treated as owned, governed contracts rather than as glue.
If you are looking for the specific decisions rather than the reassurance, skip to the four decisions.
Why an ERP or CRM migration creates integration pressure
An ERP or CRM migration is not one project. It is a platform project that detonates a second, larger project inside every system that ever depended on the platform you are replacing.
The pattern repeats:
- The ERP partner scopes the ERP. Their statement of work covers the modules, the data conversion, and the go-live. It ends at the boundary of the ERP.
- Everything crossing that boundary is “in scope for the customer.” The nightly file to the warehouse system. The pricing feed. The identity provisioning. The reporting layer. The custom portal.
- Those interfaces were never documented, because the people who built them left, and they worked.
- They surface in UAT, at the worst possible time, priced as change orders.
This is the pressure. It is structural, not a failure of anyone’s diligence, and the fix is to name an owner for the seam before the ERP partner is selected, not after.
The rivals are selling you the benefits. Here are the mechanics.
Most pages answering this question are benefits copy. They will tell you that integrating ERP and CRM gives you a single customer view and better productivity. They will not name a single mechanism, price, or failure mode. That is not an answer, it is a brochure. Here is what actually connects, and where each option bites.
Dual-write, if you are landing on Dynamics 365
Microsoft’s dual-write is the out-of-box infrastructure connecting finance and operations apps with customer engagement apps through Dataverse. It is bidirectional and near real time: a change in Finance writes to Dataverse, and a change in Dataverse writes back to Finance.
Read Microsoft’s own description carefully, because it contains the risk: dual-write is “tightly coupled.” That is a design choice, not a criticism, and it has consequences your ERP partner may not raise:
- It changes your Dataverse schema. Installing the two dual-write Marketplace solutions introduces new concepts into Dataverse, including company and party. If you already have a Dataverse estate with custom apps on it, those concepts arrive whether your apps were designed for them or not.
- Currency precision is a decision. Dual-write offers an opt-in extension of the currency data type to 10 decimal places to prevent loss in transmission between the two sides. Standard Dataverse currency is 4. If you do not need more than 4 you do not opt in, but you should decide that deliberately rather than discover it during reconciliation.
- Date effectivity is added to Dataverse, supporting past, present and future rows on the same table. Powerful, and a trap for any downstream report that assumes one row per key.
- Tight coupling means shared fate. Plan for the play, pause, and catchup modes deliberately, because a paused map is a silently diverging master.
The connector layer, and the governance boundary nobody checks
Most ERP and CRM integration in a Microsoft estate ends up flowing through Power Platform connectors, and that is where governance is won or lost. Microsoft’s data policies classify connectors as certified, custom, virtual, or Model Context Protocol (MCP) connectors, and let an administrator block a connector or a specific action on it.
Two operational facts that decide whether your integration survives a policy change:
- A policy change suspends running work. When a data policy is applied and an existing app or flow violates it, Microsoft puts that app or flow into a suspended or quarantine state, and sets the offending connection to disabled. Anything running against it fails at runtime. An integration built on a connector that governance later blocks does not degrade. It stops.
- Enforcement is not instant. Microsoft states policy changes usually take effect within an hour, and in the most extreme cases the latency for full enforcement is 24 hours. That window is exactly long enough to convince you a change was safe.
The governance question to settle before you build, not after: which connectors are your integration allowed to use, in which environment, and who signs the exception when the answer is no?
When a connector is the wrong tool
High-volume, transactional, or compliance-evidenced flows do not belong in a citizen-developer flow. That is when the estate moves to Azure Logic Apps, Azure Service Bus for durable queuing, Azure API Management for a governed contract at the edge, and Azure Data Factory for bulk movement. The decision is not ideological. It is about volume, error handling, and who has to produce the audit evidence.
The four decisions that set your integration budget
- Who owns the seam? Name a single accountable owner for the interfaces before you sign the ERP statement of work. If the answer is “the ERP partner,” get it in writing, because it usually is not true.
- What is the disposition of every existing interface? Migrate, rebuild, retire. You cannot price the project without this list, and the list is almost never in a document.
- Where does the master live for each entity? Customer, product, vendor, employee. Dual-write assumes an answer. If you have not chosen one, dual-write will choose for you.
- What is the compliance evidence chain? If an auditor asks how a number got from the ERP into the board pack, the answer must be a document, not an archaeology project.
What this costs
Real numbers from our engagements, not ranges invented to look precise:
- A typical mid-enterprise integration project costs $150K-$400K to build, with $25K-$80K in annual operational costs over a 5-year lifecycle.
- A Stabilization Protocol engagement (Phase 1 dependency mapping plus Phase 2 risk-sequenced triage) typically costs between $85,000 and $175,000 for enterprises running four to six Microsoft platforms with 40 to 120 integration touchpoints.
Notice the second number. It is the one that matters, because it is the one you can buy before committing to the migration, and it is the one that tells you whether the first number is $150K or $400K.
Who handles this work
i3solutions has spent three decades on the Microsoft stack, and the integration seam is the part of the estate we are usually called into. The through-line in how we work: interfaces are contracts, they have owners, and they are governed.
- i3solutions unified identity and automated provisioning across systems for 125,000 users by treating the interfaces as owned, governed contracts.
- i3Solutions has delivered this pattern on Microsoft Dynamics 365 CRM integrations in a regulated healthcare environment and on enterprise application integration for a global professional services firm serving 125,000 users.
- One integration for a commercial real-estate operator processed work about 40% faster while retaining roughly 90% of historical data, and that speed repeats on every cycle, not once.
- One modernization retired about $500K a year.
Start with the dependency map. See our Microsoft integration services, our Microsoft integration architecture practice, or hire Microsoft integration developers directly. If your ERP pressure is specifically a Dynamics GP end-of-life clock, start with Dynamics GP to Business Central migration.
Frequently asked questions
Who handles Microsoft integration when an ERP or CRM migration creates pressure?
Usually nobody, until it is expensive. The ERP or CRM implementation partner scopes to the boundary of the new platform, and every interface crossing that boundary lands on the customer as an unowned change order in UAT. i3solutions takes that seam as a named deliverable: we map every dependency and give each interface a disposition of migrate, rebuild, or retire before the platform work starts. A Stabilization Protocol engagement (Phase 1 dependency mapping plus Phase 2 risk-sequenced triage) typically costs between $85,000 and $175,000 for enterprises running four to six Microsoft platforms with 40 to 120 integration touchpoints.
How do we handle Microsoft integration pressure from an ERP or CRM migration?
Name the owner of the interfaces before you sign the ERP statement of work, then buy the dependency map before you buy the migration. The sequence matters: a disposition list of every existing interface (migrate, rebuild, retire) is what turns an unbounded integration risk into a priced scope. In our experience a typical mid-enterprise integration project costs $150K-$400K to build, with $25K-$80K in annual operational costs over a 5-year lifecycle, and the spread inside that range is decided almost entirely by how many interfaces turn out to need a rebuild.
What is dual-write and should we use it?
Dual-write is Microsoft’s out-of-box infrastructure providing near-real-time, bidirectional integration between Dynamics 365 finance and operations apps and customer engagement apps through Dataverse. Use it when Dynamics 365 is both your ERP and your CRM and you want a genuinely shared master. Understand first that Microsoft describes it as tightly coupled, that installing it introduces new concepts such as company and party into your Dataverse schema, that it offers an opt-in extension of currency precision to 10 decimal places, and that it adds date effectivity to Dataverse tables. If you have an existing Dataverse estate with custom apps, those schema changes arrive whether your apps expect them or not.
Why do integrations break after a Power Platform governance change?
Because Microsoft’s data policies do not degrade an offending integration, they stop it. When a data policy is applied and an existing app or flow violates it, Microsoft puts the app or flow into a suspended or quarantine state and sets the connection to disabled, and anything running against it fails at runtime. Enforcement is also not instantaneous: Microsoft states policy changes usually take effect within an hour, and in extreme cases full enforcement takes up to 24 hours. Decide which connectors your integration is permitted to use, in which environment, and who approves exceptions, before you build on them.
Should ERP and CRM integration run on Power Platform connectors or Azure integration services?
It depends on volume, error handling, and audit evidence, not on preference. Power Platform connectors are appropriate for business-user-facing, moderate-volume flows, and they inherit Power Platform data policy governance. High-volume, transactional, or compliance-evidenced flows belong on Azure Logic Apps, with Azure Service Bus for durable queuing, Azure API Management for a governed contract at the edge, and Azure Data Factory for bulk movement. The wrong answer is to let the choice be made implicitly by whoever builds the first interface.
When should we map integration dependencies, before or during the ERP migration?
Before, and it is not close. The dependency map is the only artifact that converts integration from an unbounded risk into a scoped line item, and it is cheapest when it is not being produced under go-live pressure. Map every system that reads from or writes to the platform you are replacing, give each interface an owner and a disposition, and only then let the ERP partner price their statement of work. Buying the map after the ERP contract is signed means paying for the same discovery twice, once as a change order.
