Legacy System Modernization: Best Practices for European Enterprises

Legacy system modernization is the structured upgrade, replacement or re-architecture of outdated software, infrastructure and integrations so they meet current business, security and compliance requirements. For European companies two things changed the calculation recently: the cybersecurity rules that touch legacy estates entered their enforcement phase, and the first solid evidence arrived that AI-assisted development pays out differently depending on how coupled your systems are.

This article covers what the current data actually says, which modernization strategy fits which system, and how to sequence the work so a critical system does not go down in the middle of it.

Key takeaways

• Paid cloud service adoption among EU enterprises reached 52.7% in 2025, while AI adoption reached 20.0%. Cloud is now normal infrastructure, AI is not yet, and the distance between those two numbers is where architectural constraints tend to show up.
• NIS2 has entered enforcement, though not the kind most people expect: in July 2026 the Commission referred four member states to the Court of Justice for failing to transpose the directive.
• Google Cloud's 2025 DORA research found that AI adoption improves delivery throughput while still showing a negative relationship with delivery stability, and that teams constrained by tightly coupled systems and slow processes see little or no benefit.
• A UK government review found around 28% of central government technology estates classified as legacy, with some organizations spending 70 to 85% of their technology budget on upkeep rather than modernization.
• Sequencing beats scope. Rationalize first, wrap the core in stable APIs second, refactor selectively third, and verify the decommission actually happened.

What is legacy system modernization, and why does it matter now?

Legacy system modernization is the process of improving outdated applications, databases, infrastructure and integrations so they become secure, maintainable and fit for current business needs. It matters because old systems slow down change, raise operational risk, weaken compliance evidence, and constrain what the newer layers of the stack can deliver on top of them.

A legacy system is not simply an old one. It becomes a business problem when it is hard to change, poorly documented, expensive to support, or dependent on skills that are scarce on the market. In European mid-market companies the recurring pattern is critical processes running on monolithic ERP extensions, dated .NET or Java applications, unsupported database versions, batch integrations and on-premise infrastructure whose dependency map exists only in the memory of people who may no longer work there.

The macro picture is worth stating precisely, because it is usually quoted loosely. Two different cloud indicators are in circulation and they are not interchangeable:

The two cloud numbers differ because they measure different things over different reference periods, not because one is wrong. Anyone quoting a single "EU cloud adoption" figure without saying which indicator they mean is quoting loosely.

The 2030 target deserves care too, because it is a composite: at least 75% of enterprises using at least one of cloud, big data or AI. The Commission's 2026 report does not publish a single combined percentage against that composite, so anyone claiming Europe is definitively on or off track for this specific target is estimating. What the report does say is that AI adoption grew 48% year on year in 2025, and that significant gaps remain in advanced digital take-up, with SMEs facing the largest barriers.

For a CTO or VP of Engineering, modernization decomposes into four activities:

• Discovery: cataloging applications, dependencies, data flows, users and infrastructure.
• Assessment: classifying systems by business criticality, technical risk, security exposure and change frequency.
• Target design: defining the future architecture, the release model and the migration sequence.
• Execution: migration, refactoring, integration, testing, decommissioning and monitoring.

A useful early artifact is a heatmap plotting business value against technical health. It gives the board one page on which risk, cost and customer impact intersect, and it makes the case for working on something other than whichever system is complaining loudest.

What has actually changed on the regulatory side?

The obligations moved from drafting into enforcement, but the shape of that enforcement is worth understanding precisely, because it is widely misdescribed.

NIS2. The transposition deadline was 17 October 2024. On 8 July 2026 the European Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice for failing to notify transposition measures, following letters of formal notice in November 2024 and reasoned opinions to 19 member states in May 2025. Note what this is: enforcement against member states for not transposing, not enforcement against companies. The practical consequence is that obligations attach on national implementation, so the compliance calendar a company faces depends on where it operates, and in several large markets that calendar is still being set. NIS2 also places the duty at the top: Article 20 requires the management bodies of essential and important entities to approve cybersecurity risk-management measures and oversee their implementation.

Italy. NIS2 is implemented by Decreto Legislativo 138/2024, in force since 16 October 2024, with ACN determinations setting the operational steps: incident-notification obligations from 15 January 2026, base security measures to be operational by 31 October 2026, and an annual registration renewal window in the first two months of the year.

DORA. Regulation (EU) 2022/2554 applies from 17 January 2025. On 18 November 2025 the European Supervisory Authorities designated the first critical ICT third-party providers, who are now subject to direct oversight. The relevance for a software supplier is direct: if you run infrastructure or supply software to a financial entity, DORA shapes your contracts, your incident reporting and your resilience testing, not only your client's.

GDPR. Article 83(5) caps administrative fines at EUR 20 million or 4% of total worldwide annual turnover, whichever is higher. The CMS Enforcement Tracker, a third-party aggregation, put the cumulative total at roughly EUR 6.3 billion across more than 3,200 fines as of August 2026. The modernization relevance is narrow and specific: personal-data stores, audit logs, access paths, encryption boundaries and processor relationships are architectural decisions that are cheap at design time and expensive to retrofit.

The security picture sits alongside the regulatory one. ENISA's Threat Landscape 2025, covering 4,875 incidents between July 2024 and June 2025, again placed DDoS and ransomware at the top of its prime threats. Within its recorded case distribution DDoS accounted for about 76.7% of cases and intrusions 17.8%, while phishing remained the dominant initial-access vector at 60%. IBM's Cost of a Data Breach Report 2026, published 29 July 2026, put the global average breach cost at USD 4.99 million, a record high and a 12% increase on its previous edition, and reported that one in four malicious breaches were AI-enabled at an average cost of USD 6 million.

Legacy platforms make this harder to manage for reasons that are specific rather than general: patching paths that no longer receive updates, identity controls that predate modern federation, recovery procedures that are manual, and runtime behavior that cannot be traced well enough to evidence what happened during an incident.

Why do AI investments underperform on legacy architecture?

Because AI increases the rate of change, and coupling converts change into instability. This is the finding that should reframe the modernization business case, and it comes from the largest current body of delivery-performance research.

Google Cloud's 2025 DORA report, based on responses from nearly 5,000 technology professionals, found that 90% use AI at work and more than 80% report productivity gains. It also found that AI adoption continues to have a negative relationship with software delivery stability. The mechanism is stated plainly: without strong automated testing, mature version control and fast feedback loops, an increase in change volume leads to instability, and teams working in loosely coupled architectures with fast feedback loops see gains, while those constrained by tightly coupled systems and slow processes see little or no benefit. The report frames AI as an amplifier of the system a team already has rather than a fix for it.

DORA's follow-up research on the ROI of AI-assisted development (version 2026.1, April 2026) models the same effect financially, including a J-curve where productivity dips before it rises, and shows how rising change-failure rates erode the return.

Two conditions travel together in that finding, and dropping either one overstates it: tight coupling and slow processes. The honest reading is not that AI is oversold. It is that the return on AI-assisted development depends on architecture and delivery discipline, which is what a modernization program changes. That makes modernization a precondition for the AI investment rather than a competitor for the same budget, which is a more useful argument to take to a board than either one alone.

What does the money look like?

Three sources frame the financial case, and one of them is almost always misquoted.

Run versus change. The clearest public evidence on how legacy consumes budget comes from the UK Department for Science, Innovation and Technology's State of Digital Government Review, published January 2025. It is a government self-assessment covering UK central government rather than European enterprises, so it illustrates a mechanism rather than providing a benchmark. It found around 28% of central government technology estates classified as legacy, up from 26% in 2023, and noted that organizations such as DWP and NHS England spend as much as 70 to 85% of their technology budgets on upkeep instead of modernization or innovation. It also found that 22% of legacy systems were red-rated, and that 28% of those red-rated systems had no remediation funding. That last pairing is the mechanism worth borrowing: unfunded remediation is how a legacy problem compounds instead of resolving.

Technical debt. The widely cited figure that 10 to 20% of the technology budget dedicated to new products is diverted to resolving tech debt comes from McKinsey's "Tech debt: reclaiming tech equity", published October 2020 and based on a survey of 50 CIOs at companies with revenues above USD 1 billion. It is 2020 data and should be cited as such. The same work put tech debt at 20 to 40% of the value of the entire technology estate before depreciation. McKinsey's April 2023 follow-up added that companies scoring worst on tech debt were 40% more likely to have incomplete or canceled IT modernizations.

McKinsey's March 2026 budget research, based on 17 global companies across Europe, North America and Australia, describes what the disciplined end of the market does differently. Companies it calls deliberate modernizers keep at least a third of total technology spend on change rather than run, hold run-based infrastructure costs at least 20% below other organizations, and direct 57% of their application spending specifically to change categories. The two share-of-spend figures use different denominators (total technology budget and application budget), which is worth noting when the numbers get repeated.

The growth claim, stated correctly. Accenture's 2024 research is commonly quoted as "a strong digital core delivers 60% higher revenue growth". That misreads it twice. The actual finding, published 17 July 2024, is that organizations with an advanced digital core plus strategic innovation investment plus a balanced approach to technical debt achieved "up to" 60% higher revenue growth rate and 40% higher profits. It is a three-condition result with an upper-bound qualifier, and the press release does not define the comparison cohort in enough detail to reproduce the analysis. Modernization creates conditions for growth. Presenting it as a cause of a 60% growth uplift is not what the research says.

For market context, Gartner's forecast of 27 July 2026 puts worldwide IT spending at USD 6.37 trillion in 2026, up 14.2%, with infrastructure as a service growing from USD 222 billion in 2025 to USD 287 billion in 2026. Gartner names IaaS and data center systems the top growth segments.

Which modernization strategy fits which system?

Effective modernization is a portfolio decision rather than a single project. The seven standard options, with the trade-off that actually decides between them:

These options are easy to list and hard to assign. Deciding which one fits each system, on evidence rather than opinion, is what an assessment produces.

Three practices decide whether the portfolio approach works.

Rationalize before you build. Before any new code, find duplicated applications, unused reports, redundant interfaces and manual workarounds. Scope frequently shrinks at this stage, either retired outright or replaced by a process change. It is the cheapest form of modernization available and the easiest to skip, because it produces nothing to demonstrate.

Wrap the core, then reduce its role. Rather than rewriting a central system in one high-risk program, build stable APIs around it, route new functionality through modern services, and move responsibilities off the legacy core one at a time until what remains is small enough to replace or retain deliberately. This is the strangler pattern, and it is the right default when the legacy system still runs critical transactions. Increments that only add read paths or new services are straightforward to reverse. Increments that migrate writes or data ownership are not, so those need their own rollback design rather than an assumption of reversibility.

Refactor selectively. Apply it to areas with high change frequency, poor reliability or direct customer impact. Refactoring a stable back-office function because the code looks dated is an aesthetic decision presented as an engineering one.

A practical release sequence:

1. Build a portfolio inventory and a dependency map.
2. Classify every application by business value and technical health.
3. Choose one strategy per application, with a named owner.
4. Define migration waves with explicit rollback criteria.
5. Automate tests, deployment, security scanning and monitoring before the first cutover, not after.
6. Decommission the old infrastructure once production stability is confirmed, and verify that the decommission actually happened.

Step 6 is the one most often left unfinished, and undecommissioned systems are how organizations end up carrying the cost of both the old and the new estate.

How do modernization diagrams improve planning and execution?

A modernization diagram makes current systems, dependencies, data flows, risks and the target architecture visible to technical and non-technical stakeholders at the same time. It converts assumptions into artifacts that can be checked, and it surfaces integration, security and operational gaps before they reach production.

A program needs four:

• Current-state architecture: applications, databases, integrations, users, infrastructure.
• Dependency map: upstream and downstream systems, batch jobs, APIs, file transfers.
• Target-state architecture: future services, data stores, identity, monitoring, deployment model.
• Migration roadmap: waves, go-live points, coexistence periods, decommissioning gates.

The C4 model provides a workable hierarchy of system context, container, component and code, and arc42 adds building-block and runtime views. Both are deliberately light, which is what lets them stay current alongside a delivery schedule.

Two things separate a diagram that gets used from one that gets ignored. First, it is version-controlled and updated like code rather than maintained as a slide. Second, it marks the compliance-relevant elements explicitly: personal-data stores, audit logs, access paths, encryption boundaries, third-party processors and operational monitoring. That overlay is what lets the people accountable for GDPR, NIS2 and DORA review an architectural decision while it is still a decision.

A useful diagram answers five questions: what exists today, what depends on what, what must change, what must not break, and what can be switched off. A diagram that cannot answer those is too abstract to guide execution.

What does a modernization engagement include?

A structured modernization engagement covers the full lifecycle from discovery through to operational handover:

• Assessment: source code, infrastructure, databases, interfaces, licenses, security controls and operational process review, combined with stakeholder interviews. The output is a prioritized portfolio map.
• Architecture roadmap: target state across application, data, integration and infrastructure layers.
• Migration planning: wave plans, rollback models, environment strategy, go-live criteria.
• Engineering execution: refactoring, containerization, API development, database migration, automation.
• Quality assurance: regression, performance and security testing, data reconciliation.
• Operating model: CI/CD, observability, incident management, handover to the internal team.

One structural point belongs here regardless of supplier. Outsourcing execution does not outsource accountability. The internal product owner, the security lead and the enterprise architect have to remain the decision-makers, because the dependencies that break a modernization program are usually organizational rather than technical, and an external team cannot resolve those. A well-constructed engagement ends with the internal team holding the documentation, pipelines and runbooks it needs to operate the result without the supplier.

If you are weighing modernization against a NIS2 or DORA deadline, or you have an AI initiative that is not returning what the pilot promised, talk to our engineering team directly. No form and no demo: a call with the people who would run the work.

Talk to our engineering team →

Sources

• Eurostat — "53% EU enterprises used paid cloud services in 2025"
• European Commission — State of the Digital Decade 2026 package
• Eurostat — "20% of EU enterprises use AI technologies"
• Decision (EU) 2022/2481 — Digital Decade Policy Programme
• European Commission — "Commission refers Ireland, Spain, France and the Netherlands to the Court of Justice"
• Directive (EU) 2022/2555 — NIS2, Article 20
• Regulation (EU) 2022/2554 — DORA
• ESAs — Designation of critical ICT third-party providers, 18 November 2025
• Regulation (EU) 2016/679 — GDPR, Article 83
• CMS GDPR Enforcement Tracker
• ENISA — Threat Landscape 2025
• IBM — Cost of a Data Breach Report 2026
• Google Cloud / DORA — 2025 DORA Report: State of AI-assisted Software Development
• DORA — ROI of AI-assisted Software Development, v2026.1
• UK DSIT — State of Digital Government Review, January 2025
• McKinsey — "Tech debt: reclaiming tech equity", October 2020
• McKinsey — "Breaking technical debt's vicious cycle to modernize your business", April 2023
• McKinsey — "Recalibrating technology budgets for the AI era", March 2026
• Accenture — "Reinventing with a Digital Core", July 2024
• Gartner — "Worldwide IT Spending to Grow 14.2% in 2026", July 2026
• C4 Model
• arc42