Why System Integration Projects Stall, and How to Plan Them

Integration projects rarely stall because connecting two systems is technically hard. They stall because of questions nobody answered before the work began: which system holds the correct version of a record, what the old system actually does, and what should happen when a message fails. Each is cheap to settle during planning and expensive to discover in the middle of testing.

1. Nobody has decided which system owns the data

Consider a company where customer records exist in the CRM, the ERP and the billing system. Each has a slightly different address, and each team trusts its own. The moment you connect these systems, you must decide which one wins when they disagree. That decision belongs to the business, yet it often lands on a developer who finds the conflict while writing the synchronization logic.

For every data entity that crosses a system boundary, agree on:

• The source of truth: one system where the record is created and edited.
• The direction of flow: other systems receive copies and do not change them, or change only specific, agreed fields.
• The business owner: a named person who rules on disputes and approves changes to the definition.

Two-way synchronization of the same field is where much of the pain originates. Avoid it unless there is a strong reason, and where you cannot avoid it, define explicit conflict rules.

Expect the definitions themselves to differ as well. “Customer” may mean a legal entity in finance and a branch contact in sales. Reconciling these meanings is business work that comes before the technical work.

2. Legacy systems are undocumented

Older systems often have interfaces that were built for one purpose years ago by people who have since left. Documentation is missing or out of date, and fields carry meanings that drifted over time. Some systems have no API at all and can only be reached through database access or file exports.

The practical response is a discovery phase before any estimate is treated as firm:

• Obtain real access to a test environment and call the interfaces, instead of reading about them.
• Pull sample data and examine it for empty fields, inconsistent formats, duplicates and unexpected values.
• Find the people who know the system’s behaviour, including long-serving users, and record what they tell you.
• Identify limits: request rates, batch windows, maintenance hours, licence restrictions on API use.

An estimate produced before anyone has seen real responses from the legacy system is a guess. Budget discovery separately and revise the plan based on what it finds.

3. Point-to-point connections multiply

The first integration is usually a direct link between two systems, which is reasonable. Trouble comes with the fifth and the tenth. Each new link is built slightly differently, with its own data mapping and its own way of failing. Changing one system then means examining every connection that touches it.

Not every organization needs a full integration platform, but each should make a deliberate choice once the number of connected systems starts to grow:

Approach	Suits	Watch for
Direct point-to-point links	Two or three systems, stable requirements	Hidden dependencies as links multiply
Central integration layer	Many systems, shared data such as customers and products	Needs an owner and consistent standards
Event-based messaging	Many consumers reacting to the same changes	More demanding to monitor and debug

Whichever approach you choose, keep a current inventory of every integration: what it connects, what data it moves, how often, and who is responsible for it.

4. Error handling and monitoring are left for later

Demonstrations show the path where everything works. Production brings timeouts, expired credentials, duplicate messages, records rejected by validation, and target systems that are down for maintenance. If the design does not account for these, failures happen silently and are discovered days later when someone notices that orders are missing.

Design the failure paths at the same time as the success paths:

• Retries for temporary faults, with a limit, so a failing message does not loop forever.
• Safe reprocessing, so that sending the same message twice does not create two orders.
• A holding area for messages that cannot be processed, with a way to inspect, correct and resend them.
• Alerts that reach a named person or team when failures exceed a threshold.
• Reconciliation, a periodic comparison of record counts or totals between systems to catch whatever slipped through.

Decide also who acts on the alerts. An integration with no operational owner degrades quietly.

5. Testing with real data is underestimated

Integrations that pass every test with clean sample data commonly fail on real data. Real records contain Arabic names in fields designed for Latin characters, phone numbers in several formats, dates in both Hijri and Gregorian calendars, mandatory fields left blank, and legacy records created under rules that no longer apply.

Plan testing as a major share of the project, not as a final step:

• Test with a realistic copy of production data, masked where it contains personal or sensitive information.
• Test realistic volumes, including month-end and seasonal peaks.
• Test failure scenarios deliberately: switch off a target system and observe what happens.
• Involve business users in verifying that results are correct in meaning, since a record can transfer successfully and still be wrong.
• Rehearse the cutover, including how to roll back.

A planning checklist

Before committing to a timeline, confirm that you can answer the following:

1. For each data entity, which system is the source of truth, and who is its business owner?
2. Have we called every interface in a test environment and examined real sample data?
3. Are data definitions and field mappings agreed and written down?
4. Have we chosen an integration approach that fits the number of systems we expect in two to three years?
5. What happens when a message fails, and who is notified?
6. How will we reconcile data between systems?
7. Do we have realistic test data, and time in the plan for several test cycles?
8. Who operates and maintains the integration after launch?
9. Do we depend on other vendors or teams, and have they committed to dates?

Unanswered items are the discovery work, and they belong at the start of the plan.

Practical takeaway

Settle data ownership with the business before development starts. Budget a discovery phase for every legacy system. Design for failure from the first day, and give testing with real data the time it needs.

You can read more about how we approach integration work under services, and if you are planning a project and want to review it with someone, the Tiqania team is available here.