Every acute trust has them. The Microsoft Access database a ward sister built in 2014 to track pressure ulcers. The one finance uses every month-end that only one analyst knows how to open. The theatre scheduling tool that quietly underpins a real clinical workflow and has no documented owner, no backup policy, and no entry in any system inventory.

Individually, none of them looks like a problem. Collectively, they are one of the most overlooked risks in NHS data - and for a typical acute trust, there are not a handful of them but several hundred. NHS Access database migration is rarely anyone's headline priority, yet it sits directly in the path of almost every modernisation programme a trust is trying to deliver: a new EPR, the move to cloud-first architecture, onboarding to the Federated Data Platform (FDP), and meeting the Data Security and Protection Toolkit (DSPT).

This post is about how to get a grip on that estate: how to find the databases, how to work out which ones genuinely matter, and how to decide what to do with each one - without grinding frontline work to a halt in the process.

Why NHS Access databases became shadow IT (and why they won't just disappear)

Access databases proliferate for an entirely rational reason: they solve a real problem that no official system solved at the time. A team needs to track something, central IT is at capacity, and someone capable builds a tool over a weekend. It works. It spreads. Years later it is load-bearing.

This is the textbook definition of shadow IT - technology that delivers genuine value but lives outside formal governance, support, and security controls. In the NHS the pattern is amplified by scale, mergers, and decades of departmental autonomy. Two trusts combine, and so do their two ecosystems of unofficial tools. A single organisation can easily end up running 300 or more Access databases used daily by clinical, operational, and corporate staff.

The instinct of a modernisation programme is to declare them all legacy and switch them off. That instinct is wrong, and acting on it is how trusts break things. Some of these databases are trivial and can be retired tomorrow. Others are quietly doing work that, if it stopped, would directly affect patient care or statutory reporting. The job is not to eliminate them indiscriminately - it is to tell the difference.

The hidden risks: why "300 databases" is a governance and safety problem

Before you can prioritise, it helps to be honest about why an uncatalogued Access estate is a liability rather than just untidy.

• Information governance and compliance. An undocumented database holding patient-identifiable data is almost certainly outside your Record of Processing Activities, may have no defined retention or destruction schedule under the NHS Records Management Code of Practice, and represents a gap in your DSPT evidence. You cannot demonstrate compliance for data you cannot see.

• Patient safety and continuity. If a clinically relevant tool depends on one person, one unpatched laptop, or one network share with no backup, you are one resignation or hardware failure away from losing a working process - sometimes without realising until it's gone.

• Data quality before FDP. This one is increasingly urgent. The consistent message from FDP practitioners is that data quality must be assured before data flows into the platform, because a federated layer magnifies upstream errors rather than fixing them. Access databases are frequently where data is manually re-keyed, duplicated, and quietly diverges from the source of truth. Migrate or integrate them blindly and you propagate that mess into your national reporting.

• Security. Files on shared drives with no access control, no encryption, and no audit trail are exactly the kind of soft target that security frameworks are designed to eliminate.

None of this means Access is inherently bad. It means an ungoverned, unmapped Access estate is a risk you are carrying without pricing it.

You can't fix what you can't see: start with data estate discovery

The foundation of any sensible approach is data estate discovery - building an accurate, evidence-based picture of what actually exists before deciding what to do about it. Skipping this step is the single most common reason rationalisation programmes overrun or cause outages.

Effective discovery combines two things that are often done separately:

1. Automated technical scanning to locate database files across network shares, identify size, last-modified dates, table structures, and - critically - whether they appear to hold personal or special-category data.

2. Structured human engagement with the teams who actually use them. Automation tells you a file exists and was opened yesterday; only the ward, the analyst, or the department can tell you what it does, who relies on it, and what breaks if it stops.

The output you are aiming for is a single catalogue: every database listed with its purpose, owner, the data it holds, its dependencies, how often it is used, and a first-pass view of the risk it carries. That catalogue is the asset. Everything downstream depends on it.

A risk-tiering framework: separating the critical from the disposable

Once you can see the estate, you need a consistent way to prioritise it. Trying to assess 300 databases on gut feel produces inconsistent, indefensible decisions. A simple, repeatable risk-tiering framework scores each database on two axes - business/clinical criticality and risk exposure - and sorts them into four tiers.

• Tier 1 - Critical and exposed. Supports clinical care or statutory reporting and carries significant IG, security, or continuity risk (e.g. holds patient-identifiable data with no owner or backup). These are your priorities. Stabilise first, then migrate.

• Tier 2 - Critical but lower risk. Genuinely relied upon, but reasonably controlled. Plan a managed migration to a supported platform; no emergency, but no neglect either.

• Tier 3 - Useful but replaceable. Real users, low stakes. Often the best candidates for consolidation into existing tools or a low-code platform.

• Tier 4 - Redundant. Duplicated, abandoned, or superseded. Confirm with the team, then retire under a documented decommissioning process - including secure destruction where personal data is involved.

The value of tiering is that it turns an overwhelming, undifferentiated pile into a defensible, sequenced plan you can take to a governance board.

What to do with each database: migrate, rebuild, retain, or retire

A risk tier tells you how urgently to act; the next decision is what action to take. For each database, the realistic options are:

• Migrate the data into an existing, supported repository - for example a managed SQL platform or your future cloud data store - when the data matters but the Access front end does not.

• Rebuild the capability on a governed, low-code platform (such as Power Apps with a proper backend) when the workflow itself has ongoing value and deserves a supported home.

• Retain (temporarily) with added controls - backup, access restriction, documented ownership - when migration isn't yet feasible but the risk must be contained in the meantime.

• Retire under a controlled decommissioning process, with secure destruction and a retention check against the Records Management Code, when the database is genuinely redundant.

The discipline is to make each decision explicitly and record the rationale - so the choice is auditable and nobody is left wondering, two years on, why a database disappeared.

Where this fits in a cloud-first, FDP-ready future

It is tempting to treat Access remediation as housekeeping to be done "later." In practice it is a prerequisite. A cloud-first target architecture depends on knowing where your data actually lives. FDP onboarding depends on the quality and provenance of the data you feed it. EPR implementation surfaces exactly these shadow workflows as integration questions. Dealing with the Access estate early removes friction from all three - and shrinks your governance and security exposure at the same time.

A practical first step: five questions to scope the problem

You don't need a full programme to begin. You need an honest baseline. Ask your teams:

1. Where could Access databases be living? (Network shares, personal drives, department folders.)

2. Which ones hold patient-identifiable or special-category data?

3. For each, who is the named owner - and what happens if it stops working tomorrow?

4. Which feed, or duplicate, data that will eventually flow into FDP or the EPR?

5. Which have no backup, no access control, and no entry in any system inventory?

The answers will be uncomfortable. They will also give you, for the first time, a real sense of the size and shape of the risk - which is the only honest place to start.

At VE3, we help NHS acute trusts run exactly this kind of evidence-based discovery and risk-tiering across complex, fragmented data estates - combining automated scanning with structured clinical and operational engagement, so the resulting plan reflects reality rather than assumption. If you'd find a copy of our Access database risk-tiering checklist useful, get in touch.