How to switch care management systems without losing records

Switching care management systems without losing records comes down to three disciplines: get a complete, readable export from the old system before you do anything else; migrate only what staff need to deliver care today into the new one; and keep the full export as an archive you can search for the whole retention period. Homes lose records when they skip the first step, try to migrate everything in the second, or delete the old data before the third is in place. This guide sets out the order of work, the decisions at each stage, and how to handle the parts that carry the most risk, particularly medicines.

The short answer

Read your current contract for notice, export and deletion terms, then request a full export in an open format and open it without the supplier's software to prove it is complete. Decide, resident by resident, what is live (current care plan, risk assessments, medicines, capacity and DoLS records, the last few months of notes, open incidents) and migrate that into the new care management system, cleaned and checked. Everything else stays in the archive. Cut over module by module on a planned date, run paper or the old system in parallel for days rather than weeks, verify a sample of every record type afterwards, and only then let the old supplier delete. Tell families, professionals and commissioners what is happening and when. Keep the archive access-controlled, readable and indexed for the retention period.

At a glance: export, migrate or archive

The single most useful decision in a switch is which records go into the new system and which stay in the archive. The table gives the usual answer for each record type in a care home.

Why homes switch, and why it is worth doing properly

Homes change systems because the product does not fit the service, because the price rose, because the supplier's support faded, because a group standardised, or because the original choice was made by someone else. Whatever the reason, the fear of losing records keeps homes on systems they dislike for years, and that fear is reasonable: records are the evidence of care, the basis of regulation, and personal data you are legally responsible for. A switch done badly leaves gaps that inspectors find, medicines errors on cutover day, and a safeguarding enquiry that cannot be answered because the notes are in a format nobody can open.

Done properly, a switch is a records audit and a clean start. Every resident's plan is reviewed, every risk assessment rescored, every PRN protocol checked, and the archive is tidier than the live system ever was. The homes that come out well treat it as a quality project with a project plan, not an IT job.

The legal position on your records when you switch

Your organisation is the data controller for residents' and staff records; the software supplier, old and new, is a processor acting on your instructions. That means the records are yours, the old supplier must return or delete them at the end of the contract as the agreement provides, and the obligation to keep them for the retention period sits with you, not with either supplier. The NHS Records Management Code of Practice is the usual reference for how long adult social care records are kept, and your own records policy should state the periods you apply.

Two practical consequences. First, you must be able to respond to a subject access request, a safeguarding enquiry, a coroner or a CQC request for any record within the retention period, whichever system it was created in, so the archive has to be usable. Second, changing processors is a change in processing that should be reflected in your data protection impact assessment and privacy notice. Our guide to digital social care records covers the governance around the record in more detail.

Step one: read the contract you are leaving

Before you tell anyone, read the agreement with your current supplier. Find the notice period and how notice must be given. Find the clause on data return at termination: what format, at what cost, within what time, and how long the supplier keeps the data before deletion. Find any clause that restricts export during the term. Find the renewal date, because giving notice a week late can add a year.

Then write to the supplier giving notice in the form required and requesting a full export, quoting the clause. Do this early, because export can take weeks with some suppliers, and you want the data in hand before you are committed to a cutover date. If the contract is silent on export, UK GDPR still requires the processor to return the data, and a polite letter citing that usually works. Keep every message; if the supplier is slow, the record of your requests matters.

Step two: get the full export and prove it is complete

A full export means every record type, for every resident and member of staff, current and historical, including attachments and the audit trail, in a format you can open without the supplier's product. Spreadsheets, CSV files or JSON for structured data, PDF for documents, ordinary image files for photographs, with a clear folder structure and an index. Ask for a data dictionary explaining the fields.

Then test it. Pick three residents, one long-standing, one recent and one who has left, and try to reconstruct their record from the export alone: care plan history, every risk assessment version, every MAR chart for a chosen month, every incident, every note for a chosen week, every photograph. If anything is missing, go back to the supplier before you go further. Do the same for two members of staff. This step finds the problems while the old system is still running and can be fixed; skip it and you find them when a solicitor asks.

Step three: decide what is live and what is archive

The temptation is to migrate everything so nothing is lost. Resist it. Migrating years of daily notes into a new system costs weeks of cleaning, produces a cluttered record, and rarely helps care. What staff need on the new system is what they need to deliver care safely today: the current care plan, current risk assessments and PEEP, current medicines and PRN protocols, capacity and consent records and DoLS, the last one to three months of notes and charts so that patterns and recent changes are visible, and any open incident, safeguarding case or complaint.

The archive holds the rest, and nothing is lost because the archive is complete. The one exception some homes make is incidents and safeguarding, where a longer history migrated into the new system helps pattern analysis. Decide that with your safeguarding lead. Write the decision down as a migration policy so that every resident is handled the same way and so you can explain it to an inspector.

Step four: clean the data before it moves

Migration is the best chance you will ever have to fix the record. Every care plan that has drifted, every risk assessment that was not rescored after an incident, every PRN protocol that was never written, every allergy recorded in the wrong field surfaces now. Assign each resident to a named senior or nurse with a checklist: is the plan current and does it reflect the person; are all risks assessed and scored; do medicines match the latest pharmacy record; are capacity decisions specific and dated; is the DoLS authorisation current with conditions listed.

Correct what is wrong in the old system before export, or in the new system on entry, but record which. Do not migrate an inaccurate record and plan to fix it later; later rarely comes and the inaccuracy becomes the new baseline. This is also the moment to rewrite plans into the new system's structure rather than pasting them; a 24-section person-centred care plan looks different from a six-page document and the content should be organised for it, with the person and family involved where a review is due.

Step five: map the fields between systems

No two systems store information the same way. One holds allergies as free text; another as a coded list. One has a single care plan document; another has sections. One records a risk score out of 25; another uses low, medium and high. Before any data moves, produce a mapping document that lists every field you are migrating, where it comes from in the export, where it goes in the new system, and any transformation in between.

The new supplier will usually help with this and may have templates for common source systems. Where a field has no destination, decide whether it matters; where a destination has no source, decide who will fill it. Pay particular attention to dates (formats differ), to names (preferred names and legal names), and to anything that drives an alert in the new system, such as review dates and training expiries, because a wrong date there produces a wrong alert on day one.

Medicines: the migration that can hurt someone

Everything else in a switch is about evidence; medicines are about safety on the day. The current medicines list for every resident must be exactly right in the new eMAR before the first round, and the safest source is not the old system but the pharmacy. Ask the pharmacy for a current medication record for every resident, reconcile it against the old eMAR and the MAR charts in the cupboard, resolve every discrepancy with the GP, and enter or import the reconciled list into the new eMAR. Two people check every resident's entry against the pharmacy record and sign it.

Migrate PRN protocols, allergies, administration instructions such as crushing or thickening, and the controlled drug balances, with a physical count witnessed on cutover morning. Time the cutover to the start of a medicines cycle so that stock and records begin clean together. Print a paper MAR for every resident as a fallback for the first week. Our guide to eMAR versus paper MAR describes what the first round looks like and the errors to watch for; the same applies when moving between two electronic systems.

Care plans, risk assessments and capacity records

Care plans move as the current version for every resident, entered into the new structure by someone who knows the person, and reviewed as they go where a review is due. Risk assessments move as the current version, rescored in the new format if the scoring differs, and with the new version history starting from the migration date; the old versions live in the archive. PEEPs are checked against the fire risk assessment and the current room. Capacity assessments, best interests decisions, consent records and DoLS authorisations move in full, with conditions and expiry dates entered so that the new system's alerts work from day one.

Enter a migration note on each resident's record stating the date of migration, the source, who entered it and who checked it. That single line answers the inspector's question about why every plan carries the same start date, and it is the audit trail for the migration itself.

Daily notes, charts and the recent history

Bring across the last one to three months of daily notes and charts for each resident, enough that a new member of staff can see recent patterns, that fluid and weight trends continue, and that any change in the last quarter is visible. Older notes stay in the archive. If the new system can import notes with their original timestamps and authors, do so; if it can only import them as a document attached to the resident, that is acceptable provided the document is dated and clearly labelled as migrated history.

Charts that drive alerts, such as weights, repositioning and bowel records, need at least enough history for the new system's trend functions to work. From cutover, staff record only in the new system, using its daily logs, and the migrated history sits beneath as context. Do not let staff keep writing in the old system for comfort; the record splits and both halves become unreliable.

Incidents, safeguarding, complaints and HR

Open incidents, safeguarding cases and complaints migrate in full with their reviews and correspondence, because they must be worked in the new system. Closed ones from at least the last year should migrate too, so that trend reporting and the next inspection's questions about learning have data to work with. Some homes migrate the whole history for these record types; the volume is usually manageable and the value on inspection is high.

Staff records need their own handling. Current staff move with their personal details, right to work and DBS dates, training records and expiry dates, supervision and appraisal dates, and any live performance or absence matters. Leavers stay in the archive, subject to the different retention rules for employment records. Check every training expiry date after migration, because a wrong date produces either a false alert or, worse, a missed one. An HR and training matrix that flags expiries is only as good as the dates entered on migration day.

The cutover procedure

Cut over module by module rather than everything at once, with medicines last or first depending on risk, and each on a planned date with a named lead. The procedure below is for one module; repeat it for each.

1. Confirm the export for this record type has been received, opened and verified against the three test residents.
2. Complete data cleaning and field mapping and sign them off.
3. Load the live data into the new system in a test area and have two people check a sample of at least ten residents against the source.
4. Train every member of staff who will use the module, on shift, in the fortnight before, with champions on each shift.
5. Fix the cutover date and time, ideally the start of a shift on a quiet weekday, and for medicines the start of a cycle.
6. Freeze entry in the old system for that module at the cutover time and record the last entry made.
7. Go live in the new system with a champion and the migration lead present for the first shift, and print fallback templates in case of failure.
8. Within 48 hours, verify a sample of records entered since cutover and reconcile any entries made in the old system by mistake.

Running in parallel: days, not weeks

Some parallel running is sensible: for a few days after cutover, staff may need to look at the old system for something not migrated, and a senior should reconcile any stray entries. But recording in both systems at once, or keeping the old one live for weeks as a comfort blanket, splits the record and doubles the work. Staff will record in whichever is quicker, and neither will be complete.

Set a hard date, usually within a week of each module's cutover, after which the old system is read-only for everyone and only the manager and migration lead retain access. Then set a second date, after the full export has been re-verified and the archive is in place, when the old system access ends. Tell staff both dates in advance and hold to them.

Building an archive you can actually use

The archive is the full export, stored securely, indexed, access-controlled and readable without the old supplier's software. Store it on a UK-hosted, encrypted location with restricted access and a record of who accesses it. Keep the index as a simple spreadsheet listing each resident and staff member, the date range of their records, and the folder where they sit. Test the archive twice a year by retrieving a record at random and checking it opens.

If the old supplier offers a read-only archive service for a fee, weigh it against holding the export yourself; the export is essential either way, because the supplier may not exist for the whole retention period. When the retention period for a person's records ends, delete them from the archive and record the deletion. Records that must be kept longer, for example because of a safeguarding investigation or a legal claim, are flagged in the index.

Telling residents, families, professionals and commissioners

You do not need to notify CQC of a change of records system, but you do need to tell the people who will notice. Residents and families should get a short letter explaining that the home is changing its care record system, that their records are being transferred securely, that nothing will be lost, and who to ask about it; an easy-read version belongs in learning disability services. The GP practice, district nurses, pharmacy and any visiting professionals need to know the cutover dates, particularly for medicines, and what will change in how they receive information.

Commissioners appreciate a note, because a quality monitoring visit during cutover week is unhelpful for everyone. If you use NHSmail, GP Connect or a shared care record, check whether the switch affects those connections and arrange any changes in advance. Update the privacy notice and the DPIA to name the new processor.

Verifying after cutover and closing the project

Two weeks after the last module goes live, run a verification audit. For a sample of residents across every unit, check that the care plan is current and complete, every risk has an assessment, medicines match the pharmacy record, capacity and DoLS records are present with dates, recent notes are in the new system, and no one is still recording elsewhere. For staff, check training and supervision dates against source documents. Record the audit, the findings and the fixes.

Then close the project formally: confirm the archive is complete and tested, confirm the old supplier has deleted the data and obtained written confirmation, update the records policy and DSPT evidence, and write a one-page summary of what was migrated, what was archived, the dates and the checks. That page is what you hand an inspector who asks how the switch was managed. Our guide to where to start with care home software covers choosing the new system before any of this begins.

A switch checklist

• Contract read: notice period, export terms, deletion terms, renewal date.
• Notice given in the required form; export requested in writing.
• Full export received, opened without the old software, verified against test residents and staff.
• Migration policy written: what is live, what is archive, for each record type.
• Data cleaned resident by resident with named checkers and a checklist.
• Field mapping signed off, with dates and alert-driving fields double-checked.
• Medicines reconciled against the pharmacy record, controlled drugs counted with a witness, paper MAR fallback printed.
• Staff trained on shift with champions; cutover dates fixed and communicated.
• Old system frozen per module; read-only date and access-end date set.
• Families, professionals, pharmacy and commissioners informed; privacy notice and DPIA updated.
• Post-cutover verification audit done and recorded.
• Archive stored, indexed, access-controlled and tested; old supplier deletion confirmed in writing.

Common mistakes

• Giving notice before the export is in hand, then finding export is slow, incomplete or chargeable.
• Never opening the export, and discovering at a safeguarding enquiry that attachments were missing.
• Migrating every historical note and spending weeks cleaning data nobody will read.
• Pasting old care plans into the new structure instead of reviewing them.
• Building the new medicines list from the old system instead of the pharmacy record.
• Running both systems for a month and ending up with two incomplete records.
• Letting the old supplier delete before the archive is verified.
• Forgetting that training expiry and review dates drive alerts, and migrating them wrongly.

What good looks like on inspection day

Four months after the switch, the inspector notices that every care plan carries a start date in the same week and asks why. The manager explains the migration, opens a resident's record and shows the migration note with the date, source, entry and check signatures, and the plan review completed with the family in the same month. The inspector asks for a MAR chart from before the switch and the manager retrieves it from the indexed archive in two minutes, then shows the pharmacy reconciliation sheets from cutover day with two signatures per resident and the witnessed controlled drug count. They ask how the home knows nothing was lost and the manager produces the export verification for three test residents, the post-cutover audit with its findings and fixes, and the supplier's written confirmation of deletion. They ask a night carer where they would find something from last year and the carer says they would ask the senior, who has archive access, and that everything since March is in the new system. The migration summary is one page, and it answers every question before it is asked.

Final conclusion

Changing care management systems is safe when the order is right: export first and prove it, migrate only what is live and clean it as it moves, reconcile medicines with the pharmacy rather than the old software, cut over module by module with short parallel running, verify afterwards, and keep a tested archive for the whole retention period before anyone deletes anything. Treated as a records audit rather than an IT task, a switch leaves a home with better records than it had, and a one-page story that satisfies any inspector who asks.

Frequently asked

Do I have to migrate every historical record into a new care system?

No. Migrate what staff need to deliver care now: current care plans and risk assessments, medicines and PRN protocols, capacity and DoLS records, the last one to three months of notes, and open incidents and safeguarding cases. Keep the full export from the old system as a searchable archive for the retention period.

How do I get my data out of my current care software?

Read the contract for the export clause, then request a full export in writing in an open format such as CSV or JSON with documents as PDF and images as ordinary files. UK GDPR requires the processor to return your data. Open the export without the supplier's software and verify it against a few residents before giving notice.

How long should a care home run two systems in parallel?

Days, not weeks. Recording in both splits the record and doubles the work. Freeze the old system for each module at cutover, keep it read-only for a short period for reference, and end access once the archive is verified.

What is the safest way to move medicines records to a new eMAR?

Build the new medicines list from the pharmacy's current medication record, reconciled against the old system and the MAR charts, with discrepancies resolved with the GP. Have two people check every resident's entry, count controlled drugs with a witness on cutover morning, time the cutover to the start of a cycle and print a paper MAR fallback for the first week.

How long must a care home keep records after switching systems?

For the retention period in your records policy, with the NHS Records Management Code of Practice as the usual reference for adult social care. The obligation sits with you as data controller, not with either supplier. The archive must stay readable and retrievable for the whole period.

Do I need to tell CQC that I am changing care records system?

No notification is required for a change of records system. You should tell residents and families, the GP practice, pharmacy, visiting professionals and commissioners, and update your privacy notice and DPIA to name the new processor. Be ready to explain the migration to an inspector with a short written summary.

What should I check after the switch is complete?

Run a verification audit two weeks after the last module goes live: care plans current, every risk assessed, medicines matching the pharmacy record, capacity and DoLS dates present, recent notes in the new system, and staff training dates correct. Confirm the archive is complete and tested and get written confirmation of deletion from the old supplier.

Sources

• Information Commissioner's Office: UK GDPR guidance for organisations
• NHS England: Records Management Code of Practice
• Digital Care Hub: Data Security and Protection Toolkit guidance for adult social care
• NHS England: Digital Social Care Records programme guidance
• CQC: guidance on Regulation 17 Good governance
• NICE guideline NG67 Managing medicines in care homes
• Professional Record Standards Body: digital social care record standards