{"id":18263,"date":"2026-06-09T11:00:35","date_gmt":"2026-06-09T09:00:35","guid":{"rendered":"https:\/\/www.centigrade.de\/blog\/software-modernisierung-mit-ki-schrittweise-meistern-teil-2\/"},"modified":"2026-06-09T11:15:50","modified_gmt":"2026-06-09T09:15:50","slug":"software-modernisierung-mit-ki-schrittweise-meistern-teil-2","status":"publish","type":"blog","link":"https:\/\/www.centigrade.de\/en\/blog\/software-modernisierung-mit-ki-schrittweise-meistern-teil-2\/","title":{"rendered":"Mastering Software Modernization with AI \u2014 Part 2"},"content":{"rendered":"
\n

When legacy <\/span>software becomes barely <\/span>maintainable, the desire for a radical <\/span>fresh start quickly emerges: <\/span>tear it all down, build it <\/span>all new, do it right <\/span>this time. In the first <\/span>part of this series, <\/span>Thomas Immich outlined <\/span>the vision of an AI <\/span>agent that transforms <\/span>outdated legacy systems into <\/span>modern, well-maintainable <\/span>applications with a compelling <\/span>user experience. The key point: even <\/span>problematic legacy systems contain <\/span>something valuable. They already encode <\/span>implemented requirements. How to <\/span>systematically recover those <\/span>requirements from existing systems and <\/span>derive an AI-supported, user-centered <\/span>modernization process from them is what <\/span>I’ll show in this second part.<\/span><\/p>\n

 <\/p>\n<\/div>\n

<\/p>\n

\n

When Modernization Is the Right Path<\/span><\/h3>\n<\/div>\n
\n
\n

When adding features and fixing bugs <\/span>in your own software starts to feel <\/span>like a game of Jenga, when sprint <\/span>planning keeps turning up the <\/span>proverbial bomb and even minor changes <\/span>trigger multi-sprint chain <\/span>reactions, it’s clear: the system is <\/span>under pressure. The obvious <\/span>question then isn’t just how to <\/span>stabilize it, but also whether it’s <\/span>worth investing in at all. <\/span>Wouldn’t a complete rebuild be <\/span>more consistent?<\/span><\/p>\n<\/div>\n

\n

The answer <\/span>is unspectacular but <\/span>important: it depends.<\/span><\/p>\n<\/div>\n

\n

With a small <\/span>user base, the risks of a <\/span>radical cut may be manageable. But <\/span>with a large user base, the <\/span>risks increase <\/span>significantly. Even small changes are <\/span>noticed, especially by power users, <\/span>because they affect established <\/span>routines, shortcuts, and mental <\/span>models. Failing to involve these <\/span>people sufficiently risks <\/span>acceptance problems precisely <\/span>where the system is used most <\/span>intensively in daily work.<\/span><\/p>\n<\/div>\n

\n

There’s <\/span>another factor: software <\/span>development is expensive. <\/span>Modernization offers the opportunity <\/span>to consciously manage risks <\/span>and costs, because not <\/span>everything has to be replaced at <\/span>once. Instead, functional <\/span>areas can be prioritized, <\/span>validated, and renewed step by <\/span>step.<\/span><\/p>\n<\/div>\n

\n

This allows users to <\/span>be brought along early. At the <\/span>same time, it reduces the risk of <\/span>developing a new system over a <\/span>long period that ends up looking <\/span>modern but misses real usage <\/span>requirements.<\/span><\/p>\n<\/div>\n

\n

The strongest <\/span>argument for modernization, however, <\/span>lies in the long-term reduction <\/span>of costs for further development <\/span>and maintenance. Positive <\/span>effects for marketing and sales <\/span>through a visibly modern <\/span>application are an added benefit, but <\/span>they shouldn’t be the <\/span>sole driver.<\/span><\/p>\n<\/div>\n<\/div>\n

\"\"<\/p>\n

Figure 1 \u2014 Good UI design contributes significantly to UX, as illustrated by Centigrade’s work for Tecan Introspect. (https:\/\/links.centigrade.de\/en\/references\/intuitive-data-visualisation-laboratory-software)<\/a>. But good UX depends on further factors beyond design.<\/em><\/p>\n

What matters most is working cleanly throughout the entire process, from requirements analysis to shipping modernized software components. Good requirements management helps define sensible packages and set the right focus. Prototyping and usability testing help ensure you’re not just building something new, but building the right thing. And a design specification that is “AI-ready” ensures that current AI tools can support efficiently without sacrificing quality or traceability.<\/p>\n

That alone, however, doesn’t guarantee the application won’t become another hard-to-maintain Frankenstein system. Especially with tools like Mistral, Claude, Copilot, Codex and the like, features are generated quickly, pull requests are opened fast, and the next development step is kicked off in no time. Using that speed advantage without clear architectural and quality guardrails means potentially working directly toward the next modernization.<\/p>\n

Modern language models should therefore not be understood as a shortcut around the process, but as an accelerator within a good process. Deliberate architecture and technology decisions are central to this. A modern tech stack that is actively maintained and allows interchangeable components is a foundation for maintainability. Suitable frameworks, libraries, and standards such as Angular Material, React, Vue.js, or Three.js can support rapid feature development without diluting the architecture. Visual customizations become easier through Tailwind CSS<\/a> or Framer Motion<\/a>. And future AI-powered concepts for onboarding, help, or dedicated workflows with AI agents and MCPs can be integrated more quickly when the architecture is prepared for them.<\/p>\n

Modernization remains complex. But with a structured, incremental approach, that complexity becomes manageable: user-centered, technically sound, and with a clear view of the risks.<\/p>\n

How to Extract Requirements from Legacy Systems<\/h3>\n

When structuring the modernization of a legacy system, the focus, as with any new development, should be on user requirements. They reveal which areas of the software are genuinely important from a usage perspective. This perspective should largely determine where functions are added, improved, or deliberately left unchanged. Because the value of software doesn’t come from the quantity of its features, but from how well it supports real tasks. That’s precisely why this perspective is also decisive for the ROI of UX based on professional human-centered work.<\/a><\/p>\n

Of course, understanding where the greatest technical debt lies is also relevant. But technical debt alone doesn’t answer the prioritization question. Why refactor an area used once a month when another area is slowing down daily work or generating errors?<\/p>\n

What we’re looking for, at minimum, is the 80-percent case: the areas where daily work actually happens. That’s where modernization has the greatest impact on users, productivity, and acceptance. This knowledge makes prioritization decisions more robust and helps place investments where they’ll have real effect.<\/p>\n

How do we find out which parts of the software are used how often? Through usage data analysis. It shows which functions are most relevant, where problems occur, and where changes are particularly sensitive. In practice, we use established tools like Kibana, Matomo, or Google Analytics so that modernization decisions are based not just on gut feeling, but on solid data.<\/p>\n

At the same time, a picture emerges that is also central to revising and redesigning UI concepts: which users use which functions, in what context, and toward what goal? This combination of behavior, context, and goal forms the foundation for good UI design.<\/p>\n

Why Vibe Coding Alone Isn’t Enough<\/h3>\n

Once the relevant usage data is available, the next step can seem deceptively simple: clean up the context, feed AI tools with requirements and architecture notes, and generate an implementation plan as quickly as possible. With good context engineering, surprisingly plausible-sounding proposals can indeed emerge very quickly.<\/p>\n

But this is exactly where the critical boundary lies. The risk-minimizing effects of modernization only reliably materialize when “forward engineering” is carried out cleanly after “reverse engineering” the requirements. Users must be deliberately involved, and UX must not merely function as a surface-level promise. It must genuinely be embedded in the requirements, the concept, the interaction, and the implementation.<\/p>\n

A clean forward engineering process also creates the ability to respond to market shifts, technological developments, and changing user expectations. These insights can then deliberately flow into the modernized components. Technology and architecture decisions should be based on validated design, which in turn should emerge from validated requirements.<\/p>\n

Only when human intervention, expert judgment, and quality assurance are embedded in this process can AI meaningfully accelerate the overall workflow.<\/p>\n

\"\"<\/p>\n

Figure 2 \u2014 User-centered software modernization<\/em><\/p>\n

 <\/p>\n

Where AI Supports the UX and Software Development Process<\/h3>\n

Current language models (as of April 2026) are already highly capable and developing rapidly. They become especially effective not in isolation, but in combination with automation, for example with n8n<\/a>. This combination offers several advantages over using individual AI tools alone:<\/p>\n