Rewriting a custom application rarely starts with technology.
Of course, technical choices are needed. A new backend. A modern frontend. A different database. Better deployments. A development environment that is less fragile.
But before you get there, you first need to understand what the existing application means today.
Which processes depend on it? Which exceptions have become important over the years? Which logic lives in the code, in the database, or simply in the heads of a few people?
And above all: what must not be lost during the rebuild?
In this case, we are looking at a custom application that has been doing its job for years. The application has not suddenly become worthless. It mainly runs into limitations that are becoming more significant today: maintenance, security, web access, hosting, licences and the way new development is organised.
AI can help with that. Especially with analysis, documentation, test preparation and repetitive development work. The major choices remain with the team: architecture, data modelling, security, validation and maintainability.
First decide: improve or rebuild?
Not every legacy application needs to be rebuilt from scratch.
Sometimes the foundation is still good enough. The business logic is sound. The data model is understandable. The team can still make changes with confidence. In that case, targeted refactoring can solve a lot.
You keep what works and gradually address the parts that are becoming difficult. Maintenance. Performance. Security. Testability. For users, this is often the calmest approach.
There also comes a point where small changes no longer solve enough.
Changes take longer than expected. Releases feel risky. Building in security properly becomes difficult. Testing remains largely manual. The application is tied to local installations, old technology or people with a lot of historical knowledge. New integrations require more effort every time.
At that point, continuing to build on the same foundation becomes expensive and unpredictable.
A rewrite can then be wiser than continuing to patch things up. You can design again with today’s knowledge, without simply throwing away everything that worked well before.
A good rebuild therefore does not start with code. It starts with processes, users, data, risks and the choices the organisation needs to rely on in the years ahead.
In practice, it is often a mix. Sometimes you first solve a few urgent pain points. Sometimes you rebuild module by module. Sometimes a full rebuild makes sense, as long as migration and validation are properly prepared.
Why this is sensitive
Many custom applications have grown with the organisation over many years.
They support administration, planning, reporting, internal controls or other day-to-day processes. People know the screens. They also know the exceptions, and where they need to pay attention. Some bugs have even become part of the way of working.
That is why a rewrite rarely feels like a purely technical project.
You touch habits, processes and trust. The existing application may not work perfectly, but it is familiar. That matters. Especially when it is used every day by people who simply need to get their work done.
Modernisation only becomes truly relevant when that familiar foundation starts to limit the organisation too much.
Maintenance takes more and more effort. Remote use needs to improve. Security expectations are higher. Hosting or licences become too restrictive. Updates require too much caution. New functionality takes too long.
At that point, a rewrite is mainly about control. About software that becomes easier to maintain, safer and easier to manage again.
The chosen technical foundation
For this rebuild, we at dotNET lab, together with the client, chose a modern stack that is strong and remains manageable.
The choice consists of:
- ASP.NET for the backend
- Angular for the frontend
- PostgreSQL as the database
- Aspire to organise the different parts clearly
- OpenTelemetry for observability
- Docker containers for the application components
This is not a fixed recipe. The right stack always depends on the context: the processes, the team, the hosting choices, the security expectations and the maintenance afterwards.
ASP.NET provides a strong foundation for APIs, business logic, authentication, authorisation and integrations. For business-critical software, that matters. The backend needs to be reliable, easy to test and clearly structured.
Angular fits well for a web application with multiple screens, clear flows and reusable components. Especially when people work with the application every day, predictability matters. Users need to quickly understand where they are and what is happening.
PostgreSQL is a mature relational database. For many SME contexts, that is interesting because it offers a strong database without traditional licence costs. This helps keep the total long-term cost under better control.
Docker makes the application easier to move between environments. Development, testing and production can be set up more consistently. That reduces situations where something works locally but behaves differently on the server.
Aspire helps developers work locally with a realistic application context. Think of the web application, API, database, background processes and external services. That makes development more manageable.
OpenTelemetry gives more visibility into what happens inside the application. Logs, traces and metrics make it easier to investigate errors and understand incidents faster. With business-critical software, you do not want to guess. You want to see where something goes wrong, what impact it has and what is needed to fix it.
Why Docker and PostgreSQL also matter
from a business perspective
Technology choices can seem purely technical. In a rewrite, they also determine how much freedom an organisation will still have later on.
An application that runs in containers is less tied to one specific hosting environment. That creates more choice. The application can later run in a European cloud, a hybrid environment or another hosting model that better fits the organisation.
Full platform independence does not need to be a goal in itself. Conscious control over future choices does matter.
With business-critical software, you want to avoid today’s choices becoming unnecessary constraints later on.
PostgreSQL fits that reasoning too. It is open source, mature and widely supported. You avoid traditional database licence costs that can become significant over time. For SMEs, that is not a detail. Software costs money to build, but also to manage, host, license, maintain and adapt in the future.
A rewrite is therefore a good moment to reassess those costs and dependencies.
From local application to web application
Many older custom applications were built for a different way of working.
A local installation. Specific workstations. A fixed server. Limited access outside the office. Updates that are done manually or very carefully.
Today, organisations expect more flexibility.
A modern web application makes management easier. Users only need a browser. Updates are done centrally. Access can be controlled more effectively. Working from different locations or devices becomes easier, as long as security is set up properly.
This also makes a difference for IT.
An application with a clear backend, frontend, database and container structure is easier to manage than software that strongly depends on local installations or historic server settings.
That way, the application does not only become more pleasant for users. It also becomes easier for the organisation to manage.
Security from the start
Security should be part of the design from the start of a rewrite.
That includes authentication, access control, logging, audit trails, handling sensitive data, configuration per environment and predictable deployments.
A modern stack helps structure this better. ASP.NET provides strong building blocks for identity, authorisation and API security. Docker helps make environments more consistent. PostgreSQL offers a robust foundation for data processing. Aspire makes the local development environment more realistic.
Tooling does not solve this by itself.
The most important questions remain business questions. Who is allowed to see which data? Who is allowed to change something? Which actions need to be traceable? Which errors need to become visible quickly? Which data requires extra protection?
A rewrite is a good moment to include those questions right away.
AI as practical support
AI can speed up this kind of trajectory.
It can help understand existing code, recognise patterns, prepare documentation, work out user stories and set up test scenarios. During development, it can support repetitive work such as simple CRUD logic, component structures, API contracts or initial test proposals.
That saves time.
Responsibility remains with the team. Architecture, security, data modelling, validation with users and quality control still require human judgement.
The best role for AI is practical. It brings speed where that is safe, so developers and analysts can spend more attention on the choices that really matter.
What makes a rewrite successful?
A rewrite does not succeed because of the tech stack alone.
ASP.NET, Angular, PostgreSQL, Aspire, OpenTelemetry and Docker provide a strong foundation. AI can help teams work faster. The result mainly depends on the approach.
What matters most:
- a clear scope
- a good understanding of the existing way of working
- involvement from users
- strong architectural choices
- security from the start
- good data modelling
- realistic priorities
- a well-considered migration
- thorough validation of critical processes
That is also where technical guidance adds value.
An SME does not always have all the expertise in-house to fully carry this kind of trajectory alone. In that case, it helps to work with a partner who looks at technology and business context together. Someone who helps think through risks, choices, documentation, maintainability and adoption.
Finally
Rewriting a custom application is a big decision.
Sometimes maintenance is enough. Sometimes targeted modernisation is the better path. When the technical foundation starts slowing the organisation down, a well-prepared rewrite can be the most sensible step.
With ASP.NET, Angular, PostgreSQL, Aspire, OpenTelemetry and Docker, you get a modern foundation that better fits the way organisations work today.
AI can make the trajectory more manageable, especially by supporting analysis, documentation, testing and repetitive development work.
The core remains simple.
First understand what the application means for the organisation today. Then build in a way that is secure, maintainable and ready for the future.
