Define the failure boundary before choosing a tool
The first question should not be whether an engineering team can extract the data. It should be what happens when the integration fails. Reading a product catalog is materially different from posting a shipment, changing inventory, or confirming payment. A daily batch also has different requirements from a transaction that must be visible within seconds. Start by documenting the system of record, data owner, permitted latency, expected volume, recovery owner, and whether an incorrect action can be reversed.
Treat the legacy application as a protected boundary even if its database credentials are available. Business rules are often hidden in screens, triggers, batch jobs, or undocumented field combinations. A direct table update can appear successful while bypassing validation and leaving inconsistent records behind. Prefer read-only, asynchronous, and replayable flows first. Add write capability only when there is a clear business requirement and the legacy system owner can confirm the supported write path.
Choose a pattern according to risk and timing
No single interface is right for every legacy application. A useful approach is to rank the available patterns by invasiveness, operational burden, and latency:
- Read-only database access:Ask the system owner to expose restricted views, stored procedures, or a reporting replica containing only the required fields. This is fast and transparent, but queries must be rate-limited and consumers should not depend on unstable internal table structures.
- Managed file exchange:Exchange CSV, XML, or JSON through SFTP or controlled object storage. Files are not ideal for real-time work, but they are easy to isolate, inspect, replay, and reconcile. Define naming, encoding, versioning, completion markers, retention, and duplicate-file behavior explicitly.
- Change data capture:If transaction logs or change tables are available, CDC can publish changes to a queue or staging database without aggressive polling. The trade-off is added infrastructure and careful handling of ordering, deletions, schema changes, and full resynchronization.
- Controlled database writes:Use dedicated stored procedures, staging tables, or import queues only after the vendor or application owner confirms the business rules. Integration code should not update core transaction tables directly or share an administrator account.
- User-interface automation:RPA or browser automation can reproduce human actions when no other entry point exists. It can be reasonable for low-volume or transitional workflows, but screen changes, pop-ups, session expiry, and authentication updates make it fragile. Keep a manual fallback and treat it as a last resort.
Four questions usually narrow the choice: How current must the data be? Is an incorrect write reversible? How much additional load can the legacy system tolerate? Can interface changes be announced in advance? An overnight reporting feed rarely justifies the operational cost of real-time CDC. Conversely, inventory commitments or payment status should not depend on an unacknowledged file transfer with no reconciliation process.
Use an integration layer to contain uncertainty
Whichever entry point is selected, place a dedicated integration service—often called an anti-corruption layer—between the legacy system and its consumers. This layer converts proprietary fields and codes into a stable business model, validates required values, and exposes a consistent API or event contract. Downstream applications should not need to understand old table layouts, screen behavior, or undocumented status codes. This also reduces the blast radius when the legacy application is replaced.
The integration layer must assume that messages and jobs can be delivered more than once. Give each operation a stable business identifier or idempotency key, check whether it has already been processed, and record the source version and processing state. Failed items should enter a visible retry queue with bounded retries rather than looping indefinitely. Cross-system operations rarely share a reliable database transaction, so record each step, support compensating actions where practical, and run scheduled reconciliation to detect missing, duplicated, or conflicting records.
Security controls belong in the architecture, not only in a runbook. Use dedicated service identities with least privilege, store credentials in a secrets manager, restrict source networks and connection windows, and mask or encrypt sensitive fields. Audit reads, transformations, writes, retries, and manual corrections. At the same time, keep passwords, tokens, and complete personal records out of logs. Operators need enough context to diagnose a failure without turning observability data into another sensitive database.
Require stoppability, verification, and an evolution path
Before enabling writes, run the integration in read-only shadow mode and compare volumes, latency, mappings, and business outcomes. Introduce write traffic in a narrow scope. Apply rate limits, timeouts, circuit breakers, and a kill switch so the connector can stop when the legacy application slows down or produces abnormal output. Useful monitoring includes queue depth, age of the oldest pending item, source-to-target count differences, validation failures, and reconciliation exceptions—not merely a successful process exit.
Assume schema drift will happen. Add contract tests for new columns, type changes, code-list updates, and file-format revisions, using replayable samples with sensitive data removed. Every change needs a compatibility window, rollback procedure, and named owner. If UI automation becomes responsible for core transactions, or database write rules grow too complex to verify, that is a strong signal to invest in a supported API, event interface, or targeted module replacement.
The goal is not to modernize every legacy system immediately. It is to create a controlled path from isolation and observation to restricted writes, while gradually replacing fragile interfaces. An experienced integration team can help assess the options and build the boundary, but data ownership, acceptable failure modes, and recovery decisions still need explicit agreement from the business and system owners.