System integration is the connectivity layer that allows different software in an organisation to share data without re-entry. The prerequisite for a successful integration is not technical but organisational: designating a single master record system for each data type. Integrations built without that decision result in two systems overwriting each other.
- The most critical integration decision is organisational, not technical: which system is the master record for each data type.
- Systems without an API can still be integrated; database or file-based bridges are available.
- Integration is tested at the first failure — error handling must be designed in from the start.
- Failed transfers must be logged, retried and alert-generating when thresholds are exceeded.
- The delivery package must include an integration map and field mapping table; without them, the system becomes dependent on whoever built it.
What integration solves
In most organisations, systems exist but do not know each other. Order data is entered into the ERP, shipment data into the warehouse system, invoice data into accounting — each separately. By end of day the three records disagree and reconciliation becomes someone's full-time job.
Integration eliminates this duplication: data is entered once at its source and automatically propagated to systems that need it.
The most critical decision: which system is the master record
What determines the success of an integration project is not which technology you use, but whether you designate a single owning system for each data type. Is the customer account the master in the ERP or in accounting? Is stock quantity authoritative in the warehouse system or the ERP?
Bidirectional integrations built without answering this question result in two systems overwriting each other's data. The outcome is worse than before integration: nobody knows which number is correct.
No API does not mean no integration
An open API is the cleanest path but not the only one. Depending on what the system supports, a database-level read, file-based transfer, or a middleware bridge can be used.
When choosing a method, the key risk to manage is the connection breaking when the vendor software is updated. Solutions that write directly to the database are the most fragile and should be limited to read-only use wherever possible.
Integration is tested at the first failure
Everything works on the day it is built. The real question is: what happens when the other system does not respond, data arrives in an unexpected format, or the network drops?
In a correctly designed integration, failed transfers are logged, retried at defined intervals, and an alert is generated when a threshold is crossed. Without this mechanism, errors accumulate silently and are typically noticed months later as a reconciliation discrepancy.
Field mapping: the invisible work
Two systems name the same concept differently and store it in different formats. One system may hold a customer code as a twelve-character string, the other as a number; unit codes, tax rates and currency formats may not align.
A field mapping table defines which field goes where and with what transformation, row by row. This table is the most valuable part of the delivery package; you cannot know who will inherit the integration years from now.
What must be delivered
When an integration project is complete, the following documents must remain with the organisation:
- Integration map — which system sends what to whom, at what frequency
- Field mapping table and transformation rules
- Error handling and retry policy
- Monitoring dashboard access and alert rules
- Connector source code and deployment documentation
Questions on this topic.
For typical enterprise projects, four to twelve weeks. The main drivers are the number of systems to integrate, their API support, and the complexity of field mapping. Any timeline given without an inventory is an estimate.
It can. This is why the maintenance agreement includes a compatibility check before updates, and the connector is updated as needed. Integrations that write directly to the database are most exposed to this risk.
Via a flow status dashboard showing the time of the last successful transfer, the number of pending records, and any error accumulation points. Alerts are generated by email or message when thresholds are crossed.
The existing structure can be reviewed and taken over. If the review concludes that rewriting is the better course, that is reported with reasoning and the decision is left to the organisation.
