What accounting practices should review before a client migration

When a client changes accounting systems, the practice tends to inherit the consequences: reconciling differences nobody expected, explaining why comparatives no longer line up, and absorbing cleanup that was never quoted. A short, structured review before the project begins changes that dynamic — not by taking on more work, but by making the work visible while it can still be scoped.

Why the practice is drawn in before the technical work begins

Clients rarely ask a practice to run a migration. They ask whether the new system will work for them, whether their history will still be there, and whether their reports will still make sense. Those are practice questions, and answering them requires knowledge of the file that only the practice has.

Being involved early is also self-protective. The issues that turn into unbilled work later — a file that was never properly reconciled, payroll changing mid-year, history quietly dropped from scope — are all visible before anything is moved.

Assess whether the client file is clean, current and reconciled

A file can balance and still be in poor condition. What predicts migration effort is not the trial balance; it is the accumulated residue behind it.

• Suspense, uncategorised and clearing accounts carrying a balance
• Bank accounts with stale, partial or manually forced reconciliations
• Long-outstanding receivables and payables that are unlikely to be recoverable or payable
• Duplicate contacts and inconsistent coding across similar transactions
• Manual journals used to force a reported outcome, with no supporting explanation
• Periods that were never locked, allowing prior-period changes after lodgement

Reconcile to an agreed cut-off date before migration rather than after. A migrated position can only be validated against a source position that is itself trusted, and establishing that trust afterwards means doing the work twice.

Establish who owns cleanup, decisions and final review

Three roles cause most of the friction in a client migration, and they are frequently unassigned: who performs the cleanup, who makes business decisions about mapping and scope, and who reviews the result before go-live.

Set these out explicitly, in writing, before the engagement starts — including which are chargeable practice work, which sit with the client, and which sit with whoever is performing the migration. Most disputes after a migration are scope disputes conducted in technical vocabulary.

Clarify historical-data scope and reporting needs

Clients almost always assume everything comes across. Practices know it usually should not. The conversation to have early is which reports must be reproducible after the change, over what period, and from which system.

• Comparative reporting: how many prior years need to be produced from the new system
• Lodgement history: which periods must remain reproducible, and from where
• Source documents and attachments: whether they move, are archived, or stay in the legacy file
• Legacy access: who retains it, at what cost, and for how long

Identify the compliance-sensitive areas early

Payroll

Payroll rarely behaves like the general ledger. Year-to-date figures, leave balances, superannuation obligations and reporting continuity each need a specific decision, and the timing of the change relative to the financial year is usually the largest single factor. Where there is a choice, aligning payroll to a year boundary removes a category of problems entirely.

BAS and GST

Confirm how GST codes map, how prior periods will be represented, and whether the client will need to reproduce lodged figures from the new system or from the retained legacy file. Inconsistent coding in the source becomes visible under migration review, which is useful but needs somewhere to go.

Bank feeds, debtors and creditors

Bank feed reconnection depends on the bank's timeframes, not the project's, so plan for a manual period. Debtor and creditor ledgers need to arrive with original dates and references intact, or collections and payment runs start from a distorted position on day one.

Prevent scope creep caused by hidden data issues

Scope creep in migrations is usually not a change of mind. It is a discovery: an unreconciled account, an unexpected duplicate set, a payroll history nobody had examined. The practical defences are to look for those issues during the review, to state clearly what has not been examined, and to define what happens when something material is found.

A short clause covering the process for newly discovered issues — assessed, quoted, then performed — protects both the practice and the client relationship far better than an assumption that nothing will be found.

Help the client understand the decisions they own

Clients often experience a migration as something being done to them, then feel the consequences of decisions they did not know were made. The practice is well placed to translate those decisions into plain terms: how much history moves and why, what happens to old attachments, what their first month-end will look like, and what will be different in their reports.

These conversations take little time and remove most of the post-migration surprise, which is where relationship damage actually occurs.

Review validation evidence and document sign-off

Where a practice is asked to review the outcome, the review is only as good as the evidence available. Ask for comparison output rather than assurance: counts by record type, trial balance comparison at the cut-off date, control accounts against sub-ledgers, ageing profiles, and a list of differences separated into expected changes and unexplained items.

The reasoning behind that separation is covered in more detail in our guide to validation. Record who approved the result, on what basis and when — a short file note is enough, and it is what makes the decision defensible if questioned later.

Protect the advisory role

A migration is a moment where the practice's judgement is worth more than usual: interpreting what the numbers mean, deciding what is acceptable, and advising the client on the consequences. That role is distinct from practice management, tax preparation and workpaper systems, and it is not replaced by migration tooling. Ledrix is designed around readiness, workflow visibility, validation and controlled cutover — the migration layer, not the practice's systems or its advice.

A review that lives in one person's head does not scale across a client base. Practices that handle migrations well have turned this into a standard process with a consistent output the client can read. That repeatability is the thinking behind Ledrix Pro, a planned capability, and the practice perspective is set out on for practices.