Software integrations: facts, examples and trends for 2027

Integrations are the part of your software estate that nobody owns. Each one was set up by whoever needed it, in a hurry, to solve a problem that has since been forgotten. They work invisibly until they stop, and when they stop, the first sign is usually a colleague noticing that a number looks wrong.

That is the actual risk in this category, not that integrations are hard to build, but that they are easy to build and nearly impossible to keep track of. This page is about evaluating them honestly and running them without accumulating a debt you cannot see.

What to take away

"Integration" covers four quite different arrangements.
The word on the marketing page carries almost no information.
Connect the second-most-important integration, not the first.
Integrations are the reason platform migrations overrun.

Four kinds, with different economics

"Integration" covers four quite different arrangements. Knowing which one you are buying changes what you should ask.

Native connections, built by one vendor into another's product. Cheapest to set up, least flexible, and entirely dependent on both vendors continuing to care. They break when either side ships a change, and you have no influence over the repair.

Integration platforms, which sit between systems and are configured rather than coded. Fast to build, visible, and they introduce a third vendor, a third bill, and a third thing that can fail. Pricing is usually metered on volume, which means a busy month costs more than a quiet one: model your peak, not your average.

Direct connections you build, using each system's interface. Maximum control, and you own the maintenance for ever. The real cost is not building it; it is being the organization that must react when a vendor changes something.

File exchange: a scheduled export from one system, imported by another. Unfashionable, reliable, easy to debug, and perfectly adequate for anything that does not need to be immediate. Frequently the right answer for reporting and finance, and frequently dismissed for being unexciting.

Match the mechanism to the requirement. Most work does not need to happen within seconds, and choosing a real-time mechanism for work that could run overnight buys you complexity you will maintain for years.

What "integrates with" actually means

The word on the marketing page carries almost no information. When a vendor says they integrate with something you use, ask:

Which direction? Read-only, write-only, or both. One-way is the common case and it is often described as though it were two-way.
Which objects and fields? An integration that syncs contacts but not the custom fields you keep contacts for is not the integration you wanted.
How does it trigger? Pushed immediately when something changes, or polled on a schedule. Polling has a delay and a cost; pushing needs the receiving side to be reachable and reliable.
What happens to a record that already exists? Matched and updated, or duplicated. Duplication rules are the single most common source of integration mess.
What happens to deletions? Very often nothing, which means deleted records linger on one side for ever.
Is it built by the vendor whose product you are buying, by the other one, or by a third party? This tells you who fixes it and how fast.
Where does the data go on the way? If the connection runs through a third party's servers, that is a data-handling question, not just a technical one.

Ask these about the two or three integrations you actually depend on. The catalog size is irrelevant; a vendor with a thousand connectors and a poor one for your accounting system is worse for you than one with fifty good ones.

Whose identity is the connection using?

This is the question that causes the most avoidable breakage, and almost nobody asks it during an evaluation.

When you connect two systems, the connection authenticates as somebody. Usually that somebody is the person who clicked "authorize", which means the integration inherits their access, and dies when their account does. The pattern is familiar: an automation stops working weeks after someone leaves, and it takes days to work out why, because nobody connected the departure to the failure.

What to do instead:

Give each connection its own identity, belonging to a function rather than a person, with only the access that connection needs.
Record who owns it, the human responsible when it breaks, separately from the account it runs as.
Note where its credentials live, and who can rotate them.
Check the permissions it was granted, not the ones it needs. Authorization screens routinely request broad access, and broad access granted once persists indefinitely.
Know how to revoke it, and remember that revoking access does not retrieve data already copied.

Scoping is the part that gets skipped because everything works either way on the first day. The authentication and authorization questions that a default configuration tends to gloss over are set out in the security strategies for service based systems, and the useful habit from it is to grant a connection the narrowest access that lets it work.

Then include integrations in your offboarding checklist. "Which automations run as this person's account?" belongs beside "what happens to their mail".

Five ways integrations fail

They rarely fail loudly. Learn the shapes:

Failure	How it presents	What to check for
Silent stop	Nothing arrives; nobody notices for weeks because absence is invisible	Is there monitoring on expected activity, not just on errors?
Partial sync	Some records move, some do not, and the two systems slowly diverge	Does the tool report per-record outcomes, or only overall success?
Duplication	The same record created repeatedly because matching failed	What is the matching key, and what happens when it is missing or changed?
Replay	A retry re-delivers messages already processed, doubling the effect	Does the receiving side ignore repeats, or act on them again?
Cascade	One system's change triggers another, which triggers the first, in a loop	Are there loop guards, and is there a ceiling on how much can run?

The common thread is that four of these five are invisible without deliberate monitoring. The most valuable thing you can build around any integration is an alert that fires when the expected thing does not happen: a daily transfer that did not run, a queue that did not drain. Error alerting only catches the failures that announce themselves.

Limits, versions, and the slow deprecation

Three constraints that shape what is possible:

Rate limits. Every interface caps how much you may do in a period. This is fine day-to-day and becomes the binding constraint during bulk operations, an initial load, a mass update, a migration. Find the limits before you plan anything bulk, and find out what happens when you exceed them: a clear refusal you can retry, or a temporary block on the whole account. A refusal is a normal, documented response rather than a fault, and the description of a too many requests reply and the retry hint it carries is enough to hold the conversation with whoever built the thing.

Versioning. Interfaces change. Well-run vendors version them, announce deprecations, and give you a window. Others change behavior without notice. Ask how changes are communicated, where they are published, and how long old versions are supported, and then make sure the announcement reaches a mailbox someone reads, not the address of whoever set the connection up.

Bulk versus incremental. Most systems offer a fast path for large volumes and a normal path for ongoing changes. Using the wrong one is why an integration that worked in testing hits limits in production.

What to test before committing

Connect the second-most-important integration, not the first. The most important one will get attention regardless; the second reveals how much effort a routine connection takes.
Push a record through end to end and check every field on the far side, including empty ones. Fields that silently fail to map are the standard defect.
Break it on purpose. Revoke the credential, or send a malformed record, and watch what happens. Does it stop, skip, retry, or corrupt?
Send a duplicate and see whether it is recognized.
Delete something on one side and see what happens on the other.
Run a volume test large enough to meet the rate limit.
Find the logs. Whether you can see what happened, per record, and how far back, determines whether you can ever debug this in production.

Keep a register

The cheapest useful thing in this category is a single list, kept somewhere permanent, with one row per integration:

what it connects, which direction, what it is for, who owns it, which identity it authenticates as, where the credentials live, how it is monitored, and what happens if it stops for a week.

That last column is the one that pays. It tells you which integrations deserve monitoring and which can simply be fixed when someone notices. Without it, everything is treated as equally critical, which in practice means nothing is monitored at all.

Review the register when you change either system, when someone leaves, and on a schedule. It is also the document that makes a future migration tractable, because the alternative is discovering your integrations one outage at a time.

What makes this expensive to leave

Integrations are the reason platform migrations overrun. Every connection is a small separate project with its own owner, its own credentials, and its own testing. Ten integrations is not one task, it is ten, and they cannot be done by one person in parallel because each needs the cooperation of whoever owns the system at the other end.

The mitigating actions are all cheap and all have to happen early: keep the register, prefer file exchange where immediacy is not required, use function accounts rather than personal ones, and avoid building deep dependencies on a connector that only one vendor maintains.

Where to read next

Connections exist because work is spread across products, so the decisions about those products shape how much connecting you need. The tracker decision frequently removes the need for two or three connections on its own. The collaboration decision determines how many notification feeds you will build, and the storage decision determines whether documents need to be copied between systems at all. Where identities and credentials for connections are managed, the administration decision is the one that matters.

Common questions

Should we build connections ourselves or buy a platform?

Count how many you need and how often they change. Few and stable favors native connectors or a scheduled file. Many and changing favors a platform. Building from scratch is right when one connection matters enormously and nothing off the shelf fits.

How do we find the connections we already have?

From several directions at once: the connected applications list in each product, the accounts that are not people, the finance record for small recurring charges, and a short message to every team asking what would break if this product stopped for a day. The last one finds the most.

What is a reasonable review interval for the register?

Twice a year, plus whenever somebody leaves. The review has two jobs: confirm every connection still has an owner, and switch off the ones nobody can justify. The second job is where the value is.

Is real time worth the extra complexity?

Only where a person is waiting for the result. Immediate delivery multiplies the failure modes and the cost, and a great deal of what gets specified as instant is read at the next weekly meeting.