Modernising a SaaS platform — from a decade-old application server to full DevOps
An automotive data platform for the US market ran on an application server more than a decade old and was built by hand. We moved it to a modern stack, built new interfaces for customers and staff, and a complete CI/CD process on our own Kubernetes cluster.
- environments — test, beta, canary, production
- 4
- automated tests in the modernised service
- 0 → 200+
- applications on our own cluster
- ~20
- admin panel for every internal tool
- 1
Starting point
The platform provides vehicle data through an API and a customer portal. Its core ran on an application server whose last release came out over a decade ago. Builds and deployments were manual: ad-hoc compilation, copying artefacts, restarting. Every change required someone who remembered how to do it — and nerve.
What we did
Modernising the core without stopping the business. We rewrote the service in Spring Boot, preserving every existing protocol (REST and SOAP) and the four authentication mechanisms customers relied on. Before switching the first customer, we built comparison tests: the same requests hit the old and new systems on a shared database, and the results — responses, billing, database state — were compared automatically. Traffic moved gradually through a canary release, with instant rollback.
New interfaces. A new customer portal (Next.js, GraphQL) with account management, payments, OAuth2 and MFA. A new admin panel that became the team's single workspace: customer support, a coupon system, reports, and later BPM process tasks.
Integrations. Several external data providers with failover, CRM and accounting connected through Apache Camel, business processes in a BPM engine.
Full DevOps. Every repository has a pipeline: build, tests, image, deployment. Four environments — test, beta, canary and production — run on a Kubernetes cluster we built and operate on our own hardware. Certificates, DNS and monitoring are automated.
Working with AI agents. AI agents are a standing part of our toolkit in this modernisation. In the main service the number of tests grew from zero to over two hundred, and technical documentation from nothing to several dozen documents, including migration plans and architecture decision records.
The result
- Shipping a change now takes minutes and one pipeline, not a day of work.
- New services reach production in days — for example the BPM process engine, four days after its first commit.
- The old and new systems ran side by side until the comparison tests confirmed parity. Customers did not have to change anything on their side.
Related reading
2026-10-10
AI does not ruin code. In an architect's hands it raises quality
The market consensus says language models flood repositories with lower-quality code. Our experience modernising a large platform is the opposite — on one condition.
2026-09-25
Moving a dozen-plus applications to our own k3s cluster — problems and payoffs
Our third bare-metal Kubernetes cluster — the first in production for a client. Running since November 2023, it serves about 20 applications across four environments. The architecture, seven problems that surprised us, and what we actually gained.
2026-10-18
Kubernetes is not just a new way to deploy. It changes your operational habits
Moving applications from servers into containers is the smaller part of the job. The bigger part is dropping old habits — host monitoring, logs in /var/log, the assumption that the application runs as a single instance, and knowing which machine it runs on.