Why your ERP integration keeps breaking and what to do about it

Your integration didn't break on its own. Someone else shipped a change, and your connector was the thing standing closest to it. That's the part most owners never get told. The sync that worked fine for fourteen months is now dropping records, and nobody on your team touched a line of code.

• Point-to-point connectors multiply fast. Five systems wired to each other can mean twenty separate links to maintain.
• The four usual culprits are API version retirements, field changes, expired login tokens, and rate limits that bite during your busy season.
• Middleware subscriptions add a third vendor to every data flow, and they break too.
• Cutting the number of integrations beats hardening the ones you have.
• Silent failures cost more than loud ones. Build alerting before you build the sync.

Here is how most mid-sized companies end up in trouble. You buy an ERP. Then a CRM. Then a field service app, a quoting tool, and a warehouse system. Each one comes with a connector, or a consultant builds one. Each connector runs straight from one platform to another.

That's called point-to-point. System A talks to System B. B talks to C. C talks back to A because someone needed inventory counts in the sales screen.

The math gets ugly quickly. Three systems fully wired together means three links. Five systems means ten. Seven means twenty-one. Every link has its own login, its own field mapping, its own quirks, and its own owner who may have left the company. Nobody drew the diagram, so nobody knows what the diagram looks like.

It works on day one because every vendor's software is frozen at the version you tested against. That freeze lasts about a quarter. After that, you are maintaining a web of connections between products you do not control, on release schedules you do not see.

In practice, failures cluster into a short list. Once you can name them, you stop treating each outage as a mystery.

API version retirements

An API is just the doorway one piece of software uses to talk to another. Vendors retire old doorways. They announce it in a developer newsletter that goes to an email address nobody at your company reads. Six months later the door is bricked up and your orders stop flowing. This is the most predictable failure on the list and the most common.

Field and schema changes

Somebody in sales adds a required field to the opportunity record. Somebody in operations renames a status from "Closed" to "Closed Won". Your connector was mapping that exact text. Now half your records fail validation and land in an error queue that nobody monitors. No vendor did anything wrong here. Your own team changed the shape of the data, and the integration was never told.

Expired authentication tokens

Most connectors log in using a token, which is a long password the system renews automatically. Until it doesn't. Tokens expire when a password policy changes, when the employee whose account authorized the connection leaves, or when the vendor tightens security settings. Integrations built on a named person's login are time bombs. Use a service account that belongs to the company, not to Dave in accounting.

Rate limits during your busiest week

Vendors cap how many requests you can send per minute. Your sync runs fine at normal volume. Then comes your peak month, volume triples, and the platform starts rejecting calls. The integration doesn't crash. It just quietly skips records. You find out when a customer calls about an order that never shipped.

The usual answer to connector sprawl is middleware. That's a platform that sits in the middle and manages all your data flows. Tools in this category are genuinely useful. They give you retries, logs, and a visual builder that a non-developer can follow.

They also add a third vendor to every single data flow. Now when orders stop syncing, you have three places to look and three support queues to sit in. The middleware vendor blames the ERP. The ERP vendor blames the middleware. You are the one on the phone.

And the pricing model fights you. Most of these platforms charge by task or by record processed. Growth raises your bill on the exact curve you least want. Suppose you are paying fourteen hundred a month for a mid-tier plan. That's about seventeen thousand a year, forever, for plumbing between systems you already pay for. Over five years, eighty-four thousand in rent on connections that produce nothing on their own.

Compare that to building the flows into a system you own, once. The build has a real cost. It also has an end. The subscription does not.

The pattern that holds up is simple to describe and harder to sell internally. One system holds the operational data. Quotes, jobs, schedules, inventory, customers, and status all live in one place your company owns. Everything else connects to that one system, not to each other.

This is called a hub. Instead of twenty-one links between seven tools, you have six links into one hub. If a vendor retires an API, one connection breaks and you know exactly which one.

The bigger win is that most integrations disappear entirely. Half the syncs in a typical mid-sized company exist only because the quoting tool and the scheduling tool are separate products that cannot see each other. When both functions live in the same owned system, there is nothing to sync. The data is already there. You cannot break a connection that does not exist.

We build these systems for companies in Pinellas and Hillsborough who are tired of paying rent on their own operations data. The goal is never to rebuild everything. It's to own the middle.

Not every connection should go. Some are load-bearing and some are scar tissue. Here is the split that holds up in practice.

Keep the ones where the outside system does something genuinely specialized and regulated. Accounting is the clearest example. You should not rebuild a general ledger. Push invoices and payments into QuickBooks or NetSuite and leave it alone. Payment processing is the same story. Card data belongs with Stripe or your gateway, not in your database. Shipping carriers, tax calculation, and payroll all fall in this bucket.

Cut the ones that exist only as a bridge between two tools that overlap. Typical candidates include the following.

• A CRM to project tool sync that copies the same job into two places
• A spreadsheet export that feeds a dashboard nobody has opened this quarter
• A two-way customer record sync, which is the single most failure-prone integration pattern in existence
• Any connector whose only job is moving a status field between platforms

Two-way syncs deserve a special warning. When both systems can edit the same record, you eventually get a conflict, and someone has to decide which version wins. Most connectors decide badly and overwrite good data with stale data. If you must sync two ways, pick a clear owner for each field and document it.

You cannot fix what you have not listed. This exercise takes an afternoon and it changes the conversation with your leadership team. Build a simple sheet with one row per connector.

1. Name the connection and the two systems it links.
2. Name the person responsible. If nobody owns it, write "nobody". That answer is the finding.
3. Record how it authenticates and whose account it uses.
4. List every failure in the last twelve months and how long it took to notice.
5. Write what breaks downstream when it goes offline. Be specific. "Invoices stop" is useful. "Data issues" is not.
6. Note what it costs, including middleware tasks and support hours.

Sort by that fifth column. Anything where a failure stops billing or shipping gets hardened and monitored first. Anything where the honest answer is "nothing obvious breaks" is a candidate for deletion. You will find at least one connector still running that feeds a process you retired.

Silent failure is the real enemy. A sync that crashes hard gets fixed the same day. A sync that skips twelve records an hour runs for a month before anyone notices, and then you have a month of reconciliation ahead of you.

Three things fix this, and none of them are expensive to build.

First, log every run with a count. Records attempted, records succeeded, records failed. A run that processes zero records is a failure, even when the software reports success.

Second, alert a human. Not an inbox. A Slack or Teams channel the operations lead watches, with the error message and the record ID in plain text. Alerts that go to a shared mailbox get filtered into oblivion.

Third, add a heartbeat. If the nightly sync has not reported in by 7am, someone gets pinged. The absence of a failure message is not proof of success. That distinction has saved more month-ends than any retry logic ever has.

Consolidating into an owned hub is not free and it is not always right.

You still own the remaining connectors. If Stripe changes its API, someone has to update your code. The difference is that you can schedule that work and you are not waiting on a vendor's roadmap. But the work does not vanish. Budget for ongoing maintenance, because a system nobody maintains decays the same way a leased one does.

Some integrations cannot be reduced. If your largest customer requires EDI, or your industry mandates a specific portal, that connection stays no matter what you build. Regulated data flows are the same.

Migration is real work. Moving years of records out of a platform with a weak export takes scripting, not copy and paste. Attachments and file history are usually the hardest part, and any vendor who tells you otherwise has not done it.

And a custom build is the wrong answer when your processes are genuinely standard. If you run a straightforward distribution operation that fits an off-the-shelf ERP with light configuration, buy the ERP. Custom earns its keep when your workflow is the thing that makes you money and no product matches it.

Start with the audit. Get the list of connectors on one page with owners and downstream impact. Then add logging and alerting to the two or three flows that stop revenue when they fail. Those two steps cost you an afternoon and a small amount of engineering, and they end the era of finding out from a customer.

After that, look at what you would delete if the data lived in one place you owned. If you want help mapping that out, you can book a free strategy session with our team in Clearwater.

Read this next: Build versus buy, and how to run the arithmetic on a SaaS renewal.

Related reading.

• What owning your software actually means when the vendor goes away
• Replacing a platform without stopping the business
• How to write requirements when you are not technical

How often should I expect an integration to break?

Plan for a meaningful change from at least one vendor every year per connector. Most of it is routine, like an API version retirement with six months notice. The trouble comes from not having anyone assigned to read those notices.

Is middleware ever the right call?

Yes. If you need a dozen flows across tools you have no intention of replacing, and nobody on staff can maintain code, middleware buys you visibility and retries fast. Just know you are renting it and the bill grows with volume.

Can I keep my ERP and still consolidate?

Often, yes. Plenty of companies keep the ERP for finance and inventory, then move quoting, scheduling, and field operations into an owned system that talks to the ERP through one connection. That alone removes most of the sprawl.

What's the single fastest improvement I can make this week?

Switch every connector off a personal login and onto a company service account. Then set up one alert channel for sync failures. Both are small changes and they prevent the two most common silent outages.

How do I know if a two-way sync is hurting me?

Pick twenty customer records and compare them across both systems field by field. If you find mismatches in addresses, phone numbers, or status, the sync is already losing data and your team is quietly working around it.