Map the information, not just the applications
A system map becomes useful when it shows how information moves. Identify where a record originates, who can change it and which downstream workflows depend on it. Repeated manual entry is often a sign that this ownership is unclear.
For each important data flow, agree what the receiving system needs and how soon it needs it. A scheduled exchange may fit one process; another may depend on a timely event.
Choose a boundary you can maintain
Look for interfaces the existing systems can reliably support. An API, a controlled database interface or a documented file exchange may each be appropriate in a particular environment.
Describe the data contract, access requirements and expected failure behaviour. A connector that works only when every system is available will create operational work at the first interruption.
Design for recovery
Ask what happens if information arrives twice, arrives late or fails halfway through a workflow. Decide how incomplete work is detected and how an operator can understand and recover it.
Use representative scenarios to verify reconciliation, retries and alerts. The goal is to make the behaviour understandable, including when one of the systems is unavailable.
- A named owner for each important data source.
- A defined interface and versioning approach.
- Visible failures and a documented recovery path.
- A migration plan with checks and a rollback decision.
Improve in stages
Start with a bounded flow where the benefit and dependencies are clear. Validate it in a staging environment, plan the cutover and check that results agree across systems.
That first connection can create space for the next improvement. Modernisation does not always require replacing an entire platform; it can begin with a reliable boundary around the parts that still do useful work.