Sooner or later, almost every organisation hits the same wall: a system that was once built well, that has worked valuably for years, but is now a brake on speed, hiring options, or strategic flexibility. The temptation to start over from scratch is strong — and in most cases unwise.
My work in legacy modernisation is about something else: treating the existing system not as a problem but as a starting point. Which parts are still healthy? Which parts can we replace incrementally? Where are the real bottlenecks, and where does something feel old when it's actually working fine?
Concretely, on the estate portal I let AngularJS run productively next to Angular 16 through a micro-frontend approach, and at the same time replaced the entire back-end with Kotlin on Vert.x, Keycloak, and MariaDB — in phases, with dual writes and shadow reads, without the portal going offline for a single moment. On the cultural-education portal I took over a Silverstripe system and strategically extended it rather than replacing it. On the 3D configurator I refactored large parts of a grown codebase without halting forward development.
Innovation, to me, explicitly belongs in this story. A healthy modernisation isn't just a translation from old to new but also a moment to deliberately bring in new possibilities where they create real value: BLE integrations for thrombosis care, WebRTC for the teacher platform, a low-code step engine for the COVID portal, a real-time event-driven backend for a production-file system. Each time a choice made on what the problem demands, not on what is new.
The approach I use in this kind of work is consistent: keep delivering during the renovation, small steps with good tests as a safety net, and very clear agreements about what does and does not change in this sprint. A refactor or migration is not a free pass to change everything at once — that discipline is exactly what makes the journey actually end.
Perhaps the most important lesson from this kind of work is that technology often isn't the hardest factor. Encountering implicit knowledge that exists only in the heads of a few people, managing the nerves of an organisation that depends on the old system, and explaining why "replace everything" is rarely the right choice — that's often where the real work lies.