A legacy migration filed as an IT project gets funded from the IT budget, scheduled behind everything urgent, and judged on whether it delivered the same features on newer infrastructure. Filed as a security programme, it gets a named risk owner, a deadline, and a success measure a board already understands. The second framing is not a trick to unlock spend. It is the accurate description of what an unsupported system is.
An application nobody can patch, running on a runtime the vendor stopped fixing, holding customer data, reachable from the internet, is not "legacy". It is an accepted risk that nobody wrote down. Here is how to re-file it, and how to run the programme once you have.
Why the framing decides whether the programme survives
Because framing sets who owns it, how it is measured, and what happens when something urgent appears. An IT project competes with every feature request and loses most quarters. A security programme has a risk register entry, an accountable executive and a reporting line, so deferring it becomes a decision someone has to sign their name to.
- ▸IT framing makes deferral free. "We will do it next year" costs nothing on paper, so it happens every year.
- ▸Security framing makes deferral explicit. The same delay now reads as accepting a documented risk for another twelve months, with a signature attached.
- ▸It changes the vocabulary. The NIST Cybersecurity Framework gives you functions and outcomes that map onto board reporting, insurance questionnaires and customer due diligence forms.
- ▸It survives leadership change. Feature roadmaps get rewritten by every new director. Risk register items get inherited.
Start with attack-surface goals, not a feature list
Write the goals as reductions you can count: internet-exposed services, systems running unsupported software, accounts with standing administrative rights, locations holding personal data, and third-party components with no upstream maintainer. Those counts are the programme's deliverables. Feature parity is a constraint on how you get there, not the objective.
- ▸Inventory first, and be honest about it. The inventory has to include the shadow systems: the reporting box under a desk, the supplier portal nobody logs into, the old test environment holding a copy of production.
- ▸Count what answers from the internet. Scan from outside, not from the network diagram. The diagram is always wrong in the same direction.
- ▸Date every runtime and platform. Check them against Microsoft product lifecycle and the equivalent vendor pages. Past end of support is a hard fact, not an engineering opinion.
- ▸Cross-reference against the CISA Known Exploited Vulnerabilities catalogue. Anything in your estate that appears there and cannot be patched sets the programme's first phase for you.
- ▸Count copies of personal data. Every duplicate database, export and backup is a separate breach candidate with its own access controls to get wrong.
Pick one control framework and map the legacy estate against it
Use one framework, not three. For most mid-sized organisations the NIST Cybersecurity Framework is enough, and its functions give you headings a board can follow. Map every legacy component against it once, honestly, and the migration sequence falls out of the gaps rather than out of an argument.
- ▸The mapping produces a gap register, and that register is the plan. Each gap is either closed now with a compensating control or later by migration.
- ▸Compensating controls get an expiry date. Network isolation and a web application firewall in front of an unpatchable application are legitimate for six months and negligent for six years.
- ▸Some gaps cannot be closed without replacement. Per-object authorisation, phishing-resistant authentication, meaningful audit logs and key rotation are structural. If the legacy system cannot express them, that is your replacement justification in one line.
- ▸Bring the auditor in early. The framework language you choose is the language your certification, your insurer and your enterprise customers will use later.
The EU pressure that changes the business case
Two instruments moved unsupported software from a cost question to a compliance question. The NIS2 Directive makes cybersecurity risk management and supply chain diligence a duty of the management body for in-scope organisations. The Cyber Resilience Act attaches security requirements and a support obligation to products with digital elements placed on the EU market.
- ▸Read the scope before assuming you are out of it. The NIS2 Directive covers a wide set of sectors and sizes, and national transpositions differ. Check with counsel rather than with an internet summary.
- ▸Supply chain clauses pull in companies that are not directly in scope. If your customers are regulated, their diligence questionnaires become your requirements, and "we run unsupported software" is an answer that loses contracts.
- ▸If you sell software, your legacy is now a product question. The Cyber Resilience Act sets essential cybersecurity requirements, vulnerability handling duties and a support period for products with digital elements.
- ▸The threat picture is public, so use it. The ENISA Threat Landscape documents the classes of attack European organisations are actually facing, which is more persuasive to a board than a vendor slide.
- ▸The practical effect is a date and a name. Regulatory framing gives the migration what IT framing never provides: an owner who is personally accountable and a deadline that does not move quietly.
Phase the delivery so every phase retires something
Define phases by what they remove, not by what they add. Phase one removes the most exposed unsupported component. Phase two removes the shared administrative accounts. Phase three removes the last direct database connection. If a phase adds a system without deleting one, it has increased your attack surface and should not be signed off.
- ▸Every phase carries a decommissioning exit criterion. Old service stopped, credentials rotated, host removed, firewall rule closed, monitoring updated.
- ▸Move incrementally, in the manner of a strangler migration. A routing layer in front of the legacy system lets you replace one slice at a time and roll back with a configuration change instead of a rescue project.
- ▸Keep patching the legacy while it lives. "It is being replaced" is the single most common reason a system goes unpatched for a year, and ransomware operators reach organisations through exactly that kind of neglected remote access.
- ▸Freeze new features on any component with a live replacement. Otherwise you rebuild a moving target and the phase never ends.
- ▸Public-facing systems usually go first, and they carry their own risks. Traffic, rankings and redirects need a plan of their own, which is what Leaving WordPress: A Migration Playbook That Does Not Lose Your SEO exists to cover.
- ▸Vendor platforms need a data exit plan before a migration date. Extraction, format and history come first, as set out in Escaping SaaS: The Complete Guide to Migrating Your Business to Custom Software.
Report reduction, not activity
Give the board five numbers every month, all moving in one direction: internet-facing services, systems past vendor support, standing administrative accounts, time to deploy a critical security fix, and systems holding personal data. Sprint velocity, story points and percentage complete belong in the delivery meeting, never in the risk report.
- ▸Baseline before phase one starts. Without a measured starting point, every later number is an argument instead of evidence.
- ▸Verify by scan, not by spreadsheet. Inventories drift within weeks. Automated discovery is the only version anyone should trust.
- ▸Include a line for risk accepted this month. Every compensating control still in place, with its expiry date, in plain language.
- ▸Track credential exposure as its own number. Dormant accounts, reused passwords and sessions stolen by infostealers are a live route into a half-migrated estate, so count the accounts that still exist on the legacy path and drive that number to zero.
- ▸Keep the operational baseline visible. Backups, MFA coverage, patch cadence and monitoring still need to hold while the migration runs, which is the ground covered by The Small Business Website Security Checklist for 2026.
The three programme killers, and their early symptoms
Most failures come from one of three causes: the programme is owned by IT alone, the scope is defined as feature parity, or nobody funded decommissioning. Each shows a symptom inside the first quarter. Catch them then and the programme finishes. Miss them and you end up operating two estates and paying for both.
- ▸Owned by IT alone. Symptom: no risk register entry, no board slide, no executive who can name the deadline. Fix it by assigning the risk before assigning the work.
- ▸Scope defined as feature parity. Symptom: requirements written by screenshotting the old system. Fix it by re-deriving requirements from the business process, which is also how you drop the features nobody has used in years.
- ▸No funded decommissioning. Symptom: the old server is still running six months after cutover "in case someone needs a report". Fix it by putting retirement in the same budget line and the same contract as the build.
- ▸Security review left until the end. A penetration test two weeks before launch finds design flaws you can no longer afford to fix. Review per phase instead.
- ▸Nobody owns the interim. While both systems run, one named team patches both, monitors both and holds the runbooks for both, a point worth settling in writing as part of What Website Maintenance Should Actually Include (and What You Are Probably Paying For).
How TuniCyberLabs helps
We run legacy modernisation as a security programme: external attack-surface assessment, an honest inventory, a control gap register mapped to a framework your auditors accept, phased delivery where each phase retires something, and monthly reduction metrics your board can read. Engineering in Tunisia, headquarters in Estonia, working across the EU and North Africa.
Bring us the system you cannot patch and we will give you the risk case, the phase plan and the decommissioning date: start the conversation.