QuickBooks to ERP Migration

Quick answer: the load is the easy part. What decides whether a QuickBooks migration goes well is scoping what actually comes across, rebuilding Canadian tax instead of copying it, and insisting on reconciliation evidence before anyone signs off. Most overruns trace to the phrase “all our data.”

This guide covers how to move. Whether you should move is covered in have you outgrown QuickBooks, and what QuickBooks does today is covered in job costing in QuickBooks.

Separate the Two Jobs on Day One

These get conflated constantly and they are different pieces of work.

Lossless migration means the data arrives intact and can be tied back to where it came from.

Migration to native semantics means the data now means something in the new system’s model instead of being QuickBooks’ shape stored in new tables.

Faithfully reproducing your QuickBooks structure inside an ERP produces a database where nothing native works properly. Your QuickBooks classes are not Odoo analytic accounts. Your QuickBooks items are not necessarily products with bills of materials. Deciding which fields get translated into the new model and which get preserved only as provenance is the core design work, and it happens before anyone writes an export.

”All Our Data” Is the Most Expensive Sentence

Pin this down per record type before anyone estimates anything:

Decision	Ask
Which record types	Customers, vendors, chart of accounts, items, open transactions, closed transactions, documents, attachments
How many years	And why that number
Opening balances or full history	The single biggest cost driver
What gets archived	Kept but not loaded
What is abandoned	Agreed in writing, so it is not rediscovered later

Offer yourself the read-only option early. Keeping QuickBooks available for lookups for twelve months is usually far cheaper than migrating history nobody will transact against. Full transactional history is frequently around ten times the work of opening balances, and much of what people say they need turns out to be “I want to be able to look it up.”

Ask the question that separates the two: what will you actually post against, and what do you merely need to be able to find?

What Transfers, and What Does Not

Transfers reliably	Transfers poorly or not at all
Customers and vendors	Memorised and recurring transactions
Chart of accounts	Custom report layouts
Item and product lists	Attachments and linked documents
Open receivables and payables	Payroll history
Trial balance as opening entries	Meaning encoded in classes and custom fields
Historical transactions, at a cost	Bank feed rules and reconciliation history

The right column is where migrations overrun, and the last row of it deserves attention.

Beware the field that carries meaning by convention. A class used to mean division for six years and then quietly started meaning something else. A memo field where the first three characters encode status. A customer naming convention that distinguishes two entities. None of that is documented anywhere, all of it is a business rule, and it surfaces during testing when somebody says the numbers look wrong.

Legacy identifiers are provenance and must survive. Store the QuickBooks reference on the migrated record, indexed. Every reconciliation, every audit question and every “why is this wrong” investigation depends on being able to point back at the source.

Deduplicate on the client’s rules. Every QuickBooks file of any age contains duplicate customers. Merging is a business decision with consequences for history, so the rules come from the business instead of from whoever is running the import.

The Canadian Tax Point Nobody Warns About

This is the piece most likely to surprise an Alberta buyer, and it is worth budgeting for explicitly.

QuickBooks handles sales tax as a list of tax codes you apply. Odoo’s Canadian localization works differently: it ships province-level fiscal positions, and the Canadian localization documentation states that the applicable tax follows the province where delivery occurs, with specific guidance for out-of-province customers, customer pickups, and international vendors.

Those are different models. A tax code list does not map cleanly onto delivery-province logic, which means your tax configuration gets rebuilt from your actual obligations instead of copied across.

For an Alberta-only business this is small, because GST at 5 percent covers it. The moment you ship to Saskatchewan, bill an Ontario customer, or open a BC location, it becomes design work that deserves an advisor’s review. Get it confirmed instead of assumed, because a tax setup configured wrongly repeats the error on every transaction from day one.

Profile Your Data Before You Commit to a Date

Do this in the first week, on your own file, before anyone is under schedule pressure.

Look for missing values, invalid formats, orphaned references, impossible dates, duplicate customers and vendors, inventory items with no cost, and accounts nobody has posted to in five years.

That conversation goes considerably better before a go-live date exists than after. Cleanup is either your work or scoped work you are paying for, and leaving it undecided is how it becomes somebody’s free problem at the worst possible moment.

Rehearse It, and Treat the Rehearsal as a Milestone

A rehearsal listed as an activity inside another milestone gets absorbed into somebody’s week and quietly skipped. Make it a milestone with its own date and its own sign-off.

A real rehearsal:

• Runs the actual scripts, on a copy of actual production data
• Is timed, because your cutover window is a real constraint
• Produces reconciliation evidence
• Is repeated until it is boring

Rehearse the rollback as well. A cutover plan with no tested way back is a bet, and it is a bet made with your ability to invoice next week.

Insist on Reconciliation Evidence

This is what converts “the migration ran” into “the migration is correct.” Ask for it as a document, per record type.

Check	What it proves
Record counts, source against target	Nothing was silently dropped
Control totals: AR, AP, inventory value, trial balance	The numbers mean the same thing on both sides
Spot checks on named records, agreed in advance	The detail survived down to individual records
Unmatched register	What did not come across, and why, deliberately

Counts alone are weak. The right number of wrong records passes a count check comfortably. Control totals are what an accountant will actually ask for, and the person who signs the reconciliation should be your finance lead instead of the project manager.

The Cutover Runbook

Written in advance, rehearsed, and readable by somebody tired at an unreasonable hour.

1. Freeze. When QuickBooks stops accepting entries, and who enforces it.
2. Final extract, with a checksum.
3. Load, with the timing you measured in rehearsal.
4. Reconcile, against the agreed evidence pack.
5. Sign-off gate. A named person with the authority to say no.
6. Open for business, or execute the rollback.
7. Day-one support, staffed by name and by hour.

Write the go and no-go criteria down explicitly. A cutover where the decision to proceed gets made by momentum at three in the morning is a cutover that proceeds regardless of what the evidence says.

After You Are Live

• Keep the extracts and the scripts. Questions arrive months later, and “we can rerun it” is only true if you kept everything.
• Keep QuickBooks readable for the agreed period. This is cheap insurance and it is what makes the opening-balances decision safe.
• Watch for the data quality problems the migration masked instead of fixed. They resurface as reporting oddities.

Where to Go Next

Destination matters less than the discipline above, and it does matter. Our ERPNext vs Odoo vs Zoho comparison covers the three main SMB platforms on Canadian tax, payroll and operations depth, with deeper pages on Odoo in Canada and ERPNext in Canada.

For sequencing the wider decision, the Calgary software planning guide covers what to establish before any vendor conversation.