What to check before moving a veterinary practice from server software to the cloud

Diagnostic equipment. Shared folders. Label printers, card terminals, accounting links and local backups. In a server-based practice, any of these may depend on the same infrastructure that runs the practice management system (PIMS).

Moving the PIMS to the cloud does not move those dependencies with it. Before the old server can be retired, each one needs a replacement, a new connection route or a planned end date.

Whether to move at all is covered in server-based or cloud: what your PIMS choice means. The wider migration process, including cutover, training and go-live support, is covered in how to switch veterinary PIMS without disrupting your practice. This guide sits between the two. It covers what a practice needs to identify, extract, retain and replace before a legacy server can be switched off safely.

Audit everything that depends on the server

Start by listing every device, folder and piece of software that connects to the server. Staff who use each system day to day will often know about connections that are not written down anywhere.

Things to check include:

• In-house lab analyzers that send results into the patient record
• Digital radiography, ultrasound or other imaging, including where the images are stored
• Label printers, receipt printers and card terminals
• Shared folders holding scanned consent forms, referral letters and other documents
• Accounting or payroll software that syncs with the PIMS
• Local backup drives or scheduled backup jobs

For each item, record the make, model and firmware version where relevant, and how it connects today. Then ask the new vendor, in writing and device by device, how it will connect after the move. Some devices connect to cloud software directly. Others need a small local bridge or agent installed on a practice computer. Some older equipment may not connect at all.

Where a bridge is needed, confirm who installs it, who supports it, and whether the device keeps working during an internet outage. A general assurance that integrations are supported does not confirm that a specific analyzer will work on the first day.

Agree exactly what data will move

With a legacy server-based system, practice data may sit on local hardware. The practice may still depend on the software vendor to extract it in a usable format. Export rights, fees and formats can depend on the contract. Check the current agreement for notice periods and export terms before giving notice.

The American Veterinary Medical Association's principles on veterinary data ownership and stewardship state that practice data should be portable and accessible. That is professional guidance rather than law, and it does not override contract terms, but it is a reasonable reference point in an export discussion.

When agreeing migration scope with the new vendor, ask whether it covers:

• Archived and inactive clients, as well as active ones
• Invoices, payments and outstanding balances, not only clinical notes
• Attachments, lab results and images stored against the record
• Vaccination history and reminder schedules
• Controlled substance records

Ask how the vendor validates the migration and what reconciliation evidence the practice will see before go-live. The broader validation process is covered in the switching guide linked above.

Plan access to anything that will not move

Some historical data may not migrate, either by choice or because the old format cannot be converted cleanly. The practice still needs to be able to reach it.

Veterinary medical record retention periods vary by state. Before retiring the old system, confirm the period that applies in your jurisdiction with your state veterinary medical board. The AVMA maintains a reference list of state retention rules that can be a starting point. Federal regulations also require controlled substance inventories and records to be kept and available for inspection for at least two years, and state law may add further requirements.

There are a few ways to keep that access:

• Keep the old system running in read-only mode for a set period
• Use a hosted or archival read-only service from the old vendor, if one is offered
• Export the remaining records to a documented, searchable format the practice controls

For each option, confirm what it costs, how long it is available, and who keeps it patched and backed up. If the old vendor provides archival access, ask what happens if that service is later withdrawn.

Prepare the network and an outage plan

Many server-based practices already rely on the internet for payments, laboratory services and client communications. Moving the PIMS itself to the cloud makes internet availability a direct dependency for core practice management as well.

Before go-live, check the reliability of the current connection at busy times. Consider a failover connection, such as a mobile data router that switches on automatically if the main line drops, and test it. Check Wi-Fi coverage in consult rooms, prep areas and kennels, since staff may work from more locations than before.

Ask the vendor what the system does during an outage. Some systems allow limited offline working and sync once the connection returns. Others do not. Either way, document a short fallback procedure for bookings and charges, and make sure the team knows where it is.

Set up identity and security before go-live

The security model changes when the PIMS moves off a local server. Physical access to the server matters less. Identity, device and vendor controls matter more.

Before go-live, set up an individual account for every staff member and retire shared logins. Turn on multi-factor authentication if the system supports it. Configure role-based permissions so each role sees what it needs. Agree a leaver process so access is removed on a person's last day.

On the vendor side, a current SOC 2 report is one common reference point. Ask beyond the badge as well. Which systems does the audit cover, and when did it take place? Does the vendor run penetration testing? How are incidents handled, and how do backup and recovery work? Where is data hosted, and which sub-processors can access it?

Decide how the old server will be retired

Once historical access is settled and the new system is running, the old hardware can be decommissioned. Take a final full backup first and store it securely, in line with whatever retention plan the practice has agreed.

Deleting files does not remove data from a disk. The National Institute of Standards and Technology (NIST) publishes current guidance, SP 800-88 Rev. 2, on building a media sanitisation and disposal process based on the sensitivity of the data and the type of storage. It points organizations to recognized sanitisation standards and techniques rather than treating file deletion as enough.

Choose a clear, purge or destruction approach suited to the storage medium and the risk involved, and document what was done. If a third party handles disposal, obtain written evidence of the sanitisation or destruction carried out.

Server retirement checklist

• Every server-dependent device and system identified
• Integration route confirmed in writing for each device
• Owner named for any local bridge or agent
• Export scope agreed in writing with both vendors
• Retention periods mapped to state and federal rules
• Read-only or archival access to unmigrated records agreed and costed
• Termination date agreed for any legacy software license or archival access
• Internet failover installed and tested
• Outage fallback procedure written and shared
• Individual accounts, multi-factor authentication and permissions configured
• Final data freeze and export time agreed
• Final server backup taken and stored securely
• Sanitisation or disposal method chosen and documented
• Named owner for every unresolved item

How Lupa handles a move from server software

Lupa is cloud-based, with nothing installed on a practice server. For practices moving from an existing system, Lupa runs automated and manual checks comparing migrated data against the previous system before go-live, and the migration covers clinical and financial history, including invoices, payments and health plan sign-ups. The migration team works to a timeline agreed during scoping, is on site around go-live, and provides structured support in the weeks afterwards. Lupa is SOC 2 Type 2 certified, with data encrypted in transit and at rest, and makes its security documentation available through its trust center.

To see how Lupa handles migration from a server-based system, book a demo.