Xero to Karbon: the data problems no one warns you about

When an Australian accounting firm shifts from Xero Practice Manager to Karbon, the visible work is rebuilding workflows. The invisible work is the data. Client records that lived in Xero’s contact model fragment across Karbon’s clients, contacts and organisations. Custom fields do not migrate cleanly. The firms that handle this well plan the data shape before the workflow shape. The ones that do not end up rebuilding the firm’s address book in two systems for six months.

What the migration tooling actually moves

Karbon’s import tooling is reasonable for what it tries to do. It will pull a CSV of contacts out of XPM, accept a list of clients with email addresses and phone numbers, and create matching records on the Karbon side. For a firm that wants to start fresh, this is a fine starting point.

The trouble is that “contacts in XPM” is a much smaller idea than “client records as your firm understands them.” XPM stores a contact, links it to a client code, attaches a few custom fields, and uses Xero’s contact ID as a foreign key into the ledger. Karbon stores a client (the entity you bill), a list of contacts (the people you talk to), and an organisation (the legal entity, or the business the client trades through). Same data, three shapes.

The import handles the names and the emails. It does not decide which person at the Smith family group is the primary contact for tax matters versus BAS matters versus ASIC correspondence. That decision is invisible in XPM because XPM does not ask. Karbon does ask, and if you have not decided, the import gives every contact the same default and your team spends the next three months fixing it record by record.

A useful test before any migration: pick ten of your most active client groups, write down on paper which person should receive what, and check whether your XPM data already encodes that. For most firms it does not. The information is in someone’s head.

The four data shapes that fragment

Four parts of the firm’s data fragment when XPM becomes Karbon. Knowing this in advance changes the migration plan.

The client list itself is the easy one. A client in XPM maps reasonably to a client in Karbon, and the import handles it. The cost is that XPM tends to encode legal entity, trading name, and the family group all as variants of the client name. Karbon expects the legal entity and the trading name as separate fields on the organisation record. The reshape is mechanical but every record needs a decision.

The contacts are messier. XPM stores a contact loosely. The same person might appear under two clients with two slightly different email addresses, because nobody enforced the rule. Karbon expects each contact to be one record, linked to the clients they belong to. The duplicates surface immediately and the team has to decide which version is canonical, by hand, while still doing actual work.

The custom fields are where firms underestimate the work. Most firms have built ten to thirty custom fields in XPM over the years. Lodgement preferences, billing notes, marketing source, the partner who owns the relationship, the practice software the client runs at their end. Karbon’s custom field model is structurally different: it lives at the client or work level rather than the contact level, and the field types are not a clean superset of XPM’s. About half of the custom fields will move cleanly. The rest need to be redesigned, not migrated.

The history is the part that gets quietly abandoned. XPM holds years of job records, time entries, and notes against each client. The native import does not bring this across. Firms tell themselves they will “look it up in XPM if they need it later,” and then six months later the XPM subscription gets cancelled because nobody is using it, and the history goes with it. We have walked into firms two years post-migration where nobody can answer “what did we do for this client in 2023” because the answer is in a system they no longer pay for.

Why “we’ll clean it up in Karbon” rarely happens

Every firm we have seen migrate with a “clean it up later” plan ends up with two address books. The reason sits in the work flow once the new system goes live, and it is not something a more disciplined team would solve.

The team’s daily work pulls them forward. Once Karbon is the live system, every tax return, every BAS, every email goes through it. Time spent fixing 2019 contact records does not bill. The partner who said “we’ll clean it up in the first quarter” finds that the first quarter contains tax season, and the second quarter contains the BAS rush, and by year-end the cleanup has not happened.

Meanwhile, XPM is still around, because cancelling it before the cleanup is too risky. Some staff still glance at XPM when they need historical context, which means XPM keeps getting updated in small ways, which means the two systems drift further apart. Six months in, neither system is canonical. A new client created in XPM by a partner who forgot the new process needs to be reconciled by hand. A bookkeeper updates a phone number in Karbon and not in XPM, or the other way around. The cost is real and almost no firm budgets for it.

The pattern is consistent enough that we now plan around it. The cleanup happens before the migration, in the system the team already knows, while their workflow is still familiar. Doing the cleanup after, in a new system, while learning the new system, is where the six-month address-book problem comes from.

The three-week pre-migration audit that prevents most of this

The audit is the cheapest piece of work in the whole project, and the easiest to skip.

The first stage is mapping the data shape. We extract every contact, client and custom field from XPM. We list the shapes the firm currently relies on, including the patterns that are not in XPM at all but live in someone’s spreadsheet or someone’s inbox. We identify the duplicates, the partial records, and the contacts who appear under three different clients with three different email addresses. The deliverable is a written model of the firm’s data, in plain language, including the decisions that have never been made explicit.

After that, the Karbon target model. We map each XPM field to its Karbon home. Some are direct. Most need a small rule: “the trading name in XPM goes to Karbon’s organisation.tradingName, and the legal entity gets pulled from CAS360 because it has been more accurate there.” A few fields have no clean home and need a custom field designed deliberately, with field names that match how the firm talks about the data rather than how XPM happened to store it.

The final stage is the cleanup itself. Duplicates get merged in XPM, while it is still the live system. Custom fields get back-populated where the firm wants them. Contacts get the role decisions Karbon will demand on day one: who is primary, who receives BAS, who signs off on tax returns. By the end of the three weeks, the firm’s XPM data already looks like the Karbon model. The migration itself becomes mechanical.

A pre-migration audit done well costs less than the post-migration cleanup it prevents, often by a factor of four. The reason is that the cleanup happens once, in the familiar system, by people who are not also trying to learn a new tool. We have run this against several mid-size accounting firms and the pattern holds.

For firms whose XPM-to-Karbon work also needs the ledger and the document store and the lodgement tool to keep talking, the broader integration architecture matters. Our accounting practice integration approach covers the database-first pattern that sits underneath the migration. For the wider picture of how this work fits a Melbourne accounting practice, our services for Melbourne accounting firms page describes the engagement model.

What good looks like at month six

Six months post-migration, in the firms that handled the data layer first, the operating picture is calm.

The team is working in Karbon. Nobody is logging into XPM for daily work. The XPM subscription either has been cancelled or is on a read-only archive plan. New clients get created in Karbon with the right contact roles assigned at intake, because the intake process assumes the data shape Karbon expects. The custom fields get used because the team helped design them.

When a partner asks “what is the status of the Smith family BAS,” the answer is one search away. When a bookkeeper needs to find the Q3 2024 review notes for an old client, they pull them from the historical archive that was deliberately exported during the migration, not from a system that no longer exists. The firm spends roughly the same time on data hygiene as before, but spread across new work rather than concentrated in retrospective cleanup.

The firms that did not do the audit look different at month six. The team uses both systems intermittently. New clients get created in whichever system the staff member happened to open first. Reports do not match because the underlying data does not match. The partners are not yet calling it a failed migration, but a quiet conversation has started about whether they should look at a different practice management tool. Karbon usually gets the blame. The blame belongs upstream, with the migration plan that left the data the way it was.

For firms that find themselves a year in and discover that Karbon’s contact model genuinely does not fit how their practice works, the next conversation is about a custom layer that sits alongside Karbon rather than a third practice management migration. That is a different post.

If you are scoping a Xero-to-Karbon move now, the work that pays back fastest is the boring three weeks before the cutover. Pull the contact list, count the custom fields, decide who at each client group receives what. Most of what we have written above is something a competent partner can run internally. If the data audit turns up more than a few hundred records that need decisions, that is the moment to bring in help.