How to export your data from NetSuite without losing relationships
Whether you face a renewal, an exit decision or a data residency requirement, you need to get records out of NetSuite before you can rebuild them elsewhere. Oracle documents five extraction paths, and none of them is a one-click full export. The Full CSV Export covers lists such as customers, vendors, items and employees, plus a transaction detail report, and it is limited to users with the Administrator role. It does not cover everything, so Oracle points to saved search results and report results exported as CSV for the data it misses. For bulk or structured extraction, the two remaining paths are SuiteTalk SOAP web services and SuiteAnalytics Connect, which connects through ODBC, JDBC or ADO.NET drivers.
Start by inventorying what your account holds against these paths. Run the Full CSV Export from Setup > Import/Export > Export Tasks and check the ZIP contents against your list of record types, then identify every custom record, saved search and report that the export leaves out. Confirm with Oracle which of these your account can reach, because NetSuite documentation states that ODBC access through SuiteAnalytics Connect is an additional service with an associated fee. Ask your NetSuite administrator to confirm the fee and role requirements in writing before you schedule an extraction project.
Relationships survive only if you extract the internal ID with every row. Oracle notes that every extraction method preserves relationships when the internal ID is exported alongside each record, and that report CSVs are easier to reconcile than saved searches for transaction totals. Also set your spreadsheet tool to read long numeric fields as text, because NetSuite warns that Excel displays numbers of 16 or more digits in scientific notation unless the file is opened through the Text Import Wizard or an office suite such as LibreOffice. Keep these exported IDs as your mapping key when you later import into Odoo or ERPNext, since both can match records through External IDs or import templates.
Which NetSuite data you can export, by method
This table compares each documented NetSuite extraction method by the data it covers, the output it produces and the limits Oracle documents. Read it by first identifying which data types your rebuild needs, then checking whether the method reaches them and whether the role or fee requirements apply to your account.
| Data type | Export method | Output format | Documented limits |
|---|---|---|---|
| Lists: customers, vendors, items, employees, contacts, notes, tasks, partners | Full CSV Export (Setup > Import/Export > Export Tasks) | ZIP file of CSV files | Available only to the Administrator role; Oracle states it does not currently export all data as CSV |
| Saved reports you own | Full CSV Export | ZIP file of CSV files | Covers only reports owned by the user running the export |
| Transaction detail report | Full CSV Export | CSV file within the ZIP | Detail report only; confirm it includes every transaction field your rebuild needs |
| Saved search results | Saved search exported as CSV | CSV file | Documented as the alternative when Full CSV Export does not meet your needs; check row limits and field selection in your account |
| Report results | Report exported as CSV | CSV file | Oracle notes report exports are more useful than saved searches for transaction data because totals are easier to match |
| Any record with its internal ID | SuiteTalk SOAP web services | XML responses for your integration code | Requires development work to build and run the extract; confirm current service support with Oracle |
| Analytical data via SuiteAnalytics Connect | ODBC, JDBC or ADO.NET drivers | Query results through a database driver | Documented as an additional service with an associated fee; confirm the fee with Oracle before planning |
What the Full CSV Export leaves out and how to cover the gap
Oracle documents that the Full CSV Export does not currently export all data as CSV files, so some parts of your NetSuite account will not appear in the ZIP file. The cards below cover each likely gap, the extraction route that fills it, and the written inventory you need before you ask an implementer to rebuild anything in Odoo or ERPNext.
Custom records and custom lists
Custom record types and custom lists that your administrators built are the most common gap for a Full CSV Export, because the export covers standard lists rather than every record type you have defined. Before you rely on the export, list each custom record type in Setup and confirm with Oracle's documentation whether it is included. Records that are missing need a saved search exported to CSV, with the internal ID column added to each row so relationships survive the move.
Scripts and SuiteScript logic
SuiteScript files, workflows and saved logic are not data, so no CSV export will carry them into Odoo or ERPNext. Build a written inventory of every script, its trigger (record save, scheduled run or user event) and the business rule it enforces. Use that inventory as the specification for rebuilding the behavior as Odoo modules or Frappe server scripts, and confirm the list against your own account, since script access depends on your roles and licenses.
Account configuration and setup records
Subsidiaries, accounting periods, tax codes, approval routing, roles and numbering sequences live in Setup rather than in the transaction data. The Full CSV Export may not carry these settings in a form you can reuse. Document each setting by screen and value, export the lists that do exist, and treat the rest as a manual rebuild. Ask your implementer to review the inventory before any data loads, because a wrong tax or period setting shows up later as a balance difference.
Transaction line detail
The transaction detail report in the Full CSV Export is a summary of transactions, not a complete copy of every line on every document. If you need full line-level detail for invoices, purchase orders or journal entries, run a report CSV or a saved search on transaction lines. Oracle notes that report CSVs are more useful than saved searches for transaction data because totals are easier to match, so run both and reconcile the sums against your general ledger before cutover.
Bulk extraction with SuiteTalk and SuiteAnalytics
When saved searches and report CSVs become impractical at volume, the two programmatic routes are SuiteTalk SOAP web services and SuiteAnalytics Connect through ODBC, JDBC or ADO.NET drivers. ODBC access is an additional service with an associated fee, so confirm your entitlement with Oracle before you plan the extraction. Scripted pulls also depend on developer time and on the permissions of the integration role, which your team or implementer should confirm in advance.
Confirm each gap in your account
The gaps above describe what Oracle documents as of its current help pages, but the exact contents of your export depend on your account features, bundles and permissions. Make a short register that lists each data type, the method that covers it, the person who ran the test, and the row count compared with the source screen. Keep that register with your migration evidence so that the cutover team can see which gaps were checked and which remain open.
Why exporting internal IDs decides whether relationships survive
Export the internal ID with every row, or the relationships in your NetSuite data will not survive the move. Oracle's documentation states that every extraction method preserves relationships when the internal ID is exported with each row. That applies whether you pull a Full CSV Export, saved search results, report results, SuiteTalk or SuiteAnalytics Connect. The ID is the only field that ties a record to the other records that reference it, so it belongs on every file you take out, including the customer list, the vendor list and each transaction extract.
Consider a customer, the invoice raised against that customer, and the customer payment that settles the invoice. In NetSuite the invoice carries the customer's internal ID, and the payment carries the invoice's internal ID. If those IDs are exported, Odoo or ERPNext can rebuild each link exactly. If they are missing, the only remaining key is the name, and names collide. Two customers called Northwind Ltd in different subsidiaries will both match, and an import that matches by name will attach invoices to the wrong party. Before you run any export, check that each file has an ID column for every record type you need to link, and keep a mapping file from NetSuite IDs to the new record names or External IDs you create.
Plan the import side with the same keys. Odoo recommends External IDs when importing data from a third-party application, and its import tool can update existing records when the External ID matches, so you can load masters first and then load transactions that point at them. ERPNext's Data Import tool also updates existing records from CSV or Excel files, and its documentation advises importing only a few thousand records at a time, so split large transaction files into batches and confirm each batch before the next. For transactions, prefer a report CSV over a saved search where the report offers the same fields, because Oracle notes that totals are easier to match in report output. Reconcile record counts and balances against NetSuite after each load, and confirm the exact field names in your own export, since they vary by record type and account configuration.
The export sequence and how to verify each file
This sequence turns NetSuite data into a set of files you can prove are complete and internally consistent before anyone touches the target system. Each step ends with a check, so the source can be frozen with confidence that nothing was silently dropped.
Inventory every data type in scope
Before exporting anything, the finance and operations owners list each record type the new system must hold: customers, vendors, items, employees, open transactions, saved reports, notes and attachments, and historical transactions by period. For each type, record the NetSuite source (a list, a saved search, a report or an API object) and the owner who signs off on it. The inventory is done when every row has a source and a named owner, and the owners confirm that nothing in the business process depends on data left off the list.
Run the Full CSV Export as an Administrator
A user with the Administrator role opens Setup > Import/Export > Export Tasks and runs the Full CSV Export. The result is a ZIP file of CSV files covering lists such as customers, vendors, items, employees, contacts, notes, tasks and partners, along with saved reports you own and a transaction detail report. Because Oracle states it does not currently export all data as CSV files, the operator compares the ZIP contents against the inventory from the previous step and marks every type that is missing. The step closes when each file opens, the header row matches the expected fields, and each gap is logged for the next steps.
Export saved searches and reports with internal IDs
For each data type the Full CSV Export does not cover, or covers only partly, the analyst builds a saved search or runs a report and exports the results as CSV. Oracle notes that report CSV exports are more useful than saved searches for transaction data because totals are easier to match, so transactions should go through reports where possible. Every export must include the internal ID column on each row, since that identifier is what lets the new system rebuild links between customers, invoices and payments. Excel shows numbers of 16 or more digits in scientific notation unless the file is opened through the Text Import Wizard or an office suite such as LibreOffice, so the analyst opens files that way. The check is that every file has an internal ID column populated on every row, and long numeric fields keep their full digits.
Decide on SuiteTalk or SuiteAnalytics Connect
CSV exports are manual and suit one-off moves, but a large or repeated extraction may need an interface. SuiteTalk SOAP web services and SuiteAnalytics Connect through ODBC, JDBC or ADO.NET drivers are the other two documented routes. NetSuite documentation states that ODBC access through SuiteAnalytics Connect is an additional service with an associated fee, so the owner should confirm licensing with Oracle before planning around it. The integration lead records which route, if any, is chosen, who builds and runs the extraction, and whether it must run more than once before cutover. The decision is complete when it is written down with its licensing status confirmed and a test extraction returns the same row count as the equivalent CSV export.
Store each file with a checksum and manifest
Each exported file is moved to a controlled location in your own storage, such as an encrypted volume or an approved object store, and placed in a folder that is named by source and export date. The operator generates a SHA-256 checksum for every file and writes a manifest listing file name, source report or search, export user, export time and checksum. Access to the folder is limited to the migration team, and the manifest is kept with the files for audit. The check is that recomputing the checksums on a second machine produces identical values, and that the manifest lists every file in the folder with no extras.
Reconcile record counts and report totals
Before the NetSuite source is frozen, the finance lead compares each file against the live system. For every list, the record count in the file must match the count shown in NetSuite for the same filter. For transaction data, totals by period, currency and account in the report CSVs must match the NetSuite report totals, and sample invoices and customers must match field by field. Differences are logged with a cause and resolved before sign-off. The step closes when the reconciliation sheet shows zero unexplained differences and the finance lead and the technical owner both sign it.
Freeze the source and confirm the archive
Once the reconciliation is signed, the team sets a cutoff, announces the freeze to users and records the date and time the source was locked. Then the team re-runs a sample of the exports from the frozen source and compares checksums and counts with the originals to confirm nothing changed. The final archive, with manifest, reconciliation sheet and sign-offs, is stored where auditors and future staff can find it. The step is complete when the re-run matches the original exports and the archive is indexed in your records system.
Questions buyers ask before exporting NetSuite data
Can I run the NetSuite Full CSV Export myself without help?
Yes, if you hold the Administrator role, because Full CSV Export is restricted to that role and runs from Setup > Import/Export > Export Tasks. It produces a ZIP file of CSV files covering lists such as customers, vendors, items, employees, contacts, notes, tasks and partners, along with saved reports you own and a transaction detail report. The catch is coverage: Oracle states it does not currently export all data as CSV files, so the export alone rarely finishes the job. Check the lists against your own record types and plan saved search or report exports for anything missing. Read the NetSuite CSV Export documentation before you start, and confirm with your NetSuite administrator which roles can run each step.
What makes a NetSuite data export larger or harder?
Effort follows the shape of your account rather than the size of the export button. The main drivers are the number of subsidiaries and currencies, the number and complexity of custom records and custom fields, the years of transaction history you keep, and how many saved searches and reports feed operations or audits. Each subsidiary can add its own chart of accounts mapping, and each custom record needs a decision about whether it becomes data, a module or nothing. Transaction volume affects extraction runtime and reconciliation. Ask for an inventory of record types, record counts by year and subsidiary, and a list of SuiteScript logic before any quote is accepted, so the written scope reflects your actual account.
Do SuiteAnalytics Connect fees apply to a NetSuite export?
They can. NetSuite documentation states that ODBC access through SuiteAnalytics Connect is an additional service with an associated fee, so the fee applies if you extract data over ODBC, JDBC or ADO.NET drivers. Full CSV Export, saved search CSVs and report CSVs do not depend on that route, and SuiteTalk SOAP web services are a separate method to confirm with your account team. To ask Oracle for the current terms, request a written quote for SuiteAnalytics Connect for the specific drivers and user count you expect to use, and ask whether any fee is one-time or recurring. Get the answer in writing before you build the extraction plan around it.
How long does a NetSuite data export project take?
The duration depends on scope, and no fixed figure applies to every account. Timing is driven by the number of record types, the volume of transactions, the number of subsidiaries that must reconcile separately, and how many rounds of test extracts your finance team needs to sign off. A simple account with a few entities behaves very differently from a multi-currency group with heavy custom work. Ask for a phased plan with named milestones, the staff hours each phase requires from your side, and the acceptance criteria for each dataset. Treat any duration without that breakdown as provisional until it appears in the written plan.
Which internal roles does a NetSuite export need from my team?
At minimum you need a data owner who decides which records are in scope and signs off on the target design, and a finance reconciler who checks that balances, totals and transaction counts match between NetSuite and the export. Most projects also need a NetSuite administrator for the Administrator role work and export tasks, and a subject matter owner for each area such as sales, purchasing, inventory and payroll. Plan time for these people in advance, because reconciliation and approvals are where projects stall. Ask the implementation partner to list every internal role, the expected time commitment per role and the decisions each person must make.
Does exporting internal IDs really matter for Odoo or ERPNext?
Yes, because internal IDs are what let you rebuild relationships after the data lands. Oracle notes that every extraction method preserves relationships if the internal ID is exported with each row. Without it, linking a sales order to its customer, or an invoice to its vendor, depends on names that may be duplicated or changed. Odoo recommends External IDs when importing from a third-party application, and ERPNext's Data Import tool supports child table rows, so you can map each NetSuite internal ID to a stable reference in the target system. Also confirm with Excel users that 16-digit or longer numbers stay intact, because NetSuite warns that Excel shows them in scientific notation unless the file is opened through the Text Import Wizard or LibreOffice.
Can DeployOpen run the NetSuite data extraction under a fixed-scope agreement?
DeployOpen plans, implements, customizes, integrates and documents self-hosted open-source platforms inside the client's own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. An extraction plan covering the methods, record types, internal ID handling, reconciliation steps and staff roles can be written into that scope. DeployOpen does not hold NetSuite credentials or administrative rights by default, so access, role assignments and any SuiteAnalytics Connect purchase remain with your organization. Ask for a written scope that names who performs each export step and who approves the results. DeployOpen does not publish a price list, and a quote follows from that written scope.
What to plan before the NetSuite contract ends
Most of the export work is decided by contract terms and calendar dates, not by tooling. The cards below cover the decisions that determine what you can extract, when you must start, and what you still need after the subscription stops. Confirm every notice period and data return term in your own agreement with Oracle before you act on any of them.
Confirm export rights and roles
Full CSV Export is available only to the Administrator role, so check who in your organization holds that role and whether your contract with Oracle grants you the access you need. Ask Oracle in writing which extraction methods are included in your subscription. SuiteAnalytics Connect over ODBC, JDBC or ADO.NET is an additional service with an associated fee, so confirm that cost before you plan around it.
Schedule extraction before the notice date
Work backward from your notice deadline and the cutover you want, then set dates for each extraction pass. Repeated test exports reveal missing lists, truncated fields and formatting problems early, when a fix is still cheap. Do not leave the first full extraction until after notice has been given, because the data you need may be harder to reach once access narrows.
Decide what must be retained
Identify which records you must keep for audit, tax and legal purposes, including transaction detail, customer and vendor history, and closed periods. Ask your finance, legal and tax advisers which retention periods apply in each jurisdiction where you file. Keeping a copy outside NetSuite does not replace a retention decision, so record who owns each dataset and where it will be stored.
Plan a read-only reconciliation period
Agree a window after cutover in which NetSuite stays available to compare balances, open transactions and reports against the target system. Report CSV exports are easier to match to totals than saved searches for transaction data, so use them as the reference for reconciliation. Set clear exit criteria, such as agreed totals per period and per subsidiary, before anyone switches off the old system.
Arrange access to historical data
Confirm what happens to your NetSuite data after the subscription ends, including how long you can sign in, whether read access continues, and how data is returned or deleted. Ask Oracle for these terms in writing. Where the contract is silent, treat your own exported archive as the only reliable copy of historical records and keep it in a location you control.
Budget for the target platform
Odoo Enterprise and ERPNext both carry costs beyond the software itself, including hosting, implementation, data migration and ongoing support. ERPNext self-hosting is free as a license, but the ERPNext pricing page notes that implementation is available through certified partners. Request written quotes that separate data mapping, import runs, customization rebuild and testing, so the budget reflects the scope you agreed.
What to do with the files once you have them
An exported file is only useful once it has been loaded into the target system and checked there. Treat the export as the start of a staged load, not as the migration itself. Load the master data first (customers, vendors, items, employees), then the open transactions and balances, and check each stage against totals from NetSuite before moving on. Keep the internal ID column in every file, because it is the key that lets you rebuild customer-to-invoice and item-to-line relationships later.
Odoo can import data into any business object from Excel (.xlsx) or CSV files, and its documentation recommends using External IDs when the source is a third-party application, so the NetSuite internal ID can be stored as the external reference on each record. ERPNext Data Import reads CSV or Excel files, or public Google Sheets, using downloadable templates, and supports child table rows for documents with line items. Its documentation advises importing only a few thousand records at a time, so split large masters into batches and reconcile counts after each one. Confirm the current limits and template layouts against the Odoo export and import documentation and the ERPNext Data Import guide for the version you deploy.
The detailed work of mapping NetSuite fields to each target's chart of accounts, items, customers and opening balances is covered in the sibling migration guides for Odoo and ERPNext. Before you start those mapping exercises, agree who signs off each reconciliation, which NetSuite report is the reference for totals, and how files containing long numeric IDs are opened, since spreadsheet applications can change them when they are saved.
How DeployOpen scopes and delivers a NetSuite data export
DeployOpen treats a NetSuite data export as a written, fixed-scope engagement. We map which extraction method covers each record type, keep internal IDs in every file, and deliver the export into your own environment, ready for an Odoo or ERPNext import.
How we scope
- We inventory which lists, saved searches and reports your business depends on for the export.
- We confirm which record types Full CSV Export omits and which need saved searches or SuiteTalk.
- We agree in writing whether SuiteAnalytics Connect access, with its associated fee, is in scope.
- We confirm your NetSuite role access, since Full CSV Export is limited to the Administrator role.
How we build
- We build repeatable extraction runs and retain internal IDs on every exported row.
- We check Excel-sensitive fields such as 16-digit numbers, keeping them as text where needed.
- We reconcile exported transaction totals against NetSuite reports before any file is accepted.
- We prepare target import templates for Odoo or ERPNext, sized to load in controlled batches.
How we hand over
- You receive the export files, extraction scripts and a reconciliation log, all stored in your environment.
- We document each extraction method, its limits and the record types it does not cover.
- We walk your team through the mapping from NetSuite internal IDs to External IDs in the target system.
How we support
- Ongoing support, upgrades and re-extraction runs are available as a retainer after handover.
- Re-running exports for cutover or a period close is agreed in the written scope, not assumed.
- Ask any provider to confirm the NetSuite edition, role and API access your organization holds.
