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 start, you first need to understand what the existing application means today.
Which processes depend on it? Which exceptions became 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 definitely not be lost in a rebuild?
In this case, the application is a custom system that has been doing its job for years. It has not suddenly become worthless. It mainly runs into limitations that now weigh more heavily: maintenance, security, web access, hosting, licences and the way new development is organized.
AI can help with that. Especially with analysis, documentation, test preparation and repetitive development work. The big choices stay with the team: architecture, data modelling, security, validation and maintainability.
First choose: improve or rebuild?
Not every legacy application needs to be rebuilt completely.
Sometimes the foundation is still good enough. The business logic is correct. 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 address the parts that are becoming difficult step by step: maintenance, performance, security, testability. For users, that is often the calmest approach.
But there also comes a point where small interventions solve too little.
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 on the same foundation becomes expensive and unpredictable.
A rewrite can then be more sensible than continuing to repair. You can redesign with today's knowledge, without simply throwing away everything that used to work well.
A good rebuild therefore does not start with code. It starts with processes, users, data, risks and choices the organization needs to rely on in the coming years.
In practice, the path is often mixed. Sometimes you first solve a few urgent pain points. Sometimes you rebuild module by module. Sometimes a full rebuild makes sense, provided migration and validation are well prepared.
Why this is sensitive
Many custom applications have grown with the organization for years.
They support administration, planning, reporting, internal controls or other daily processes. People know the screens. They also know the exceptions, and where to pay attention. Some bugs have become part of how work gets done.
That is why a rewrite rarely feels like a purely technical project.
You touch habits, processes and trust. The existing application may not be perfect, but it is familiar. That matters. Especially when it is used every day by people who need to get their work done.
Modernization only becomes truly relevant when that familiar foundation starts to limit the organization too much.
Maintenance takes 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 simpler to manage again.
The chosen technical foundation
For this rebuild, dotNET lab and the customer 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 organize the parts clearly
- OpenTelemetry for observability
- Docker containers for the application parts
That is not a fixed recipe. The right stack always depends on the context: processes, team, hosting choices, security expectations and maintenance afterwards.
ASP.NET provides a strong foundation for APIs, business logic, authentication, authorization and integrations. For business-critical software, that matters. The backend must be reliable, testable and clearly structured.
Angular fits well with a web application that has multiple screens, clear flows and reusable components. Especially when people work with the application every day, predictability counts. Users need to understand quickly where they are and what is happening.
PostgreSQL is a mature relational database. For many SME contexts, that is interesting because you get a strong database without classic licence costs. That 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 creates fewer situations where something works locally but behaves differently on the server.
Aspire helps developers work locally with a realistic application context: the web application, API, database, background processes and external services. That makes development clearer.
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 fails, what impact it has and what is needed to fix it.
Why Docker and PostgreSQL matter commercially too
Technology choices sometimes look purely technical. In a rewrite, they also determine how much freedom an organization will still have later.
An application in containers is less tied to a specific hosting environment. That creates more choice. Later, the application can run in a European cloud, a hybrid environment or another hosting model that better fits the organization.
Full platform independence does not have to be a goal in itself. Conscious control over future choices does matter.
For business-critical software, you want to avoid choices today becoming unnecessary constraints later.
PostgreSQL fits that reasoning too. It is open source, mature and broadly supported. You avoid classic database licence costs that can weigh heavily 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 manual or have to be done very carefully.
Today, organizations expect more flexibility.
A modern web application makes management simpler. Users only need a browser. Updates happen centrally. Access can be controlled better. Working from different locations or devices becomes easier, as long as security is set up properly.
That 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 historical server settings.
The application becomes more pleasant for users, and more manageable for the organization.
Security from the start
Security belongs in the design from the start of a rewrite.
That includes authentication, permissions, logging, audit trails, handling sensitive data, configuration per environment and predictable deployments.
A modern stack helps structure this better. ASP.NET offers strong building blocks for identity, authorization and API security. Docker helps make environments more consistent. PostgreSQL provides a robust foundation for data processing. Aspire makes the local development environment more realistic.
Tooling does not solve this automatically.
The most important questions remain substantive. Who may see which data? Who may change what? Which actions must be traceable? Which errors must become visible quickly? Which data needs extra protection?
A rewrite is a good moment to include those questions immediately.
AI as practical support
AI can accelerate a project like this.
It can help understand existing code, recognize patterns, prepare documentation, work out user stories and set up test scenarios. During development, it can support repetitive parts such as simple CRUD logic, component structures, API contracts or first test proposals.
That saves time.
Responsibility stays with the team. Architecture, security, data modelling, validation with users and quality control still require human judgement.
The best role for AI is practical: bring speed where it is safe, so developers and analysts have more attention for 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 speed up the work. The result mainly depends on the approach.
What matters most:
- a clear scope
- a good understanding of the existing operation
- user involvement
- strong architecture choices
- security from the start
- good data modelling
- realistic priorities
- a thoughtful 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 carry such a project completely. Then it helps to have a partner who looks at technology and business context together. Someone who helps think through risks, choices, documentation, maintainability and adoption.
In closing
Rewriting a custom application is a major choice.
Sometimes maintenance is enough. Sometimes targeted modernization is better. When the technical foundation starts slowing the organization 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 how organizations work today.
AI can make the project more feasible, especially by supporting analysis, documentation, tests and repetitive development work.
The core remains simple.
First understand what the application means for the organization today. Then build in a way that is secure, maintainable and ready for the future.