.svg)
Sometimes the right shape for the history is files: a successor system that imports CSV, a warehouse that loads them, an auditor who asked for them. This page sets out how a full extraction is delivered as a CSV collection, what survives the flattening and what does not, how the files are verified, and when a database is the better choice.
The CSV files NetSuite produces by hand and the CSV collection an extraction produces look alike on disk and behave differently the moment a question crosses two files.
Row ceilings and timeouts on large accounts, sublists flattened or missing, custom records easy to overlook, and no way to show the set is complete.
The account is extracted in full into a relational database first and verified against the source. The files are then exported table by table: one file per record type, sublists as their own files, and the identifiers that link records kept on every row. AcroXtract runs the extraction.
Delivered with its folder structure and an attachment index that says which record each document was attached to, so a document can still be traced to the transaction it supports.
The same scope as a full extraction, written down before the work starts, and delivered as files rather than as a database.
Transactions by type, entities, accounting records and custom records, each as its own file with the fields the record carried, custom fields included.
Invoice lines, expense lines, applied payments and the other sublists, each keyed to the parent record so nothing is flattened away.
The accounts, subsidiaries, periods and accounting books each transaction posted to, as a file of its own.
The chart of accounts, items, departments, classes and locations, so codes in the transaction files resolve to names.
Internal identifiers on every row, so a warehouse or a successor system can rebuild the relationships the account enforced.
The files with their folder structure and the attachment index.
A zip of the CSV files and the File Cabinet.
The MySQL database snapshot as well, where you want both.
Verification results per file: row counts compared with the source.
Optional hosting on DBVault for the same extraction.
No API into a successor system; the files are the hand-off.
Files do not enforce relationships and do not produce statements. A trial balance for a closed year needs the records joined and summed, which is a database's job. If that is a question you will be asked, keep the database snapshot as well, or host the archive on DBVault, where the statements are built in.
A folder of files cannot show its own completeness, so the checking happens before the export and after it.
The database the files come from is compared with the account at the database level: record counts per type, and a transaction resolving to its entity, its lines and its posting.
Each file's row count is compared with the record count in the source, so a file that lost rows in the export shows up before it is loaded anywhere.
Load a few files where they are going and ask the questions you expect to ask. Each issue is raised as a ticket and cleared before sign-off.
If you already have files, the checks that catch a gap are in How to verify a NetSuite export is complete.
Files are the right shape when something else will do the loading and the reporting.
The team doing the load imports the files; the identifiers on every row and the field names in each header are what they map from. We supply the collection and answer questions about it. We do not perform the load.
Load the files, rebuild the relationships from the identifiers, and report on the history alongside everything else the warehouse holds.
Files an outside reviewer can open with the tools they already have, with the attachment index saying which document supports which transaction.
It does not load data into NetSuite or into a successor system; the files are the hand-off.
It does not produce financial statements; that needs the database snapshot or DBVault.
It is not a saved-search export; the files come from a verified extraction of the whole account.
Hosting on DBVault is optional and separate; the files are yours either way.
Choose the CSV collection when something else will do the loading and the reporting: a successor ERP, a warehouse, an auditor's tools. Choose the database when the history itself has to answer questions, and DBVault when people who are not database specialists have to ask them.
Both come from the same verified extraction, so asking for both is a scoping choice rather than a second project. Say where the files are going and who will load them, and the shape follows.
Each of these organisations had its NetSuite account extracted in full and the data handed to it. The write-ups describe what was extracted, how it was confirmed and in what form it was delivered.
“The cost was very reasonable. It far outweighs not having access to our historical data.”
“From start to finish, the project was completed to our satisfaction in under a month.”
“High quality work and communication. Project delivered in time and budget, can't wish for more.”
“They covered their bases well and knew exactly what we needed ahead of us asking.”
“The thought of exiting NetSuite was daunting and Blueacrobat made it a quick and efficient process.”
“They turned an impossible-seeming challenge into a managed, on-budget success.”
.webp)
Yes. The database is where the extraction is verified; you receive the files. Keep the snapshot as well if a statement or a joined question may come up later.
The identifiers that link records are on every row, so the relationships can be rebuilt wherever the files are loaded. They are enforced only once the files are in a database.
Yes. Sublists are delivered as their own files keyed to their parent records, and custom records as files of their own, custom fields included.
Yes, as files with their folder structure, with an attachment index that says which record each document was attached to.
No. There is no API for onward migration; the files are the hand-off, and we work alongside the team performing the load.
Yes. The same extraction can be hosted on DBVault when people need to search the history or run statements without a database, and the files stay yours.
Tell us where the files are going and who will load them. We will walk through the scope, how the collection is verified, and whether the database or DBVault should come with it.
.svg)
.svg)
.png)
.png)
