The Real Cost of Delaying Your Goodbye to ESR Files (And Why You Must End It This Year)

The illusion of “cheap” ESR file integrations

ESR exports are still the backbone of NHS workforce operations—starters, leavers, position changes, cost centres, departments, and everything that feeds payroll/rostering and access workflows.

File-based integration looks “cheap” because:

• it’s familiar
• it already exists
• it doesn’t require API contracts
• and it can be pushed onto “the downstream systems”

But that’s exactly the trap. With CSV drops, the cost doesn’t disappear—it gets distributed across teams, vendors, and systems. And distributed cost is the hardest kind to see… until it becomes the norm.

1: You’re paying for the same integration many times

Every consumer of ESR files effectively builds their own integration:

• their own parser
• their own mapping rules
• their own validation logic (or none)
• their own scheduling assumptions
• their own “fixes” for missing data

That means you don’t have one ESR integration—you have many. And every time ESR changes, or a requirement changes, you pay again: rework, re-testing, re-coordination, re-bugfixing.

2: Late errors are the most expensive errors

In file flows, errors are often discovered:

• after import into downstream systems
• after payroll/rostering has already reacted
• after access workflows have already run
• after operational decisions were made

That’s not a data quality problem. That’s a timing problem. When validation happens late, the cost multiplies: manual cleanup, urgent fixes, reconciliations, “why doesn’t system A match system B?”, root cause investigations with 4 different owners.

3: Batch truth slows operations and creates shadow processes

CSV integrations are batch by default:

• nightly drops
• weekly extracts
• “manual run when someone remembers”

So your workforce processes become slow:

• starters appear late for rostering/bank workflows
• leavers don’t trigger timely access removal
• position changes land out-of-sync
• teams stop trusting data freshness

Then the shadow process arrives: spreadsheets to reconcile reality, manual chasing, side databases, “we’ll fix it in the next file.”

4: Security and compliance risk is quietly compounding

Files spread. They get copied:

• onto laptops
• into shared drives
• into vendor storage
• into email threads
• into “temporary” folders that live forever

Even when everyone is well-intentioned, file-based flows widen the attack surface and reduce traceability: who accessed what, where did it go, was it encrypted, was it retained too long?

5: Change becomes a permanent project pipeline

CSV flows turn change into coordination hell.

Because change is distributed:

• a “small mapping update” becomes a mini-project across multiple consumers
• each vendor has different timelines and interpretations
• testing is fragmented
• rollback plans don’t exist
• ownership is unclear

This creates a permanent pipeline of “integration projects” that never ends.

6: Vendor lock-in gets worse every year

Here’s the quiet problem with ESR CSV drops: your vendors become the integration owners.

If each downstream system has its own ESR feed and logic, you end up locked into their mapping definitions, their data assumptions, their “ESR truth”, and their release schedules.

Switching vendors becomes harder than it should be—not because of features, but because integration knowledge is trapped.

7: Workforce analytics become political (not factual)

When multiple systems ingest ESR differently, your reporting becomes inconsistent, debated, and slow to reconcile.

You end up with meetings where the key question is: “Which number is right?”

And the answer is usually: “It depends which system you ask.”

What “ending ESR files” actually means (realistic approach)

This doesn’t mean ESR magically becomes API-native overnight.

It means:

• ESR exports can still exist as the ingestion method
• but nobody downstream consumes raw CSV anymore

Instead:

• ingest ESR files centrally
• validate + normalise
• apply rules and integrity checks
• publish stable APIs and events
• log everything (audit trail)

So operational systems and vendors connect to one governed surface—and file chaos stops spreading.

A simple roadmap you can execute this year

Phase 1 (Weeks 1–2): Stop the bleeding

• inventory who consumes ESR files today
• identify duplicated feeds and broken mappings
• define 2–3 high-frequency use cases (starters, leavers, position changes)

Phase 2 (Weeks 3–6): Centralise ingestion + validation

• ingest ESR exports into a controlled workflow
• standardise parsing and schemas
• add validation + exception handling
• create an audit trail (file → record → output)

Phase 3 (Weeks 7–10): Publish the first APIs

• expose key resources as REST APIs (and optionally events)
• pick one downstream consumer to migrate first
• measure reduction in manual fixes and reconciliation time

Phase 4 (Weeks 11–12): Scale repeatably

• turn the flow into reusable templates
• onboard the next consumer
• retire the raw file dependencies one by one

The bottom line

Delaying your goodbye to ESR files isn’t neutral.

It’s a decision to keep paying:

• duplicated integrations
• late, expensive errors
• slow batch operations
• growing security risk
• endless change projects
• deeper vendor lock-in
• and inconsistent reporting

Ending ESR file dependency this year doesn’t require a miracle. It requires one governed layer: ESR exports in → clean APIs/events out with shared rules, validation, and audit.