Most mid-sized and large organizations run several core systems that were bought at different times from different vendors. An ERP holds finance and supply data, a CRM holds customer interactions, and in healthcare a hospital information system, usually called a HIS, holds patient records, orders and billing. Connecting them is rarely the most visible part of a project, yet it often decides whether the project finishes on time. This article covers the problems that appear most often and the practices that reduce them.

Why integration projects slip

Integration estimates tend to be optimistic because the work is hidden until it starts. Four causes appear repeatedly.

  • Undocumented fields. A table has a column used for a purpose nobody remembers, and the only way to learn its meaning is to ask the person who configured it years ago.
  • Two sources of truth. Customer or product data exists in both systems, and the two copies disagree. Someone has to decide which one wins and under what rules.
  • Batch versus real-time expectations. A business user asks for current data, the source system can only export nightly, and the gap is discovered late.
  • Vendor-controlled interfaces. The vendor decides which interfaces are available, what they cost and when they change, so the integration team depends on external schedules.

Interface options

The choice of interface depends on what the source system supports and how fresh the data must be. REST and SOAP web services are the most common route for modern ERP and CRM products. They support request and response exchange and are easy to monitor, but they require the source system to expose the right operations.

File exchange is still widespread. Scheduled CSV or XML exports are simple and robust, and they suit reporting and nightly synchronization. Message queues decouple the sender from the receiver, so one side can be unavailable for a while without losing data. They suit event-driven flows where order and delivery matter.

In health data, HL7 version 2 messages remain common for admissions, orders and results, and FHIR is increasingly used for API-based exchange. Using these standards reduces custom mapping, although local profiles and extensions still need to be agreed with each vendor.

Data mapping and data quality

Mapping is the core of the work. For each field the team records the source, the target, the transformation and the rule for conflicts. Code lists, units, date formats, character encodings and identifiers need particular attention, since a patient, a customer or a product can carry a different identifier in each system.

Data quality problems usually surface during this stage, such as duplicate records, missing mandatory values and free-text fields used as codes. These are best resolved at the source, with cleaning rules agreed with the data owners, and not patched inside the interface where they become invisible.

Security and audit

Integration accounts should follow least privilege, with access limited to the operations the interface needs. Every call that reads or changes personal data should be logged with who, what and when, and the logs should be protected and retained according to policy.

Personal data is subject to KVKK in Türkiye and GDPR in the EU. For health data the requirements are stricter. The integration design should define what data is transferred, for what purpose, how it is protected in transit and at rest, and how long copies are kept.

Testing and rollback

Interfaces should be tested with realistic data, including edge cases such as long names, special characters, cancelled orders and corrected results. Test environments that mirror production versions of both systems are valuable, because behavior often differs between versions. A cutover plan should state the order of steps, the checks after each step and the conditions under which the team returns to the previous state.

Operating after go-live

An interface is a running service. It needs monitoring for failures and delays, an error queue where rejected messages can be inspected and replayed, and alerts that reach a named person. Each interface should have an owner on the business side and on the technical side, with documentation that describes its purpose, schedule, mapping and known limits. Without this, small failures accumulate until the data in the two systems no longer matches.