Short answer: No EU law tells you to migrate an old business system. But GDPR, NIS2 and DORA require security appropriate to the risk, and proof of it. A system you cannot patch, audit or easily change makes that proof hard. DORA goes furthest: financial entities must risk-assess every legacy ICT system at least yearly. The Cyber Resilience Act matters mainly if you sell software.

This article explains what the texts say in our interpretation and focusing on legacy systems. It is not legal advice. Check your own position with your data protection officer or a lawyer.

Key points

  • GDPR (Regulation (EU) 2016/679) asks for erasure, export, breach reports within 72 hours, and security that reflects “the state of the art”.
  • NIS2 (Directive (EU) 2022/2555) makes “vulnerability handling” a duty (Art. 21(2)(e)). Hungary adds a cybersecurity audit every two years.
  • DORA (Regulation (EU) 2022/2554) names legacy ICT systems explicitly, in Article 8(7).
  • The Cyber Resilience Act (Regulation (EU) 2024/2847) covers products you sell, not systems built for your own use.
  • Migration is not the only fix. Containment and upgrades close many gaps.

Does any EU law require you to migrate a legacy system?

No. EU law sets outcomes, not technologies. None of these texts mentions Delphi, COBOL or any platform. What they share is a duty to manage risk and to show that you do: under GDPR the controller must “be able to demonstrate compliance” (Art. 5(2)).

An auditor, or the Hungarian data protection authority (NAIH), asks: who read this record, can you delete this person, is this component patched? Old systems often cannot answer.

Which laws apply to you:

  • GDPR: any system holding personal data.
  • NIS2: medium-sized and large organisations in the sectors in its Annexes I and II, such as energy, transport, health and manufacturing.
  • DORA: banks, insurers, investment firms, payment institutions and other financial entities.
  • CRA: manufacturers that sell software or devices in the EU.

What GDPR asks of an old system

Four GDPR duties land directly on the code.

Deleting data. Personal data may be kept “for no longer than is necessary” (Art. 5(1)(e)), and a person can demand erasure “without undue delay” (Art. 17(1)). Records of processing should give “the envisaged time limits for erasure” (Art. 30(1)(f)). Many old systems have no delete function, because foreign keys block it or a “deleted” flag was easier, and copies sit in exports and backups.

Access and export. A person is entitled to “a copy of the personal data undergoing processing” (Art. 15(3)), sometimes in “a structured, commonly used and machine-readable format” (Art. 20(1)), within one month (Art. 12(3)). If only a developer can pull one person’s data out of dozens of tables, every request becomes a small project.

Security. Article 32(1) opens: “Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing…”. Article 25 adds data protection by design and by default. An end-of-life TLS library, or one database login shared by all users, is hard to call the state of the art. The technical side is in security and platform risks in legacy Delphi.

Breaches. A breach goes to the authority “not later than 72 hours after having become aware of it” (Art. 33(1)), with “the categories and approximate number of data subjects concerned” where possible (Art. 33(3)(a)). If the system does not log reads, you cannot say whose data was seen, and the safe answer becomes “everyone’s”. The Commission’s Digital Omnibus proposal (2025/0360(COD)) would change the breach rules; until it is adopted, 72 hours applies.

Fines reach €20 million or 4% of worldwide annual turnover, whichever is higher, for the principles and data subject rights (Art. 83(5)), and €10 million or 2% for Articles 25 to 39 (Art. 83(4)).

What NIS2 asks

NIS2 makes vulnerability handling a legal duty and the board answerable for it. Article 21(2) lists minimum measures, including:

  • “(d) supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers…”;
  • “(e) security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure”.

A component whose vendor stopped shipping fixes fails both. Significant incidents need an early warning within 24 hours, a notification within 72 hours and a final report within a month (Art. 23(4)). Management bodies approve the measures and “can be held liable” (Art. 20(1)).

In Hungary, NIS2 is implemented by Act LXIX of 2024, in force since 1 January 2025. Companies supervised by the SZTFH must commission a cybersecurity audit every two years (§ 16); those already operating before 2025 had to complete the first one by 30 June 2026.

What DORA asks

DORA is the only one of these laws that says “legacy”, and it sets a yearly cycle. Article 8(7):

“Financial entities, other than microenterprises, shall on a regular basis, and at least yearly, conduct a specific ICT risk assessment on all legacy ICT systems and, in any case before and after connecting technologies, applications or systems.”

Note the second half: every new connection to an old system, such as an API, a portal or an AI assistant, needs an assessment before and after. DORA also requires an inventory of ICT assets and their interdependencies (Art. 8(4)) and “documented policies for patches and updates” (Art. 9(4)(f)).

If an outside firm maintains the system, you stay “fully responsible” (Art. 28(1)(a)), and critical or important functions need an exit strategy. A system only one supplier can change is hard to exit.

Does the Cyber Resilience Act apply to your in-house system?

Our interpretation, as of 2 October 2026.

Generally, no, if the system is developed solely for an organisation’s own internal use and is never supplied to others as a product. The European Commission’s CRA FAQ, section 1.5, expressly confirms that products manufactured for one’s own use fall outside the CRA.

However, “used internally” or “installed on-premises” does not by itself create an exemption. The CRA covers software and hardware products supplied on the EU market in a commercial activity, including for business use.

Situation CRA position
Your employees build an application exclusively for your company’s internal operations Normally outside scope, under the own-use principle.
You purchase or license software and run it internally Generally in scope as a supplied product. The manufacturer’s obligations primarily sit with the supplier; simply using it does not make you its manufacturer.
Your company supplies a bespoke application to one client for that client’s internal use Can be in scope. A single customer and custom development do not provide a general exemption.
External developers join your team to help build your own internal application Needs assessment: determine whether the arrangement supplies a software product or only development services.

These distinctions follow from the CRA’s market-supply and manufacturer definitions and the Commission’s express treatment of tailor-made software. The contractor scenario requires a contract-specific assessment.

NIS2 can still apply to internal systems where the organisation is covered: its cybersecurity risk-management requirements extend to the systems used to provide its services. An internal system being outside the CRA does not remove those obligations.

It does apply if you sell the software, including an old desktop product:

  • Since 11 September 2026: actively exploited vulnerabilities need an early warning within 24 hours (Art. 14; Art. 71(2)).
  • From 11 December 2027: everything else, including a support period of “at least five years” (Art. 13(8)). Components you cannot patch break that promise.

What the law asks, and what fixes it

What the law asks What a typical legacy system struggles with What fixes it
Erasure and storage limits (GDPR Art. 5(1)(e), 17, 30(1)(f)) No delete path; foreign keys block deletes; copies in exports and backups Contain: documented retention rules, anonymise in place. Upgrade: add an erasure routine. Migrate: retention built into the data model
Access and portability within one month (GDPR Art. 12(3), 15, 20) Data spread over many tables; only a developer can extract it Upgrade: one subject-export report. Migrate: an API that returns a person’s data
Security reflecting “the state of the art” (GDPR Art. 32; NIS2 Art. 21(2)(e)) Unsupported runtime, old TLS, shared database login Contain: network isolation, TLS-terminating proxy. Upgrade: current libraries, per-user logins. Migrate: when the stack itself is unsupported
Knowing what a breach touched (GDPR Art. 33; NIS2 Art. 23) No logging of reads; no user identity at database level Contain: database auditing. Upgrade: application audit log. Migrate: audit built into the API layer
Supply chain and vendor support (NIS2 Art. 21(2)(d); DORA Art. 28) Components with no vendor; one maintainer Contain: documentation, source escrow, a second engineer. Migrate: replace orphaned components
Yearly legacy risk assessment (DORA Art. 8(7)) No inventory of components, versions or interfaces Contain: inventory and assessment, with a recorded decision, owner and date

What to do this quarter

  1. Make an inventory. Each legacy system, its components, versions and interfaces, and who can change it.
  2. Check vendor support. Is each component still getting security fixes? Write down the end date.
  3. Assess risk per system. Mandatory under DORA; cheap evidence for everyone else.
  4. Test erasure and export on one real customer. Time it, and list every place the data turned up.
  5. Check the logs. Could you tell, within 72 hours, whose records an attacker read last Tuesday? If not, add logging first.
  6. Record the decision: contain, upgrade or migrate, with an owner and a date. An accepted risk with a plan is defensible; an unknown one is not.

When migration is not the answer

If a system holds little personal data, sits on an isolated network and runs on supported components, contain it and document why. Migration earns its place when the gap is in the foundations: an unsupported runtime, no user identity, or rules nobody can safely change. The cost side is in our hub article on moving off Delphi.

How we approach it

  1. Map the system against the law: what it can show today.
  2. Close the cheap gaps first: logging, isolation, retention.
  3. Migrate where the foundation is the problem, slice by slice, with the old system running until each slice proves it behaves the same. Audit logging, per-user identity and erasure go in from the first slice.

Our usual target is a hybrid solution where we keep as much of the business logic in Delphi as possible and use Java (Spring Boot) with React (though C# or another stack can fit better) to modernise the environment, but other scenarios are also plausible, depending on the case. We work alongside your data protection officer and lawyers, not instead of them.

Frequently asked questions

Is running unsupported software illegal under GDPR or NIS2?

Neither bans it outright. You must show your measures are appropriate to the risk, and unsupported software makes that harder to argue.

We are not a bank. Does DORA’s legacy rule matter to us?

Not legally. But a yearly written assessment of each legacy system is good evidence under GDPR and NIS2 too.

Does migrating make us compliant?

No. It lets you build in logging, erasure and per-user access from the start; you still have to use them.

Who supervises this in Hungary?

The NAIH for data protection. For NIS2 it depends on the sector: the SZTFH for the business sectors listed in the Act, the national cybersecurity authority for the rest. The Magyar Nemzeti Bank for DORA.

Need a clear view of where your legacy system stands? Talk to an engineer about a technical audit, or read how our re-engineering practice works.

Sources

Checked 1 October 2026. EUR-Lex is the authoritative text; article wording was read on the mirrors listed.