How to migrate to NetSuite without losing data or momentum

A NetSuite migration is rarely about the software itself. The platform is cloud-based and ready to configure; the difficult part is deciding what to bring from your current setup, cleaning it, proving it is right and switching over on a date your finance team can live with. Whether you are moving to NetSuite from a tangle of spreadsheets, an entry-level accounting package or an ageing on-premise ERP, the same disciplines apply.

This page covers both senses of the word: migrating to NetSuite, and keeping your account healthy as NetSuite itself moves from one release to the next. For the wider picture, see our general guide to ERP migration.

Which kind of NetSuite migration are you facing?

The starting point shapes the project more than the destination does.

If you are still weighing up the platform, our page on NetSuite for UK businesses explains where it fits, and the alternatives page is worth a read before you commit.

Step one: decide what you are actually migrating

Migration is a good moment to be ruthless. Most UK SMEs and mid-sized firms discover that a large share of their legacy data is duplicated, dormant or wrong.

Group your data into four layers:

• Configuration: subsidiaries, departments, locations, currencies, tax codes, approval rules, roles and permissions.
• Master data: customers, suppliers, items, employees, projects and the chart of accounts.
• Open items: unpaid sales and purchase invoices, open orders, stock on hand, fixed assets and work in progress.
• History: closed transactions, past years' ledgers and attachments.

The first three are essential. The fourth is a judgement call, covered below.

Clean before you load

Loading dirty data into a clean system just creates a clean-looking system that produces wrong answers. Before any file is prepared:

• Merge duplicate customers and suppliers, and agree one naming convention.
• Retire inactive items, accounts and contacts.
• Standardise addresses, VAT registration numbers and payment terms.
• Reconcile the old ledger so that you know the trial balance you are migrating is correct.
• Name an owner in the business for each data set. A migration without data owners stalls on the first awkward question.

Step two: choose a loading method

NetSuite's own tooling covers the simpler cases. According to Oracle's documentation, the CSV import assistant (found under Setup > Import/Export > Import CSV Records and requiring the "Import CSV File" permission) takes you through five stages: scanning and uploading the file, setting import options, mapping files for multi-file imports, mapping fields, and finally saving the mapping and running the import. The import can run immediately or be queued for later.

That is enough for many master-data loads, and the saved mappings can be reused across test and live runs, which is exactly what you want. For more complex needs, such as large volumes, transformations from a legacy schema or continuing synchronisation, an integrator will usually combine scripted loads with the platform's integration capabilities. Our page on NetSuite integrations covers the options.

A sensible rule: load master data with simple tools, load transactions through a repeatable, scripted and documented process, and never load anything into production that has not already been loaded into a test account at least once.

Step three: handle history sensibly

How much history to bring is one of the most debated questions in any project. Our usual guidance is to separate what the system needs from what the business wants to look at.

• Opening balances by account, period and dimension give your ledger a clean start.
• Open transactions must be loaded as individual documents so that payments and credit notes can be matched against them.
• Summarised history by month or by customer lets you compare year on year without importing every line.
• Full detail can stay in an archive or read-only extract, with a named person responsible for retrieving it.

Check with your accountant what you must retain and in what form. UK businesses have record-keeping duties for tax, and VAT records in particular need to remain accessible. If you file through software under Making Tax Digital, make sure the new system's connection and digital links are settled before the first live return; our Making Tax Digital guide sets out what to ask your integrator.

Payroll deserves its own line. If employees, pensions or Real Time Information submissions are moving, plan the switch around a tax-period boundary and read the notes on payroll and RTI in an ERP first. Many firms keep a specialist payroll product connected to the ledger rather than migrating it at the same time as finance.

Step four: design the cut-over

The cut-over is the weekend, or the few days, when the old system stops being the record and NetSuite takes over. There are three main strategies.

Big bang

Everything switches on one date. It is the simplest to explain and the cleanest for reporting, but it concentrates the risk. It suits smaller organisations with a limited number of processes.

Phased by module or process

Finance goes first, then inventory, then manufacturing or projects. Risk is spread, but you must run temporary interfaces between old and new systems. Our pages on accounting and finance and inventory and purchasing show how the core areas hang together.

Phased by entity or location

Subsidiaries or sites go live one after another, often starting with a smaller entity as a pilot. This works well for groups with several legal entities, including those operating across England, Scotland, Wales and Northern Ireland.

Whichever you choose, align the switch with a period end. Going live in the middle of a month forces you to reconcile two systems in one period, and your accountant will not thank you.

Step five: test properly, more than once

Treat testing as the main activity of the project, not a phase at the end. A well-run migration typically includes:

1. Trial loads: the full migration run end to end in a test account, with timings recorded and errors logged.
2. Reconciliation: totals by account, customer and supplier ledgers, stock valuation and open orders agreed to the legacy system, line by line where necessary.
3. Process testing: real scenarios from order to cash, procure to pay and period close, executed by the people who will do them every day.
4. User acceptance: sign-off by named business owners, recorded.
5. Dress rehearsal: a final run of the cut-over plan, with the clock running.

Your people also need to be ready. Plan training for NetSuite before go-live, not after the first complaints.

Step six: write the rollback plan

A rollback plan is not pessimism; it is what lets the steering group take a calm decision at the worst moment.

Define in writing:

• Go/no-go criteria: which reconciliations must balance, and which defects are acceptable at launch.
• A decision point: the time by which you will either proceed or revert, and who decides.
• A frozen fallback: the legacy system kept intact, read-only or restorable, with its last good backup identified.
• A record of what was loaded: so that a failed load can be removed cleanly rather than patched.
• A communication plan: who tells customers, suppliers and the bank if the date moves.

For spreadsheet-based businesses, the fallback is simply the archived workbook and the old process; for a legacy ERP, it is the old system kept alive for a defined period.

Migrating between NetSuite versions

Once you are live, you will go through a different kind of migration every release. Oracle's documentation describes NetSuite 2026.2 as a planned version upgrade, delivered twice a year, that brings new features, enhancements and changes across the platform. Its release notes are organised into three families: the planned release notes, monthly release notes for improvements delivered after the upgrade, and notes for SuiteApps released separately.

The areas covered in 2026.2 include Ask Oracle (AI-based help and chat), Intelligent Close Manager and IFRS 18 support in accounting, passwordless authentication with passkeys, bank reconciliation, capacity planning in manufacturing, event subscribers and the LLM module in SuiteScript, and .xlsx export from SuiteAnalytics. Not every item will matter to you, but someone should read the notes and decide which do.

Use Release Preview

NetSuite provides a Release Preview account: a temporary, isolated test account, separate from production, that runs the new software version. According to Oracle, it lets you test customisations, SuiteScripts, web services integrations, online stores and SuiteAnalytics Connect access before the upgrade reaches your live account.

Some practical points from the documentation:

• It stays available until the source account is upgraded, or until there have been fourteen consecutive days without a login, after which it is purged.
• Initially only administrators can access it; they can then open it to other users.
• It is for testing only, so do not treat it as a place to keep work.

A sensible routine is to keep a regression checklist covering your key processes, scripts and integrations, and to run it in Release Preview each time. If you have a lot of bespoke code, see our page on NetSuite customisation and on versions and editions for how release cadence interacts with your build.

Mistakes to avoid

• Migrating the mess. Skipping cleansing because "we can tidy later" almost never happens.
• Recreating the old system. Copying every legacy report and workaround wastes the chance to simplify.
• Loading production first. Every load must have rehearsed in a test account.
• No data owners. Without them, nobody can answer whether a customer record is correct.
• Going live mid-period. It doubles the reconciliation effort.
• Under-investing in training. Users revert to spreadsheets if they cannot do their job on day one.
• Ignoring releases after go-live. Customisations and integrations that were fine last release may not be fine this one.
• No decision rules. If go/no-go criteria are not agreed beforehand, they get argued under pressure.

If a project has already stumbled, an independent NetSuite audit or project rescue can establish what is wrong before more money is spent.

Getting the right help

Most UK businesses do not run a migration alone; the value of a good integrator is in the lessons from previous cut-overs. We do not carry out migrations ourselves. We introduce you, free of charge, to an ERP integrator suited to your sector, size and starting point; our page on how it works explains the process. For the full project picture, from scoping through to support, see NetSuite implementation.

Software names mentioned are trademarks of their respective publishers and are referred to for information only. This site is independent and is not affiliated with any software publisher.