Replacing an EMR is, for most hospitals, a once-in-five-to-ten-years undertaking: requirements, feature comparison, price negotiation, migration, go-live. The project management gets endless attention. From a security standpoint, though, this period is far more dangerous than normal operation.
The reason is simple. Things happen during migration that never happen otherwise. The entire patient database is extracted at once and travels on external media. Engineers from a migration contractor, never normally on site, touch production data. Two systems run at the same time and permissions are managed twice. And at the end, the old server and old media — still full of patient data — sit in a corner of the building.
All of this tends to be waved through as "unavoidable during migration." But what you fix as a requirement during the migration determines the security level of the next decade. This article works through three phases — extraction, parallel running, and disposal. For the technical practice of migration itself, see The EMR Data Migration Guide; for procurement requirements generally, Putting Security into Your Procurement Requirements.
Disclaimer: This article is general information. Retention obligations and the treatment of external storage are governed by the relevant statutes and MHLW notifications and guidelines. Consult counsel on contract terms.
What Changes During Migration
| Aspect | Normal operation | Migration | Resulting risk |
|---|---|---|---|
| Data scope | Staff open individual patients as needed | Every record of every patient is extracted at once | One incident affects the entire patient population |
| Data location | Inside the production system | Extract files, external media, the contractor's workspace | Location fragments and stops being traceable |
| Who has access | Hospital staff | Plus migration contractor and both vendors' engineers | Temporary accounts survive |
| Permissions | One system | Two systems in parallel | One of them gets deprioritised |
| Verification | — | Display checks performed on real data | Production data lands in a test environment |
| At the end | — | Old servers and media remain | They sit in the building undisposed |
"One incident affects the entire patient population" is the essence of it. A breach in normal operation is usually confined to particular patients or a department. A migration-phase breach has a total scope. The same level of care does not balance the same risk.
Phase 1: Extracting the Data
| Requirement | What to settle |
|---|---|
| Where extracts live | On a hospital server, on encrypted media, or in the contractor's environment |
| Encryption | Encryption of extract files and transport media; key handover on a separate channel |
| Transport | Hand delivery, locked case, courier — and if courier, tracking and receipt confirmation |
| Named workers | Require the names and employers of engineers on the migration in advance |
| Work location | On site only, or is removal to the contractor's environment permitted |
| Work logs | Date, time and operator for each extraction, conversion and load |
| Intermediate files | When conversion artefacts and verification copies are deleted |
| Proof of deletion | Deletion of data remaining in the contractor's environment after completion, evidenced |
The item that slips most often is deletion of intermediate files. Migration generates extracted CSVs, conversion script output, error-checking excerpts, verification samples — scattered across engineers' laptops and file shares, and unmanaged the moment the project closes. Put this in the contract: "Within 30 days of migration completion, delete the extracted data and all intermediate files generated during the work, and report completion of deletion in writing."
Naming the workers matters too. Migration falls in busy periods, so vendors bring in additional or partner-company engineers. That is unavoidable, but the ability to record who touched production data should be preserved. Require a roster in advance and notification of changes. See Supply Chain Risk for Hospitals and Questions to Ask Your Vendor. ISO/IEC 27001 is the framework by which a migration contractor evidences to a third party how it manages its own people and subcontractors — see What Is an ISMS? for how to read certification and its scope.
Real data in the verification environment
Verification often only means something with real data. Mangled characters in names, long diagnosis strings truncated, input habits peculiar to the old system — none of these appear in synthetic data.
Yet verification environments are almost never managed to production standards. That is the classic migration hole. A workable compromise:
- Place the verification environment under production-equivalent controls — network separation, restricted access, logging
- Narrow the verification data by period, department and record count
- Delete the verification data immediately on completion, and record the deletion
- Grant access to named individuals only, and remove it when they finish
Note that "just anonymise it" often fails here: checking that names and diagnoses render correctly makes that very data the object of the test. Narrowing the period, keeping it controlled, and deleting it fast is more realistic than anonymisation.
Phase 2: Running Old and New in Parallel
| Issue | What happens | What to do |
|---|---|---|
| Two permission sets | All attention goes to the new system; the old one's permissions are left alone | Review the old system's permissions at parallel-run start, including leaver accounts |
| Maintenance ends | An out-of-support old system stays on the network | Check nothing unpatched remains connected |
| "Read-only" in name only | Declared read-only, but write permissions remain | Confirm writes are blocked by configuration, not just by instruction |
| Network exposure | The old system stays more connected than it needs to be | Narrow connectivity to what reference requires; consider physical disconnection |
| Logging stops | Logging on the old system is switched off, so reads leave no trace | Keep logging running through the parallel period |
| Deciding to stop | Parallel running drifts and the old system survives for years | Fix an end date in the plan and contract; make extension an exception |
The end date is the real problem. Three months is planned, then clinicians keep asking to see records from that period, and it stretches. The stretched old system loses its maintenance contract, stops receiving patches, and stays connected with nobody managing it.
A recurring structure in published breach cases is exactly that: a poorly-attended device or system as the entry point. Extending parallel running manufactures that structure.
Two remedies. First, set the end date during planning and require internal approval for any extension. Second, include in the migration requirements a means of retaining the data people need to look up, inside the new system or in another format — which removes the reason to keep the old system at all. See Network Segmentation and Asset Management.
Phase 3: Disposing of the Old System and Media
What remains at the end of the project is an old server, old endpoints and backup media, all still holding patient data — and the attention of everyone involved has moved on. This is the phase most often left undone.
| Item | What to verify |
|---|---|
| Old servers | Disk erasure or physical destruction; method and certificate received |
| Old endpoints | Collection of ageing devices around the building; any extracts held locally |
| Backup media | Tape, RDX, external drives collected and disposed of — every generation |
| Portable media | USB drives and external disks used during migration, collected |
| Paper | Patient lists and error reports printed during the work, shredded |
| Contractor environment | Deletion of extracts and verification data held by the contractor, evidenced |
| Cloud | If the old system was cloud-hosted, the completion date including backup generations |
Three practical points.
1. Require evidence of erasure, not just of disposal. Where disposal is outsourced, obtain separate proof of erasure or destruction for storage media. A waste manifest evidences disposal of waste, not deletion of data.
2. Manage "collected" and "erased" as separate states. Collected media stacked in a store room for months is a common sight. Track both stages in a register with their own completion dates.
3. Build the media register before migration starts. Trying to compile it at disposal time means nobody can remember what was where. List every device and medium connected to the old system before the migration begins. See Managing USB and Portable Media.
Turning This into Contract Terms
Note that migration is usually a separate contract from maintenance, so these terms belong in the migration contract.
| Stage | What to write |
|---|---|
| Planning | Roster of migration workers, work location, capture and submission of work logs |
| Extraction and transport | Encryption method, transport method, key handover channel |
| Verification | Control level of the verification environment, data scope, deletion deadline |
| Parallel running | End date, method of making the old system read-only, continued logging |
| Completion | Deletion deadline and report for intermediate files, proof of deletion in the contractor's environment |
| Disposal | Erasure/destruction method, certificates, the list of items to collect |
Getting data out of the outgoing vendor turns on return format and cost. Proprietary-only export, or an expensive extraction job, cannot be solved in the weeks before a replacement. Making "must be exportable in a standard format" a requirement at initial purchase is what makes the next replacement bearable. See Questions to Ask Your Vendor and Selecting a Cloud Provider.
If you are using the replacement to reset your security posture, it is sensible to fold the criteria of the FY2026 electronic clinical information coordination system development addition into the requirements for the new system. Backups by multiple methods with part held offline, and a BCP with exercises, both depend on how the system is built. See Backup Design for Hospitals: the 3-2-1 Rule, A BCP for Cyberattacks, and The FY2026 Fee Revision.
Conclusion
- Migration is the window in which the whole patient database moves at once — the blast radius of one incident is orders of magnitude larger
- In extraction, deletion of intermediate files is what gets missed; put a deadline and a written report in the contract
- Verify with a narrowed data set under production-equivalent control, deleted immediately — anonymisation rarely works for migration verification
- Fix the parallel-running end date during planning. An abandoned extended old system as an entry point is a repeatedly documented pattern
- Track collection and erasure separately, and obtain proof of erasure. A waste manifest is not proof of deletion
- Build the media register before migration starts; compiled at disposal time, it will be incomplete
- Migration is usually a separate contract — write the requirements into that one
Replacement projects routinely run more than a year from requirements to go-live. Adding security requirements late means reopening cost and schedule. To get them settled at requirements stage, contact us.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Guidelines, edition 6.0 (PDF) | MHLW
- FY2026 Fee Revision | MHLW
- Information-technology Promotion Agency (IPA)
- Personal Information Protection Commission
Note: guideline requirements and fee criteria change with revisions and official Q&A; the effect of contract terms depends on applicable law and the individual agreement. Check the latest published material.