Twenty years ago, I was the architect of a custom application for a client.
Today, that application is still running.
That says something about the solution that was built back then, but even more about the way it found a permanent place within the organization. Software rarely stays relevant for that long if it does not play a real role in day-to-day operations.
What I find at least as important: the relationship with that client is still strong today.
With custom software, you do not just build functionality. You touch processes, habits, responsibilities and decisions. When the collaboration is still strong 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 better understand why certain choices were made, and you can speak more openly about what needs to keep working and what can be improved.
Today, we are looking together at rebuilding that application.
The existing application still works well. It still supports the process it was originally built for. Without new technological possibilities, it probably could have kept running for quite some time.
Still, this is a good moment to look at the foundations again.
Why rebuild a custom application that still works?
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 built around it. The organization has learned how to work with it. That is why a rebuild can at first feel like investing again in something that already exists.
That explains why this type of project used to be difficult to justify. Technically, a rebuild could make sense, but financially the threshold remained high as long as the existing software continued to do its job.
AI-assisted 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 components.
The investment remains serious, but the balance between effort and added value changes.
AI does not take over the thinking. With business-critical software, process understanding, architecture, security, data migration and validation with users remain essential.
When part of the project can be handled more efficiently, rebuilding becomes more accessible for an SME.
That is what makes this case interesting. The existing application does not have to become a problem before it makes sense to look at its foundations again.
Legacy modernization starts with respect for what works
The word legacy often sounds as if something is wrong, which 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 needs to be handled carefully.
In legacy modernization, you are not just replacing 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 needs to be preserved. Which steps are critical? Which exceptions occur frequently? Which reports or controls are more important than they may seem at first glance?
A rebuild only makes sense if you take 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 easier. Users can work more centrally. Access can be controlled more effectively. 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 will be 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 does require a different technical foundation.
Security belongs at the core of business-critical software
Security has a different place today than it did twenty years ago.
Strong authentication, two-factor authentication, proper access rights and clear logging are no longer extras. They belong at the core of a business-critical application.
Twenty years ago, the focus was mainly on functionality. The process had to be digitally supported and work reliably. That remains important, but the environment around it has become more complex.
Applications are more often connected to other systems. Data is more sensitive. Users work in different ways. Expectations around availability and security are higher. That is why we start again from today’s reality when rebuilding.
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. That is where we build from.
Conscious technology choices: Docker, .NET and PostgreSQL
For this rebuild, we at dotNET lab are choosing 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. As a result, the setup can also run on infrastructure outside the major cloud platforms, or in an environment chosen by the client.
That makes the architecture more big-tech independent. We are convinced of this approach because we believe that freedom of choice, portability and predictable costs are important when rebuilding a business-critical application.
We are also moving away from a solution where database licenses formed a structural cost. PostgreSQL is a mature open-source database system without a traditional database license cost. That makes it interesting in projects where long-term costs, portability and control matter.
For an SME, those choices matter. They influence where you can host later, how manageable costs remain and how easily maintenance can be organized.
That is why we prefer to make technology choices consciously rather than accidentally.
AI-assisted development makes rebuilding more feasible
AI plays a clear role in this project, but not as a replacement for software engineering.
We use AI to approach certain steps faster and more efficiently. Think of analyzing existing logic, documentation, test scenarios and repetitive development components.
That can make the total effort of a rebuild more manageable.
For SMEs, that matters. A software modernization project that was previously difficult to justify can now become financially feasible sooner.
The responsibility still remains with people. Especially with business-critical software.
Someone needs to understand what the application does. Someone needs to determine which processes must be preserved. Someone needs to assess which architecture is defensible. Someone needs to validate whether the new solution matches the reality of the users.
AI helps accelerate.
Craftsmanship determines whether the result is reliable enough.
Final thoughts
For me, the value of this project lies in the combination.
An application that has done its job for twenty years. A client relationship that has remained strong. And a moment where rebuilding becomes practically and financially meaningful.
The new version needs to do more than offer the same functionality again. It needs to support secure remote work, be easier to maintain, provide more control over hosting and costs, and create room to add new features faster when the organization needs them.
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.
