Moving the Books From NetSuite to Intuit Enterprise Suite: A Bookkeeper's Plan

Migrating a set of books between ERP platforms is a data migration with a trial balance at the end of it. The software changes; the accounting does not. This guide covers the bookkeeper's side of moving from NetSuite to Intuit Enterprise Suite: what to freeze, what to rebuild, and how to prove the new ledger agrees with the old one.

What actually moves and what gets rebuilt

A migration is not a copy. Chart of accounts, historical detail, and open transactions each get a decision. Some map across, some get summarized, and some stay behind in an archive.

The usual pattern is a full chart-of-accounts mapping, open items in detail (AR, AP, unbanked payments), and a summarized opening balance for closed history. NetSuite's segment structure (department, class, location) needs an explicit decision, because the receiving platform tracks dimensions differently. Decide the mapping before any data moves, and write it down.

Where does the cut-off land?

Pick a clean cut-off: a month end, ideally a quarter end or year end. Close the books in NetSuite through that date, complete the reconciliations, and lock the period. Everything after cut-off is posted fresh in the new system.

Resist the temptation to run both systems in parallel for live posting. If you must parallel for a month, keep one as the system of record and treat the other as a check, not a second source of truth.

How do you prove the opening balances?

The acceptance test is simple to state: the closing NetSuite trial balance at cut-off, plus summarized history, must equal the opening trial balance in the new system, line by line. Build a working paper that shows both columns and the difference column, and require the difference to be zero before go-live.

Reconcile the balance sheet items individually, not just in total. Every bank account, every loan, every subledger with its own statement (AR aging, AP aging, fixed assets, payroll liabilities) must tie to its control account on day one. If an aging does not tie, fix it in NetSuite before migration. Migrating a broken subledger just relocates the problem.

What should you preserve before anyone touches the data?

Before extraction, take your own copies: the final trial balance, all reconciliations, the AR and AP agings, the full chart of accounts with segment mappings, and reports of any custom postings. Export historical financial statements for the retention period your jurisdiction requires. Once access to the old system lapses, these are the only evidence of the history.

When does this stop being bookkeeping?

Mapping accounts and proving balances is your work. Extraction failures, corrupted exports, or a segment structure that will not map cleanly are migration work. At that point stop and bring in a specialist rather than improvising repairs on a live file; a botched conversion damages both ledgers. Our NetSuite data migration service handles that lane, and the two efforts should be planned together from the start.

A worked example

Suppose a distributor cuts over at 30 June. NetSuite closes with cash at 84,200, AR aging totalling 191,500, AP at 96,300, and retained earnings carrying the rest. The migration carries the bank balances in full, each open invoice and bill with its original date and terms, and a single summarized journal for prior-year history. On 1 July, the new trial balance matches NetSuite's 30 June balance to the cent, the AR aging sums to 191,500, and the first bank reconciliation in the new system opens with a zero difference. That is a clean migration, and it is entirely provable from the working papers.