Why legacy system integration starts before you sign
A legacy system is rarely a problem on its own. Many still run finance, stock, and orders reliably, which is why businesses keep them. But they were built before webshops and PIM (product information management) systems expected live data on demand. That gap stays hidden until something new has to draw on them.
The business still buys around the system it keeps. It might add a webshop for a new channel, a PIM for a growing catalogue, or a WMS (warehouse management system) for a second site. Each new vendor demos against clean sample data and plans as if the old system will keep up.
If it can't, two expensive decisions tend to follow: an ERP replacement nobody budgeted for, or a shortlist narrowed to what the old ERP can handle. Legacy system integration starts before either is made, with questions only the business's own team can answer.
What your team must answer about legacy system integration
Six things decide what the old system can offer a new one. None of them shows up in a vendor demo, because each depends on how this system has been run.
- The new system inherits the old identifiers: article numbers, customer codes, and price list structures were defined in the old ERP. Ask which ones the new webshop or PIM must adopt, and which it can map.
- The new vendor assumes things the old system may not do: a webshop demo assumes current stock and orders written straight back. Ask whether the old ERP can do either, or whether it updates stock in a nightly batch.
- Status codes mean what years of use made them mean: a code created for "on hold" may now mean "awaiting a credit check". A new system will read it literally, so ask the people who use it.
- The old system can only bear so much reading: month-end close, the nightly batch, and decade-old hardware limit how often anything can query it. Ask IT when it can be read without slowing its users.
- Anything outside the network has to be let in: an on-premises ERP usually sits behind a firewall for good reason. Ask who decides how an outside platform reaches it, and on what terms.
- Nobody outside the business can approve a change: the new system may need one extra field, such as a promised delivery date. Ask who can authorise a change inside the old system.
The six answers belong to the first stage of a system project, seen from the system that stays. Everything after that stage, through to who owns the integrations after go-live, is in the integration checklist. Identifiers and vendor assumptions are usually what changes scope the most.
How does legacy system integration change the new software's scope?
A new system's scope is written by its vendor, against its own assumptions. Legacy system integration rewrites parts of that scope while it can still be negotiated.
If the old ERP only updates stock overnight, the webshop shows a morning figure, and the delivery promise at checkout has to reflect that.
The quickest route to integrating legacy systems is often a script written directly against the old database. It works, but its logic lives in code only its author knows, and the ERP's vendor may not support that kind of access. An integration platform offers a third route, between replacing the ERP and working around it.
How an integration platform connects the system you keep
An iPaaS (integration Platform as a Service) is a cloud-based, central hub that a business connects its systems to, one at a time. It transforms data into the format each system expects and automates the exchange of orders, stock, and product data, in real time or on a schedule, instead of relying on a separate link for every pair.
For a business keeping its ERP, that changes the buying decision. The new webshop or PIM connects to the hub, not the ERP. It can be chosen for what the business needs, not for what the old ERP can handle. Where the two don't match, the difference can be resolved in the hub, and the ERP itself usually stays as it is.
The Alumio integration platform provides features that can be configured to resolve those differences:
- Web orders reach finance without retyping: a Route can be built from the webshop to the ERP that delivers each order in a format the ERP accepts.
- Customers see the stock the ERP holds: a Route between the ERP and the webshop can pass stock across as often as the ERP can bear.
- The new catalogue keeps the old codes working: a Transformer between the ERP and the webshop can map article numbers and translate status codes such as "on hold".
- A missing field can come from outside the ERP: a Route can combine ERP and warehouse data to give the webshop a promised delivery date.
B&S International, a consumer goods distributor, connected its custom ERP to Akeneo PIM and Adobe Commerce through Alumio. Data tasks that used to take weeks now take days, and its business analysts adjust the flows themselves.
How legacy system integration protects the next go-live
A legacy ERP that still runs finance well is an asset. It turns into a liability only when the software bought around it is planned on assumptions nobody checked. The cost then lands as a delayed go-live.
Legacy system integration done before signing changes that. Settling what the old system can and cannot supply turns the new vendor's assumptions into scope it can plan against. An integration platform then gives the old ERP and the new webshop one place to exchange orders, stock, and product data.
It also keeps the next decision open. When the time comes to replace the ERP, the platform can keep old and new running side by side through a phased legacy system migration. The webshop can go live on the plan it was bought for, and the ERP is replaced when the business decides, not when a new system forces it.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
