Big-bang replacement is where these projects die
The plan looks clean on a slide. Build the new system for a year, pick a weekend, move everyone across, retire the old one. What happens instead is that the go-live weekend uncovers a dozen behaviours nobody documented, the team loses a week of work, and someone reopens the old system temporarily for one department. Replacing a legacy system without stopping the business means never having a single moment where everything depends on the new thing working perfectly. You get there by moving in slices small enough that any one of them can fail without taking orders, invoices or customers with it.
First, find out what the old system actually does
The documentation, if it exists, describes what the system was built to do fifteen years ago. The value is in what it does now. Sit with the people who use it daily and watch them work. You will find rules that live in nobody's specification: the discount that applies when a code starts with a certain letter, the report finance runs every Tuesday, the field somebody repurposed years ago to track something else. Miss these and your replacement is technically correct and operationally useless. This part is slow, and it decides whether the project succeeds.
Replace it one slice at a time
Put the new system alongside the old one and route a narrow piece of traffic to it. One report. One customer type. One department. Everything else keeps hitting the legacy system exactly as before. When that slice runs clean for a few weeks, take the next one. The old system shrinks until what is left is small enough to switch off without ceremony. This takes longer on paper than a single cutover and finishes sooner in practice, because you find the surprises while they are still cheap.
The data migration is the project
Teams budget the new features and treat the data as a task at the end. Then they discover the same customer stored four times with three spellings, dates in two formats, mandatory fields that were never filled, and a decade of records referencing codes nobody can explain. Move a copy of the data early, run it through the new system, and look at what breaks. Do it again every few weeks. The last migration before go-live should be the twentieth one you have run, not the first.
Run both systems while you can afford to
For a period, the old and new systems both hold live data. That is uncomfortable and it is safer than the alternative. Decide clearly which one is authoritative for each piece of information, and make it a one-way sync rather than two systems both writing to the same records. Set a date for switching off the old one and hold it, because a parallel period without an end date becomes permanent, and then you are paying to maintain two systems and reconciling them by hand forever.
The people are harder than the software
Your team learned the legacy system over years and has built shortcuts around every part of it. A new system, even a better one, makes everyone slower for a few weeks, and that is where resistance appears. Bring the heaviest users in early, let them shape the parts they touch daily, and give them something they actually wanted rather than only what management wanted. Train on their real work rather than on a demo dataset. A department that helped design its slice defends it. A department that had one dropped on it finds reasons to keep using the old one.
Be clear about what you are not replacing
Not everything old is worth rebuilding. Some legacy systems do one job reliably and cost little to keep. The case for replacement is strong when the system blocks something the business needs to do, when nobody left can safely change it, when it cannot connect to anything else, or when it holds data you cannot get at. The case is weak when the real complaint is that it looks dated. Write down which of these applies before you start, because it also tells you what the replacement has to prove.
How to start without committing to everything
Pick the smallest slice with real value and ship it. A single report the business fights over, one workflow that costs hours a week, one integration that currently runs on a person copying between two screens. You get a working piece of the new system in production, a team that has been through the process once, and evidence about what the rest will take. That evidence is worth more than any estimate produced before a line of code exists.
Written by
Idennex
Strategy-first agency, Istanbul