Legacy vs modern platforms: a practical modernisation roadmap

Many government agencies and banks still run critical services on platforms designed before today's threats, cloud services and mobile channels existed. These systems often work reliably, which is exactly why they survive. But reliability is not the same as security or agility. Every year of deferral raises the cost of change, shrinks the pool of people who understand the system, and widens the gap between what the institution needs and what the platform can deliver.

What makes legacy systems risky

The technical problems are remarkably consistent across sectors:

• Unsupported operating systems and middleware. Once a vendor stops issuing security fixes, every newly discovered vulnerability becomes permanent.
• Mainframe and core banking dependence. Business logic is buried in decades of customised code, with thin documentation and few remaining specialists.
• Flat networks. Servers, workstations and administrative interfaces often share one network, so a single compromised host can reach almost everything.
• Weak authentication. Shared administrator accounts, static passwords and no multi-factor authentication (MFA) on remote or privileged access.
• Brittle integration. File transfers, hard-coded credentials and point-to-point interfaces that nobody dares to touch.

Start with a risk-based inventory

You cannot modernise what you have not mapped. Begin with an inventory of systems, owners, data classifications, interfaces and dependencies. Then rank each system on two axes: how critical the service is, and how exposed and unsupported the platform is. A payment switch running an unsupported operating system and reachable from several networks belongs at the top of the list; an internal reporting tool used by one department does not. This ranking, not vendor roadmaps or internal politics, should decide the order of work. NIST CSF 2.0 and ISO/IEC 27001 both expect asset identification and risk assessment as the foundation for exactly this decision.

Modernise in phases, not in one leap

Big-bang replacements of core platforms are where many programmes fail. A safer pattern is incremental, often called the strangler approach:

1. Wrap. Place an API or integration layer in front of the legacy system so that new channels stop depending on its internals.
2. Carve out. Move one capability at a time, such as customer onboarding, document workflows or reporting, to a modern platform while the legacy core keeps running.
3. Run in parallel. Reconcile results between old and new until the business trusts the output.
4. Retire. Decommission the legacy component formally, including data archiving and access removal.

Each phase delivers value and can be stopped or reversed, which is essential for regulated environments where service interruption is not an option.

Compensating controls while you wait

Some systems cannot be replaced for years. Until then, reduce risk around them:

• Isolate them in dedicated network segments with strict allow-lists, and place a firewall between them and user networks.
• Enforce MFA and a privileged access management (PAM) gateway for every administrative session, even if the system itself cannot support MFA.
• Apply virtual patching through intrusion prevention or web application firewalls where vendor patches no longer exist.
• Increase logging and monitoring, and forward logs from the legacy system to a central SIEM.
• Keep tested, offline backups and a documented recovery procedure aligned with ISO 22301 principles.

Apply Zero Trust thinking as described in NIST SP 800-207: never assume a device or user is trusted merely because it is inside the network. For banks, also map these controls against PCI DSS v4.0.1 and the SWIFT Customer Security Programme where they apply.

How Wethaq ICT helps

Wethaq ICT supports government bodies and financial institutions through the full journey: assessing legacy estates, building a risk-ranked modernisation roadmap, designing segmentation and identity controls, and operating monitoring services that protect systems while they are being replaced. Our approach is vendor-neutral and phased, so that services stay available and every step can be justified to auditors and leadership.