Know what will migrate before you switch

Send a client and patient export. We map it, run it, show every rejected row and reconcile the counts. Nothing touches a live practice.

Request a client/patient-list dry run See exactly what imports

What moves

What the importer takes on its own, and what needs a conversation. On a narrow screen, scroll the table sideways to see every column.
Imported automatically No automatic path yet
Clients Clinical history and notes
Animals Appointments
Which animal belongs to whom Invoices and payments
Stock, lots and movements

Three entities import on their own, and that is all of them. The right-hand column is not a closed door: send what your system exports and we will say what can be moved by hand. It stays readable where it is either way. Every column the importer reads is below.

The first step

A dry run, against your own list, before you decide

Practices stay because twenty years of records are inside the old system and nobody knows what would survive the move. So the first thing we do is not sell you anything.

  1. You export from your current system

    Your client and patient list, in whatever shape it comes out. We read three files from it. Export everything your system will give you and keep the rest.

  2. We run it without committing it

    The importer reads the file and reports what it found, row by row. Nothing is written. Run it as many times as you like.

  3. You read the errors

    Which rows would not load and why, in the terms of your own file. Duplicate clients. Animals with no owner. Dates that are not dates.

  4. The counts have to agree

    Clients, animals and ownership, in against what the file held. If they do not reconcile, that is the conversation, and it is better now.

Scope

Exactly what the importer takes today

Three files: clients, animals, and which animal belongs to whom. Send a CSV or JSON export from any system. There is no vendor-specific adapter and no list of approved systems, so getting your columns onto those three files is our job, part of the dry run, and covered by the price.

Clinical history, appointments, invoices, payments and stock have no automatic path. An old system's notes arrive as free text with no agreement about what a field means, and a record quietly reshaped on the way in is worse than one you can still go and read where it is. Send what your system exports and we will say what can be moved by hand.

The columns each file needs
What one row of each file has to carry, and what else is read if it is there. On a narrow screen, scroll the table sideways to see every column.
File Every row must have Also read if present
Clients external_id, last_name first_name, email, phone. An address that is not an address fails the row rather than being guessed at.
Animals external_id, name species, breed, sex, date_of_birth, microchip_number, colour_markings, household_name
Which animal belongs to whom external_id, owner_external_id, animal_external_id is_primary. Both references have to name rows that were already imported, so this file goes last.

external_id is your current system's own key for that record, required on every row. It is what makes a second run safe: the same file imported twice updates the same records instead of duplicating your client list. One entity per file, 5,000 rows a batch, and a longer list is split rather than truncated.

What the dry run hands back
Four counts: created, updated, skipped, failed. Then every failed row on its own, with its line number and what was wrong with it. Plus the SHA-256 of the exact bytes we read, so you can check it against the file on your own disk.
What happens to your file
A review nobody applies is deleted after seven days, with the date shown on the batch itself. Applying one discards the uploaded rows and keeps only the mapping between your old keys and the new records. Our log records the batch and never a row, and never the filename, because a filename is frequently a client's surname.

Leaving

You can take it back out

Request a structured export at any time. How to leave lists every dataset included and every known gap, both generated from the exporter itself rather than described from memory.

There is a complete export of our demonstration practice on that page, produced by the same code that would produce yours: 63 CSV files, a manifest whose checksums match the files beside them, and an uploaded document in its patient folder. Open it before you send us anything.

The day

Going live

The whole plan on one screen, written down before rather than described after, so you can hold us to it.

Before the day

  1. A dry run has been read, by you, and the counts reconcile against the file you sent.
  2. Every failed row is either fixed in the source file or deliberately left behind, written down either way.
  3. A date that is not a Monday and not a surgery list. A Tuesday afternoon costs less to get wrong.
  4. Your current system's notice period and export rights checked before anything is cancelled. Get the export in your own hands first.
  5. Staff have signed in once already, so the first time is not the live day.

On the day

  1. A final export from the old system, after the last appointment on it.
  2. The import is applied. Client, animal and ownership counts compared against that file before anybody books anything.
  3. Ten records opened side by side in both systems, checked by somebody who knows the clients.
  4. Booking starts in Vetmira. The old system stops taking new work and stays readable.

The first weeks

Done with you, not handed to you

Nobody should promise a practice rushed across in a weekend. The first practices get their migration done with them, and we will tell you where the rough edges are rather than finding them together later.

Request a client/patient-list dry run Book a founder-led demo