Migrating from QuickBooks Online to Business Central: What to Expect, Step by Step

Business Central includes a built-in data migration tool that lets you bring data directly from QuickBooks Online. On the surface, the process looks straightforward. In practice, there are enough friction points that a client going in unprepared will likely hit at least two or three blockers before a single record lands cleanly in BC.
We recently worked through this migration with a client who needed to move their customer and vendor master data from QBO into a freshly configured Business Central environment. This post documents the end-to-end process, the errors we encountered, the fixes required, and the things we would recommend any implementer do before running the migration.
What the Tool Can Migrate
The QuickBooks Online Data Migration extension supports the following data:
Customers
Vendors
Items
Chart of Accounts
Beginning balance transactions in the General Ledger
On-hand quantities for inventory items
Open documents for customers and vendors, including invoices, credit memos, and payments
A few important limitations to understand upfront. The tool migrates only full, unpaid amounts on sales and purchase documents. If a customer has partially paid an invoice, the full original amount comes over and the partial payment is lost. You will need to apply those payments manually, either before or after the migration.
Purchase orders and sales orders are not migrated at all.
In our engagement, we were not moving the full dataset. We only needed customer and vendor master data. The tool lets you select from four tables: G/L Account, Customer, Vendor, and Item.
Where to Start
You access the migration tool from two places in Business Central. Either search for Data Migration directly and open the Data Migration page, or go to Settings > Assisted Setup, search for "data," and select Migrate business data from the list. Both paths launch the same Data Migration assisted setup wizard.
Before you click anything, there is one important prerequisite: the BC company you are migrating into must not already contain records of the same type you are importing. For example, if you are bringing in customers, the company cannot have any existing customer records. The same applies to vendors, items, or any other table you select. The migration will fail and migration tool will ask you to delete those records before it can proceed.
Also worth noting: if you have previously run or partially run the migration in a browser session, open BC in a private window before starting again. The QBO OAuth credentials from a previous session can interfere with reconnecting.
Step-by-Step: What the Wizard Walks You Through
Step 1: Choose Your Data Source
The wizard opens with a welcome screen and asks you to choose your source system. Select Import from QuickBooks Online. The wizard will then prompt you to authenticate with your QBO account.
Step 2: The Account Number Error (Plan for This)
Once the connection to QBO is established, BC reads the Chart of Accounts in QBO and immediately validates it. If any GL account in QBO is missing an account number, you will see an error:
You have at least one account with no account number. Please assign account numbers in QuickBooks and rerun the migration.
This is a hard stop. The migration will not proceed until every active account in QBO has a number assigned.
To fix it in QBO: go to Settings > Account and Settings > Advanced, enable account numbers under the Chart of Accounts section, then go back into the Chart of Accounts and populate the Number field for any account that is missing one. Note that inactive accounts do not migrate regardless, so you only need to assign numbers to active accounts.
We hit this exact error with our client. There were several GL accounts without numbers. Once we corrected them in QBO and reconnected, the wizard moved forward.
Step 3: Account Mapping for Posting Groups
After the COA validation passes, the wizard presents a screen where you map GL accounts to BC posting accounts for sales, purchases, and inventory. If your goal is to migrate only customer and vendor master data and you are not bringing over transactions or items, you can leave this section blank and proceed. We did exactly that.
Step 4: Unit of Measure
The wizard requires you to select a default Unit of Measure before it will advance to the record selection screen. Even if you are not migrating items, you cannot skip this step. Select an appropriate UOM from BC to continue.
Step 5: Select What to Migrate
This is where you choose which tables to include. The selection screen shows: G/L Account, Customer, Vendor, and Item. Alongside each table, BC displays the number of records it found in QBO. Verify these counts look right against what you expect from the source. In our case, we selected only Customer and Vendor and left the other tables unchecked.
Step 6: Data Migration Settings
Before running the migration, you can configure default templates for each data type under Data Migration Settings. This allows you to pre-assign a Default Customer Template, Default Vendor Template, and Default Item Template. Templates allow you to default field values to incoming records. Setting this up before running the migration will save cleanup time afterward. If left blank, records will come in without those defaults and you will need to populate the fields manually or via Configuration Package.
Step 7: Running the Migration and Monitoring Progress
Select your tables, click Migrate, and the process begins running in the background. Navigate to the Data Migration Overview page to monitor progress. This page shows each table, the number of records migrated so far, a progress percentage, status, the next task queued, and an error count.
This page also serves as your control panel if something goes wrong. If the migration stalls and the progress counter stops moving, you can stop the job from this page, investigate the error, correct the data, and restart. Similar to a configuration package, you can also edit records with errors directly in the Data Migration Overview and re-apply them without restarting the entire migration from scratch.
Errors We Hit During the Migration Run
Even after getting past the account number issue, the migration surfaces additional errors at runtime through the Data Migration Overview page. You can correct these errors inline without having to restart from scratch.
Error 1: Missing Gen. Bus. Posting Group "QB"
The QBO migration extension defaults to assigning a General Business Posting Group named QB to all incoming customer and vendor records. If that posting group does not exist in BC, the migration will fail on those records. The fix is to create a Gen. Bus. Posting Group with the code QB in BC before running the migration, or correct it inline from the Data Migration Overview page.
One thing worth knowing: you do not have to keep the QB posting group code permanently. Once the records are in BC, you can update the Gen. Bus. Posting Group on customers and vendors to whatever code fits your actual posting setup, then decommission or leave the QB group unused. The code is simply a requirement of the migration mechanism itself, not something you are locked into.
Error 2: Contact Number Series
The migration also attempts to create Contact records and establish business relations between those contacts and the incoming customer and vendor masters. BC uses the Contact number series to generate contact numbers during this process. If the last number used in the Contact number series is not current, BC will attempt to create contacts with numbers that already exist, causing a conflict.
Before running the migration, verify that the last number used in your Contact number series is up to date and that there is room for the new records the migration will create. You can check and update this in the No. Series setup.
What We Did Not See: GL Data and the QB Journal Batch
One notable observation from our engagement. The migration did not produce any GL data. There was no General Journal batch named 'QB,' which the tool is expected to create to hold beginning balances and subledger history for review and posting.
We cannot say definitively why this did not occur in our environment. The client is running a configuration that includes third-party extensions, and it is possible that the combination of factors, including the fact that we migrated Customer and Vendor master data only and skipped the GL Account and Item tables, affected what the tool attempted to create on the financial side.
The practical implication: if you are expecting GL beginning balances to come across via this migration, test this in a sandbox environment first and verify the QB journal batch actually appears before relying on it for your go-live approach. Do not assume the tool will produce it. If it does not, you will need to enter beginning balances through a separate import method like Configuration Package.
After the Migration Completes
The migrated records land in BC as editable master data. Review your data for completeness. QBO has fewer fields than BC, so many fields will arrive blank including payment terms, currency codes, and specific posting group assignments beyond the QB posting group discussed above.
A few other post-migration checks worth running:
Update the Gen. Bus. Posting Group on customers and vendors from QB to your actual posting group codes once the records are in
Confirm the Gen. Bus. Posting Group QB has the correct posting setup if you plan to use it for any interim posting before switching
Review contact records created by the migration and verify the business relations were established correctly between contacts, customers, and vendors
If you selected the GL Account table during migration, verify beginning balances in the general ledger, as QBO does not store current balances for all accounts and corrections may be needed
What the Tool Is and What It Is Not
The QBO Data Migration extension is useful for what it is: a way to bootstrap master data into a clean BC environment without a manual import exercise. For a company moving from QBO to BC, it removes a significant amount of data entry and gives you a starting point for master data that is reasonably structured.
It is not a full-fidelity migration tool. Transactional history, partial payments, purchase orders, and sales orders do not come across. GL beginning balance behavior appears inconsistent across environments. For companies with complex COA structures, significant open transaction volumes, or inventory that requires careful costing configuration, the tool is a starting point, not a complete solution.
As always, the configuration that surrounds the migration, posting groups, number series, templates, and account mapping, determines how usable the data is once it lands. Getting that foundational setup right before running the tool is where the real migration work happens.
Struggling with a specific Business Central area? We’ll run a free 2-hour session with your team on that exact topic.
Evolve Advisory Group is a senior Microsoft Dynamics 365 Business Central consulting firm based in Calgary, specializing in inventory-intensive organizations. If you are evaluating Business Central as your next step, we offer a no-obligation discovery conversation to help you understand whether it is the right fit for your business.




Comments