Free checklist · 36 checks
The NetSuite Integration Readiness Checklist
Most NetSuite integrations that fail were never going to work: two systems both believed they owned the same data, nobody planned for errors, or the design ignored the account’s API limits. Run these checks before you connect anything to NetSuite. Every “no” is a risk worth resolving first.
Scope and ownership
- Every system that will read from or write to NetSuite is listed, including spreadsheets and manual imports.
- Each record type (items, customers, sales orders, fulfillments, invoices) has one system named as its source of truth.
- Sync direction is decided per record type: one-way, two-way, or write-once.
- A named person owns the integration after launch, and knows they do.
- Your NetSuite partner and your integration developer know who changes scripts, roles, and custom records.
Data model
- Item structure is settled: matrix items, kits, assemblies, and how variants map to the other system.
- Custom fields and custom records the integration depends on are documented with their internal IDs.
- Units of measure, currencies, and subsidiaries are mapped explicitly, not assumed.
- Customer and address matching rules are defined, so duplicates are not created on every sync.
- Pricing logic (price levels, customer-specific pricing, quantity breaks) is written down in one place.
- External IDs are set on synced records so both sides can find each other without guessing.
Freshness and volume
- You know how fresh each data type must be: seconds, minutes, or daily.
- Peak volumes are estimated, including seasonal spikes and bulk catalog updates.
- The design fits within your account’s API concurrency limit for your service tier.
- Long-running work runs in scheduled or map/reduce scripts, not in user-event scripts that slow down saves.
- Saved searches or SuiteQL queries used by the integration have been tested at production data volume.
Failure handling
- Every failed sync lands somewhere visible: an error queue, a report, or an alert, not just a log file.
- Writes are idempotent, so a retry cannot create a duplicate order or payment.
- There is a documented way to replay a failed record after fixing the cause.
- Someone is notified when the integration stops running entirely, not only when a record fails.
- You have decided what customers see when NetSuite is slow or unavailable.
Security and access
- The integration uses a dedicated role and token-based authentication, not a person’s login.
- That role has only the permissions the integration needs.
- Credentials live in a secrets manager or environment configuration, never in code or shared documents.
- Access can be revoked for a vendor without breaking anything else.
Testing
- A sandbox account is available and reasonably close to production.
- Test cases cover edge cases: partial shipments, returns, backorders, and price changes mid-order.
- Initial data load and ongoing sync are planned as separate jobs.
- Success is defined in numbers before launch, such as sync lag, error rate, and orders needing manual touch.
Go-live and the first two weeks
- There is a cutover checklist with named owners and a rollback plan that says who decides to use it.
- Orders and transactions in flight at cutover have a decided home: finished in the old process or moved, never both.
- Reference data (items, customers, prices) syncs and is checked before any transactions flow.
- Manual entry of the records the integration now creates stops on a named date, so nothing is entered twice.
- The first day’s synced orders are compared one by one with the source system.
- The old import, script, or connector is switched off, not left running beside the new one.
- The integration owner reviews the error queue every day for the first two weeks.