How to Integrate Existing Systems with New Software Solutions

Why Integration Is Where the Budget Actually Goes

Before the method, the evidence for why the method matters. Two measurements explain most of what goes wrong.

The connectivity gap is widening

MuleSoft's 2026 Connectivity Benchmark Report, published 5 February 2026 and based on a survey of 1,050 IT leaders globally, reports that the average organization manages 957 applications and has connected 27% of them.

Comparing that against the prior edition is the part worth pausing on. The 2025 Connectivity Benchmark Report, published 29 January 2025, measured 897 applications with 29% integrated. In one year the application estate grew by roughly 60 applications while the connected share fell two points.

The 2026 report attaches a consequence to that gap: 71% of respondents agree their IT infrastructure makes systems overly dependent on one another, and 26% of IT projects on average were not delivered on time in the previous 12 months.

A third of engineering capacity already goes here

Your capacity planning needs the second measurement more than the first. The 2026 report puts IT time spent designing, building, and testing new custom integrations at 36%. The 2025 edition put it at 39%.

A three-point improvement over a year, against an estate that grew by 60 applications, is a real gain. It is also a reminder of the scale of the baseline: more than a third of available engineering time is spent on plumbing rather than on the product.

Step 1: Inventory What You Have Before You Design Anything

Step one is not technical. It is clerical, and it is the one most often skipped.

You cannot integrate a system nobody has documented. That sounds obvious until you look at how common the failure is at the highest levels of institutional discipline. The US Government Accountability Office's report GAO-25-107795, published 17 July 2025, examined 11 critical federal legacy systems. They ranged from 23 to 60 years old: a Department of Defense system at 60 years, Treasury systems at 59 and 51, a Health and Human Services system at 55.

Of those 11 systems, only three had all three elements of a documented modernization plan. Two had no plan at all. GAO's stated concern is that incomplete plans raise the likelihood of "cost overruns, schedule delays, and overall project failure."

If agencies with statutory reporting obligations arrive at that state, a mid-sized business with no such obligation will arrive there faster.

A usable inventory records six things per system:

Run this as a fixed-length exercise of two to three weeks, not an open-ended discovery phase. The goal is a decision-grade map, not a complete one.

Step 2: Decide What to Integrate and What to Replace

With the map in hand, every system falls into one of three buckets: keep and integrate, replace incrementally, or retire. Skipping that decision and defaulting to a rewrite is the expensive mistake.

Why the rewrite is usually the wrong instinct

Martin Fowler's strangler fig application pattern, named after the Queensland vines he observed in 2001 and most recently revised on 22 August 2024, exists precisely because wholesale replacement keeps failing for structural reasons rather than technical ones.

His argument has two parts. Big-bang rewrites take so long that the business needs features before the replacement is ready. And replicating existing behavior accurately is harder than it looks, compounded by the fact that, as Fowler puts it, much of that behavior "is stuff that isn't really wanted, so building it is a waste."

The strangler fig alternative is to build new functionality alongside the old system and migrate behavior across progressively, letting the old system shrink until it can be switched off. Fowler's assessment is that "reduced risk and earlier value from the gradual approach outweigh its costs," even accounting for the transitional architecture needed while both systems coexist.

For an integration project specifically, this reframes the work. The integration layer is not scaffolding you throw away after cutover. It is the mechanism by which the cutover happens at all, one capability at a time.

A decision rule that holds up

Sort each system by two axes: how much the business depends on it, and how expensive it is to change.

Read the table as a sequencing instruction, not just a classification. The retire quadrant pays back fastest and is the one most often deferred; the strangler-fig quadrant is the one that needs the integration layer built first.

Step 3: Choose the Integration Pattern That Matches Your Constraint

There are four patterns that cover almost every real case. Choosing on fashion rather than constraint is how organizations end up with an event-streaming platform moving eleven messages a day.

The MuleSoft research points to where the demand is heading: 94% of IT leaders say AI agents will require IT architecture to be more API-driven, and 82% cite data integration as one of the biggest challenges their organization faces when using AI. 86% agree that without proper integration, AI agents introduce more complexity than value.

That last figure is the one to take literally. Connecting an AI capability to a system estate that is 27% connected does not produce an intelligent organization. It produces a confident one, which is worse.

Step 4: Fix the Data Contract Before You Build the Connection

The most common integration defect is not a broken connection. It is a working connection carrying data that means different things on each side.

Before writing transport code, settle four questions in writing:

1. Canonical definitions. What is a "customer"? If billing counts a legal entity and support counts a person, an integration that maps one to the other will produce reconciliation failures that look like bugs and are actually disagreements.
2. Ownership per field. For every field that exists in two systems, one system owns it and the other reads it. Bidirectional sync without a designated owner produces write loops.
3. Failure semantics. What happens when the target system is down? Retry, queue, or drop, and after how long. Decide this now, because you will decide it under pressure otherwise.
4. Historical data scope. How much history moves, and does it need to be transformed to the new definitions or preserved as recorded? These are different projects.

Panorama Consulting's 2026 ERP Report (170 respondents, data collected January 2025 through January 2026, median project timeline nine months, median annual revenue $200.5 million) found that more than a quarter of organizations went over budget, and that among those, the most common cause was the unexpected need for additional technology. The report attributes this to "fatal misfits" discovered late in the project, which teams then patch with "additional technology, scope expansion, and custom builds."

Late-discovered misfits are almost always data-contract misfits. Step 4 is where you buy them down.

Step 5: Choose Between iPaaS, Custom Code, and the Vendor's Connector

Three delivery options, and the honest answer is that most organizations end up with a mix.

The vendor's own connector is the cheapest path when it fits. It is also the least flexible, and the one most likely to be deprecated on someone else's schedule. Use it for commodity integrations where the data contract is simple and the vendor relationship is long-term.

An integration platform (iPaaS) trades licensing cost for speed and standardization. The same build-versus-buy reasoning applies to your delivery tooling, which we covered in 5 DevOps tools every business should know in 2026. Gartner's market sizing reached the public through vendor announcements of the May 2025 Magic Quadrant for iPaaS — for example Informatica's 22 May 2025 press release — which put market revenue above $9 billion in 2024, up from $7.8 billion in 2023 and $5.9 billion in 2022, with a forecast above $17 billion by 2028. The Gartner report itself is paywalled; these figures are quoted second-hand by a vendor named in it, so treat them as directional rather than as a citable benchmark. The practical case for iPaaS is not the tooling. It is that the platform forces a consistent pattern on a team that would otherwise produce twelve different ones.

Custom code is correct when the integration carries genuine business logic, when latency requirements are strict, or when the systems involved are unusual enough that no connector exists. The failure mode is writing custom code for commodity problems because it felt faster in week one.

A reasonable default: vendor connectors for commodity SaaS-to-SaaS, iPaaS for the hub, and custom code only where the logic is specific to your business. If you are weighing whether to build this capability internally or bring in a team that has done it before, our comparison of dedicated developers versus an in-house team covers the staffing side of that decision, and our dedicated development teams page covers the engagement model.

Step 6: Test Integrations Like Production, Because They Are

Integration testing is systematically under-resourced because it sits between two teams and belongs to neither.

Four tests that catch most of what reaches production:

• Contract tests. Assert the shape of every payload at every boundary, and run them in both systems' pipelines. A contract test that lives only in the consumer's repository will not stop the producer from breaking it.
• Volume tests at realistic peak. Not average load. The month-end batch, the Monday-morning burst, the annual enrollment window.
• Failure-injection tests. Take the target system down mid-transaction and confirm the behavior you specified in Step 4 is what actually happens.
• Reconciliation tests. After a sync run, count and compare both sides. This is the test that finds silent data loss, and it is the one most often omitted.

Postman's 2025 State of the API Report, the seventh annual edition, surveying over 5,700 developers, architects, and executives, found 93% of teams report collaboration blockers, and 69% of developers spend more than 10 hours a week on API-related work. Integration testing failures are usually collaboration failures wearing a technical costume.

An edition note, because it matters here: several 2026 articles cite a "2026 State of the API Report." Postman's current edition is the 2025 report. Anyone quoting 2026 Postman data is quoting 2025 figures under the wrong label.

Step 7: Govern the APIs You Just Created

Every integration you build creates an interface that someone else will depend on. The governance problem starts the day the first one ships, not the day someone notices there are two hundred.

The 2026 MuleSoft data quantifies how far behind this typically runs: 27% of all APIs in surveyed organizations remain ungoverned, and only 54% have a centralized governance framework with formal policies and oversight from a dedicated team or board.

The minimum viable governance set is small:

1. A registry. One place that lists every interface, its owner, its consumers, and its status. A spreadsheet beats nothing by a wide margin.
2. A versioning policy. Decide how breaking changes are communicated and how long old versions are supported, before you need it.
3. Authentication and authorization standards. One pattern, applied everywhere. Per-integration improvisation is how credentials end up in configuration files.
4. A deprecation path. Interfaces that nobody can retire accumulate until they constrain the architecture.

Postman's 2025 State of the API Report shows 82% of organizations have adopted some level of an API-first approach, with 25% self-identifying as fully API-first. The gap between "some level" and "fully" is almost entirely governance.

Step 8: Sequence the Cutover, Don't Schedule It

This last step determines whether the previous seven paid off.

A cutover is not an event on a Saturday night. It is a sequence of reversible steps, each with a defined rollback and a defined success signal. The strangler fig pattern from Step 2 is what makes this possible: if new capability already runs alongside the old system, "cutover" means redirecting traffic for one capability at a time.

Three sequencing rules:

Run both systems in parallel longer than feels necessary. Parallel running is how you discover the data-contract disagreements that testing missed. The cost of running two systems for an extra month is almost always lower than the cost of discovering a reconciliation gap after the old system is off.

Move read traffic before write traffic. Reads are reversible. Writes accumulate state in the new system that has to be migrated back if you roll back. If the data side of the cutover is the part you are least sure about, our guide to the future of data engineering and AI/ML workflows covers how modern pipelines handle this.

Define the rollback trigger before you start, in numbers. "If reconciliation variance exceeds X, we revert" is a decision anyone on the team can execute at 3am. "If it looks bad" is not.

Panorama's 2026 report found that among projects that ran over schedule, the most common cause was organizational issues (governance, resistance to change, process redesign) rather than technical execution. The same report notes that fewer than a quarter of organizations reported an intense focus on organizational change management. Cutover is where that shortfall becomes visible.

There is one encouraging number in that report worth ending this section on. The share of organizations realizing benefits related to "removing silos" rose from 55.2% to 77.4% year over year (2026 ERP Report, Benefits Realization section). Integration work does eventually deliver the thing it promises. It is just slower to arrive than the business case assumed.

Five Integration Numbers You Will Be Quoted. Each One Fails a Different Check.

Research for this article surfaced the same handful of figures repeated across secondary articles. Each one fails a different check: one is unsourced, one is nineteen years old, one rests on a self-selected sample, one describes a different population, and one is attributed to a report that does not contain it. They are corrected here because a reader is more likely to encounter these than the sourced figures above.

"70% of legacy modernization projects fail"

A search run for this article in September 2026 returned this claim on the first page of results from at least six separate vendor and agency blogs, usually attributed to Gartner with no document title, report number, or date. Following those attributions returns only further secondary articles citing each other. Treat as unsupported. The sourced alternatives are in this article: roughly a quarter of ERP projects over budget and a quarter over schedule in Panorama's 2026 data, and GAO's finding that 8 of 11 critical federal legacy systems lacked complete modernization plans.

"84% of data migration projects overrun on time or budget"

This one has a real source, and the source is 2007. Bloor Research's original survey found over 80% of data migration projects overran or were aborted. Bloor's own 2011 follow-up put the figure at 38.3%, with an average overrun cost near $268,000. Both Bloor figures are paywalled at source; the 2011 revision is reachable through Curiosity Software's summary of the Bloor studies, which is where the comparison above was read. The exact "84%" variant has no traceable document of its own — Bloor's stated 2007 finding is "over 80%." A nineteen-year-old figure that the same research house subsequently revised downward by more than half is not a 2026 benchmark.

"Poor data quality costs organizations $12.9 million a year"

From Gartner's Magic Quadrant for Data Quality Solutions, published 27 July 2020. The figure comes from asking 154 reference customers across 16 data quality vendors to estimate what poor data quality costs them. That is a self-selected sample of organizations already buying data quality software, producing self-reported estimates, from six years ago. The Magic Quadrant itself is paywalled, so the figure circulates almost entirely through secondary retellings that drop the sample description. Useful as an illustration that the cost is large. Not usable as a benchmark for your organization.

"80% of IT budgets go to maintaining legacy systems"

This is a real, well-sourced number that is being applied to the wrong population. GAO reports that US federal agencies have typically reported spending about 80% of their IT budget on operations and maintenance of existing IT, against annual federal IT and cyber spending above $100 billion — both figures from GAO-25-107795, 17 July 2025. That is a statement about federal government IT, where systems run 23 to 60 years. Generalizing it to "enterprises" or "businesses" is a category error, and it is repeated constantly.

"73% of ERP projects fail, with 215% average cost overruns, across 2,400 implementations"

Several 2026 articles surfaced in the same September 2026 search attribute these figures to Panorama Consulting's 2026 ERP Report. The report was read directly for this article. It surveyed 170 respondents between January 2025 and January 2026, reports that more than a quarter of organizations went over budget and almost a quarter over schedule, and contains no 73% failure rate, no 215% overrun figure, and no sample of 2,400 discrete manufacturing implementations. The attribution is incorrect.

A related figure does hold up with a date caveat. The frequently-cited "large IT projects run 45% over budget, 7% over time, and deliver 56% less value" comes from a genuine McKinsey study with the University of Oxford covering more than 5,400 IT projects with budgets above $15 million, published in 2012. It is solid research. It is also fourteen years old and should be labeled as such.

What to Actually Do in the Next 90 Days

A sequence that fits one quarter and produces a decision at the end of it.

Days 1 to 21 — Inventory. Complete the six-field map from Step 1 for every system in scope. Time-box it. An 80% complete map delivered in three weeks beats a complete one delivered in three months.

Days 22 to 35 — Classify and decide. Run the two-axis sort from Step 2. Produce a written decision per system: integrate, strangler fig, retire, or replace. Get it signed off by someone who owns a budget.

Days 36 to 50 — Write the data contracts. For the three highest-value integrations only. Canonical definitions, field ownership, failure semantics, history scope. This is the highest-leverage two weeks in the quarter.

Days 51 to 75 — Build one integration end to end. Not three in parallel. One, with contract tests, volume tests, failure injection, and reconciliation. The point is to discover what your actual delivery cost per integration is before you commit to twenty.

Days 76 to 90 — Stand up governance and review. Registry, versioning policy, auth standard, deprecation path. Then review the one integration you built against its estimate, and use the variance to re-plan the rest.

If you want a second opinion on the classification step, or an integration architecture reviewed before you commit engineering months to it, talk to our team. That review is the cheapest part of this entire sequence.

The Bottom Line

Integration is not the hard part of a software project because the technology is difficult. It is the hard part because it is where two organizations' assumptions about the same data meet for the first time.

The measured picture in 2026 is consistent. The application estate is growing faster than the connected share. A third of engineering time already goes to custom integration work. Overruns cluster at the point where a misfit is discovered late and patched with more technology. And the governance debt starts accruing on the first interface, not the fiftieth.

What addresses this is not a novel method, which is part of why it works: inventory before architecture, classify before building, write the data contract before the connection, build one integration end to end before committing to twenty, and treat the cutover as a reversible sequence rather than an event.

What has changed in 2026 is the cost of getting it wrong. With 86% of IT leaders reporting that poor integration makes AI agents a source of complexity rather than value, an unconnected estate is no longer just an efficiency problem. It is the constraint on everything built on top of it.

If your systems map is out of date or you are weighing integration against replacement on a specific estate, our custom software and integration team reviews architectures like this regularly and will tell you plainly which of the four quadrants each system belongs in.