Most companies don't buy their software all at once. The ERP arrives first. Then a webshop. Then a warehouse tool, then a marketplace account or two. Each one solves a real problem. Together they create a new one. The same product, price, and order now live in five systems, and none of them agree.
Software integration is how you make them agree. It connects separate systems so they share data without a person retyping it. A price changes in the ERP and the shop shows the new price a few minutes later. An order arrives on a marketplace and lands in the warehouse system ready to pick. The systems keep doing their own jobs. The integration moves the data between them and translates it on the way, because two systems rarely name the same field the same way.
This article covers what businesses connect, why they bother, how the connection actually works, and how to pick an approach that fits. The examples lean toward manufacturers and brand owners, since that is where most of the messy, high-value integration work sits.
What Businesses Connect, And Why
Watch where the copy-paste happens in a company, and you'll find the integration that's missing. Someone exports a spreadsheet from one system every Monday and imports it into another. That weekly ritual is a manual integration held together by a human, and humans mistype prices.
The systems most businesses want to connect fall into a few groups:
- ERP.
The book of record for items, prices, stock levels, and orders. Almost every integration touches it. - Ecommerce platform.
Shopify, Magento, Shopware, and the rest need product content and stock pushed in, and they produce orders that have to go back. - PIM.
Where product descriptions, attributes, and images get enriched before they reach any sales channel. - Marketplaces.
Amazon, eBay, and others, each with its own field names and rules for what a listing must contain. - Warehouse, accounting, and CRM tools.
These need order, stock, and customer data flowing in both directions.
The reason to connect them is money and time. Manual transfer is slow, and it breaks quietly. A wrong stock number oversells an item you can't ship. A price that is updated in the ERP but not the shop sells goods below cost for a week before anyone notices. Scale makes this worse, not better.
The scale is real. Research by Salesforce found the average enterprise now runs 897 applications, and about 71% of them stay disconnected from each other. Most companies are not short on software. They are short on the wiring between them.
How Integration Needs Vary
There is no standard integration, because there is no standard company. What you connect depends on how you sell and what already runs your business.
A manufacturer usually starts with one painful gap. The product data lives in an ERP built for finance and production, not for selling online. It has item numbers, prices, and stock, but no marketing descriptions, no clean attributes, and no images fit for a shop. Manufacturers turn to us with exactly this: rich data trapped in a system that was never meant to publish it. The fix is rarely a direct ERP-to-shop line. A PIM system sits in the middle, pulls the raw data from the ERP, gets enriched by the product team, and pushes finished content out to the shop and the print catalog. Two integrations, one clean flow.
A distributor has a different shape. They may carry hundreds of thousands of articles from dozens of suppliers, each supplier sending data in its own format. Here the hard part is inbound. The integration has to accept a supplier's Excel file, a second supplier's API, and a third supplier's nightly file drop, then map all of them onto one consistent structure. The outbound side to the shop is almost easy by comparison.
A multi-channel seller lives and dies on stock accuracy. They sell the same item on their own shop, on Amazon, and in a physical store, all drawing from one warehouse. If the channels don't share a live stock figure, they oversell. This integration is less about rich content and more about speed and direction. Stock and orders need near real-time sync, while product descriptions can update once a day and nobody minds.
The lesson from these cases is simple. Decide which system owns each piece of data before you connect anything. The ERP might own price and stock. The PIM owns descriptions and images. The shop owns nothing except the orders it captures. Get that map wrong, and two systems will fight over the same field, each overwriting the other on every sync.
How Software Integration Works
Under the hood, integration is a question of transport and translation. First the systems have to reach each other. Then the data has to be reshaped so the receiving system understands it.
Systems connect through one of a few methods:
- API calls.
REST, SOAP, or GraphQL requests, the modern default when both systems offer a web service. - File exchange.
CSV, Excel, JSON, or XML files moved over SFTP or a shared folder, still common with older ERPs and many suppliers. - Direct database access.
Usually through read-only views, when a system has no usable API but you can read its tables.
Real projects mix these. A single scenario might read a supplier's SFTP file, call the shop's API to push products, and query a database view for stock. The method matters less than picking the one each system actually supports well.
Then there is the shape of the whole thing. You can wire systems point-to-point, one custom connector per pair. That is quick for two systems and a nightmare at six, because every new system multiplies the connections you maintain. Most companies past a certain size move to a hub, a central layer that every system connects to once, which handles the mapping and routing in the middle.
That central layer is where the product choice happens. A managed iPaaS such as Boomi or Workato runs the flows in the cloud and suits teams that want a hosted service. Some companies build custom connectors in-house when they have the developers and unusual requirements. Others run the integration on a data platform like AtroCore, which sits between the systems, maps every field, and syncs on the schedule you set, with the configuration stored as data rather than code so an administrator can adjust a mapping when a connected system changes, without a deployment. The right pick depends on your team, your budget, and how much you need to change after go-live.
The market has grown up around this need. Gartner estimates iPaaS revenue passed $9 billion in 2024 and will top $17 billion by 2028, which tells you how many companies have stopped treating integration as a one-off script.
What You Get When It Works
A finished integration is quiet, and that is the point. Prices and stock move on their own. Orders route themselves. The Monday spreadsheet ritual disappears, and so do the errors that came with it.
The concrete wins show up fast. Launching on a new marketplace stops being a data project and becomes a configuration change, because the product content is already clean and central. Stock figures stay close to reality, so overselling drops. Staff who spent hours moving files spend them on work that needs a person. And the number of "why does the shop show the wrong price" tickets falls toward zero.
Choosing An Approach
The tool matters less than the fit. Before you commit, get clear answers to a short list of questions:
- Which system owns each field?
Settle this first. It decides the direction of every sync and prevents systems from overwriting each other. - How fresh does the data need to be?
Stock might need updates every few minutes. Product copy can wait for a nightly run. Not everything needs real time, and pretending it does raises cost. - Who maintains it after launch?
If a connected system adds a field next year, can your own team add it to the mapping, or does every change need the vendor and a bill? - What happens when a run fails?
Look for logs, automatic retries, and a way to correct and re-run bad records. A silent failure is worse than an obvious one. - Does it handle your custom data?
Off-the-shelf connectors that only move standard fields fall apart the moment your business has its own attributes, and most do.
One more piece of hard-won advice. Test the integration on real extracts of your own data before it goes live, not on tidy sample files. Real data is messy in ways sample data never is, and the first productive run should not be the first time the mapping meets a malformed record.
Software integration is not glamorous work. Done well, it is the difference between systems that argue and systems that cooperate. Start by mapping who owns what, connect through the hub that fits your team, and keep the ownership of the configuration in your own hands. The rest is detail.