- Systems Modernization
- Integration
The integration tax is falling, and it changes which projects are worth doing
For twenty years, connecting systems to each other was the most expensive line in the estimate and the reason most good ideas died. In 2026 that line got dramatically cheaper. Very few organizations have re-run the numbers.
Ask anyone who has costed a software project where the money actually goes, and they will not say the feature you asked for. They will say the connections.
Getting the new system to talk to the ERP. Getting the ERP to talk to the warehouse. Getting the warehouse to acknowledge a message from a tool bought by a department that no longer exists. In most estimates we have ever reviewed, somewhere between a third and half the budget is integration, and integration is where the schedule slips, because it is the part that depends on somebody else's system behaving as documented.
That cost is what killed most sensible projects. Not the idea, not the interface, not the model. The plumbing.
In 2026 the plumbing got substantially cheaper, and the consequence is not "companies can build AI features." It is that a whole category of project that was correctly rejected three years ago should now be reconsidered.
What actually changed
The specific thing that changed is that connecting software to software stopped requiring a bespoke adapter every time.
The Model Context Protocol, or MCP, is an open standard, originally built by Anthropic, that gives an AI model a defined, secure way to reach external data and services: a database, a calendar, a ticketing system, a payments API. Rather than writing a custom integration per pair of systems, a system exposes one MCP server and anything that speaks MCP can use it.
The reason it matters is that it won, quickly and across competitors:
- OpenAI adopted it in March 2025, which is unusual, because it is a rival's standard.
- Google followed in April 2025, and shipped managed MCP servers for its own tools by December.
- In December 2025, Anthropic handed MCP to the Linux Foundation, with OpenAI and Block joining the effort, a deliberate move to make it neutral infrastructure rather than one vendor's asset.
- The official specification landed in May 2026, and GitHub, Slack, Notion, Stripe, Salesforce and X now publish their own servers.
When every major model provider and thousands of enterprise tools converge on one interface, the per-connection cost stops being a negotiation and becomes a commodity. That is the whole story.
It is still maturing, visibly. A July 2026 revision moved session handling from stateful to stateless, so a deployment behind a load balancer no longer needs every machine to know about session IDs issued by another. Arcade's Nate Barbettini described the old behaviour as "a serious pain", an accurate summary of a problem that only appears once you are running at real scale.
The arithmetic that just changed
We started Novyant on the observation that the cost of replacing a bad system collapsed and almost nobody re-ran the numbers. The integration tax is the clearest single example.
Here is the shape of it, in the way a finance director would recognise:
| The old estimate | What it looks like now | |
|---|---|---|
| Connecting to a system with a published interface | Weeks of bespoke adapter work | Days, often hours |
| Connecting to a system with no interface | Months, or "not feasible" | Still hard, but the wrapper is reusable |
| Adding a second consumer of that data | A second integration project | Close to free |
| Maintaining connections as systems change | A permanent tax on every release | Meaningfully smaller, not zero |
That third row is the one that changes decisions. Under the old model, every new consumer of a data source paid the integration cost again, which is why so many organizations have three separate pipelines pulling the same table for three different reports. Under the new one, the second, third and fourth use of a connection cost almost nothing.
Projects are approved or rejected on marginal cost. When the marginal cost of one more connection falls by an order of magnitude, the set of projects that clears the bar changes, even if nobody's strategy changed at all.
What this does not fix
It would be dishonest to stop there, because the protocol solves a narrower problem than the enthusiasm suggests.
It does not fix your data. MCP standardises how a system is reached. It says
nothing about whether the field called client_id means the same thing in two
places, whether the dates are in the same timezone, or whether the customer
record has been duplicated four times. That work is unchanged, and in most
organizations it is the larger half.
It does not fix systems that have no interface. The genuinely painful integrations are the ones where the incumbent software has no API worth the name, or the vendor charges for access, or the data lives in a workbook on a shared drive. A standard does not conjure an interface that does not exist.
It does not fix permissions. A cheap connection is also a cheap way to give something access it should not have. As we wrote about agents outrunning their governance, the ease of connecting is exactly why the number of unmonitored connections is growing.
It does not make the project small. The interface is now the easy part. Migration, parallel running, training and the weeks after go-live are not, and they are still most of the bill.
Which projects should be reconsidered
Four patterns move from "we looked at that and it was not worth it" to worth another look. In each case the thing that changed is the cost of connection, not the idea.
The report someone assembles by hand every week. Almost always, the reason it is manual is that the numbers live in three systems and joining them automatically was quoted at more than the labour cost. That comparison has flipped for a lot of these.
The second system that duplicates data entry. Where staff key the same information into two tools because connecting them was never justified, the justification is now easier, and the ongoing error rate was always the real cost.
The workflow that stops at a system boundary. Processes that run smoothly until they reach a department using different software, then continue by email. The boundary was expensive to cross. It is less so.
The reporting layer nobody could afford. Organizations that gave up on a single view of operations because unifying the sources cost more than the insight was worth. This is the most common one we are asked about, and the one where the old arithmetic is most out of date.
How to test whether it is real for you
Do not start from the protocol. Start from a decision you cannot currently make quickly, and trace backwards to why.
If the answer is "the data exists but is in three systems and nobody has time to join it," that is an integration cost problem, and it is worth re-pricing this year. If the answer is "the data exists but we do not agree what it means," no protocol will help you. That is a definitions problem, and it is cheaper to fix directly than to automate around.
The distinction matters more than any technology choice. We have watched organizations spend eighteen months building a data platform to answer a question that turned out to be unanswerable because two departments counted the same thing differently.
The bottom line
MCP is not exciting, and that is the point. It is a plumbing standard that happened to be adopted by every serious vendor within eighteen months, and the result is that a fixed cost which shaped a generation of software decisions got materially smaller.
The organizations that benefit will not be the ones that talk about the protocol. They will be the ones that go back through the list of things they decided not to build between 2018 and 2024, and check which of those rejections were priced on assumptions that no longer hold.
Most of that list is still sitting in someone's drawer. It is worth reading again.
If you want a view on which of your systems are worth connecting and which are worth replacing, that is what our modernization work starts with, and a consultation is where it begins.
