Blog

How to Plan a Legacy System Integration

Legacy systems are often treated as a problem to replace. In many organizations they are still the place where orders, inventory, claims, financial records, or customer history actually live. The software may be older. It may also still do its core job well.

The harder question is usually not "should we delete it tomorrow?" It is "how should this established system exchange information with a newer application, platform, or workflow without corrupting the records people already trust?"

This guide is for technical leads, CTOs, product owners, engineering leads, IT leaders, and operations leaders who need a planning sequence before integration work starts. It is a commercial evaluation and design briefing, not a coding tutorial.

What the legacy system actually owns

Start by inventorying ownership, not interfaces. List the business entities the older system still governs: customers, products, invoices, appointments, inventory levels, or whatever defines daily operations. For each entity, note who updates it, who reads it, and which reports depend on it.

Teams get into trouble when they treat a legacy application as a black box and still expect a new product to become the system of record overnight. If the older system remains authoritative for an entity, the integration should respect that. If authority will move later, plan the transition as a separate decision, not as a side effect of the first connection.

Source of truth before connectors

Decide, entity by entity, which system is allowed to create or change the canonical record. Dual write without clear authority produces silent conflict: two systems hold different "current" values, and operators invent spreadsheets to reconcile them.

A useful planning artifact is a short ownership map. For every critical field group, name the system of record, the systems that may read a copy, the systems that may request a change, and the systems that must never invent their own version. That map constrains later technical choices more than any vendor brochure.

Inspect the interfaces that already exist

Only after ownership is clear should the team inspect what the legacy environment can actually expose. Available options vary widely: documented APIs, undocumented APIs that still require reverse engineering, scheduled exports, flat-file drops, secure file transfer, database views, stored procedures, message queues, or partner-mediated exchange.

Document constraints as carefully as capabilities. Rate limits, batch windows, nightly processing cutoffs, brittle authentication, limited field coverage, and read-only endpoints all change the design. An interface that can export yesterday's snapshot is not the same as one that can accept near-real-time updates with acknowledgements.

Choose an exchange approach that fits the system

There is no universal "best" legacy integration method. Choose based on what the system can support, how fresh data must be, and how failures should be handled.

APIs and webhooks

APIs help when the legacy or surrounding platform exposes stable create, read, and update operations. Webhooks help when one side can notify the other that something changed. Both still need authentication, validation, idempotency, and clear behavior when a call times out or returns a partial success.

Scheduled synchronization

Scheduled sync fits when near-real-time updates are unnecessary and overnight or hourly windows are acceptable. It is often easier to operate than chatty event flows, but teams must design conflict rules for records changed on both sides between runs.

Files, CSV, and structured transfers

File-based exchange remains common with older systems and external partners. CSV, fixed-width, XML, or other structured files can be reliable when formats, naming, schedules, acknowledgements, and quarantine folders are explicit. They become operational debt when a missing file is discovered only after finance or customer support notices wrong numbers.

Database-mediated approaches

Direct database access or shared tables sometimes appear when APIs do not exist. They can be fast to prototype and expensive to maintain. Schema changes, locking behavior, security boundaries, and unclear ownership of writes make this path risky unless governance is unusually strong. Prefer it only when safer interfaces truly are unavailable and the risk is accepted deliberately.

Middleware or a custom integration layer

An integration service or custom middleware layer can centralize mapping, retries, logging, and monitoring when several systems participate or when the legacy surface is awkward. That layer is itself software your organization must own. It earns its keep when it reduces brittle point-to-point links; it fails when it becomes an undocumented second product nobody maintains.

When the work is mainly connecting systems and data flows, start with System Integration. A custom application or integration layer may also belong under Custom Software Development when the exchange logic, ownership rules, or operator tooling go beyond configuration.

Mapping, identifiers, and validation

Most integration failures are data-design failures. Agree on identifiers early: customer numbers, SKUs, internal UUIDs, partner codes. Decide how to handle records that exist in one system and not the other. Document field mapping with types, allowed values, null handling, and timezone or currency conventions.

Validation should happen before writes reach the system of record. Invalid dates, truncated strings, unknown status codes, and duplicate keys should land in a reviewable error path, not in corrupted production rows. If humans currently catch these issues in spreadsheets, the integration needs an equivalent, preferably better, control.

Design for failure before you design for success

Happy-path demos are easy. Production integrations fail in ordinary ways: timeouts, delayed batches, invalid payloads, partial updates, duplicate deliveries, conflicting edits, and retries that create more duplicates.

Plan answers to these questions before go-live:

What happens to a failed message or file, and who is alerted?
How do you prevent the same event from creating duplicate records?
If only half of a multi-step update succeeds, how is the system left consistent?
What is the retry policy, and when do retries stop?
How are delayed batches distinguished from missing batches?
When two systems update the same entity, which value wins and how is the loser reconciled?
Where do operators inspect logs, error queues, and reconciliation reports?

These are engineering considerations, not evidence of any particular client failure. Integrations that skip them usually push failure detection back onto people, which recreates the manual work the project was meant to remove.

Authentication, throughput, and operational limits

Treat credentials, tokens, certificates, and network paths as first-class design items. Rotate secrets, limit privilege to the minimum needed fields and operations, and avoid giving an integration account broad write access "just in case."

Throughput limits matter as much as security. A nightly export of 50,000 records has different failure modes than a burst of webhook traffic during a promotional peak. Match the exchange approach to the real volume and to any hard ceilings the legacy platform imposes.

Test incrementally, then monitor after release

Do not connect every entity on day one. Start with a narrow flow: one entity type, one direction of authority, a small volume, and observable outcomes. Compare counts and sample records between systems. Add automated checks for duplicates, missing acknowledgements, and mapping exceptions.

Rollout should include an explicit rollback or pause plan: how to stop writes, how to drain queues, and how to leave operators with a known state. After launch, monitoring should cover success rates, lag, error volume, and reconciliation gaps, not only server uptime.

Ownership after launch

Integrations age poorly when nobody owns mapping changes, certificate expiry, schema drift, or vendor upgrades on either side. Name an owner for the interface, an owner for each system of record, and a path for change requests when either application evolves.

Also decide what manual bridges can be retired once the connection is stable. If spreadsheets remain the unofficial truth, the project has not finished.

A practical planning sequence

1. Understand what the existing system still owns and which workflows depend on it.

2. Assign source-of-truth ownership for each critical entity and field group.

3. Inspect available interfaces and their real constraints.

4. Choose an exchange approach that fits freshness, volume, and maintainability.

5. Design failure handling, retries, duplicate prevention, and reconciliation before coding the happy path.

6. Test with a narrow slice, then expand.

7. Monitor after release and keep ownership of mappings and incidents explicit.

Next step

Explore System Integration when the requirement is connecting an established system to newer applications and workflows. If the integration needs a durable custom layer or supporting application, review Custom Software Development. To discuss an integration requirement, talk to our team.

Back