What to assess before changing accounting systems

Changing accounting systems is usually scoped from a product demo and an optimistic estimate. The software rarely turns out to be the difficult part. The difficult part is the condition of the data being carried across, the decisions nobody has made yet, and the weeks either side of go-live when the business still has to invoice customers, pay suppliers and meet payroll.

This guide sets out what is worth assessing before you commit to a migration date, whether you are moving from MYOB to Xero, from Xero to MYOB, out of QuickBooks Online, or from any of them towards a larger finance system. None of it removes risk entirely. It does move most of the unpleasant discoveries forward to a point where they are still cheap to deal with.

Treat the change as a business change, not an export

A data export is a technical task with a clear finish line. A system change is not. It touches how invoices are raised, how approvals happen, how the bank reconciliation is done each week, how BAS is prepared, what the management report looks like, and how much your team trusts the numbers in front of them.

The practical implication is that the assessment cannot be delegated entirely to whoever is doing the technical work. Someone who understands how the business actually operates has to be involved in deciding what must still work the day after go-live.

Start from requirements, not features

Before comparing platforms, write down what the finance function must be able to do after the change: the reports that go to owners or lenders, the approval steps that cannot be skipped, the integrations that feed sales or payroll, the compliance lodgements and their timing. A requirement list written in your own language is a far better basis for scoping than a feature comparison written by a vendor.

Assess the condition of the data you intend to move

Most migration difficulty is inherited, not created. The file you are moving has usually been in use for years and carries the residue of every workaround, staff change and half-finished cleanup along the way.

Customers and suppliers

• Duplicate contacts created by slightly different spellings, trading names or ABN entries
• Inactive records kept alive because nobody was confident they could be removed
• Missing or inconsistent payment terms, contact details and tax registration information
• Contacts that exist as both a customer and a supplier and need to remain linked correctly

Chart of accounts

A chart of accounts that has grown organically usually contains accounts that are duplicated, misclassified, or kept for a single historical transaction. A system change is the natural moment to rationalise it — but only if you know what is there and what has actually been used recently.

• Which accounts have had activity in the last two financial years
• Accounts with near-identical names or overlapping purposes
• Catch-all accounts used for anything uncategorised
• Control accounts that should never be posted to directly

Historical transactions and open items

Open receivables, payables, credit notes, part-payments, unreconciled bank lines and inventory balances are where migrations most often go wrong. They carry ageing, allocation and tax characteristics that a balance transfer does not preserve on its own.

• Outstanding invoices and bills with their original dates, due dates and references
• Credit notes and part-payments that must remain matchable after the move
• Unreconciled bank transactions and the reconciliation cut-off you intend to use
• Long-outstanding balances that are unlikely to be real and should be resolved first
• Inconsistent GST treatment on similar transactions, which becomes visible under review

Decide the migration scope deliberately

Scope is the single biggest driver of effort, cost and elapsed time. Bringing everything across since inception feels safe, but it multiplies validation work and imports problems you would rather leave behind. The alternative — opening balances, open items and a defined period of transactional detail — is faster to move and considerably easier to verify, provided there is a plan for reaching older records when required.

Identify who makes the decisions

Migrations stall more often on unowned decisions than on technical failure. Before starting, name the people responsible for approving scope, approving how accounts and tax codes map, reviewing validation results, and authorising go-live. In a small business these may be the same person; in a larger one they rarely are, and the difference matters when a decision is needed quickly.

If an external adviser or bookkeeper is involved, agree what they own and what the business owns. Cleanup, in particular, tends to sit in the gap between the two.

Plan for continuity through the change

The business does not pause for a migration. Continuity planning is about deciding, in advance, how routine finance work continues while the change happens.

• Invoicing: which system raises customer invoices during the changeover window, and how numbering continues without duplication
• Supplier payments: when the last payment run happens in the old system and the first in the new one
• Payroll: whether a pay run falls inside the window, and how obligations and reporting continuity are preserved
• Bank feeds: allow for approval lead times and expect a period of manual import
• Management reporting: which system produces the next month-end pack, and whether comparatives come from the legacy file

Understand why validation and a planned cutover matter

An import that completes without error messages has told you the destination accepted the records. It has not told you the resulting financial position is complete and explainable. Validation — comparing balances, counts and open items, and documenting differences on purpose — is what turns a completed load into something a reviewer can approve. That subject is covered in more depth in our guide to validation.

A planned cutover is the other half. It defines the freeze point in the old system, the sequence of final steps, who checks what, and the point at which the business commits to the new system. Deciding all of that during the changeover weekend is how avoidable problems become expensive ones.

Turning assessment into a plan

An assessment is only useful if it produces something you can act on: a cleanup list with owners, a set of mapping decisions, an agreed scope, a validation approach and a realistic date. That output is what separates a migration that feels manageable from one that runs on hope.

Ledrix is designed around a structured approach to readiness, workflow visibility, validation and controlled cutover, so this stage is repeatable rather than dependent on whoever happens to be diligent that week. You can read more about the sequence in how it works, or about current product direction and availability on platform direction.