Kommune Aktiv - Development of a SaaS
There is software that doesn’t sound loud. No hip logos, no aggressive marketing, no overhead demos with music from the synthesizer. And yet: it runs, it works, it is appreciated. Especially when it does its job every day in a sensitive area such as public administration – and has been doing so for many years.
Our customer operates just such a software solution: economically successful, used by local authorities, with strong end-user loyalty. But even the most robust old-school software reaches its systemic limits at some point. Hosting only on-premise, .NET framework, no containerization, long release cycles – time for a fundamental upgrade. But how do you modernize without losing the proven core?
Initial situation
The existing application had developed organically over many years. It had grown, adapted to customer requirements and had a huge range of functions. The software had earned an excellent reputation, particularly in the municipal sector, where stability and reliability are key values.
In terms of technology, however, the platform was a classic child of the early 2010s:
.NET Framework
Monolithic structures
Local installations at the customer’s premises
Little to no automation in the deployment processes
In short, the software wasn’t bad – on the contrary. But it had become old. So old that certain technological decisions were simply no longer economically viable. The desire for a “greenfield site” was therefore not a reckoning with the status quo, but an attempt to rethink the tried and tested in a future-proof way.
The goal:
A modern, containerized architecture that can be operated in the cloud in the long term, but retains the old business logic. Not a new start for the sake of a new start – but a controlled transition into the next decade.
Implementation
Phase 1: Rethinking the technological basis
Initially, the focus was on transforming the technological foundation:
Replacement of all relevant .NET Framework components with .NET (Core or currently .NET 6+)
Gradual conversion to modern libraries and interfaces
Identification of legacy code that had to be migrated – or, in exceptional cases, rewritten
Phase 2: Containerization & infrastructure
The next step was to dockerize the entire software landscape. The advantages were obvious:
Clear isolation of the components
Standardized deployment processes
Preparation for a Kubernetes deployment
At the same time, the infrastructure was completely rebuilt as code:
Use of Terraform to define and provision cloud and Kubernetes resources
Development of a production-capable K8s cluster including monitoring, ingress, service mesh, etc.
Implementation of central services such as secrets management, certificate management, observability and logging
Phase 3: Automation
Without automated processes, such a project would be almost impossible to manage. This is why a CI/CD pipeline was set up at an early stage:
Automated builds via Git
Container build and push via own registry
Automated deployments in development and test environments
Separation of configuration and code to support multiple clients and target systems
Phase 4: Maintain business logic
Dealing with the existing business logic was particularly challenging. It was large, complex – and in many cases undocumented. To avoid slipping into a costly and risky new development, an accompanying workshop process was set up:
Close cooperation with developers, technical experts and key users
Reconstruction of logic from existing code and distributed knowledge
Mapping of functional requirements in user stories and epics
Comparison with the new architecture model, particularly with regard to responsibilities between services
As a side effect, a formalized, cross-team documentation of the processes was created for the first time – a benefit that will have an impact beyond the project.
Phase 5: Organization and methodology
A project like this not only changes the code, but also the teams. The changeover was used to introduce Scrum and an agile Kanban board. Instead of rigid planning, iterative cycles were established, including regular reviews and retrospectives. Acceptance was surprisingly high – many colleagues welcomed the new transparency and predictability.
Result
After a year of work, there is still no final product – and that’s perfectly fine. The sheer size and complexity of the application cannot be recreated in just a few months. But the progress is clearly visible:
The entire infrastructure was modernized and migrated to Terraform & Kubernetes
All relevant services are containerized and deployable
The first sections of the application are already functional and can be tested
A central authorization service was introduced as middleware that will control all applications across the board in future
Development is noticeably faster and more reliable thanks to the new CI/CD pipeline
The introduction of an agile working mode with Scrum elements was very well received and has structured collaboration
What is still missing is the complete renovation of the application itself – but the foundations are in place. And anyone who has ever renovated an old house knows that once the foundations are in place, the rest is just hard work.
Conclusion
Success in software development is not only measured by how quickly you can build something new. Sometimes it is a greater success to know the existing so well that you can transform it in a meaningful way. The journey from an established on-premise solution to a modern cloud platform is long – but worthwhile.
And while the old monolith is slowly but surely being transformed into its modular future, not only is a new architecture emerging – but also a new way of thinking, developing and operating software together.