Modernise your legacy system without downtime
Phased migration for systems that cannot stop. The question everyone asks first, answered properly.
You can modernise a legacy system without downtime by moving it in stages. The old and new systems run side by side, traffic moves across gradually, and every step can be reversed without an outage. AMT (Advanced Millennium Technologies) runs phased migrations on systems in constant use, choosing the right pattern for each component instead of one approach for everything. We are ISO 9001:2015 and ISO 27001:2022 certified.
Trusted by
// hard_to_replace
Why legacy systems are so hard to replace
It has run the business for a decade and it still does the job. The people who built it have moved on, and the documentation, if any, describes a version from three rewrites ago. Every proposal to change it stalls on the same question, what if it breaks, and nobody can answer it with confidence. So nothing happens, and the risk keeps growing.
Here is the thing. A big-bang replacement, where everything switches over in one go, is what most people picture. It is also the riskiest option available. Phased migration is slower and less exciting in a board paper, and far more likely to work.
// migration_patterns
Five migration patterns, and when each one is safe
These are the actual techniques. A real migration usually uses three or four of them in different places.
| Pattern | How it works | Safe when | Risky when |
|---|---|---|---|
| Strangler fig | The new system sits in front of the old one and takes over one function at a time, until the old system has nothing left to do. | Requests can be routed at a clear boundary, and functions split cleanly. | The old system shares data everywhere with no clean seams. |
| Parallel run | Both systems process the same input. Only the old system's output counts until the new one matches it for long enough. | Accuracy matters more than speed and outputs can be compared automatically. The standard choice for anything financial. | Processing has side effects that cannot happen twice, such as emailing a customer or taking a payment. |
| Read-only shadow | The new system reads live data and produces answers alongside the old one, but nobody uses them yet. | You need confidence on real data before anything depends on it. Very low risk and often the right first step. | You need to test writes, which this deliberately never does. |
| Branch by abstraction | A common interface is placed in front of the part being replaced, then the old and new versions are swapped behind it. | Replacing one component inside a system that otherwise stays. Reversible with a configuration change. | The two versions behave differently, not just look different in code. |
| Staged cutover with rollback window | A real switch at a chosen moment, with the old system kept running and a tested way back. | The component cannot run in parallel, and the rollback has been rehearsed. | The rollback has never been tested. Then it is a big bang with better paperwork. |
The question to ask any vendor
Ask which of these patterns they plan to use for each major component, and what the rollback is for each step. A partner who answers phased approach without naming a pattern has not thought it through yet.
Get the five migration patterns on one page
Each pattern, when it is safe, when it is not, and the question to ask a vendor about each. Built to survive a steering committee and an architecture review.
// understand_first
Step one: understand what the old system really does
Nobody can safely change a system they cannot see into. Before migrating anything, we establish three things.
- What the system actually does. Behaviour rebuilt from the code, the data and the people who use it every day.
- What correct looks like. Safety-net tests that record how the system behaves today, including the bugs other systems rely on. Engineers call these characterisation tests.
- What is actually used. Most old systems have features nobody has touched in years. Finding them is the cheapest way to cut scope, and it is often a third of the system.
// modernisation_paths
Typical modernisation paths
| From | To | Usual pattern |
|---|---|---|
| VB.NET or ASP.NET MVC on .NET Framework | Modern .NET services | Strangler fig, one module at a time |
| AngularJS front ends | Angular or React | Page by page behind the same URLs |
| Monolithic Java applications | Java and Spring Boot services | Branch by abstraction for shared components |
| On-premise servers | AWS with Docker and Kubernetes | Read-only shadow, then staged cutover |
| Manual, multi-system operations | One integrated platform with ERP sync | Region by region rollout, as in the case study below |
// modernisation_process
Our legacy modernisation process
| Step | What happens |
|---|---|
| 1. Assessment | What the system does, what is used, what it connects to, and what can be switched off for good. |
| 2. Safety-net tests | Tests that capture current behaviour, so every later change can be checked against it. |
| 3. Phasing plan | A pattern chosen for each component, with a rollback defined for every step. |
| 4. Step-by-step migration | One component at a time, in production, always reversible. |
| 5. Data migration | Usually the hardest part. Writing to both systems, backfilling history and reconciling until the numbers match. |
| 6. Decommissioning | Switching the old system off properly. The step most plans forget. |
// case_study
Case study: phased migration of a live global e-commerce and ERP platform
A global wellness and personal care B2B platform, shipping from warehouses in Germany, Singapore and New Zealand, needed to move its commerce and ERP operations onto a new multilingual platform without pausing trade. We migrated it in controlled phases over about six months, one module, warehouse and market at a time, and the business kept taking and fulfilling orders throughout. The new platform supports 200,000+ SKUs, with 28% faster order fulfilment and 34% higher customer retention.
// cost_and_timeline
Legacy migration cost and timeline
| Stage | Pricing model | What drives the effort |
|---|---|---|
| Assessment and phasing plan | Fixed price, 2 to 3 weeks | System size, how much documentation exists, and how many integrations must be traced. You own the plan. |
| Phased migration | Scoped after the assessment (high effort) | How well the old system is documented is the single biggest driver. Data migration and the number of phases follow from it. |
| Typical budget range | 20 to 35 USD per hour | Legacy specialists and migration architects at the higher end, steady-state development at the lower end. |
A phased migration takes longer in calendar time than a straight replacement, and far less time offline. That trade is the whole point.
// not_right_fit
When we are not the right fit
// faqs
FAQs: legacy system migration
Can you modernise a legacy system without downtime?
What is the strangler fig pattern?
What are the 7 Rs of application modernization?
How long does a legacy system migration take?
What if nobody understands the old system anymore?
What happens if a migration step goes wrong?
Can you migrate the data without losing anything?
Should we rewrite, replatform or refactor?
Ask us the question you actually have
Which is usually: can you do this without taking us down? 30 minutes with an architect who has run phased migrations on live systems, and a straight answer either way.
Not ready to talk? Read how we deliver. No form.