the problem.
Many companies want to replace one system, say the webshop, and leave the rest alone. That gets difficult once the old systems talk directly to the system that is going away. Each of them then has to be changed, and nobody likes touching old systems. Sometimes it is not even possible: the supplier is gone, the knowledge is gone, or the change costs more than the replacement itself.
the idea: the integration behaves like the old system.
Instead of rebuilding the old systems, we let the integration layer imitate the behaviour of the system that is going away. The old systems send and ask in the same way as before. They do not notice that anything was replaced. Behind the scenes the integration passes everything on to the new system, and answers in the way the old system expects.
why that works.
- Nothing has to be developed on the old system, even if its supplier no longer works on it.
- The switch is smaller and easier to test, because you replace one side instead of every side at once.
- You can replace the old systems later, at your own pace.
an example.
On Profuomo's new webshop we rebuilt the old APIs, so the existing systems kept working with the new webshop. Read the Profuomo case for the whole project.
what makes it hard.
There is no room to negotiate. The old system does not change, so the integration has to work exactly as the departed system did. That can be difficult, because you cannot choose a simpler solution: what the old systems expect is fixed. Allow plenty of time for working out exactly how the old system behaves.
what the old system expects.
Start by taking stock of what the old system sends and what it expects back. That is more than a list of fields. Record per interface:
- The message format: file layout, field names, date and number formats and field lengths.
- The identifiers: which numbers the old system uses for customers, products and orders, and whether the new system adopts them or needs a lookup table.
- The responses: which confirmation the old system expects, within what time, and what it does on an error or an empty response.
- The rhythm: does the old system fetch or is it fed, how often, and in which order.
Documentation is rarely complete. So keep a period of real traffic as the yardstick: what is not in it you probably do not have to rebuild, and what is in it has to match exactly.
old and new side by side.
The integration can serve both the new and the departing system for a while. The old systems see one interface, the one they always had. Behind it you decide which part already goes to the new system, for example only stock lookups first and creating orders later. That way you find differences in small steps instead of all on one day.
compare before you switch.
Before the new system takes the lead, you want to know that it gives the same answers as the old one. Send the same requests to both and compare the results: counts, totals and a sample of individual records. Decide up front what "the same" means. A different order in a list may be harmless, a different rounding of an amount is not. Also agree who decides that it is good enough.
know which system handled what.
Once two systems take on work at the same time, every record has an origin. Record per order, shipment or invoice which system handled it. Other processes need that information to choose the right next step.
An example from practice: a customer moved to a new webshop and a new WMS at the same time. During the switch nobody recorded which WMS each order had gone to. Other automated processes needed that information to keep working correctly. The result was that orders that went to the old WMS had to be handled manually, while new orders could run fully automatically. Together with the customer we solved it with a reconciliation flow. It is a lesson for every switch: record per order which system handled it, and think of it up front rather than afterwards.
rolling back.
Agree up front to which point you can go back and what that takes. As long as the old system stays unchanged and the integration can switch back, rolling back is a setting, not a project. Do decide what happens to records the new system handled in the meantime: they have to be known in the old system or tracked separately.
what it costs.
We first validate technically whether the integration is possible, then give a fixed price for the agreed scope. The price depends on the types of systems, known or legacy, on the number of routes and on the overall complexity.
checklist.
- Interfaces of the old system inventoried: messages, identifiers, responses, rhythm.
- Real traffic kept as the yardstick.
- Agreed which parts move first and which later.
- Old and new compared against criteria set in advance.
- Per record, recorded which system handled it.
- Rollback point agreed, including what happens to interim records.
