Cloud accounting migrations are one of the most common projects Australian bookkeepers take on — and one of the most commonly underestimated. A migration that looks like a weekend job can easily consume three weeks of billable time if it's not structured properly. The clients who get the best outcomes are the ones whose bookkeepers treat migration as a project, not just a data import.
This guide walks through the migration process I've refined over dozens of client transitions, from the initial assessment through to post-go-live support.
Step 1: Pre-Migration Assessment
Before touching any software, spend time understanding what you're actually migrating. Meet with the client and document:
- Current software (MYOB AccountRight, Xero desktop, spreadsheets, Reckon, etc.) and version
- Volume of historical data — how many years of transactions exist? Do they want to bring all of it across?
- Integrations — payroll, inventory, POS systems, e-commerce platforms, payment gateways
- Users — who currently accesses the system and what are their roles?
- Compliance deadlines — avoid migrations in the two weeks before a BAS lodgement date
A common question is whether to migrate historical data at all. My default recommendation is to start fresh from a migration date (usually 1 July or 1 January) and retain the old system in read-only mode for historical lookups. Full historical data migration is expensive, often messy, and rarely used. Most clients only need a clean opening balance.
The exception is clients who need historical data for ongoing work — property investors tracking depreciation schedules, for example, or businesses with multi-year contracts or warranty obligations.
Step 2: Clean the Data Before You Move It
The biggest mistake bookkeepers make in migrations is importing messy data and expecting the new system to fix it. It won't. If the old file has duplicate contacts, orphaned transactions, incorrect opening balances, or uncoded bank entries, all of that comes across with it.
Before migration:
- Reconcile all accounts in the old system to confirmed closing balances
- Clear unreconciled items older than 90 days — these are almost certainly errors
- Merge duplicate contacts (suppliers and customers with multiple entries)
- Review the chart of accounts — this is an excellent opportunity to rationalise accounts that have accumulated over years
- Confirm superannuation and payroll clearing accounts are at zero
Send the client a clear outstanding items report and get sign-off that the closing balances are correct. This becomes your baseline and protects you if questions arise later.
Step 3: Set Up the New File
With the old system cleaned up, configure the new cloud environment before importing anything:
- Chart of accounts — import or manually create the rationalised COA from step 2
- Tax codes — confirm GST, BAS, and PAYG codes match ATO requirements
- Opening balances — enter balance sheet items as at the migration date. Trial balance from the old system is your source of truth
- Contact list — import suppliers and customers, being careful to remove duplicates again if the old export had them
- Bank accounts — set up each account and connect the bank feed
- Users and permissions — create logins for the client and any other users
For payroll migrations, this step is significantly more complex. Year-to-date figures for each employee must be entered correctly, and if you're mid-year, the STP reporting history needs to be considered. This warrants its own project if the client has more than a handful of employees.
Step 4: Run Parallel for at Least One Month
A parallel run — operating both old and new systems simultaneously for one period — is the most reliable way to verify the migration is correct. It's also the most time-consuming, which is why many bookkeepers skip it. That's usually a mistake.
During the parallel period:
- Enter the same transactions in both systems
- Reconcile both systems to the same bank statements
- Compare trial balances at the end of the period — they should match exactly (allowing for any mapping differences in the COA)
- Have the client review reports in both systems to build familiarity with the new one
A one-month parallel run is usually sufficient. For complex clients with multiple entities or integrations, run two months.
If the trial balances don't match after the parallel period, find and fix the discrepancy before cutting over. Do not go live on a file with unexplained differences.
Step 5: Cut Over and Decommission
Once you're satisfied the new system is accurate:
- Set the cut-over date (typically the last day of a month or quarter)
- Complete the final reconciliation in the old system
- Export or archive all data from the old system (required for ATO record-keeping — five years minimum)
- Disconnect bank feeds from the old system
- Connect all bank feeds to the new system and confirm transactions are flowing
- Cancel old software subscriptions (but retain the archived data)
Send the client a clear "we are now live" communication. Update any integrations — payroll systems, e-commerce platforms, payment gateways — to point to the new file.
Step 6: Post-Go-Live Support
Plan for a higher-than-normal support workload in the first month post-migration. The client will need help navigating the new interface, running reports they're used to, and understanding workflow differences (bank rules, approval flows, etc.).
Schedule a 30-day review call to check in on:
- Any transactions coded incorrectly due to unfamiliarity
- Bank rules working as expected
- Payroll running correctly through STP
- Integrations performing as expected
Document any lessons from the migration in your practice's playbook — every migration teaches you something that makes the next one faster.
Summary
A cloud accounting migration done well is one of the most valuable things a bookkeeper can do for a client. It modernises their record-keeping, enables real-time collaboration, and sets up a much cleaner platform for compliance work. The key is treating it as a structured project: assess carefully, clean before migrating, verify with a parallel run, and support the client through the transition. Rushing any of these steps is false economy — the time you save upfront, you'll spend tenfold fixing problems afterwards.