Every company has at least one legacy system they're afraid to touch. The payroll application built in VB6. The inventory system running on a Windows Server 2008 VM. The "temporary" PHP script from 2012 that somehow became the backbone of order processing. These systems work — until they don't. And when they fail, they take revenue with them.
We've modernized legacy systems for clients in manufacturing, logistics, and professional services. The one thing we've learned: the full rewrite is almost always wrong. Here's what works instead.
Assessing Your Legacy System
Before choosing a strategy, assess the system honestly. Not all legacy systems need modernizing — some just need better care.
| Signal | Severity | Action |
|---|---|---|
| Runs on unsupported OS/runtime (e.g., Windows Server 2012, PHP 5.x) | Critical — security risk | Replatform or containerize immediately |
| Only 1-2 people understand the codebase | High — bus factor risk | Document, then incrementally modernize |
| Can't add new features without breaking existing ones | High — velocity blocker | Strangler fig or modular extraction |
| Performance degrades under current load | Medium-High | Replatform (cloud) or optimize (database/caching) |
| Integration with modern tools is difficult (no API) | Medium | API wrapper or integration layer |
| UI looks dated but system works fine | Low | Frontend refresh only — don't touch the backend |
The Six Modernization Strategies
Gartner's "6 R's" framework, adapted with our practical experience:
| Strategy | What It Means | Effort | Risk | Best For |
|---|---|---|---|---|
| Retain | Keep as-is, improve monitoring/security | Minimal | Low | Systems that work and rarely change |
| Retire | Decommission — it's no longer needed | Low | Low | Duplicate systems, unused features |
| Rehost (lift & shift) | Move to cloud without code changes | Low-Medium | Low | On-prem servers needing cloud benefits |
| Replatform | Move to a modern platform with minor changes | Medium | Medium | Database migrations, runtime upgrades |
| Refactor (strangler fig) | Incrementally rebuild around the legacy system | Medium-High | Low-Medium | Business-critical systems that need new features |
| Replace | Full rebuild or switch to SaaS | High | High | Last resort when the system is fundamentally unfit |
The Strangler Fig Pattern (Our Favorite)
Named after a tree that grows around its host, this pattern lets you replace a legacy system piece by piece while the old system keeps running. It's the safest approach for business-critical systems.
How It Works
- Identify a module to extract (start with the one that changes most often or causes the most pain)
- Build the replacement as a separate service with its own database and API
- Route traffic — new requests go to the new service; legacy handles everything else
- Verify — run both in parallel, comparing outputs (shadow mode)
- Cut over — switch traffic to the new service, keep the old one as a fallback
- Repeat for the next module
┌──────────────┐ ┌────���────────────┐ ┌──────────────┐
│ │ │ API Gateway │ │ New Auth │
│ Clients │────▶│ (Router) ���────▶│ Service │
│ │ │ │ └──────────────┘
└──────────────┘ │ Routes: │
│ /auth/* → New │ ┌──────────────┐
│ /* → Legacy │────▶│ Legacy │
│ │ │ Monolith │
└─────────────────┘ └──────────────┘We used this pattern to modernize a logistics client's order management system over 8 months. We extracted authentication first (2 weeks), then order creation (4 weeks), then reporting (3 weeks). By month 8, the legacy system only handled one rarely-used module — which we retired a month later.
Data Migration Without Downtime
Data migration is where modernization projects die. The old system has 10 years of data with inconsistencies, duplicates, and undocumented relationships. Here's our approach:
- Dual-write pattern: New system writes to both old and new databases during transition. Old system remains the source of truth until verification passes.
- Incremental migration: Move data in batches, not all at once. Start with the most recent 6 months (active data), then backfill historical data.
- Data cleansing before migration: Fix data quality issues in the old system BEFORE migrating. Migrating dirty data into a clean system creates a new legacy problem.
- Rollback plan: Every migration step must be reversible. If step 5 fails, you can roll back to step 4 without losing data.
Risk Management During Migration
| Risk | Likelihood | Mitigation |
|---|---|---|
| Undocumented business rules in legacy code | Very High | Shadow mode: run old and new in parallel, compare outputs for 2+ weeks |
| Data inconsistencies during dual-write | High | Reconciliation job that compares databases nightly; alerts on drift |
| Team underestimates legacy complexity | High | Time-box each module migration; adjust estimates after the first one |
| Users resist the new system | Medium | Involve power users in testing; change management from day one |
| Integration points break during migration | Medium | API compatibility layer: new system exposes same endpoints as old system initially |
Frequently Asked Questions
How long does legacy modernization typically take?
Simple rehosting: 2-4 weeks. Strangler fig for a medium-complexity system: 6-12 months. Full replacement: 12-24 months (and it always takes longer than planned). The strangler fig approach gives you value incrementally — you're not waiting a year for the payoff.
Should we modernize or replace with SaaS?
If a SaaS product covers 80%+ of your requirements, replace. If your system has significant custom business logic that no SaaS handles, modernize. We've seen companies force-fit Salesforce to replace a custom CRM and spend more on customization than the original system cost to maintain.
Can we modernize while adding new features?
Yes — that's the beauty of the strangler fig pattern. New features are built in the new system. The legacy system stays frozen (maintenance-only). Over time, the new system absorbs more functionality and the legacy shrinks. You're modernizing AND delivering features simultaneously.
What about modernizing the database?
Database modernization is the hardest part. Our recommendation: keep the legacy database as the source of truth longer than feels comfortable. Build new services that read from it via views or APIs. Migrate the database last — after all application code is running on the new platform. Database migration is a topic that deserves its own guide.