QuickBooks to NetSuite Migration: The Playbook for Multi-Entity and Construction Groups

You’ve decided to switch. Maybe you recognized yourself in the seven signs — consolidating in spreadsheets, intercompany balances that never tie, a close that lives in one person’s head. The decision was the easy part.

Now comes the migration, and this is where groups get hurt. Not because NetSuite is hard, but because a migration is treated as an IT project when it’s actually an accounting project with software attached. Having moved groups from QuickBooks to NetSuite — including a 20+ entity real estate group with intercompany loans, CIP balances, and lender reporting riding on the outcome — here is the playbook we actually use.

Decide what you’re migrating to before you touch data

The worst NetSuite implementations copy the old QuickBooks chart of accounts into new software. You pay ERP prices to industrialize your existing mess. Before any export, lock down three things:

Entity hierarchy. In NetSuite OneWorld, subsidiaries are structural — parent, children, elimination subsidiaries. Draw the tree on one page, including dormant entities and the joint ventures everyone forgets. This determines consolidation, intercompany, and every roll-up report you’ll ever run.

One chart of accounts. Separate QBO files drift: “Subcontractors,” “Sub-contractor costs,” and “Subs” are three accounts for the same thing across three entities. Build a single unified chart and map every legacy account to it. This mapping document becomes the spine of the whole migration.

Segments before software. Departments, classes, locations, and custom segments (project, phase, cost code for construction groups) must be designed now. A transaction migrated without its project code is a transaction you’ll re-code by hand later — we’ve watched teams spend weeks doing exactly that.

For construction and development groups, scope the modules honestly: Fixed Assets (your CIP will live somewhere real — see how CIP should actually work), project accounting for job costing and WIP, and OneWorld if you have more than one entity. Skip what you don’t need; every unused module is configuration debt.

The cut-off decision: full history or opening balances

Every migration faces one fork in the road, and it should be decided early because it changes everything downstream.

Option 1 — migrate full history. Every transaction from day one comes across. You get seamless drill-down and comparative reporting inside NetSuite. The cost: far more data preparation, open prior periods, and weeks of reconciliation. Realistic only when volume is modest and the books are clean.

Option 2 — opening balances plus open items. You bring over the trial balance at cutover, plus everything still alive: open AR and AP, open POs and sales orders, undeposited funds, unreconciled bank items — loaded through clearing accounts that must net to zero before go-live. History stays in QuickBooks.

For multi-entity groups we default to Option 2, with one construction-specific exception: bring job-cost history for open jobs. A project that’s 60% complete needs its cost history in NetSuite, or your percent-complete calculations and WIP schedules start from a lie. Closed jobs can stay behind; open jobs come across at cost-code level.

Either way: QBO gives you roughly one year of read-only access after you cancel. Don’t rely on it. Export full backups of every file — reports and raw lists — and archive them somewhere permanent before you cancel anything.

What to pull out of QuickBooks

For each entity, export the lists first: chart of accounts, customers, vendors, employees, items and services, classes and locations. Then the open records per your cut-off decision: open invoices and bills, unapplied credits and payments, open estimates and POs, and the trial balance at the cutover date.

Multi-entity groups have an extra pre-processing step that single-entity guides skip: merge the lists. Combine every entity’s vendor list into one de-duplicated master and tag which subsidiaries each vendor belongs to. Same for customers and the chart. Do this in spreadsheets now — deduplicating vendors inside NetSuite later is miserable.

Construction groups add three exports most checklists miss:

• Retainage balances, receivable and payable, by contract. In QuickBooks these usually live in a mislabeled other-current-asset account or, worse, buried in AR aging. Break them out by job before migration — you will never have a better excuse to clean them up.
• Open job budgets and estimates, at whatever cost-code level you actually maintain.
• The draw-to-GL position per project — funded draws, receivable draws, and any variance you’ve been carrying. If your draws don’t reconcile to the books today, fix that before you migrate, because migration will freeze the discrepancy into the new system’s opening balances.

Mapping: the unglamorous step that decides everything

Data mapping is a document, not a vibe: every QBO field on the left, its NetSuite destination on the right, transformation rules in the middle. Two mechanics matter:

Internal IDs. NetSuite assigns an internal ID to every record. The working sequence is: load your lists first (accounts, entities, items, segments), export them back with internal IDs, then use lookups to stamp those IDs onto your transaction files. Transactions loaded by name instead of ID are how duplicates and misposts happen.

Intercompany translation. QuickBooks records a cross-entity transaction twice — once in each file, often with different amounts and dates, which is why your intercompany balances never reconcile. NetSuite records it once, as an intercompany journal entry (ICJE) touching both subsidiaries. Migration is where you convert: match up every due-to/due-from pair across entities, resolve the differences now, and load one clean ICJE per position. Migrating unreconciled intercompany balances into NetSuite doesn’t fix them — it launders them into a system that will enforce the mismatch forever.

Load in sandbox first. No exceptions.

NetSuite gives you a sandbox environment. Use it for the entire first pass:

1. Load lists → verify, export with internal IDs.
2. Load a small validation batch of each transaction type → check posting, segments, subsidiaries.
3. Load everything else in dependency order: journals and opening balances, then open AP/AR, then open orders.
4. When an import errors, fix and re-load only the error file — never the original file, unless you enjoy hunting duplicates.
5. Tie out (next section), document every fix, then repeat the identical, now-boring sequence in production.

The production load should be an anticlimax. If it’s exciting, sandbox wasn’t finished.

The tie-out: how you know the migration worked

“The data is in” is not a success criterion. Reconciled is. Before anyone books a live transaction:

• Trial balance tie-out, entity by entity. QBO TB at cutover vs. NetSuite TB, mapped through your chart-conversion document. Every difference explained in writing.
• Sub-ledger tie-out. AR and AP agings match by entity and by customer/vendor — not just in total. Totals can match while the detail is scrambled.
• Clearing accounts at zero. If you used the opening-balance method, every clearing account nets out. A clearing account with a balance is an unfinished migration.
• Job-cost tie-out. Cost-to-date per open job in NetSuite equals QuickBooks. Then rebuild the CIP schedule from NetSuite data and confirm it reconciles to the new GL — this is the single best end-to-end test a construction group can run, because it exercises jobs, segments, and GL balances at once.
• Intercompany at zero. Group-wide due-to/due-from nets to nothing. This is the moment the group’s books are cleaner than they’ve been in years. Protect it.
• Consolidation check. Run the consolidated balance sheet. Eliminations post automatically; the report that used to take a spreadsheet week now takes a click. If it doesn’t, the subsidiary or elimination setup is wrong — better to find out now.

The first close is part of the migration

Cutover isn’t the finish line; the first month-end close is. Run it with the migration team still engaged, against a written close checklist — entity closes, intercompany tie-out, CIP roll-forward, consolidation, reporting package. Expect it to be slow. The second close should be faster. The third should be boring, and boring is the goal. Only then has the migration actually landed.

Two housekeeping items that get skipped: train the team on their daily workflows (AP entry, job costing, draw processing — not a generic NetSuite tour), and archive the QuickBooks backups with a note on where historical detail lives, because in year three an auditor will ask.

Timelines and honest costs

A focused single-entity migration on the opening-balance method: 8–12 weeks. A multi-entity group with open jobs, intercompany positions, and job-cost history: 3–5 months. Anyone quoting two weeks is planning to skip the tie-out — and the tie-out is the product.

Don’t want to run this playbook yourself? Our QuickBooks to NetSuite migration service does all of it — structure design through reconciled tie-out — as a fixed-fee engagement. Or start with the free books review, which includes a migration-readiness assessment.

#netsuite#quickbooks#migration#multi-entity