Requirements gathering: document processes, not features
The single most common mistake in ERP selection is starting from a feature list. NetSuite's demo will show you dashboards, revenue recognition, and multi-subsidiary consolidation, and all of it will look great, because demos always do. What the demo can't tell you is whether your quote-to-cash process, your month-end close, or your return-and-credit flow maps onto the way NetSuite wants those processes to run. That's on you to document first.
Before any sales call, write down your ten to fifteen core business processes as they actually run today, including the exceptions and workarounds. For each one, note who touches it, what systems it crosses, and where it breaks. Then mark each process as standard (any ERP handles it), configurable (needs setup but no code), or custom (needs development). NetSuite customization means SuiteScript development and SuiteFlow workflows, and every process in the custom column is billable partner work that also needs re-testing when NetSuite pushes its twice-yearly releases.
- Document core processes as they run today, exceptions included, before the first demo.
- Classify each process as standard, configurable, or custom development.
- Get every department head to sign off on their processes in writing.
- Rank requirements as must-have, should-have, and nice-to-have, and score the demo against the must-haves only.
Data migration scope: decide what history you're bringing
Data migration is where ERP budgets quietly die, because it's usually scoped after the contract is signed rather than before. The requirement to pin down early is simple to state and painful to answer: which records, how far back, and at what level of detail. Master data (customers, vendors, items, the chart of accounts) always comes over. The expensive question is transactional history: open orders and open AR/AP are non-negotiable, but three years of closed invoices is a scoping decision with a real price tag attached.
NetSuite's native path for bringing data in is CSV imports, which works well for clean master data and becomes a mapping project for anything messy. Budget time for cleansing before migration, not during it: duplicate customers, stale SKUs, and inconsistent naming conventions cost far more to fix inside a live system than in a spreadsheet the month before. And decide up front where the old system's archive will live once you switch off its license, because "we'll keep it read-only forever" often carries its own recurring fee.
- List every data object to migrate: master data, open transactions, historical transactions.
- Set an explicit history cutoff and get finance to agree to it in writing.
- Schedule a data cleansing pass before migration starts, with a named owner.
- Plan at least one full trial migration into a sandbox before the real one.
- Decide where legacy history lives after cutover, and what that costs annually.
Integrations inventory: list every system that touches the ERP
Walk the org chart and list every system your teams use that will need to talk to the ERP: e-commerce storefronts, 3PL and shipping platforms, payment processors, payroll, CRM if it stays separate, EDI with large retail customers, banks, tax engines, BI tools. For each connection, write down the direction of data flow, the frequency (real-time or batch), and the volume. This inventory is one of the biggest cost drivers in the entire project, and it's the one buyers most often leave to "phase two."
For NetSuite specifically, ask each vendor on your list whether they offer a supported native connector, whether the integration runs through an iPaaS layer (Celigo, Boomi, and similar platforms are common in the NetSuite ecosystem), or whether it means custom SuiteTalk API work. Each of those tiers carries a different build cost and, importantly, a different recurring subscription. An integration layer that costs meaningful money every month is a permanent line item, so it belongs in your five-year cost model, not just the implementation budget.
- Inventory every connected system with direction, frequency, and data volume.
- Classify each as native connector, iPaaS-mediated, or custom API work.
- Capture the recurring subscription cost of every middleware layer, not just the build cost.
- Flag any integration on the critical order-to-cash path as a go-live blocker, not a phase two item.
Licensing and user counts: model the renewal, not the intro quote
NetSuite is sold as an annual subscription made up of a base platform fee, per-user licenses, and separately priced modules, and the pricing isn't published: every number arrives through a sales process. That structure has two practical consequences for your checklist. First, count your real users honestly, including the warehouse staff, part-time approvers, and seasonal workers who only touch the system occasionally, because full-access users are the metric that scales the bill. Second, list which modules your must-have requirements actually depend on, since capabilities that look core in the demo may be add-ons on the order form.
Then model the renewal, not just year one. First-year discounting is common in enterprise software sales generally, and the number that matters is what the subscription costs in year two and beyond once introductory pricing lapses. Ask for multi-year price protection in writing, ask what happens to the rate when your user count grows, and get the full module list itemized so you can see what each piece costs on its own. If the five-year number makes the room uncomfortable, better to find out now, which is exactly the moment to look at where NetSuite costs tend to accumulate.
- Count all real users, including occasional and warehouse users, before requesting a quote.
- Map every must-have requirement to the specific module that provides it.
- Get year-two-and-beyond pricing and renewal caps in writing, not verbally.
- Build a five-year total cost model: licenses, modules, integrations, partner support, and sandbox environments.
Implementation partner evaluation: interview the team, not the logo
NetSuite implementations are delivered either by NetSuite's own professional services arm, often through its packaged SuiteSuccess methodology, or by a solution-provider partner. Either way, the delivery team you get matters more than the brand on the proposal. Ask who, by name, will run your project, how many implementations that person has led in your industry, and how much of the work is subcontracted. Ask for references you can actually call, from companies your size, that went live more than a year ago, because year-two references tell you how the system aged, not just how the go-live party went.
Scrutinize the statement of work as hard as the price. Fixed-scope proposals that assume your requirements are "standard" convert every real-world wrinkle into a change order. Confirm what happens after go-live: who answers tickets, what support costs monthly, and whether the people who built your customizations are the ones maintaining them. The questions in our partner vetting guide were written for Odoo partners, but every one of them applies to a NetSuite partner too.
- Get the named delivery team and their industry track record, not the sales team's bios.
- Call references your size that are at least a year past go-live.
- Read the SOW for change-order triggers: what counts as "out of scope"?
- Price post-go-live support explicitly, including who maintains custom scripts.
Timeline and budget reality: plan in quarters, not weeks
ERP timelines are measured in months, not weeks, and NetSuite is no exception. Packaged approaches like SuiteSuccess advertise fast activation for simple, single-entity businesses, and that's real as far as it goes. But the clock that matters runs until your team transacts confidently in the new system, and for a mid-market company with integrations, data history, and custom processes, that journey routinely spans several quarters from kickoff to stable operation. Every custom requirement, every integration, and every mid-project scope change stretches it further.
Budget the same way. The subscription is only one layer of the total: implementation services, integration builds and their recurring platform fees, data migration, training, and internal time all stack on top, and implementation services alone are commonly quoted as a substantial fraction of, or a multiple of, the first-year subscription depending on complexity. Add a contingency reserve you control, because scope discovered mid-project is the rule rather than the exception. If you want a sense of what a realistic ERP schedule looks like phase by phase, our implementation timeline guide breaks one down; the phase structure applies to any ERP, NetSuite included.
- Plan the timeline to "team transacts confidently," not to the contractual go-live date.
- Budget every layer: subscription, services, integrations, migration, training, internal time.
- Hold a contingency reserve for scope discovered mid-project.
- Sequence around your business calendar: never cut over during your peak season or fiscal year-end close.
Go-live readiness: define "done" before you start
The last checklist section is the one to write first, because it defines what finished looks like. Set measurable acceptance criteria per department: finance can close a month in the new system, the warehouse can receive, pick, and ship a real order end to end, sales can quote and invoice without touching the old system. Run at least one full user-acceptance test cycle on migrated data, not sample data, and make department leads sign the results.
Decide your cutover strategy deliberately: big-bang cutover is faster but concentrates risk into one weekend, while running parallel for a period is safer but doubles data entry while it lasts. Either way, name a hypercare period after go-live during which the implementation team stays on call and issues get same-day triage, and agree on the rollback criteria nobody likes to discuss. Teams that skip this section are the ones that discover, three weeks after cutover, that go-live was declared rather than achieved. The failure patterns are remarkably consistent across platforms; our rundown of seven ERP warning signs reads the same whether the logo is Odoo or NetSuite.
- Write measurable, per-department acceptance criteria before the project starts.
- Run UAT on migrated production data, with sign-off from department leads.
- Choose big-bang or parallel-run deliberately, with rollback criteria agreed in advance.
- Contract a named hypercare period with same-day issue triage after cutover.
The full checklist in one table
Here is the whole thing condensed. Score each row before you sign: green if the requirement is documented and priced, yellow if it's understood but unquantified, red if nobody has looked at it yet. A contract signed with red rows on this table is a change order waiting to be invoiced.
| Requirement area | The question to answer | Red flag if... |
|---|---|---|
| Requirements gathering | Which processes are standard, configurable, or custom? | The feature demo happened before the process documentation |
| Data migration | Which records, how far back, cleansed by whom? | Migration is a single line item with no object list |
| Integrations | Native connector, iPaaS, or custom API, per system? | Critical integrations are deferred to "phase two" |
| Licensing & users | What does year two cost at the real user count? | Only the discounted first-year number is on paper |
| Partner evaluation | Who delivers, and what did their year-old projects become? | References are all recent go-lives hand-picked by sales |
| Timeline & budget | What is the all-in five-year cost with contingency? | The plan is denominated in weeks and has no reserve |
| Go-live readiness | What are the measurable acceptance criteria per department? | "Done" is a date on a Gantt chart, not a test result |
When the checklist points away from NetSuite
Sometimes the honest answer to this checklist is that NetSuite is the right call: it's a mature, deep platform, and for multi-subsidiary companies with complex revenue recognition and the budget to match, it earns its place. But the checklist exists precisely because the exercise sometimes points the other way. If your five-year license model keeps climbing at renewal, if most of your "custom" column could be standard configuration on a more flexible platform, if the module-by-module pricing turns every new requirement into a procurement cycle, or if you're a sub-100-person company being asked to carry enterprise-grade implementation fees, those are signals worth taking seriously before you sign, not after.
The useful next step is a structured comparison rather than a leap. Our Odoo vs NetSuite comparison puts the two platforms side by side on licensing model, customization approach, and total cost profile, using the same requirement areas as this checklist. And if you're already on NetSuite and the renewal math is what brought you here, the NetSuite to Odoo migration guide covers what moving actually involves: data extraction, process mapping, and a phased cutover that doesn't bet the company on one weekend.
Either way, the checklist above is platform-neutral on purpose. Run NetSuite through it, run Odoo through it, run anything else on your shortlist through it, and let the red and yellow rows make the argument. The ERP that survives your requirements honestly is the one worth signing for.
See the full Odoo vs NetSuite comparison →