The vendor's import handled the easy part
The practice has chosen new software, perhaps moving to Karbon, Xero Practice Manager or another system. The vendor's import tool brings across clients and contacts. What it does not bring across properly are the recurring job settings, the custom fields your practice built up over years, the notes on each client, the time records and the emails filed to clients.
Two months after go-live, a recurring job that never recreated means a client's accounts were not started. Someone needs a note from three years ago and it is not in the new system.
Practice data is richer than an import template
Over years, practices customise their software heavily: fields for AML dates, flags for special handling, job templates with checklists, notes that hold institutional memory. Standard imports handle the common fields and leave the rest.
The new system also works differently. Recurring jobs, deadlines and workflows are modelled in their own way, so moving them is a translation, not a copy. And the practice has to keep running during the move, with deadlines not pausing for the migration.
Staff time is the hidden constraint. The people who understand the old setup best are also the busiest, and a migration planned around them rather than with them tends to miss the details they carry in their heads.
What a rushed migration costs
| Issue | Effect |
|---|---|
| Recurring jobs not recreated | Work missed in the months after go-live |
| Custom fields dropped | Information the practice relied on disappears |
| Notes and emails left behind | History lost or split across systems |
| No reconciliation | Nobody knows what failed to move |
| Old system switched off early | Historic records unavailable |
The cost of getting it wrong also lasts. A migration that leaves gaps can shake staff confidence in the new system for years, and parallel spreadsheets creep back in as a safety net.
How we run the migration
- We extract everything from the old system through its API or exports: clients, contacts, services, jobs, recurring settings, custom fields, notes, time and filed documents.
- With your team, we map each item to the new system's structure, decide what to move, what to archive and what to retire, and agree how recurring jobs will be rebuilt.
- The import runs first on a test copy of the new system, and your staff check a sample of clients across different types.
- Counts of clients, jobs and deadlines are reconciled between the old and new systems, and differences are explained before go-live.
- On go-live, the final import runs, and a deadline check confirms every upcoming deadline has a job in the new system.
- Historic notes, time and emails that do not fit the new system are placed in a searchable archive linked to each client, so the history stays available after the old system is switched off.
Where the new vendor's own tools cover part of the move well, we use them rather than rebuilding.
A switch without a gap
The practice moves with every deadline accounted for, every recurring job rebuilt and the history still findable. Staff trust the new system from the start because they checked it before go-live. And the old system can be switched off on a date you choose, not one forced by the contract.
It also gives the practice a chance to tidy up. Custom fields nobody uses, job templates that no longer match how work is done and duplicate clients can be retired during the move rather than carried forward.
Is a software move on your horizon?
- You are planning or have started a practice software switch
- Your current system has many custom fields and templates
- Recurring job settings are complex
- Notes and filed emails matter to your team
- You are worried about deadlines during the move