PHP 5.6, Classic ASP, Visual Basic, on-prem Delphi, monolithic Java EE, ageing .NET 4. Whatever your legacy stack, we replace it piece by piece — with the business still running, the data preserved, and the rewrite never blowing the budget.
Legacy systems don't die in a single dramatic failure. They die from a thousand quiet cuts — until the day a new requirement, a security advisory, or a key-person resignation forces the rebuild that should have been planned three years earlier.
The codebase is brittle and untested. Changes ripple unpredictably. Engineers tip-toe around modules they don't understand. What should be a one-week feature becomes a three-week archaeology project. The roadmap silently halves its throughput.
"PHP 5.6 and Classic ASP, on Windows Server 2008" is a job advert that doesn't attract candidates. The team that still maintains it is shrinking, and replacing them takes 6 months and a 30% salary premium per person. Eventually one person knows the system, and they're a flight risk.
PHP versions out of support. Frameworks that haven't shipped a release in 5 years. Libraries with known CVEs you literally cannot upgrade because the runtime is too old. The compliance officer is starting to ask uncomfortable questions.
Big-bang rewrites have ~70% failure rate in the industry. We've seen it on the ground: 18-month "phase 1" projects that ship nothing, run out of budget, and leave the team back on the legacy system with three new architectures' worth of half-built code.
There are basically three patterns to retire a legacy system. The right one depends on the system, the business risk tolerance, and the budget. We'll tell you honestly which fits — and we'll talk you out of the wrong one.
Move the legacy system to modern infrastructure (cloud, containers) without rewriting the code. Buy time, reduce hosting risk, defer the bigger decision.
Replace the legacy system one module at a time, with the new system and the old system running in parallel until each module is safely migrated. Low-risk, incremental, value every month.
Build the entire replacement separately, then cut over in one go. Theoretically fastest. Industry failure rate ~70%. We rarely recommend it — and if we do, we'll tell you exactly why this case is different.
The strangler-fig pattern, named after the rainforest tree that grows around a host until it stands on its own, is the safest way to replace a legacy system. Here's how we run it.
Big-bang rewrites fail because the replacement is built in the dark, against a moving target, with no production feedback. The strangler-fig pattern fixes all three problems: every module ships to production, you find the surprises early, and you can pause or pivot any time.
Crucially, the business keeps running — customers don't know a migration is happening. There's no "site down for upgrade" weekend, no "we'll get back to you next week" while we hand-fix data, no betting the entire roadmap on a single launch date.
Coined by Martin Fowler in 2004; battle-tested across thousands of migrations since.
An API gateway sits between users and the legacy system, so we can intercept and route requests as modules migrate.
Often a read-only report or a low-traffic admin screen. Validate the migration mechanics on something safe.
The new module reads from the same data store (or a synced replica). Both versions are live; the facade routes traffic.
Send 1% of traffic to the new module, compare outputs, fix discrepancies. Ramp to 100%. Decommission the old module.
The new service takes ownership of its data. The legacy system reads via the new service's API. Coupling is reversed.
Keep repeating module-by-module. When the last module migrates, the legacy system is decommissioned. The facade becomes the new app.
Every one of these migration pairs is something we've delivered on SA-based modernisation projects. We know the gotchas.
Modernisation projects fail when they break the business they're meant to save. These six commitments are how we make sure that doesn't happen.
Migration runs alongside the live legacy system. Customers don't see "site under maintenance" pages — every cutover is silent.
Every 2-week sprint ends with something live — a migrated module, a measurable speed-up, a removed risk. Never "the rewrite will be done in 9 months".
Each module migration includes a documented rollback plan. If something looks wrong in production, we route back to legacy in minutes.
Every migrated record gets a reconciliation report. We sample, diff, and verify. Nothing gets quietly lost or transformed without us catching it.
We pair-program, code-review, write ADRs, and run knowledge-share sessions throughout. The system is yours to run, not ours to lease.
Modernisation is the chance to bake in the compliance the legacy system never had: data-export, deletion, audit logs, encryption, retention.
The new system, the documentation, the runbooks, the team training. You own everything from day one — modernisation is a hand-off, not a hostage situation.
Every migrated module written in modern, idiomatic, tested code. MIT-licensed, in your repo. Boring mainstream tech your team or any agency can pick up.
Terraform-defined AWS Cape Town infrastructure with CI/CD pipelines, observability, backups, secrets management — POPIA-friendly by default.
A detailed playbook documenting every module migration: source/target schemas, reconciliation reports, cutover steps, rollback procedure, ADRs.
Unit + integration + characterisation tests of legacy behaviour, regression tests on migrated modules, CI gates that prevent breaking changes.
Sentry, Datadog (or Grafana), CloudWatch dashboards, SLO definitions, on-call alerts. You see problems before customers do.
Any defect we introduce, we fix free for 90 days post-final-migration. We pair-program with your team to ensure handover sticks.
Most modernisations run 3–9 months depending on scope. Every phase has explicit go/no-go gates — you can pause, pivot, or stop at any boundary.
Audit the legacy system, map the modules, document the data, interview the people who know it. Produce a system inventory + migration order.
Stand up the modern infrastructure (AWS, Terraform, CI/CD, observability) and the API facade that will route traffic between old and new.
Migrate the smallest, lowest-risk module end-to-end. Validate the strangler-fig mechanics on something safe. Establish the team rhythm.
Sprint by sprint, module by module. Each sprint ends with something live. Mid-engagement re-prioritisation based on what we've learned.
Modern services take primary ownership of their data. Legacy now reads via new APIs. Coupling is fully inverted.
Final module migrates. Legacy system shut down. 90-day warranty + on-call coverage starts. Knowledge transfer to your team completes.
Indicative figures across SA modernisation projects, measured 12 months post-final-cutover. The biggest gains are silent — incidents that never happened, features that shipped on time.
Every modernisation is scoped per system — these are the bands we usually land in. 25% on signature, 25% on phase-2 demo, 25% on first migration, 25% on final decommission.
Honest answers about cost, timelines, risk, and how to know if it's genuinely time to modernise.
Send us a description of your current stack, the modules, the team that maintains it, and the friction you're hitting. We'll come back with a 45-min audit call, a recommended approach, and an indicative budget.