Integrating Legacy Systems: The Honest Playbook for US Mid-Size Companies

Every US mid-size company we work with has some version of this conversation: there’s a legacy system at the core of operations, it works (mostly), nobody wants to touch it, and it doesn’t integrate with anything modern. The data inside it is critical. The interface is from 2003. The original developers left years ago. The current team is afraid to make changes.

The choice usually feels binary: rewrite it (expensive, risky, slow) or leave it alone (everything else stays disconnected from it). Neither is the right answer for most cases. The right answer is integration: wrap the legacy system with modern interfaces so new infrastructure can interact with it without forcing a rewrite.

The integration work is harder than vendors promise and easier than companies fear. The patterns below are what works.

What “legacy” actually means in 2026

For most US mid-size companies, legacy systems fall into one of these categories:

Type 1: On-premises commercial software (Microsoft Dynamics GP, Sage 100, JD Edwards, Macola, custom CRM from 2007). The software vendor still exists but the version you’re on is old. Upgrading is technically possible but expensive and risky.

Type 2: Custom-built internal applications. Built by an in-house developer or local consulting firm 10-20 years ago. The original team is gone. Documentation is minimal. Code lives in a SVN or TFS repository nobody has accessed in 5 years.

Type 3: Database-centric systems with embedded business logic. SQL Server or Oracle databases where most of the business logic lives in stored procedures, triggers, and views. The “application” is just a UI on top of the database.

Type 4: Mainframe and AS/400 systems. Still common in manufacturing, financial services, and some healthcare. Run reliably for decades but talk only through arcane interfaces.

Type 5: Embedded systems and SCADA. Industrial control systems in manufacturing, utilities, logistics. Often run on Windows XP or older. Network access is restricted for security reasons.

The integration approach differs by type. Type 3 and Type 1 are the most common in mid-size companies and the integration patterns are reasonably mature.

The integration patterns that work

Pattern 1: API wrapper around legacy system.

The most common pattern. Build a modern REST or GraphQL API that internally talks to the legacy system through whatever interface is available (direct database access, file imports/exports, old web services, screen scraping in worst cases).

External applications interact with the API. The legacy system stays untouched. The wrapper becomes the integration point for everything new.

Best for: Type 1, Type 2, Type 3 legacy systems where read access and limited write access are feasible.

Implementation effort: typically 4-12 weeks for a focused API wrapper covering 10-20 core operations.

Pattern 2: Event-driven integration via change data capture.

The legacy system continues operating as it always has. A change data capture (CDC) layer reads database transaction logs and publishes events when data changes. Modern applications subscribe to those events and react accordingly.

Best for: Type 3 (database-centric) legacy systems where you can install CDC tools (Debezium, AWS DMS, Fivetran) on the database.

Implementation effort: typically 6-16 weeks depending on the number of tables and downstream consumers.

Pattern 3: Scheduled ETL pipelines.

Modern data infrastructure (a data warehouse or operational data store) gets populated by scheduled extracts from the legacy system. Modern applications read from the modern data store, not the legacy system. Writes to the legacy system go through a separate sync process.

Best for: Type 1, Type 4 legacy systems where real-time integration isn’t required and the data volume is manageable.

Implementation effort: typically 4-10 weeks for the initial pipeline, then ongoing maintenance.

Pattern 4: Replica database for read access.

Set up a replica of the legacy database that modern applications can read from without affecting the production system. Writes still go through the legacy system, but reads happen against the replica with no risk to the original.

Best for: Type 3 legacy systems where read-only access is the primary integration need.

Implementation effort: typically 2-6 weeks for setup plus ongoing replication maintenance.

Pattern 5: Service mesh facade.

For more complex legacy systems with multiple interfaces, build a service mesh layer that provides a single modern interface while internally routing to the right legacy subsystems. Less common for mid-size companies but powerful when needed.

Best for: Type 4 mainframe systems with multiple components needing integration.

Implementation effort: typically 12-24 weeks for the initial mesh plus ongoing work as integration needs expand.

The 90-day integration project structure

For most mid-size company legacy integration projects, the work fits in a 90-day window if structured well:

Weeks 1-3: Discovery and architecture.

• Map the legacy system: what data is in it, what operations does it support, what interfaces are available
• Document the business operations that depend on it
• Identify the 5-10 most important integration points (the operations external systems need to do with it)
• Choose the integration pattern that fits
• Set up development infrastructure (replica database, test environments, monitoring)

Weeks 4-8: Core integration build.

• Build the wrapper, ETL pipeline, or CDC integration for the chosen pattern
• Implement the 5-10 most important integration points
• Build automated tests against representative data
• Set up monitoring and alerting

Weeks 8-11: Integration with consuming systems.

• Connect the first downstream consumer (modern web app, mobile app, partner integration)
• Validate end-to-end flows work correctly
• Fix issues that emerge with real usage
• Build the second and third consumer integrations

Week 12: Production cutover and stabilization.

• Roll out to production
• Monitor closely for first week
• Address issues that emerge
• Document the integration patterns for future expansion

This timeline assumes the legacy system has accessible interfaces (database access, web service endpoints, file exports). Some legacy systems are more locked down and require more discovery work upfront.

What goes wrong (and how to prevent it)

The integration projects that fail show consistent patterns.

Failure 1: Underestimating data complexity.

The legacy system has accumulated 10-20 years of edge cases, exceptions, and special rules. The integration project assumes the data is “mostly clean” and discovers in week 6 that 15% of records have non-obvious quirks that break the integration.

Prevention: Spend the first 2 weeks of any integration project actually looking at the data. Pull samples. Run profiling queries. Talk to the people who use the system daily about what edge cases they handle manually. The data is always messier than the documentation suggests.

Failure 2: Building everything before testing anything.

The team designs the complete integration architecture, builds it for 8 weeks, then tries to plug in the first consumer in week 9 and discovers fundamental issues. Schedule slips by 8 weeks.

Prevention: Build vertical slices end-to-end. Pick the simplest integration scenario, get it working all the way from legacy system to consumer system, then add the next slice. Continuous validation prevents big surprises.

Failure 3: Ignoring the operational reality of the legacy system.

The legacy system has scheduled maintenance windows, peak usage periods, and operational constraints. The integration project doesn’t account for them. The integration works in testing but breaks in production because the team didn’t realize the legacy database has heavy load during month-end close.

Prevention: Talk to the operations team running the legacy system. Understand the patterns. Design the integration to respect them.

Failure 4: No fallback when the legacy system is unavailable.

The integration becomes a hard dependency. When the legacy system is down for scheduled maintenance, every modern system that depends on it breaks too. Suddenly the integration project has made operations more fragile, not less.

Prevention: Design for graceful degradation. Cache critical reference data. Queue writes when the legacy system is unavailable. Make sure modern systems can operate in read-only mode if integration is temporarily broken.

Failure 5: Skipping documentation because “we’ll do it later.”

The integration ships. The team moves to the next project. Two years later, someone needs to extend the integration and discovers no documentation exists. Reverse-engineering takes weeks.

Prevention: Document as you build. Not exhaustive specs but enough to onboard a future developer: what does each integration do, what data does it move, what are the failure modes, who owns ongoing maintenance.

The decision: integrate or replace?

Sometimes the legacy system genuinely needs to be replaced, not integrated. The signals that suggest replacement might be the right call:

• The legacy system’s underlying business logic has fundamental problems (not just technical issues)
• The cost of ongoing maintenance is approaching the cost of replacement
• Critical features the business needs cannot be added to the legacy system
• The legacy vendor is going out of business or has dropped support
• Compliance or security requirements cannot be met by the legacy system

If none of these apply, integration is usually the better path. Replacement projects for mid-size companies often run 18-36 months with significant operational disruption. Integration projects ship in 90 days and keep operations stable.

The honest test: would the business operations actually improve if the legacy system was replaced? Sometimes yes. More often, the business operations just need the legacy data accessible to modern tools, which integration solves at a fraction of the cost.

The cost reality

For most mid-size company legacy integration projects:

• API wrapper approach: $40-150K for initial build, $20-50K/year ongoing maintenance
• CDC/event-driven approach: $60-200K for initial build, $30-80K/year ongoing
• ETL pipeline approach: $30-100K for initial build, $20-40K/year ongoing
• Replica database approach: $20-60K for initial build, $10-30K/year ongoing
• Service mesh approach: $150-500K for initial build, $80-200K/year ongoing

Compare to full system replacement:

• Mid-size ERP or core business system replacement: $500K-$3M, 18-36 months, significant operational risk

For most companies, integration is dramatically cheaper than replacement and ships much faster. The math heavily favors integration for the cases where it’s feasible.

What good integration looks like

The legacy integration projects that succeed have these characteristics:

• Modern applications can interact with legacy data without touching the legacy system directly
• The legacy system continues operating normally; no team needs to learn it to use the integrated data
• The integration is monitored and has clear ownership
• Failure modes are understood and handled gracefully
• Documentation exists for the next team that needs to extend the integration
• The integration is treated as production infrastructure, not a side project

When these characteristics are in place, the legacy system stops being a constraint on what the business can do digitally. The data inside it becomes accessible to whatever modern tools and processes the business needs.

The legacy system might still need to be replaced eventually. But integration buys years of optionality and unlocks immediate business value, at a fraction of the cost and risk of replacement.

For most US mid-size companies in 2026, integration is the right answer for legacy systems. The patterns are mature. The work is bounded. The business outcomes are substantial. The teams that have done this well have unlocked operational capabilities they wouldn’t have otherwise had access to for years.