Legacy system modernization: replace in parts or rewrite?

Monday, seven in the morning. The base's system is slow to open, the weekend boarding report came out with an empty time column, and the only person who understood that part of the code left the company last year. Operations has already started two side spreadsheets so work does not stop. In the meeting, someone says the right move is to throw it all away and build a new system. Someone else remembers that last time the new project took a year and never went live.

This article helps you make that decision with clear criteria. You will find what makes a system legacy, why a full rewrite tends to go wrong, a comparison of the two paths, a decision matrix to use in the meeting and a plan for modernizing in parts without stopping work. If your question comes earlier, between having your own system and buying one off the shelf, start with the article on custom software vs off-the-shelf.

What is a legacy system?

A legacy system is a system that still runs the operation but has become hard to change: every adjustment takes long, breaks something else or depends on one specific person. Age matters less than that. A five-year-old system with no tests, no documentation and unsupported versions already behaves like legacy.

The Microsoft Azure Architecture Center describes the picture this way: over time, the tools, hosting and architecture a system was built on become obsolete, and each new feature makes it more complex and harder to maintain. In the operations companies we work with, legacy usually shows up in three forms: a web system built by a vendor that no longer exists, a program installed on the office computers and a spreadsheet with macros that became a system without anyone deciding it should.

The clearest sign of legacy is how the team behaves. When operations starts keeping parallel controls in spreadsheets because the system cannot keep up, the problem has left IT and reached the field.

Why does rewriting from scratch usually go wrong?

Rewriting from scratch usually goes wrong because the old system holds years of rules and fixes that nobody documented, and the new project takes far longer than planned to reach what the old one already does. Meanwhile, operations stays stuck on the old system with no improvements.

Martin Fowler, a reference author on software architecture, wrote in his piece on the Strangler Fig pattern that the plan of building a new system that does exactly the same thing, only in better technology, failed most of the times he saw it tried. He gives three reasons: replacement takes a long time, users cannot wait for new features and it is hard to work out the details of existing behavior. Much of that behavior, he adds, is no longer wanted, and rebuilding it is waste.

Joel Spolsky, co-founder of Stack Overflow, called the full rewrite the single worst strategic mistake a software company can make. His argument applies to internal systems too: that ugly two-page function carries fixes for problems that only appeared after weeks of real use. Throwing the code away throws that knowledge away with it.

In the systems we maintain, we see the same pattern on a smaller scale. The rule for who can approve overtime, the rounding in a billing calculation, the reason a field is mandatory at the gatehouse: none of it is in a document. It is in the code, and it only surfaces when someone rebuilds the screen and a user complains that "it used to work".

What changes between modernizing in parts and rewriting?

Modernizing in parts replaces the system module by module, with operations using it the whole time. Rewriting builds an entire system in parallel and switches over at once. The table compares both paths on the points that matter most to the people running the operation.

The transition cost row deserves attention. Fowler acknowledges that the gradual approach needs a transitional architecture, which exists only so both systems can coexist and goes away at the end. It looks like waste, but in his view the lower risk and the earlier value outweigh that cost.

How do you decide between modernizing and rewriting?

The decision comes from a survey of what exists today and an honest conversation about which signs weigh most in your operation. The matrix below gathers the questions we ask when we take over a system another company built.

Use the matrix in a short meeting with someone from operations, someone from IT and whoever approves the budget. The first group comes before everything else: without access to the code and the database, neither option can be assessed properly, and getting that access is often the first task.

If most checks fall in the second group, the path is to modernize in parts. If they fall in the third, it is worth estimating a rewrite, preferably still in stages. When the checks are split, the most common outcome is to modernize the base and rebuild only the module that cannot be fixed.

The matrix organizes the conversation, and the technical assessment confirms the choice. In our support and modernization work, that assessment reads the code, checks the infrastructure and lists the risks by priority. With that list, the company decides what to fix first.

How do you modernize in parts without stopping operations?

Modernizing in parts means placing a cut point between the users and the old system and, from there, moving one module at a time to the new code until the old one can be shut down. Microsoft describes this path in the Strangler Fig pattern: a facade receives the requests and decides whether each one goes to the old system or the new one, and the new one takes on more functions at every stage.

In practice, the plan we follow has seven steps:

1. Secure access and backups. Code, database, server and domain are held in the company's name, and a backup is restored in a test environment to prove it works.
2. Put the system under observation. Error and uptime monitoring shows what actually breaks, before any change.
3. Update the base. Unsupported versions of the language, framework and database are upgraded first, in small, tested steps.
4. Pick the first module. Prefer one that hurts operations and has a clear boundary, such as scheduling, gatehouse or reports.
5. Rebuild the module next to the old one. The new module reads and writes the same data, or a separate synchronized database, while the team checks the results.
6. Switch the module with a way back. Users move to the new module, and the old one stays available for an agreed period.
7. Shut down the old part and move to the next. Remove old tables and screens only after the new module has been validated in real use.

When the new system needs to talk to parts of the old one that have not been replaced yet, a translation layer comes in. Microsoft calls it an anti-corruption layer: an adapter that translates data and calls between the two systems so the new code does not inherit the habits of the old model.

The offshore passenger transport case shows an example of this kind of evolution. The boarding scheduling system started out serving a single crew boat operator. Once the operation was established, we began redesigning it as a platform for several operators, with data isolated per operator, QR code tickets and an audit trail. The core concept of the system changed: it stopped being the user who registered and became the operator, the supplier and the trip.

What if nobody has the code, the documentation or the people who built the system?

Without code or documentation, modernization starts from the data and from real use: what is in the database, which screens the team uses and which reports come out of the system. It is slower, but it is the most common situation when the original vendor has left the picture.

Some situations change the plan:

1. The code exists, but nobody knows where. Look on the hosting server, in old contracts and with the former vendor. The code is often sitting on the production server itself.
2. Only the database exists. The database reveals the entities and a good part of the rules. Once it has been read and documented, the new system can be built module by module on the same data.
3. The system is a closed third-party program. Microsoft notes that the facade pattern does not work when there is no access to the code and no other integration point. In that case, the usual way out is to build around it, reading the data the program exports, and replace it one process at a time.
4. The system is a spreadsheet with macros. Treat each tab as a module. The formulas are the business rules and need to be written in plain language before any code.
5. The team resists the change. Start with the module they complain about most. When the first replacement fixes a real annoyance, resistance to the next ones drops.

A security review helps in these situations because it forces you to read the system route by route. In the port operations platform we maintain, we built a matrix of route, action and role and fixed actions the screen hid but the server accepted. That kind of reading also shows where the undocumented rules live.

When is rewriting the best way out?

Rewriting is the best way out when the system is small, when there is no usable code or data, or when operations has changed so much that the current system answers questions nobody asks anymore. In those cases, modernizing in parts spends effort preserving what will be thrown away.

Even then, a rewrite can be done in stages. Instead of building everything and switching over in one day, the new system goes live with one complete process, and the other processes migrate later. The port operations platform grew this way: it started with safety processes and gained modules as operations asked for them, all using the same records of people, companies and locations. Today its database has more than 160 tables, and the system has been in continuous development since 2019.

There is also what neither option solves on its own. If the process is confusing on paper, it will stay confusing in the new system. Fowler points out that without a change in how people work, the new system tends to end up in the same mess as the old one. So before discussing technology, write down the process as it should work.

If you want to see what a project like this looks like from start to finish, the article on custom software projects describes each stage and what the client decides in each one.

When is this not enough?

This article helps you choose a path, but it does not replace reading the code, the data and the infrastructure. Two companies with the same symptom can need opposite answers. Bring in someone from outside when your internal team has no time for the assessment, when nobody in the company knows the system's technology or when the system holds personal data and the switch has to comply with privacy law (in Brazil, the LGPD, the country's general data protection law, similar in scope to the GDPR).

boosting.tech is a custom software company that takes over existing systems, including ones built by other companies, and modernizes them in stages without stopping operations. We can look at your system in a diagnostic conversation, at no charge, through the contact page or by email at jcm@boosting.tech. The details are under support and modernization, and when the answer is to rebuild, the work continues as a custom web system project.