Services
Modernize existing systems
Most established systems are not too old to keep. They are too old to change safely.
- 9 in 9 days
- backend services moved to Spring Boot 3 at gematik
Upgrades like this often hold up feature work for months. Here it took nine days, and registrations and accreditations kept running.
Why upgrades stall
A framework version falls out of support, then the next one. Each skipped upgrade makes the next one larger, until the gap is so wide that nobody wants to touch it. New features slow down, security updates stop, and replacing the whole system starts to look like the only way out. It rarely is. Legacy modernization works in small, tested steps instead, while the system stays in use. Legacy modernization works in small, tested steps instead, while the system stays in use. Legacy modernization works in small, tested steps instead, while the system stays in use. Legacy modernization works in small, tested steps instead, while the system stays in use.
How we modernize
- Tests first: automated tests record what the system does today before anything is changed.
- Small steps: each upgrade step is released on its own, while the system stays in use.
- Runtime and frameworks: Java, Spring Boot and Angular, version by version.
- Process engine: from Camunda 7 to CIB seven, without rewriting the process models.
The numbers
At gematik, nine backend services moved to Java 17 and Spring Boot 3 within nine days. The frontends went through eight major Angular versions, from 11 to 19, in joint work with gematik’s teams, and the process engine moved from Camunda 7 to CIB seven. Production business processes kept running throughout.
At Gesundheit in Bewegung, the platform now runs on Java 25, Spring Boot 4 and CIB seven, and the frontend moved from Angular 14 to 21.
What stays
Your processes, your data and the way your people work. What changes is the technology underneath, and the cost and risk of the next change.
OUR APPROACH
Our engineering approach
Understand
Clarify requirements and context.
Engineer
Design a solution that fits the problem.
Verify
Consider integration, operations and quality.
Common questions
- Do we have to stop feature work during an upgrade?
- No. We upgrade in small steps that are each released on their own, so feature work continues alongside and every step can be checked in production before the next one starts.
- How do you avoid breaking what works today?
- Tests come first. Before anything changes, automated tests pin down what the system does today. The upgrade has to keep them green.
- Camunda 7 is end of life. What are the options?
- The Community Edition of Camunda 7 reached end of life in October 2025 with its final release, 7.24, and receives no further security updates. Enterprise customers are supported until April 2030. After that there are two ways forward. Camunda 8 runs on a different architecture, so the Java integration code has to be migrated. Open-source continuations such as CIB seven keep the Camunda 7 programming model. Both long-running platforms we work on moved to CIB seven without rewriting their process models.
A system that has to keep running while it changes?
30 minutes with Benjamin Huskić, founder and engineer. Tell us about the problems, pressures, or risks that matter most right now. We'll provide an initial assessment, share relevant insights from how we've addressed similar challenges, and explore how our experience could help you move forward.