How Much NetSuite History Do You Actually Need?

Tracey Wisner
Jul 26
3 min read

The five year default

Ask a project team how much history is going into the new system and the answer is almost always the same. Five years. Sometimes seven if someone in the room is nervous about audits.

Nobody arrives at five years through analysis. It is the number that sounds responsible. It gets agreed to early, it goes into the scope, and then it quietly shapes the budget and the timeline for the rest of the project.

It deserves more than twenty minutes.

What actually gets used after go live

Once a company is live, the historical data that gets touched regularly is a short and predictable list:

Open AR and open AP, because you have to collect and pay
Open sales orders and purchase orders, because they are in flight
Current customer, vendor, and item records, because transactions need somewhere to point
Trial balance by period, because you need comparative reporting and a starting balance sheet

That is the working set. It is the data the business runs on from day one.

Closed transactions from three fiscal years ago are a different category. They get pulled for audit support, for a dispute, or for the occasional long-range analysis. Real needs, but rare ones, and they do not require the records to live inside your production ERP.

The cost is not the load

The load is the cheap part. What costs money is everything around it.

Mapping. Every legacy field has to be mapped to a NetSuite field, and old data was rarely captured the way your new configuration expects. Three years of a field used for two different purposes at different times is not a load problem, it is a decisions problem.

Reconciliation. Every converted period has to tie. If you bring in four years of closed transactions, you own the reconciliation of four years of closed transactions, and any variance you find belongs to you now.

Inherited bad data. Duplicate customers, dead items, inconsistent statuses. Converting history means importing the mess along with it, and then living with it inside a system where it will show up in searches, in reporting, and increasingly in anything AI-assisted that reads your records.

Permanent reporting drag. Historical records that predate your current chart of accounts, your current item structure, or your current subsidiary setup do not fit cleanly into current reports. Every report that spans that boundary needs a caveat or a workaround, forever.

Three questions that right-size the scope

Go through the conversion list one line at a time and ask:

Who is going to run a report against this, and how often? If the honest answer is "nobody, but it would be nice to have," that is not a requirement. That is anxiety.
Does this need to be transactional, or does it need to be readable? Open AR needs to be a live record you can apply a payment against. A closed invoice from 2022 needs to be findable. Those are very different jobs and only one of them requires conversion.
What does our audit or retention obligation actually say? Read the policy instead of guessing at it. Retention requirements are usually satisfied by an accessible archive, not by presence in the current ERP.

What to do with everything you leave behind

Leaving history out of NetSuite is not the same as deleting it. The options are ordinary and they work:

Keep the legacy system in read only mode for a defined window, often twelve to twenty four months
Export closed transaction detail to flat files and store them where finance and audit can reach them
Load summarized history rather than detail, for example monthly GL summaries by account instead of every underlying transaction

Any of these satisfies "we can produce it if asked" at a fraction of the cost of full conversion.

Where to start

Before the next conversion conversation, write down the working set for your business. Open items, current master records, and the trial balance history you need for comparatives. Then treat everything past that as a request that has to justify itself, one line at a time, with a named person who will actually query it.

The projects that go badly are rarely the ones that converted too little. They are the ones that spent six weeks reconciling data nobody has opened since.