There's one kind of project that's scarier than any other: replacing the system the company operates on every day. It isn't starting fresh on empty ground — it's changing an engine on a moving car.
It's also one of the projects where the most money gets lost when it's approached badly.
First: old doesn't mean bad
Before planning a migration, check whether you need one. A ten-year-old system that works, is stable and can still be evolved is not a problem. Replacing it for the sake of modernity is one of the most expensive ways to gain nothing.
A legacy system is a problem when one of these holds:
- Every change costs disproportionately. Modifying something simple takes weeks and nobody can quite explain why.
- Nobody dares touch it. It works, but changes are kept minimal out of fear.
- The technology no longer receives security patches. This one is urgent, especially if it handles customer data.
- It can't integrate with anything. No API, and every connection to another system is manual.
- It depends on one person. If they leave, the company is exposed.
- The infrastructure is unsustainable. A physical server under a desk, with backups nobody has tested restoring.
If you checked none of these, leave it alone.
Start by finding out what you have
In most of these cases there's no documentation and the original author is gone. Nobody in the company can explain in detail what the system does.
You can't plan a migration on that. The first step is an audit that reconstructs the map: what modules exist, what each does, what data it handles, what it depends on, where the security risks are and how bad the technical debt is.
From USD 1,500 and a few weeks of work. It looks like an avoidable preliminary expense and it's precisely the opposite: without that map, any migration quote is a made-up number, and you'll pay the difference later.
The three strategies
Full rewrite ("big bang")
The new system gets built complete in parallel and one day you switch.
When it makes sense: small systems, or when the old one is so broken it isn't worth understanding.
The risk: this is the strategy that sinks the most projects. While it runs — and it always runs longer than planned — the company operates on a system nobody is maintaining, because all effort is on the new one. If the rewrite slips, and it slips, you now have two problems.
Module-by-module migration ("strangling")
One part gets replaced at a time. New and old coexist with synchronized data, and the old one gradually loses functions until it's switched off.
When it makes sense: most cases. Slower on paper and considerably safer.
The real advantage: each migrated module is already delivering value while the rest is in progress. If the project stalls for budget or any other reason, what's done stays working.
The cost: during transition you maintain both systems talking to each other, and that's work that doesn't show but does get paid.
Wrap and extend
The old system isn't touched. An API gets built on top of it and new functionality is built outside, against that API.
When it makes sense: when the core works well but is isolated, and what you need is to integrate it or put a modern interface on it.
The advantage: cheapest and fastest option, and sometimes it solves the whole problem without migrating anything.
Worth evaluating seriously before deciding on a migration: more often than you'd expect, what's bothering you isn't the system but the fact that it's locked in.
How to do it without stopping operations
One part at a time. Pick the module with the most pain and fewest dependencies. Replace it, ship it, stabilize it. Only then the next.
Synchronization during transition. While both coexist, data has to stay consistent across them. Technically the most delicate part, and it must be quoted.
Parallel operation before each cut. Same as any migration: for a few weeks both get used and results compared. Old gets switched off when numbers match, not when the calendar says so.
A rollback plan for every phase. If something goes wrong there must be a defined way back to the previous state. If there isn't one, you're not ready to cut.
Data is half the project
In old systems, data accumulates decades of odd decisions: fields used for two different things depending on the era, codes that meant something different before a certain year, records migrated from an even earlier system that already arrived broken.
None of it is documented and it's only discovered by looking.
Budget cleanup and validation as their own task. And ask that someone look at a real sample of the data before closing the migration price: it's the half hour that saves the most money in the whole project.
What to negotiate up front
If the old system was built by another vendor and the relationship isn't ideal, settle this before starting:
- Access to the source code and repository with history.
- Administrator access to servers, database and services.
- A complete data export, in a readable format.
- Documentation, if it exists.
Get all of that before announcing you're migrating. After the announcement, cooperation tends to slow down.
What it costs
No single number, but an order of magnitude:
| Stage | From |
|---|---|
| Audit of the current system | USD 1,500 |
| Wrap with an API and extend | USD 2,000 |
| Migrating one module | USD 4,000 |
| New complete management system | USD 15,000 |
The audit is what turns the rest into reliable numbers. Without it you'll get enormous ranges — rightly so, since nobody can price what they can't see.
A note on the team
There's a dimension that gets underestimated: the people working with the old system have mastered it. They know its quirks, its shortcuts, how to work around its flaws. That knowledge represents years of value.
Treat them as obstacles and you'll lose information that exists nowhere else, and earn resistance that doesn't reverse later. Involve them from discovery and they'll tell you exactly what the new system has to do — including the fifty exceptions no document records.
If you have a system that's holding you back and don't know whether to migrate it, wrap it or leave it alone, that's exactly the question a technical audit answers. Tell us what you have and we'll look at it.
Frequently asked questions
Should I rewrite a legacy system from scratch?+
Almost never all at once. A full rewrite takes longer than planned and, while it runs, the company operates on a system nobody is maintaining anymore. What usually works is migrating module by module: pull one out, replace it, ship it to production, move to the next.
What if the system has no documentation and its author is gone?+
That's the most common case. You start with an audit that reconstructs what the system does, how it's built and where the risks are. From USD 1,500. Without that map, any migration quote is guesswork.
How do I migrate without stopping operations?+
By replacing one module at a time and keeping both systems coexisting during the transition, with data synchronized. The old part gets switched off only once the new one has proven it produces the same results.
How do I know if my system is really a problem or just old?+
Old isn't bad. It's a problem when every change costs disproportionately, when nobody dares touch it, when it runs on technology without security support, or when you can't integrate it with anything. If it works, it's stable and you can evolve it, leave it alone.
Want this working in your company?
At Deepyze we turn manual processes into systems that work on their own: AI automation, web and mobile apps, and custom software. Tell us your case and you will have a concrete proposal within 24 hours.
Sin compromiso · Respuesta en 24 hs · Equipo en tu mismo huso horario