LEGACY MODERNIZATION ARCHITECTURE
The safest way to modernize legacy software — one module at a time.
TL;DR: The Strangler Fig Pattern replaces legacy systems incrementally — building new services alongside the old one, routing traffic gradually, and decommissioning the legacy system only after the replacement is proven in production. Zero downtime. Zero data loss. This is the strategy we use for every legacy modernization project at RPDI, from COBOL mainframes to SQL Server database migrations. Named after the strangler fig tree that grows around its host until the original is no longer needed.
Why Big-Bang Rewrites Fail
Every year, companies attempt "let's just rebuild it from scratch." And every year, most of them fail. The data is consistent across our project portfolio and industry benchmarks:
- 18-24 months is the average timeline for a full rewrite of a medium-complexity system
- 70% of rewrite projects go over budget or are abandoned entirely
- Business never stops — while you're rebuilding, the old system still needs maintenance, leaving you paying for two systems simultaneously
- Institutional knowledge disappears — legacy systems contain years of business logic that nobody documented. Rebuild from scratch and you'll spend months re-discovering rules you already solved
The Strangler Fig Pattern exists specifically to eliminate these risks.
How the Strangler Fig Pattern Works
Named after the strangler fig tree — which grows around a host tree, eventually replacing it entirely — this pattern follows three engineering phases:
Phase 1: Wrap
Put an API layer (a "facade") in front of the legacy system. All requests now route through this new layer. The legacy system doesn't know the difference — it still receives the same requests. But now you control the routing and can intercept, transform, or redirect any traffic.
Phase 2: Replace
Build new microservices for individual modules. Start with the lowest-risk, highest-value module. Route traffic to the new service for that module only. The facade handles the routing — users never notice the switch. The legacy system still handles everything else.
Phase 3: Retire
Once all modules are replaced and validated in production, decommission the legacy system. By this point, it's handling zero traffic. Turn it off. No drama. No downtime. No migration weekend.
Real Project: Houston Energy Company (VB6 → Cloud)
A Houston-based pipeline inspection company was running a 15-year-old VB6 application for work order management. 200+ field workers depended on it daily. Two agencies quoted a full rewrite at $180,000 and 12 months.
Using the Strangler Fig approach, we completed the migration in 5 months at 76% less cost:
| Phase | What We Built | Cost |
|---|---|---|
| Month 1 | REST API facade wrapping the VB6 system | $8,000 |
| Month 2 | New dispatch dashboard (React) — highest-pain module routed first | $15,000 |
| Month 3 | Mobile-first PWA for field data entry — 200 workers moved off desktop VB6 | $12,000 |
| Month 4 | Reporting module with real-time analytics — VB6 now only handling legacy exports | $8,000 |
| Month 5 | Legacy system decommissioned | $0 |
| Total | Complete modernization — zero downtime | $43,000 |
Application: Mainframe and COBOL Migrations (Healthcare)
The healthcare industry is sitting on "bulletproof" mainframes deployed in the late 90s. They technically still process claims, but the developers who maintain them are retiring, and the systems can't interface with modern patient portals or automated insurance verification APIs.
For a mid-to-large medical practice running legacy AS/400 or mainframe billing, we apply the Strangler Fig pattern over a 4-6 month timeline:
- Month 1: Code freeze on the mainframe. Automated analysis of the legacy codebase — mapping data structures, business logic, and external dependencies.
- Month 2-3: HIPAA-compliant AWS environment provisioned. Change-data-capture (CDC) pipeline replicates mainframe data to PostgreSQL in real-time.
- Month 4: Core business logic translated to modern microservices (Node.js/Go). Secure API layer built. Legacy system remains source of truth, but modern apps can interact with the data.
- Month 5-6: Clinical workflows (patient intake, then billing) systematically routed to the new system. Once all workflows are validated, mainframe decommissioned.
Application: SQL Server to PostgreSQL (Database Migration)
Database migration is a specific application of the Strangler Fig philosophy. Instead of a risky overnight cutover, we run both databases in parallel during transition:
- Schema Translation: Automated schema conversion (pgLoader or AWS SCT) handles table definitions. We manually review edge cases — T-SQL stored procedures, computed columns, SQL Agent jobs.
- Stored Procedure Rewrite: T-SQL to PL/pgSQL conversion. For a typical billing database, this is 20-50 procedures, each tested against sample data with output parity validation.
- Parallel Sync: pgLoader handles bulk data transfer (50GB in under 2 hours). Logical replication keeps both databases synchronized during the transition period.
- Application Cutover: Connection strings updated. If the app uses an ORM, it's a single config file change. If it uses raw SQL, we audit every query for compatibility.
| Migration Type | Typical Timeline | Cost Range | Annual Savings |
|---|---|---|---|
| SQL Server → PostgreSQL | 6-10 weeks | $15K-$30K | $15K-$50K/year (licensing elimination) |
| COBOL/AS400 → Cloud | 4-6 months | $40K-$80K | $30K-$100K/year (hardware + talent costs) |
| VB6/Access → Web App | 3-5 months | $25K-$50K | Operational risk elimination (unquantifiable) |
| Big-Bang Rewrite (for comparison) | 12-24 months | $100K-$300K | 70% failure rate before completion |
When Should You NOT Use the Strangler Fig Pattern?
- System is tiny — if the legacy app is under 5,000 lines of code, a full rewrite via a 30-day MVP sprint is faster and cheaper
- No API access — if you can't put a facade in front of the legacy system (rare, but some mainframes resist wrapping)
- Hard compliance deadline — if a regulation requires you to be on a new system by a specific date, the incremental approach might not be fast enough
The Houston Factor
Houston's industrial base runs on legacy software. Pipeline inspection firms, logistics operators, medical practices, energy companies — these organizations depend on applications that were deployed before the iPhone existed. The talent pool capable of maintaining COBOL, VB6, and RPG is shrinking every year. The cost of not modernizing is accelerating — see our analysis of why Houston companies are replacing legacy software in 2026.
We've executed Strangler Fig modernizations for multiple Houston industrial companies. The pattern works because it respects operational reality — your business doesn't stop while we upgrade the infrastructure underneath it.
Legacy system keeping you up at night?
Start With a 2-Week Code Audit
We assess your legacy codebase, map all dependencies, and deliver a phased migration roadmap with fixed pricing. If the system is too small for Strangler Fig, we'll tell you and recommend a simpler path.
Schedule Your Code Audit ($5K) →