Modernizing without the big-bang rewrite

DTU's digital platform supported more than 100 subsites on a large, tightly coupled legacy codebase.

Modernization was necessary, but replacing the entire platform at once would have introduced significant technical and business risk. A change in one area could affect many existing sites, making a traditional rewrite both difficult to validate and expensive if something went wrong.

The goal was to move DTU toward a new design system and a more modern frontend architecture without disrupting the large ecosystem already running on the platform.

A big-bang rewrite would have meant rebuilding and validating a substantial amount of functionality before any of the modernization could safely reach production — and with more than 100 subsites depending on the same platform, the blast radius of getting it wrong was significant.

I introduced an approach where legacy and modern components could coexist: replacing parts of the platform progressively rather than committing to a high-risk cutover. This follows the same principle commonly associated with the Strangler Fig Pattern — incrementally replacing a legacy system rather than rewriting it all at once.

I introduced an incremental modernization strategy, allowing legacy and modern components to coexist while we migrated the platform piece by piece.

Rather than replacing existing components immediately, new versions were developed and validated alongside them. This allowed us to migrate component by component, validate each step in production and continue operating more than 100 existing subsites throughout the modernization — limiting the blast radius of any given change.

I also introduced a GitFlow-based development and release process to create clearer control around how changes moved through development and into production.

With more than 100 subsites depending on the same platform, release strategy was part of the architecture. Modernization needed to happen without making everyday development and releases unpredictable.

The approach gave DTU a practical path from a tightly coupled legacy platform toward a modern design system without committing to a high-risk rewrite.

Each step could be introduced, validated and adjusted before the next part of the platform was migrated.

Instead of treating modernization as a single project with a hard cutover, we turned it into an incremental technical strategy that could evolve alongside the existing platform.

For me, this project demonstrated an important principle of technical leadership: modernization isn't always about replacing old technology as quickly as possible. Sometimes the stronger architectural decision is creating a safe path from where a system is today to where it needs to be tomorrow.