Insights Systems integration
Before you replace your core system
An ageing system can make a replacement project feel inevitable. Before committing, establish whether the main constraint sits inside the platform or in the manual work needed to connect it to the rest of the business.
A customer places an order online. Someone copies it into the finance system, checks availability in a spreadsheet and emails the warehouse. When the customer calls, another person reconstructs the progress from those same sources.
In this example, the business needs a better flow of information. A new core platform might help, but the project still has to resolve those handovers. Otherwise, the manual work can survive the migration.
The first useful investment is a clear account of where work slows down and what causes it.
Follow one transaction through the business
Take a common transaction, such as an order, service request or new customer enquiry. Follow it from arrival to completion with the people who handle it.
Record where information is entered again, where someone checks another system and where work waits for a reply. Include the exceptions. A returned order or changed customer detail can reveal dependencies that the normal process hides.
For each handover, establish which record is authoritative and how the receiving team knows it is current. If two systems can change the same field, decide how conflicts should be resolved.
This gives a replacement proposal something concrete to answer. It also reveals improvements that may be possible within the existing environment.
Compare the available options
There are usually several approaches worth assessing:
- Configure the existing platform when its capabilities already cover the requirement and the problem is how it has been set up or used.
- Connect systems when each performs a useful role but information moves between them through manual work.
- Replace a component or the core platform when its limitations prevent the required operation or make continued support impractical.
Compare the full cost and disruption of each option. Integration needs ongoing monitoring and maintenance. Replacement needs data preparation, migration, testing and staff training, as well as the new software itself.
A staged replacement can also be appropriate. Microsoft documents incremental modernisation as an established architecture approach, although its suitability depends on whether functions and dependencies can be separated safely.
Design the connection for daily use
An integration needs a clear operating model after it goes live. Agree what happens when a record is incomplete, a destination system is unavailable or the same transaction arrives twice.
The people using the process need to see which items have completed and which need attention. Someone must own the queue of unresolved items. A connection that fails silently can create another reconciliation task.
Test the proposed improvement with representative records, including corrections and exceptions. Measure whether it removes work across the whole process. Saving a few minutes in sales has limited value if it creates a larger checking task in finance.
Where replacement is planned later, consider whether the integration can be retained or adapted. That decision affects the value of doing the work now.
Recognise when the core platform needs to change
Integration cannot resolve every limitation. An unsupported platform, inadequate access controls or a data model that cannot represent the required work may justify replacement.
The assessment should explain which limitation matters, what evidence supports that conclusion and how the proposed system addresses it. It should also identify the work that remains outside the new platform.
The business can then compare ways to improve a known process, with the scope and dependencies clear before implementation begins.
Discuss your systems integration requirements
Further reading: Microsoft Azure Architecture Center on incremental modernisation.