Key takeaways
- Four factors drive integration cost: how many systems, the state of your data, validation requirements, and whether legacy connectors must be built from scratch.
- Simple API connections take weeks. Multi-system integrations in regulated environments typically take two to four months.
- The predictable failure modes, undocumented data, mid-project system updates and scope creep, are all addressable in discovery, which is why skipping discovery is the most expensive shortcut available.
- Wildly different vendor quotes usually describe wildly different amounts of work. The comparison worth making is line by line.
Most agencies keep this information for the sales call. We'd rather you walked into every vendor conversation, including one with us, already knowing what integration work involves, what stretches it, and which questions separate a serious quote from an optimistic one.
The four cost drivers
-
Number of systems, or more precisely, number of connections. Cost scales with connections, and connections multiply faster than systems. Two systems need one connection; five systems exchanging data freely could need ten. Real projects never need every possible connection, which is exactly why scoping matters: the difference between "connect our five systems" and "build the four connections that carry the risk" is most of the budget.
-
Data quality. The single most underestimated driver. If your product codes are formatted three ways across systems, if the same customer exists under four names, if free-text fields hold what should be structured data, all of that must be reconciled before information can flow automatically. Clean, consistent data makes integration largely a technical exercise. Messy data adds a cleanup phase, and nobody knows how messy their data is until someone looks. This is most acute with older systems, where formats have drifted for a decade, one of several reasons legacy integration is its own discipline.
-
Validation requirements. A connection between two non-critical systems needs solid engineering and little paperwork. A connection touching your QMS needs an interface specification, a risk assessment and qualification evidence, work we describe in how to integrate without breaking validation. That documentation is what lets the integration survive an audit. But it's real effort, and a quote that ignores it is quoting a different project.
-
Legacy connectors. Modern platforms expose supported interfaces. Older systems may offer nothing but scheduled exports or database access, and connecting them means building and testing a custom connector. Each legacy system in scope adds meaningful engineering time, though rarely enough to justify replacing a system that otherwise works.
Realistic timelines
For a single connection between two modern systems with decent interfaces and clean data, a few weeks from kickoff to production is achievable.
For multi-system work in a regulated environment, two to four months is the honest range. Roughly: a discovery and mapping phase measured in weeks, then connection-by-connection build, test and staged rollout, with validation documentation produced alongside rather than bolted on at the end.
What stretches timelines is rarely the engineering. It's the discoveries: a data model nobody documented, an export that turns out to omit the one field that matters, a system update landing mid-project. The two-to-four-month range assumes some of these will happen, because some of them always do. A quote promising a five-system regulated integration in three weeks has assumed none of them will, and that assumption fails reliably.
What goes wrong, specifically
Undocumented data models. The vendor manual describes the system as designed. Ten years of use created fields repurposed for other things, conventions that live in people's heads, and records from before the last migration. Integration exposes all of it, and mapping takes longer than anyone budgeted.
Mid-project system updates. A vendor pushes an update that changes an interface the half-built integration depends on. Recoverable if the project tracks vendor release schedules from day one; disruptive if it arrives as a surprise.
Unowned master data. The project reveals that three systems each believe they hold the authoritative product list, and they disagree. Resolving which system is the source of truth is an organisational decision, and engineering stops while the organisation makes it. Settling data ownership during scoping is dramatically cheaper than settling it mid-build.
Scope creep by enthusiasm. Working integrations are persuasive. Departments that ignored the project start requesting connections mid-delivery, each individually reasonable, collectively a schedule risk. The fix is a roadmap with a phase two, so good ideas have somewhere to go that isn't the current milestone.
What discovery produces, and why skipping it costs more
Discovery done properly is short, structured and produces three artefacts. A system map: every system in scope, what it holds, and its interfaces. A data flow audit: how information moves today, including manual re-typing, and where it breaks. A risk register: what could compromise the project or, once live, your compliance position.
Beyond de-risking the build, these documents fix the failure modes above before they're expensive: the data model surprises surface in mapping, ownership arguments happen in a workshop rather than mid-build, and the risk register catches the vendor update problem early. Discovery also frequently redraws the project itself. Some planned connections turn out unnecessary; occasionally the whole business case changes shape, as when the driver is keeping regulatory documentation consistent with quality events and a single well-chosen connection delivers most of the value.
Skipping discovery doesn't remove this work. It moves it into the build phase, where every surprise costs engineering time at full rate and every decision blocks a milestone.
Comparing quotes that look wildly different
Three quotes for "the same" integration can differ by a factor of five, and the explanation is almost always scope rather than efficiency. Check each quote for:
Discovery: included, priced separately, or absent? Absent means the vendor is guessing, and the gap between guess and reality becomes change requests later. Validation documentation: who writes the interface specs, risk assessments and qualification evidence? If the answer is your team, the cheap quote just moved the cost rather than removing it. Failure handling: does the price cover what happens when transfers fail, or only the path where everything works? Production integrations spend their lives in the real world. Post-launch support: connected systems evolve. A quote that ends at go-live leaves you renegotiating from a weak position at the first vendor update.
The cheapest quote on paper is frequently the most expensive by year's end. What you want is the quote whose scope actually matches your project, and after discovery, you'll be equipped to recognise it.
ULAM LABS builds integration and workflow layers for MedTech companies on top of the validated systems they already run. We scope during discovery before committing to a timeline, and every project ships with its documentation, failure handling and support model included, because we've spent ten years learning where regulated integrations go wrong. If you're budgeting an integration project, book a system integration health check: a free assessment that produces the system map and gives you a realistic picture of scope, whoever you end up building with. You can see how this approach played out across 150 hospitals in our case studies, and more on the service itself at our integrations page.
