The Legacy System Problem
According to McKinsey, over 70% of enterprise IT budgets are spent maintaining existing systems rather than building new capabilities. But modernisation projects have a terrible track record. Gartner reports that 83% of data migration projects either fail or exceed their budgets. The reason is not technical — it is strategic. This framework breaks the process into six manageable steps.
Step 1: Discovery and Assessment (2-4 Weeks)
Before writing a line of code, you must understand exactly what you are dealing with.
Technical Discovery
- Application mapping — Document all components, services, batch processes, integrations, and data flows.
- Dependency analysis — Map upstream and downstream dependencies. Legacy systems often have undocumented integrations.
- Technology audit — Catalogue the tech stack. Identify end-of-life or unsupported components.
- Performance baseline — Capture current metrics to validate that the modernised system performs at least as well.
Business Discovery
- Business process mapping — Identify which processes are core differentiators vs commodity functions.
- User interviews — Actual users know the system's workarounds and pain points.
- Cost of doing nothing — Calculate annual maintenance cost. This is your business case.
Step 2: Define the Target Architecture (2-3 Weeks)
For most clients, we recommend the strangler fig pattern: incrementally replace legacy components with modern services while the legacy system continues running. You deliver value incrementally and can stop at any point with a partially modernised system that still works.
Step 3: Build the Foundation (4-8 Weeks)
- Infrastructure as Code — Terraform or Pulumi. Non-negotiable.
- CI/CD pipeline — Include integration tests that validate behaviour against the legacy system.
- API gateway / routing layer — The critical component for strangler fig migration. Start with 100% of traffic going to legacy, then shift route by route.
- Observability stack — Centralised logging, metrics, and tracing for both systems.
- Data synchronisation layer — Bidirectional data sync using Change Data Capture (Debezium).
Step 4: Incremental Migration (3-12 Months)
- Static content and read-only endpoints — Zero risk of data corruption.
- Non-critical write operations — Build confidence in data synchronisation.
- Core business logic — one domain at a time — Do not partially migrate a domain.
- Authentication and authorisation — Migrate last, or implement a shared auth layer early.
Step 5: Validation and Cutover (2-4 Weeks per Component)
- Functional testing, performance testing, data integrity verification, and rollback testing.
- For critical business logic, use the parallel run pattern: route requests to both systems, compare results, but only return the legacy response until confidence is established.
Step 6: Decommission the Legacy System (2-6 Weeks)
- Stop writes to legacy database (keep read-only for 30-90 days)
- Archive the legacy database for compliance
- Decommission infrastructure, cancel licences
- Update documentation
Realistic Timelines
| System Complexity | Timeline | Team Size |
|---|---|---|
| Small (single app, < 50K LOC) | 3-6 months | 2-4 engineers |
| Medium (3-5 apps, integrated) | 6-12 months | 4-8 engineers |
| Large (enterprise system of systems) | 12-36 months | 8-15+ engineers |
If you recognise the signs that your legacy system needs modernisation, our legacy modernisation service follows this exact framework. We start with a fixed-price discovery phase. Contact us to start the conversation.
