The Practice Software Portability Record

The Practice Software Portability Record

Version 1.0 | October 2026

Published by VetSoftwareHub.com, in The Veterinary Software Insider, Issue 32. Free to use, adapt, and fork under the same open license as the Veterinary Software Buyer's Addendum v1.0. No email wall.

What this is

A practice manager can hand this page to a software vendor, a consultant, or a buying group, and say: this is what we expect to be able to take with us, and what we expect to be told before we start.

It assembles the work of Issues 21 through 31 of The Veterinary Software Insider into six parts. Each part names what a practice is owed, what a practice should hold, and what a practice should ask for in writing. Every item points back to the issue that argued it, so anyone can read the reasoning behind a line before deciding whether to push on it.

It is not legal advice. It is not a mandate, and nothing in it binds a vendor who does not sign. It is a common reference, and its value comes from being common: a vendor that sees the same page from forty practices is looking at a market, and a vendor that sees a custom redline from one practice is looking at a nuisance.

How to use it

Attach it to the order form, the same way the Buyer's Addendum is attached. Do not redline the vendor's paper. Add this page beside it and cite the version number. A sentence that reads "we sign version 1.0 of the published record" is harder to argue with than a sentence that reads "my consultant wants this."

If you can only get three items, get R1.1 (a dated, priced export), R4.1 (ninety days of read only access, priced today), and R5.5 (a named consultant and a written handoff). Everything else improves a deal. These three protect you from the three most common ways a practice ends up paying twice.

Part 1. Your records

From Issues 18, 21, 22, 23 and the Addendum in Issue 24.

R1.1 The export right. On written request, the vendor delivers a complete copy of practice data within fifteen business days, in a documented, machine readable format, with a current data dictionary and with attachments in their native file formats. Two requests per year at no charge. A pending request suspends any retention or deletion clock until delivery.

R1.2 The five layers. "Practice data" means clinical records, client and patient demographics, financial history, attachments, and communications. If a layer is missing from an export, the export is incomplete.

R1.3 Attachments are files. Images, PDFs, lab reports, and scans arrive as files a practice can open without the old vendor's server. A link to a server that will stop existing is not a delivery.

R1.4 The shape of exchange. Data that moves between systems carries six things at minimum: an envelope that says who sent it, from which system and version, on whose authority, and when; the patient; the client and what they have authorized; current medications and allergies; problems and results as discrete values with units; and references to documents and imaging that work without a portal account. Every coded value travels as three things: the code, the system it came from, and the original text exactly as entered. Units of measure are never optional.

R1.5 Claims you can check. The vendor publishes a capability statement at a stable address naming the interfaces, export formats, and specification versions the product supports. Any claim of conformance to a published specification can be verified by a public test that the buyer can run against their own system.

R1.6 Run the door quarterly. The practice exercises its self serve export once a quarter and keeps the result. A right that has never been used is a rumor.

R1.7 Referrals move as data. A receiving hospital can state the minimum it needs in a referral packet, and the sending practice's system can be asked to deliver that minimum as structured data rather than as a PDF to be re-keyed on arrival.

Part 2. Your half of the database

From Issue 29.

The configuration layer is everything the practice built inside the vendor's product: the item catalog, reminder logic, templates, appointment types, estimate and treatment plan templates, roles and permissions, canned text, and operational rules. It is not in any export today. This part says what a practice should hold anyway.

R2.1 Keep a current profile. The practice maintains a plain language description of its configuration in six sections:

1. The item catalog with intent: code, name, price, tax treatment, bundle contents, reminder triggers, inventory effect, a category, and a notes column for items that are not what they look like.
2. Reminder intents: what each is for, the trigger, the interval, the channel and fallbacks, the repeat behavior, and the suppression conditions, written as intent and never as implementation.
3. Templates as content plus named insertion points, using plain names for the fields rather than any vendor's internal names.
4. Appointment types and schedule structure: duration, resource, provider eligibility, blocking rules, and the shape of a normal day.
5. Roles as capability lists in plain language.
6. The exception list: everything deliberately unusual, written for a stranger, with the reason.

R2.2 Legible, not executable. The profile is for people. It does not need to import into anything. Its job is to cut the discovery weeks of the next implementation, and to survive the departure of whoever knows why the reminder fires at fourteen months.

R2.3 Refresh yearly. Once a year, someone walks the catalog and the reminder list with the people who use them and retires what is dead.

R2.4 The vendor delivers its half. On request, and at project close, the vendor delivers the practice's configuration in a documented, human readable form covering the six sections above. Executable import files are not required. (Proposed Addendum clause 6.1, below.)

Part 3. What the move made

From Issue 28.

A migration produces seven artifacts, and two years later most practices hold none of them.

R3.1 The seven. The mapping table, in three columns: what it was, what it became, and why. The cleaned catalog and its decision log. The client and patient reconciliation rules. The written procedures. The validated export and its validation results. The integration inventory, with named contacts. The exception log, covering what did not come across, what was re-keyed, and what was left behind on purpose.

R3.2 Put it in the statement of work. The implementation statement of work names five deliverables, in named formats, due within thirty days of go live, as a condition of final milestone sign off: the final mapping table as data, the catalog decision log, the reconciliation rules in plain language, the integration inventory, and the exception log.

R3.3 Ownership in one sentence. The practice owns all configuration and mapping documentation describing its own data and operations, and receives a copy in a machine readable format at project close.

R3.4 Keep it somewhere that is not a laptop. Store the seven in a place the practice controls, with a named owner, before the consultant who made them moves on.

Part 4. The paper

From Issues 24 and 25.

The Buyer's Addendum v1.0 carries twelve clauses in five families. They are reproduced here by name. The full text, with annotations and the attorney cover note, is at https://www.vetsoftwarehub.com/addendum.

R4.1 Clause 4.1, the read only window: ninety days of read only access to your data after termination, attachments included, for a flat fee stated in the order form today.

R4.2 Clauses 1.1 to 1.4, the way out: the export right, the standing export, the definition of practice data, and the data use boundary.

R4.3 Clauses 2.1 and 2.2, prove it: read access to your own data without a toll, and a public capability statement.

R4.4 Clauses 3.1 and 3.2, who pays for the mess: two test migrations with written acceptance criteria before go live, and the outgoing vendor's cooperation at a published rate.

R4.5 Clauses 5.1 to 5.3, the calendar and the sale: a renewal notice one hundred twenty days out with the price stated, an escalator cap that is a formula rather than "then current list," and continuity if the vendor is acquired or the product is discontinued.

R4.6 Two dates on the calendar. The renewal date and the notice window, with a reminder one hundred eighty days ahead, for every agreement the practice holds. Leverage is a calendar.

Part 5. The project

From Issues 30 and 31, with the continuity clause written out in Issue 32.

R5.1 Split the quote. The implementation timeline is stated as discovery weeks, the time spent learning how the hospital operates today, and build weeks, the time spent making the new system do it.

R5.2 Name one decider. Before kickoff, and in front of the team, the practice names the person with authority to end an argument about an estimate template, and says it will back their decisions.

R5.3 Quote the stabilization period. The vendor states the post go live period of reduced throughput that its other customers typically report. If the vendor has never measured it, that is an answer.

R5.4 Show the distribution. On request, the vendor provides the elapsed weeks from kickoff to go live for its most recent twenty comparable implementations, as a median and a range.

R5.5 Name the person. The statement of work names the primary implementation consultant, how long they have held the role, and how many projects they carry at kickoff. If that person changes before go live, the vendor gives written notice within five business days, delivers a written handoff covering decisions made, decisions still open, exceptions logged, and contacts, before the replacement's first call, and holds one transition call with both consultants present where the departing consultant is still employed. If the change delays the project, the go live date and any payment date tied to it move by the same number of weeks, with no added fee. (Proposed Addendum clause 6.3, below.)

R5.6 An accelerated track with a stated precondition. A practice that arrives with a clean catalog, a written exception list, and one empowered decider is quoted a shorter timeline, in writing, with the precondition stated.

Part 6. Your number

From Issue 26.

R6.1 Price all six components. Data, integrations, process, people, revenue, and the contract. A quote that covers the license difference and the implementation fee covers part of one component. Price the rest before signing.

R6.2 Six moves that cut it in half. Get the export priced, dated, and exercised once. Write down the four or five highest volume workflows. Audit custom fields and item codes once a year. Prefer integrations built on documented interfaces. Get one real quote from an alternative every renewal cycle. Put the renewal date and the notice window on the calendar.

Proposed additions to the Buyer's Addendum (v1.1 draft)

These three clauses were promised in Issues 29, 30, and 31 and are written out here together for the first time. They are drafts for counsel to read, not final text.

Clause 6.1, configuration documentation. At project close, and once per year on written request, the vendor delivers the practice's configuration in a documented, human readable format covering, at minimum: item catalog and attributes; reminder rules stated by trigger, interval, channel, and suppression condition; document templates with named insertion points; appointment types; roles stated as capabilities; and any exception notes the practice has recorded in the system. Delivery is within fifteen business days of request. The first request in each year is at no charge. The vendor is not required to deliver executable import files.

Clause 6.2, implementation transparency. The implementation statement of work states the timeline as discovery weeks and build weeks separately, states the post go live stabilization period reported by the vendor's other customers of comparable size, and on request provides the median and range of elapsed weeks from kickoff to go live for the vendor's twenty most recent comparable implementations.

Clause 6.3, personnel continuity. The statement of work names the primary implementation consultant, that consultant's time in the role, and the number of concurrent projects carried at kickoff. If the named consultant changes before go live, the vendor will: give the practice written notice within five business days; deliver, before the replacement's first call with the practice, a written handoff covering decisions made, decisions still open, exceptions logged, and named contacts at the practice and at third party systems; and, where the departing consultant remains employed, hold one transition call with both consultants and the practice present. If the change delays the project, the go live date and any payment date tied to it move by the same number of weeks, without penalty and without added implementation fees to the practice.

What is deliberately not in version 1.0

A published deferral list stops a cut item from being re-argued at every meeting.

• Pricing benchmarks and any statement about what a fair price is.
• Clinical decision support, alerting logic, and what a receiving system must do with the data it gets.
• Real time two way synchronization between systems of record.
• A mandated vocabulary. Version 1.0 mandates the shape of a coded value, not the codes.
• Software that acts on a practice's behalf rather than being operated by its staff. Identity for non human actors, audit records for automated actions, and the grading of agent readiness are a separate body of work and will be treated separately.

Governance and versioning

Version 1.0 is maintained by VetSoftwareHub.com. Proposed changes, and any language a vendor has actually signed, can be sent to Adam Wysocki through VetSoftwareHub.com. Every disposition will be recorded publicly. Version 2.0 will remove or deprecate at least one item, because a record that only ever grows eventually becomes unusable by the people it was written for.

Adam Wysocki is the founder of VetSoftwareHub.com, an independent, vendor-neutral veterinary software directory and consulting practice, and principal of the PIMS Selection Navigator engagement service. VetSoftwareHub accepts no referral fees or affiliate compensation from any software vendor.