Veterinary Software Migration: A Readiness Checklist

Uploading a file to new veterinary software does not establish that your practice is ready to switch. Are patients linked to the correct owners? Do future appointments appear at the right time? Where will the team open documents that were not imported? A migration plan should give those questions testable answers.

This guide gives practice managers an acceptance checklist for changing systems. It makes scope and the go-live decision explicit, without assuming every record from every legacy system can be migrated automatically.

1. Inventory the data before choosing a date#

Ask the existing supplier what you can export, in which formats and under which permissions. Client and patient lists are separate data groups from clinical history, attachments or account balances. Assess each group independently.

Mark each row as migrate, retain in an accessible archive or decision pending. Do not hide the latter two states inside an impressive total record count. Use the software cost guide to account for work outside the quoted migration scope.

2. Preserve the source and transform a working copy#

Keep the original export under controlled access. Clean, map and transform a separate working copy, recording who changed what. Do not guess a missing or ambiguous value while normalising telephone or date fields.

A backup file and a tested recovery path are different things. The CISA ransomware guide recommends protecting critical backups and testing their availability and integrity in recovery scenarios. The principle applied here is to verify the fallback rather than closing the question with “we have a backup.”

Before sharing files with a migration provider, agree the approved transfer channel, authorised recipients and retention arrangements after the work. Do not paste real patient information into a public document or use it casually as a support example.

3. Test a small but varied sample#

Do not select only straightforward records. Include an owner with multiple pets, pets sharing a name, a missing field, accented characters and past and future dates. These are proposed test cases; authority to use actual data still needs to be established.

Keep source column, destination field, transformation rule and exception handling together in a mapping table. If a date format is ambiguous, do not silently interpret 03/04 from a country assumption. Confirm the source format before accepting that row.

The Vetigen migration page describes CSV and Excel uploads, field mapping, validation and background import for client, patient, appointment and vaccination data. Do not assume the same support for all clinical notes, attachments, balances or stock history. Confirm each data group separately.

4. Reconcile counts and relationships#

Do not require source and target counts to match blindly. An approved duplicate merge can reduce the target count, while rejected rows remain outstanding work. A reconciliation report should explain both.

Source rows = accepted rows + rejected rows + explicitly excluded rows. This is a proposed tracking classification. If records are merged or transformed into multiple destinations, keep a separate transformation map; the destination count alone cannot establish whether data was lost.

A correct count can still conceal a patient linked to the wrong owner. Open sample relationship chains: client, patient, appointment and relevant document. Compare future appointment times with the source. Report the sample's scope rather than presenting one correct example as proof that the entire file is correct.

5. Write the cutover and fallback decision first#

Define the final entry time in the old system, final export, verification owner and start of use in the new system. Include records added to the old system after the pilot; a successful test export is not necessarily the final dataset.

These are examples; your practice must define its own thresholds. Once new records exist in the destination, reverting may require more than reopening the original export. Assign a method and an owner for preserving intervening work and reconciling changes between systems.

Frequently asked questions#

Can everything in the old system be migrated?#

That depends on the available export, destination fields and agreed service scope. Before switching, establish an accessible archive or a separate solution for information that cannot be imported.

Is a successful upload the end of migration?#

No. Review validation results, rejected rows, relationships and daily workflows. File transfer success should not replace operational acceptance.

Can we close the old account immediately?#

Check access, exports, contractual terms and applicable retention requirements first. Do not schedule closure on the assumption that unverified archive needs will resolve themselves.

Rehearse the first working day#

Download the migration acceptance worksheet. Add evidence and a decision owner to every check. Use the patient intake guide to rehearse the first visit in the new system, and the data protection overview for broader access and archive considerations.

A blank tracking table is also included. Use record references; do not duplicate patient or client information in this working file.