Modernizing Legacy Systems in Healthcare: A Guide to Healthcare Software Modernization

Key Takeaways

• Age doesn’t make a system legacy. Losing patches, support, or a way to share data in FHIR does.
• Treat healthcare software modernization as a portfolio job: score each system on value and risk before anyone picks a strategy.
• Expect a mixed result. Some systems get an API wrapper, others a rebuild, and a few just get archived and switched off.
• Deadlines often decide the order now, whether that’s January 2027 for payer APIs or the end of Windows 10 patches.
• Plan data migration and cutover separately; that’s where the months go.
• Record a baseline first, or you’ll never prove the program paid off.
• NHS projects need DSPT, DTAC, and DCB0129/DCB0160 sign-offs budgeted on top of the engineering.

Ask anyone who’s worked on modernizing legacy systems in healthcare where it started, and you’ll often hear about one box in a server room. Ours would be a lab system still on Windows Server 2012, three years past extended support. Exactly one engineer knows its quirks. Results reach the EHR over an HL7 v2 feed that falls over every few weeks. When it does, the engineer resends the batch by hand.

That setup isn’t rare. Versions of it sit inside legacy systems in healthcare organizations of every size. Most stay unnoticed until an audit or a FHIR deadline drags them into a meeting. Patient apps, AI pilots, every real push toward digital transformation in healthcare: they all end up waiting on plumbing like this.

So where do you start? Which systems get modernized first, how, and in what order? That’s the question this article works through for US and UK (NHS) teams, drawing on what we’ve learned building healthcare IT solutions in both markets.

What Is a Legacy System in Healthcare?

A legacy system in healthcare is software your organization still depends on but can’t properly patch or connect to modern data standards anymore. Age doesn’t decide it. A 2010 EHR that still gets patches and exchanges FHIR data isn’t legacy, while a three-year-old app locked into flat files is.

In practice, a system has crossed into legacy territory when it fails one or more of these tests:

• Support: the vendor no longer supports it or ships security patches.
• Data exchange: it can’t send or receive data in current standards such as HL7 FHIR and USCDI.
• Security controls: it can’t support MFA, encryption, or detailed audit logging.
• Knowledge: only a handful of people still know how it works, and that knowledge isn’t written down.

Failing one test is a warning. Failing two usually means the system already costs more than it saves, even if nobody has put a number on it yet.

In the NHS, the same tests apply to EPR, patient administration systems (PAS), and pathology systems. There, current standards mean FHIR UK Core and connection to NHS Spine services.

The general principles of legacy system modernization still hold. Healthcare just adds constraints most industries never face, starting with systems that can’t go offline at 3 a.m.

What keeps legacy systems in healthcare organizations running

Most of these systems stay because they still work. A lab system that has run for 15 years without losing a result has earned some trust. Changing it carries clinical risk, and staff have built years of workflow around its quirks. Certified device firmware can’t be touched without revalidation. Add a vendor contract with three years left and a budget set 18 months ago. Old records must stay reachable, too. Eventually, patching costs outgrow the replacement quote.

Common Legacy Systems in Healthcare

Here’s what we see most often across healthcare organizations, along with where each system tends to go next.

Electronic health records

Nobody runs a vanilla record system. Ten years of custom order sets and one-department tweaks pile up, and suddenly the vendor’s upgrade path doesn’t fit anymore. Upgrades turn into months of regression testing.

Most teams end up on a supported version, or consolidate onto one platform after a merger. Whatever’s left gets exposed through a FHIR API layer. For workflows the vendor platform won’t touch, EHR/EMR software development on supported APIs usually costs less than another round of in-core customization.

Laboratory information systems

Ask a lab manager how many analyzer interfaces they have. You’ll often get an estimate. Each one usually speaks its own flavor of HL7 v2, written years ago by someone who’s since moved on. Replacing the LIS is the easy part, honestly. Rebuilding those feeds on an integration engine, and documenting every mapping while you’re there, is where the real work sits.

Radiology and imaging systems

Image archives only grow. One CT study can take hundreds of megabytes, and on-premises PACS answers that the only way it can: more storage hardware, every budget cycle. A vendor-neutral archive or cloud imaging breaks the link between the images and the viewer. As long as everything stays in DICOM, your next PACS swap won’t turn into a data migration.

Pharmacy and medication management

This is the corner of healthcare IT where we’d slow down. A pharmacy system holds formulary rules and talks to dispensing cabinets, and a single wrong mapping can reach a patient before the next shift change. Phase it. Run old and new in parallel, and don’t switch off the old one until pharmacists have checked every rule themselves.

Revenue cycle, billing, and claims

On the payer side, claims adjudication often still runs on a mainframe. Decades-old COBOL rules, X12 batches overnight. It works, and that’s exactly why nobody in finance or IT wants to be the one who touches it.

Wrapping the core in APIs buys time and gives newer apps something to call. After that, refactor rules module by module, starting with whichever ones change every plan year.

Practice management and scheduling

Lots of outpatient clinics still schedule in a desktop app nobody outside the front desk can open. Patients call because they can’t book online. The phones ring all morning. Off-the-shelf SaaS replaces most of them, and a custom web app earns its cost only when booking logic gets truly odd. Think multi-resource appointments across three sites.

UK: patient administration systems

In plenty of NHS trusts, the PAS is older than the EPR sitting next to it. Some still run on databases their supplier stopped supporting years ago, full of local clinic and specialty codes. Fold it into the EPR, ideally. That rarely happens fast, so an API wrapper keeps PAS and EPR talking until switch-off.

Integration engines and point-to-point interfaces

How many interfaces does your engine run? In large health systems, the honest answer is often several hundred, give or take. Each point-to-point link is one more thing that can fail quietly on a Sunday night, with nobody watching the queue. Moving them onto a single modern integration platform, with FHIR wherever partners support it, at least puts every feed where you can see it.

Medical device software

Clinical engineering knows this one well. A CT scanner might stay in service for over a decade, long after Microsoft has stopped patching the Windows build inside it. You can’t patch it yourself either, not without the manufacturer. What you can do today is segment those devices on the network and lock down who reaches them. Replacement plans come later, with the vendor.

Custom departmental databases

Every hospital has at least one. Picture an Access file a nurse manager built in 2009 to track bed turnover, still feeding a monthly board report today. No audit trail. Author long gone. Before you retire it into a supported app or data platform, find out what still reads from it.

Risks of Keeping Legacy Systems in Healthcare

Running legacy healthcare systems carries risks that rarely show up as a line item until something breaks.

Security exposure from unsupported software

Microsoft stopped shipping free Windows 10 patches on October 14, 2025. You can still pay for Extended Security Updates, but only until October 2028. After that, there’s nothing. Sophos found that exploited vulnerabilities were the top technical cause of healthcare ransomware in 2025, at 33%. Few healthcare cybersecurity challenges are this predictable. The NHS saw it in May 2017. WannaCry spread through unpatched Windows machines and hit at least 81 trusts and 595 GP practices.

Higher breach costs

IBM’s Cost of a Data Breach Report 2026 puts the average healthcare breach at $6.64 million. It’s the 13th straight year healthcare tops the list, even though the figure fell from $7.42 million. Legacy systems push that number up in quiet ways. Missing audit logs slow the investigation. Data nobody mapped makes it hard to say which patients were affected, and every day of uncertainty adds legal and notification costs.

Interoperability gaps and information blocking

Under the Cures Act, interfering with access to electronic health information can count as information blocking. A legacy system that can’t answer a patient’s request through a standard API doesn’t automatically get you off the hook. Penalties are real. Hospitals that OIG refers to CMS can lose three-quarters of their annual market basket increase. Certified health IT developers and exchanges face fines of up to $1 million per violation.

Compliance exposure

In the US, the HIPAA Security Rule requires a current risk analysis for every system holding ePHI. An unpatchable server is hard to defend in an OCR investigation, and information blocking adds a second exposure. In the UK, organizations answer to UK GDPR’s Article 32 security duty. Then there’s the annual DSPT submission. Trusts have to list every unsupported system and show how they’re managing the risk until it’s gone.

Patient safety and clinician time lost to workarounds

Every workaround lands on clinicians. Lab results get re-keyed into the EHR by hand. A pharmacist spots two medication lists that don’t match and spends twenty minutes on the phone sorting out which one’s right. On a bad night, the system goes down, and patients wait while the ward switches to paper. Synnovis showed how far that spreads. After ransomware hit the London pathology supplier in June 2024, King’s College Hospital and Guy’s and St Thomas’ postponed over 10,000 outpatient appointments by mid-September. Another 1,700 elective procedures slipped too.

Blocked analytics and AI

A sepsis alert is only useful if it sees vitals and lab results within minutes. Plenty of legacy systems only export data in a nightly batch, so the model ends up scoring yesterday’s patient. Most AI in healthcare runs into the same wall. Models need timely, consistently coded data. Closed databases with local code sets can’t supply it, and no amount of model tuning fixes a problem that sits upstream.

Regulatory Deadlines Driving Healthcare Software Modernization in the US and UK

For a growing number of healthcare organizations, these dates now set the modernization order, and the budget cycle has to fit around them.

US: federal rules and deadlines

UK: NHS and UK rules

Maintain or Modernize? A Decision Framework for Each Healthcare System

Don’t judge a healthcare IT estate as a whole. Give each system two scores instead, one for clinical and business value and one for technical risk, then check the grid.

Signals that a system has moved to “high risk”

• The vendor has published an end-of-support date, or the box still runs Windows Server 2012 or a database nobody patches anymore.
• You can’t add MFA, encryption, or audit logging without the vendor, and the vendor won’t.
• A new interface takes a quarter to build. Or someone exports a CSV by hand every Monday morning.
• Two people understand it, and both get called on holiday.
• Licensing and support go up at every renewal while usage doesn’t move.
• One of the deadlines above lands before you could realistically fix it.

Healthcare Legacy Software Modernization Strategies

Rehost and replatform follow familiar cloud migration best practices, so the sections below spend their time on patterns that are specific to healthcare.

Wrapping legacy systems with a FHIR API layer

Wrapping legacy healthcare systems in a FHIR API layer is usually the quickest win. New apps and partner systems talk FHIR, while the old core keeps running untouched until replacing it makes sense. That buys time. It also makes the next move cheaper, because the API contract stays put when the system behind it changes. In England, it can also map local codes to FHIR UK Core and handle NHS Spine calls. Built properly, that layer becomes reusable EHR integration plumbing. Later it can anchor a healthcare platform as a service.

Incremental modernization with the strangler fig pattern

The name comes from a vine that slowly grows around its host tree. In code, a routing layer sits in front of the old system. You rebuild one function, say referrals or bed management, point traffic at the new service, and leave everything else where it was. Then the next function. The legacy core shrinks month by month until switching it off is a non-event. It’s slower than a big-bang cutover. For a hospital that can’t close for a weekend, that trade is usually worth it. You also don’t have to settle monolith vs microservices on day one.

Replacing legacy systems in healthcare: when full replacement is the right call

Sometimes wrapping and strangling just delay the inevitable. At that point, replacing legacy systems in healthcare is the cheaper path. Full replacement makes sense when the vendor has announced end of life, or when a regulatory gap can’t be closed on the current platform. Mergers are the other trigger, usually leaving two record systems doing one job. It’s also the most demanding option. Expect months of parallel running, with clinicians in both systems while results get compared. You’ll need a data migration plan signed off by someone clinical, and training that fits around real shifts instead of classroom demos. Skip either and adoption stalls.

Retiring and archiving legacy clinical data

Switching a system off doesn’t switch off its records. HIPAA wants compliance documentation kept for six years. Medical records themselves follow state law, which often demands longer retention, and longer again when the patient was a minor. England works from the Records Management Code of Practice. Its minimums include 8 years after treatment for adult hospital records and 10 years after death for GP records. Children’s run to 25, or 26 if treatment ended at 17. A read-only clinical archive, or records moved into a governed healthcare data warehouse, is usually cheaper and easier to audit.

Using AI to understand legacy code — carefully

AI coding assistants are genuinely useful on old healthcare systems. They can read a 20-year-old codebase and draft the documentation nobody ever wrote. Test generation before refactoring is another quick win. One rule, though. No PHI goes into a tool that isn’t covered by a business associate agreement. Watch the test databases too. In legacy environments, they’re often copies of production, real patients included.

How to Modernize Legacy Systems in Healthcare: Step by Step

1. Inventory systems, interfaces and data

No healthcare IT inventory is complete on day one. The CMDB covers part of it, and procurement records, firewall rules, and the interface engine’s channel list fill in more. The rest turns up on foot. An analyzer PC under a desk, say, or an Access file on a shared drive that finance swears by. Each one gets an owner, a support status, and a note on what patient data it holds.

2. Map clinical and business dependencies

What happens if this system is gone for a day? Ask it about every entry on your list, starting with anything that touches medication or lab results. Some answers come fast: the wards stop, pharmacy loses its feed. Billing may take a week to notice. Record the downtime procedure each department actually follows as well, since that’s what will keep things moving during cutover. It rarely matches the binder.

3. Prioritize by risk and value

Most of the sorting happens on the value-versus-risk grid from the previous section, so this step is quick. High value, high risk: top of the list. Hard dates jump the line, and for payers January 2027 is the obvious one. Healthcare providers tend to get pushed by something less dramatic, like an unsupported OS or a DSPT finding. Easy wins? Useful for morale. They shouldn’t decide the order, though.

4. Choose the strategy and target architecture

We’d settle the target architecture before a single line of code. Our default is FHIR as the contract between old and new, which lets either side change without breaking the other. Cloud services need to be HIPAA-eligible and covered by a business associate agreement. Read the exit terms carefully. Plenty of today’s legacy systems started life as somebody’s shiny new closed platform.

5. Build security and compliance in from the start

In healthcare, bolted-on security costs more. So the HIPAA risk analysis happens early, while the design is still a sketch on a whiteboard and changes are cheap. Access roles, encryption, and audit logs go into sprint one. UK teams also owe a DPIA, plus DSPT evidence gathered along the way rather than reconstructed in June. NHS suppliers keep a DTAC pack per product version.

6. Migrate, cleanse and validate data

This is where months disappear quietly. Every field needs a mapping, including the free-text box in the old EHR that someone repurposed in 2011 for something nobody remembers. Duplicate patient identities get merged before anything moves. After the load, counts should reconcile. If the old system held 412,318 allergy entries, so should the new one. The final check belongs to the doctors, nurses, and pharmacists who’ll rely on those records.

7. Pilot, cut over and support clinicians

Pick one department for the pilot. Before it starts, regression, interface, and load tests should already have run through proper QA and software testing. Rollback plan and paper downtime forms ready? Then go, with trained staff and a hypercare desk for the first weeks. UK sites need one more thing first: a clinical safety officer’s sign-off on the DCB0129/DCB0160 safety case. Rehearse it like any application migration. Twice, ideally.

8. Decommission and measure

Plenty of programs stall at the last step. The new system works, so the old one keeps running “just in case,” still costing money and still exposed. Archive its data, cancel the licenses, and turn it off. Then pull out the baseline: maintenance spend, outage hours, interface failures, workaround time. Put the before-and-after numbers in front of the board, because they’re what funds the next round of modernizing legacy systems.

Healthcare Software Modernization in Practice: Wrapping a Health Insurer’s Core Systems in a Mobile Layer

Our closest example comes from health insurance, where the EuroAccident project put a mobile layer over core systems that stayed in place.

Client	EuroAccident, a NASDAQ-listed company operating since 1996
Industry and country	Health insurance and health services, Sweden
Legacy system and its problem	No mobile channel; paper-based refunds; manual case processing on top of back-end systems that had to stay in place
Modernization strategy used	Encapsulate: a new mobile layer integrated with existing infrastructure through APIs
Technologies / standards	Native iOS and Android, cloud-based back end, Swedish Mobile BankID, integration with Sweden’s most popular doctor booking service
Project duration and team	Not disclosed on the case page
Results	Qualitative: self-service claims, appointments and deductible payments; paperless refunds; Stevie Award for “New Service or Product” (insurance)

The challenge

EuroAccident, a NASDAQ-listed Swedish health insurer operating since 1996, had never had a mobile app. Refunds meant paperwork. Much of the case processing depended on staff, and the back-end systems that ran it had to stay where they were. Doing nothing carried its own cost. Manual work would keep piling up, while customers expected to handle claims from their phones.

The solution

We picked encapsulation. Instead of touching the core, the team built cloud-based native iOS and Android apps. They connect to EuroAccident’s existing infrastructure through APIs. Workshops came first. For sign-in, the app relies on Swedish Mobile BankID, the same ID people use with their banks. Doctor appointments go through the booking service most Swedes already know. And because the core never moved, the switch to the new channel happened without a big-bang cutover that staff would have had to work around.

The results

Customers now handle claims, appointments, and deductible payments in one app. A refund takes a photo of the receipt and a few form fields, with no paperwork. On EuroAccident’s side, self-service and automated processing took routine cases off the team’s desks, which was the whole point. The project earned a Stevie Award in the insurance category for New Service or Product. Planning for the app’s next version followed.

Challenges of Modernizing Legacy Systems in Healthcare

Most of what makes modernizing legacy systems in healthcare hard has little to do with writing code.

Data quality and mapping

Twenty years of healthcare records rarely arrive clean. The same allergy might be coded three different ways across departments, and the old PAS may hold two identities for one patient. Profile the data in month one, when fixing it is still cheap. Local codes get mapped to SNOMED CT, LOINC, or ICD-10 along the way, and anything that won’t map goes on a list a person reviews. Then count records before and after the load, twice.

Downtime during cutover

A bank can take its systems down at 1 a.m. on a holiday weekend. Healthcare can’t. An emergency department has patients waiting at that hour. So cutover happens in phases, with old and new running side by side and downtime procedures that someone has actually rehearsed. One rule we hold to: read access to the old system stays on until the new one has run cleanly for a few weeks.

Integration with remaining legacy systems

Nobody modernizes everything at once. So new and old systems share data for years. Your integration layer has to speak FHIR to new apps and HL7 v2 to legacy healthcare systems that won’t change. That’s also where many cloud migration risks hide, like a feed that worked fine on the local network and now times out across regions.

Undocumented logic and lost knowledge

Somewhere in the old billing system there’s a rule that rejects claims from one payer at month-end. Nobody remembers why. Before anything changes, we’d run code analysis and sit down with whoever still answers the support calls. Automated tests then pin the current behavior in place. After that, you can change the rule on purpose, with the tests telling you exactly what moved. Or keep it.

Getting staff to use the new system

Expect complaints in week two. Even a faster system feels slower while people relearn where everything lives, and patience runs thin by the end of a twelve-hour shift. Most of that can be defused months earlier. Pull a few ward nurses and a receptionist into the design sessions; they’ll spot the awkward click paths your analysts miss. Then name a super-user in each department and train them first. At night, they’re the help desk.

Vendor lock-in and contracts

Long contracts are normal in healthcare. The trap is the data format. If only the vendor’s own product can read your records, switching later turns into a migration project nobody budgeted for. We push for exit terms at signing, while there’s still leverage. That means named export formats, FHIR for records and DICOM for images, plus exit costs in writing. It’s also worth asking how the vendor’s last customer left. Vague answers tend to mean a messy exit. Done well, legacy system modernization leaves you less tied to any single supplier than you were when the project started.

How Much Does Healthcare Software Modernization Cost?

There’s no honest single number for modernizing legacy systems in healthcare. A FHIR wrapper around one lab system and a multi-year EPR replacement across a trust group sit orders of magnitude apart. Any estimate without a defined scope is a guess.

Start with scope. Ten systems or forty? A handful of departmental tools, or the platform the whole emergency department runs on? Strategy moves the number next. Putting an API layer in front of a stable LIS is a small project compared with rebuilding it. Interfaces surprise people. Each feed has to be mapped and tested, and after go-live somebody still has to own it. Data is the other wild card. Two million records full of duplicates and free text can take longer to move than ten million clean ones.

Compliance work runs alongside all of it, from the risk analysis to evidence packs for auditors. Parallel running is the line item people underestimate, since you pay for two systems and some double entry until the old one goes. Training costs scale with headcount and shift patterns. Decommissioning and archiving aren’t free either. In the UK, add the clinical safety case under DCB0129/DCB0160, plus DTAC assurance if you’re a supplier. Most healthcare organizations only see the full list after a proper discovery phase, which is why we scope before we quote.

Measuring the ROI of modernization

Two formulas cover most board conversations about legacy system modernization:

ROI (%) = (Total benefits − Total modernization cost) ÷ Total modernization cost × 100

Payback period (months) = Total modernization cost ÷ Monthly net benefit

ROI component	What to include
Total benefits (over the same period as the cost, usually 3 years)	Avoided maintenance, licensing and extended-support fees for the old system Avoided costs of security incidents and unplanned downtime Staff time saved × loaded hourly rate (manual data entry, workarounds, interface fixes) New or protected revenue (fewer claim denials, faster billing, new digital services)
Total modernization cost	Assessment and planning Development, integration and data migration New licenses and cloud infrastructure Training, parallel running and hypercare Decommissioning and data archiving
Baseline KPIs (record before starting)	Annual maintenance and licensing spend Security incidents and unplanned downtime hours Time to build a new interface Clinician time on manual data entry

Here’s an illustrative example, not Intellectsoft pricing: a healthcare program that costs $400,000 and saves $250,000 a year. Over three years, ($750,000 − $400,000) ÷ $400,000 × 100 = 87.5% ROI. Monthly net benefit works out to roughly $20,800, which puts payback at about 19 months.

Some of the value won’t fit the formula. Lower breach risk and a clean DSPT or HIPAA audit are hard to price. Report them next to the number anyway. Any digital transformation ROI case works on the same principle, with the hard-to-price items listed beside the math. Don’t wait for the end, either. Recalculate after every phase, while there’s still time to change course.

How Intellectsoft Approaches Healthcare Software Modernization

In 18+ years, Intellectsoft has worked with 35 Fortune 1000 clients. Our healthcare software modernization services support healthcare organizations in the US and the UK, where the rules differ but the risks look surprisingly similar.

Nothing gets built before the assessment. We inventory systems and interfaces and score each one on value and risk. Only then does a recommendation appear. That’s the difference between custom software modernization for healthcare and a generic migration plan with healthcare written on the cover.

Our healthcare legacy software modernization work ships in increments, usually function by function. FHIR acts as the data contract between old and new, so the legacy core keeps running while services move out around it. Compliance comes in at design time: HIPAA risk analysis for US work, DSPT evidence and DCB0129 safety cases for NHS projects.

The EuroAccident project above shows the incremental side of this: a new channel went live while the insurer’s core systems kept running. If you’re weighing legacy software modernization companies, ask each one how it ran its last parallel cutover on a system that couldn’t go down. A good partner will have a specific answer, with dates. Having done this for healthcare organizations on both sides of the Atlantic, we’d rather show you ours. Our healthcare software development services and IT consulting services cover the full path, from first inventory to the day the old server goes dark.

FAQ

What is a legacy system in healthcare?

A legacy system in healthcare is one your organization still relies on but can’t keep patched or connect to current data standards such as FHIR. Age alone doesn’t make a system legacy. Lost vendor support does, along with missing MFA or audit logging, or a codebase only one or two people understand. Plenty of legacy healthcare systems still run daily operations without complaint.

Why are legacy systems still used in healthcare organizations?

They still work, mostly. Pulling one out carries real risk, and fifteen years of reliable patient records buys a system a lot of goodwill. Staff have also bent their routines around its quirks. Contracts, capital budget cycles, device certification, and retention rules add friction. Healthcare providers also can’t pause care for a cutover, so change tends to get deferred until a deadline or an incident forces it.

What is healthcare software modernization?

It means modernizing legacy systems until they run on supported technology and can swap data in FHIR or another current standard. Sometimes that’s an API wrapper around a core that still works fine. Other times the system moves to the cloud, gets refactored, or is switched off for good. Most programs mix several of these. What sets healthcare apart is that care can’t stop while the work happens.

What is the best approach to replacing legacy systems in healthcare?

There isn’t one best approach, because the right one depends on each system’s value and technical risk. A stable system that still earns its keep can sit behind an API layer for years. An unsupported or non-compliant one usually can’t. If replacement wins, the boring parts decide whether it works. Parallel running takes weeks, someone senior signs off the migrated data, and training gets scheduled around real shifts.

How long does healthcare legacy software modernization take?

It depends on scope. We’d only commit to dates after an assessment. A single FHIR wrapper and a multi-site record system replacement aren’t remotely the same job. Schedules usually stretch because of interfaces, messy data, long parallel runs, or staff who can’t be spared for testing. Regulatory sign-offs, such as a DCB0160 safety case for NHS deployments, add time too.

How much does healthcare software modernization cost?

It depends on scope, and any number quoted without an assessment is a guess. Strategy matters most. Wrapping a stable system in APIs costs a fraction of replacing it outright. After that, the bill grows with interface count, messy data, long parallel runs, and training. For NHS projects, budget for DTAC and DCB0129/DCB0160 assurance as well, since it takes real people and real weeks.

How is legacy system modernization different for NHS organizations?

The technical work is similar, but the assurance around it is heavier. Every change needs a DCB0160 safety case, and suppliers need DCB0129 plus a current DTAC pack. Unsupported systems have to be declared in the annual DSPT. On the data side, NHS work means FHIR UK Core and NHS Spine integration, which US projects never touch. And when an old system is switched off, its records still have to meet the NHS Records Management Code of Practice.