PMR Migration Without the Horror Stories: Planning a Clean Switchover

Why do PMR migrations go wrong?

PMR migrations go wrong for four predictable reasons: prescriptions left open in the outgoing system, dispensing history that transfers more shallowly than anyone expected, workflow records that have no equivalent in the new system and contract terms that nobody re-read before serving notice. Almost every migration horror story in the sector traces back to one of these, and all four are preventable with preparation rather than technical skill.

The fear is real and it keeps pharmacies on systems they have outgrown. Ask owners why they have not switched and data migration is routinely the first answer, ahead of cost and ahead of training. That fear is rational only if you approach the switchover unprepared. The failure modes are known, documented by the suppliers themselves and avoidable, which is what the rest of this guide is for.

One framing point before the detail. The Electronic Prescription Service (EPS) does not migrate in the way people imagine. Your new system connects to the NHS Spine in its own right; what moves between systems is your local record of patients, medication history and workflow. The risk is not that EPS breaks nationally. The risk is what falls down the gap between two local databases during the handover, which is a gap you control.

What data actually transfers when you switch PMR systems?

A standard PMR migration transfers patient demographics, medication history, prescriber and surgery details, exemption information and repeat information, and the Community Pharmacy IT Group (CP ITG) publishes a minimum transfer dataset specification that suppliers use as the reference for pharmacy-to-pharmacy system transfers. Community Pharmacy England (CPE) hosts this specification within its guidance on choosing and changing a system supplier, and it is the document to name when you ask both suppliers what will move.

The word minimum is doing important work in that sentence. Three limitations catch pharmacies out repeatedly:

History windows. Suppliers commonly convert a defined window of dispensing history rather than the full archive, and a six-month default is typical, meaning patients with no dispensing or service activity inside the window may not be included in the conversion at all. Longer windows are usually available on request, sometimes at a price, but you must ask before the extraction is run, not after.

Workflow records rarely move. Open owings, uncollected items, pending orders, monitored dosage system (MDS) configurations, care home round setups, patient notes held in free-text fields and interventions logged against dispensings frequently have no mapping into the new system. Assume workflow state does not transfer and plan to close it out or rebuild it, then treat anything better as a bonus.

Incomplete electronic prescriptions do not transfer. Supplier migration documentation is explicit that EPS prescriptions not yet claimed or returned in the outgoing system will not move to the new one. An unclaimed prescription at cutover is unclaimed revenue and an unfinished patient record simultaneously, which is why the pre-migration housekeeping below is not optional.

Ask both suppliers for a written statement of exactly which fields and record types will transfer, against the CP ITG dataset, and treat any answer given verbally as an answer not given. The criteria for judging the receiving system itself are covered in our companion guide to choosing a PMR in 2026.

What must you do before migration day?

Before migration day you must bring the outgoing system to a clean state: every EPS prescription claimed or returned, owings resolved or documented, instalments marked, the problems queue emptied and a verified backup taken. This housekeeping is the single biggest determinant of a clean switchover, and it is dispensary work, not IT work, which means it needs to start two to three weeks out rather than the night before.

The second item deserving emphasis from experience is training locums. The migration weekend is exactly when a regular pharmacist takes leave, and a locum meeting the new system cold on the first Monday is how dispensing slows to a crawl. Book your regulars onto the training and confirm cover in advance; the staffing logic is the same as in our guide to new staff onboarding in a dispensing pharmacy.

How long does a PMR switchover take?

From decision to steady state, a realistic PMR switchover takes eight to twelve weeks, of which the cutover itself is one to two days. The elapsed time is governed by contract notice periods, supplier scheduling and service reconfiguration lead times rather than by the data transfer, which is why starting the clock early costs nothing and compressing the end costs plenty.

The date matters more than people admit. Do not cut over in the last week of the month when MDS trays are due, do not cut over the week a GPhC inspection is booked and do not cut over during your strongest trading period. A midweek closure day or your quietest weekend, with the following week deliberately understaffed with appointments and overstaffed with people, is the pattern that works.

What are your legal duties to the data in the old system?

Switching PMR systems does not end your legal duties to the records the old system holds: you remain the data controller for every record in it, and pharmacy record retention requirements continue to apply regardless of which supplier's database the records sit in. This is the part of migration planning that owners most often skip, and it is the part with regulatory consequences.

The retention baseline, per Specialist Pharmacy Service (SPS) guidance on pharmacy record keeping: records of private prescriptions must be kept for two years under regulation 253(5) of the Human Medicines Regulations 2012, controlled drug registers must be retained for two years from the date of the last entry and electronic patient records are in practice retained indefinitely, with SPS noting that where a system is decommissioned the records and audit trails should be retained for the retention period of the last relevant entry. Your PMR contains records at every one of these tiers.

So before you sign anything, answer three questions in writing:

1. How will you access old records after cutover? The clean answers are a read-only licence on the outgoing system for an agreed period, or a complete structured export you can actually open.
2. What does the outgoing contract say about your data at exit? Data export fees, deletion timescales and format commitments belong in the exit terms. Under UK GDPR you are the controller and the supplier is your processor, so their obligations to return or delete data at contract end should already be in your data processing agreement, which is one of the six supplier questions covered in our patient data security briefing for pharmacy owners.
3. Who is responsible for the archive? Name a person, usually the superintendent, who owns the old-system archive, knows where the export lives, and can produce a record within a working day if the General Pharmaceutical Council (GPhC), an NHS auditor or a patient subject access request asks for it.

How should you run the cutover weekend?

Run the cutover as a checklist exercise with named owners, a verification step before the doors open and a rollback decision point, not as a day when the engineer turns up and everyone hopes. The technical work belongs to the suppliers; the verification belongs to you.

Before extraction: final EPS sweep confirmed clean, instalments marked, backup taken and verified, reference reports printed. The pharmacist in charge signs off each item. Ten minutes of discipline here beats ten days of reconstruction later.

After installation, before go-live: run your own verification against the reference reports. Pick twenty patients deliberately, not randomly: your most complex MDS patient, a care home resident, a patient with a long repeat list, a patient with recent owings, a private prescription patient. Check demographics, history depth and repeats for each. Print a label, scan a barcode, send a test EPS claim. Confirm smartcards work at every terminal.

The rollback question: agree in advance what failure looks like and what happens next. If verification fails badly, the correct move is usually to delay go-live and keep dispensing on the old system, which is only possible if the old system is still alive, which is why you never let the outgoing supplier switch anything off until you have signed off the new one.

The first Monday: overstaff it, keep appointments light, keep the reference reports on the bench and log every discrepancy in one place rather than fixing things silently. A pattern in the log on Tuesday, for instance owings missing across the board, gets escalated to the supplier as one systemic issue instead of forty anecdotes.

What should you ask both suppliers before you commit?

Before you commit, get written answers from the incoming supplier on scope and support, and from the outgoing supplier on exit terms, because the quality of a migration is decided in these two conversations rather than on the weekend itself.

For the incoming supplier: exactly which record types and fields transfer, judged against the CP ITG minimum dataset; the history window and the cost of extending it; who performs verification and against what; what on-site and remote support is provided at cutover and for how long afterwards; the training included per staff member; and lead times for every integration you rely on, from Pharmacy First referrals to delivery apps to your website. If the system is clinical software, the supplier's clinical safety documentation under DCB0129 should be part of the same due diligence, covered in our guide to DCB0129 for pharmacy software buyers.

For the outgoing supplier: the notice period and any exit fee; the format, completeness and cost of the final data export; how long read-only access can be retained and at what price; and written confirmation of what happens to your data on their servers after termination, which their obligations as your processor under UK GDPR should already govern.

A supplier who answers these questions slowly before the sale will not answer them faster afterwards. Treat the quality of the pre-sale answers as your best evidence of migration-weekend behaviour.

Key takeaways

FAQs