Rebuilding a custom application after 20 years: when does legacy modernization make sense?

Twenty years ago, I was the architect of a custom application for a customer.

Today, that application is still running.

That says something about the solution that was built then, but especially about the way it found a fixed place in the organization. Software rarely stays relevant for that long if it does not play a real role in daily operations.

What I find at least as important: the relationship with that customer is still strong today.

With custom software, you build more than functionality. You touch processes, habits, responsibilities and decisions. If the relationship is still healthy twenty years later, there is room to look at the future together again.

Twenty years of collaboration helps. You know the history of the application, you understand better why certain choices were made, and you can speak more openly about what must keep working and what can improve.

Today, we are looking at rebuilding that application together.

The existing application still works well. It still supports the process it was originally built for. Without new technological possibilities, it could probably have continued running for quite some time.

Still, this is a good moment to look at the foundations again.

Why rebuild a working custom application?

Rebuilding a custom application is not a small decision for an SME, especially when the current application still does what it needs to do.

Users know the application. Processes are aligned with it. The organization has learned how to work with it. That is why a rebuild can initially feel like reinvesting in something that already exists.

That explains why these projects used to be difficult to justify. Technically, a rebuild could make sense, but financially the threshold remained high as long as the existing software kept doing its job.

AI-supported development does not magically change that reality, but it does lower part of the practical threshold. Certain steps can now be handled more efficiently: understanding existing logic, preparing documentation, working out test scenarios and building repetitive parts.

The investment remains serious, but the balance between effort and value changes.

AI does not take over the thinking. For business-critical software, understanding the process, architecture, security, data migration and validation with users remain essential.

If part of the project can become more efficient, a rebuild comes within reach for an SME sooner.

That makes this case interesting. The existing application does not first have to become a problem before it makes sense to look at the foundations again.

Legacy modernization starts with respect for what works

The word legacy often sounds as if something is wrong. That is certainly not always fair.

An application that lasts twenty years has usually proven that it had value. It fitted the way the organization worked. It supported important processes. It became part of the way people work, and that deserves care.

With legacy modernization, you replace more than code. You also touch habits, exceptions, controls and knowledge that have grown into the system over the years.

Anyone rebuilding a custom application must first understand which business logic must remain. Which steps are critical? Which exceptions happen often? Which reports or controls matter more than they seem at first glance?

A rebuild only makes sense if you bring that context with you.

From existing application to modern web application

The new application will be a web application. That may sound obvious today, but it is about more than convenience.

A modern web application makes management simpler. Users can work more centrally. Access can be controlled better. Updates can be rolled out in a more structured way. Integrations become easier. Monitoring and logging can be included from the start.

Because the application is web-based, users only need a browser. That makes it work across different devices and operating systems.

Secure remote work is also better supported. That is much more normal today than it was twenty years ago, but it requires a different technical foundation.

Security belongs in the foundation of business-critical software

Security has a different place today than it did twenty years ago.

Strong authentication, two-factor authentication, correct permission management and clear logging are no longer extras. They belong in the foundation of a business-critical application.

Twenty years ago, the focus was mainly on functionality. The process had to be supported digitally and work reliably. That remains important, but the environment around it has become more complex.

Applications connect to other systems more often. Data is more sensitive. Users work in different ways. Expectations around availability and security are higher. When rebuilding, we therefore start again from today's reality.

We look at how people use the application, which processes have changed and which choices are needed to keep the application secure, maintainable and reliable in the coming years. From there, we build further.

Conscious technology choices: Docker, .NET and PostgreSQL

For this rebuild, dotNET lab chooses Docker containers, .NET and PostgreSQL.

That combination gives us control over how the application is built, managed and hosted. Containers make the application less dependent on one specific hosting environment. The setup can also run on infrastructure outside the large cloud platforms, or in an environment the customer chooses.

That makes the architecture more independent from big tech. We believe choice, portability and predictable costs matter when rebuilding a business-critical application.

We are also moving away from a solution where database licences were a structural cost. PostgreSQL is a mature open-source database system without classic database licence costs. That makes it interesting in projects where long-term cost, portability and control matter.

For an SME, those choices count. They determine where you can host later, how manageable costs remain and how easy maintenance will be.

That is why we prefer technology choices to be conscious rather than accidental.

AI-supported development makes rebuilding more feasible

AI has a clear role in this project, but not as a replacement for software engineering.

We use AI to handle certain steps faster and more efficiently. Think of analysing existing logic, documentation, test scenarios and repetitive development parts.

That can make the total effort of a rebuild easier to manage.

For SMEs, that matters. A software modernization that used to be hard to justify can now become financially feasible sooner.

Responsibility remains with people. Especially in business-critical software.

Someone must understand what the application does. Someone must decide which processes remain. Someone must judge which architecture is defensible. Someone must validate whether the new solution fits the reality of the users.

AI helps accelerate.

Craftsmanship determines whether the result is reliable enough.

In closing

For me, the value of this project lies in the combination.

An application that has done its job for twenty years. A customer relationship that has remained strong. And a moment where rebuilding becomes practically and financially sensible.

The new version must do more than offer the same functionality again. It must support safer remote use, be easier to maintain, give more control over hosting and cost, and create room for new functionality faster when the organization asks for it.

That creates a healthy modernization project.

We start from what has worked for twenty years.

And we build further in a way that better fits how organizations work today.