Legacy Modernization in the Energy Sector and Industry: Why a Clean Slate Is Almost Never the Right Answer

Legacy systems exist in every industry. But in energy supply, grid operations, and industrial manufacturing, a combination of factors makes modernization particularly challenging.

The first characteristic is criticality. Many of these systems are not only essential to operations but are also classified as critical under NIS2 and the KRITIS umbrella law. A grid control system that fails is not an IT glitch, but a supply problem. Downtime that would be tolerable in other industries is unacceptable here. This places strict demands on any migration strategy: it must ensure continuous operation, even while modernization is underway.

The second characteristic is long lifecycles. Industrial plants and energy infrastructure are designed to last for decades. Software is purchased as part of a plant or control system and then simply runs. While the surrounding requirements change, new regulations are introduced, new types of feed-in must be integrated, and new interfaces to market data systems emerge, the software remains static. This generates technical debt at a rate that eventually becomes unmanageable.

The third characteristic is the state of documentation. Systems that have been further developed over many years by different teams are rarely well documented. Knowledge resides in the minds of employees who have since retired. Configurations are hidden in undocumented parameters. Interdependencies between systems have evolved over time and are not fully documented anywhere. Before modernization can take place, it is often necessary to first understand what actually exists.

There is no single, universally correct answer to the question of how to modernize a legacy system. The choice of strategy depends on the system, its risk profile, the available resources, and the time frame. Three basic approaches are commonly used in practice.

Replatforming essentially preserves the functionality of the existing system but migrates it to a more modern technical platform. The use case is clear: The system works well from a business perspective, but the underlying infrastructure is no longer maintainable, the technology stack is no longer supported, or the deployment environment has become a security risk. A Java EE monolith running on an outdated application server is a typical candidate: The business logic has retained its value, but the underlying platform has not. Replatforming is faster than a complete new development, but it also carries the risks of legacy issues: If the existing architecture has structural weaknesses, these will be migrated along with it.

Incremental modernization is often the most realistic option for systems that must remain in operation. Instead of replacing everything at once, individual modules or components are modernized step by step while the rest of the system continues to run. The Strangler Fig pattern is the best-known approach for this: a new layer grows around the legacy system, gradually taking over functions and supplanting the old system until it is finally completely replaced, without ever having to go offline.

This approach requires a well-defined architectural strategy from the very beginning: clear interface definitions, a well-thought-out data migration strategy, and a team that is familiar with both the old and the new systems. The risk lies in the transition phase: Running two systems in parallel is resource-intensive and prone to errors if the coordination is not carefully planned.

A completely new development from scratch is the option that promises the most freedom—and carries the most risks. In practice, “big bang” migrations fail disproportionately often because the knowledge of the existing system is underestimated. Implicit business logic—which is not documented anywhere but has been executing correctly for years—only comes to light when the new system fails to reproduce it. In regulated environments with ongoing operational obligations, parallel operation over long periods is particularly costly.

Developing a new system makes sense when the existing system is functionally and technically outdated, when new regulatory requirements call for a fundamentally different architecture, and when it is possible to manage the transition in a controlled and phased manner. It is not a shortcut, but rather the most resource-intensive path, requiring the highest level of commitment and resources.

One of the most time-consuming aspects of any legacy modernization project is understanding the existing system. Code that has evolved over decades cannot be fully grasped in just a few weeks. AI-powered code analysis tools can now significantly speed up this process.

Specifically, AI tools help systematically analyze codebases and reveal implicit dependencies that do not appear in any documentation. They can extract business logic from old COBOL code, mature Java monoliths, or undocumented stored procedures and convert it into readable documentation. They can generate test suites for legacy systems that serve as a safety net before the actual migration begins. And they assist in creating a Software Bill of Materials, which is now mandatory under the CRA anyway.

At BAYOOTEC, a significant portion of the new code is generated with the help of AI, and we use AI-powered automation for pull request reviews and security scans. In modernization projects, we specifically use AI for the initial analysis and documentation of the existing system, which significantly shortens the discovery phase and improves the quality of the migration strategy. To ensure that AI remains compliant with regulations even in regulated environments, we have established an internal AI compliance officer with TÜV certification.

For a long time, legacy modernization was an issue that IT departments prioritized internally but that senior management kept putting off. That is changing now, because external regulatory pressure is forcing decisions that couldn’t be made internally.

NIS2 requires affected companies to implement verifiable risk management and ensure that their IT systems are auditable. A legacy system that lacks proper logging mechanisms, is not documented, and does not have controlled update processes structurally fails to meet these requirements. It hasn’t become a bad system; it was simply never built to meet these requirements. But to the legislature, that makes no difference.

The Cyber Resilience Act, which will take full effect in December 2027, requires all products with digital components to have a software bill of materials, active vulnerability management, and secure update mechanisms. For manufacturers of industrial software, this means that systems that do not meet these requirements may no longer be placed on the market in the EU as of that date. The situation is also becoming more challenging for operators, as they must demonstrate the compliance of their supply chain.

And specifically in the energy sector: Redispatch 3.0 will impose new requirements on communication and data processing between grid operators and feed-in providers—requirements that many existing systems are not technically designed to handle. Those who have already modernized their systems can integrate these requirements in a modular fashion. Those still running legacy systems face a project with tight deadlines.

BAYOOTEC has been modernizing legacy systems for over 20 years—not as a generic IT project, but with the industry expertise that makes all the difference in regulated environments. Some of our developers and architects bring academic and practical expertise from the energy sector: Knowing what “redispatch” means, how balancing groups work, and what NIS2 requirements for auditability entail is not a learning curve for us, but rather our starting point.

Our approach to legacy projects doesn’t start with the code, but with understanding. A structured discovery phase—which uses modern analysis tools and AI-powered code analysis to assess the system’s actual state—forms the foundation for any robust modernization strategy. Based on this, we work with our clients to determine whether replatforming, incremental modernization, or a phased rebuild is the right approach, and we plan the migration so that ongoing operations are never compromised.

We have successfully brought all the projects we’ve started into full-scale operation. In a field where projects disproportionately often end up late, over budget, or incomplete, this is no small feat. It is the result of an approach that consistently combines technical quality, industry expertise, and transparent project communication.

If you’d like to know which modernization strategy makes sense for your system, we’d be happy to start with a brief discovery phase to assess the current state, evaluate risks, and develop a concrete roadmap. Feel free to get in touch.