How to Migrate from NetSuite to Odoo:
The Enterprise Downgrade Guide

Why Mid-Market Companies Start Looking at Alternatives to NetSuite

Most companies don't wake up one morning and decide to migrate off NetSuite. The decision builds over several quarters, usually triggered by one of five recurring patterns. We've walked into enough rooms where the CFO is staring at a renewal quote and the CIO is holding a list of broken customizations to know the pattern by memory. This section lays out the triggers honestly — not to bash NetSuite, which is a capable product, but because understanding why you're moving changes how you should move.

Trigger 1: The Renewal Quote

The most common trigger is a renewal quote that comes in 30 to 60 percent above the previous year. NetSuite's pricing is per-user and per-module, and Oracle's renewal strategy leans on cost-of-living adjustments plus usage-based increases for storage, transactions, and API calls. A company that paid $72,000 a year three years ago often sees a quote for $140,000 at renewal — with no new modules added. When the finance team realizes they're paying more for the same functionality, they start looking.

Trigger 2: Forced Upgrades Breaking Customizations

NetSuite pushes two major version upgrades per year. These are not optional. If your account has SuiteScript customizations — client scripts, user event scripts, suitelets, scheduled scripts — there's a real chance one of them breaks after an upgrade because a deprecated API was removed or a governance limit changed. The 2023.2 release alone deprecated several N/record patterns and forced dozens of our clients into emergency re-engineering sprints. When you're spending two weeks per year firefighting upgrades, the hosted model stops feeling like a benefit.

Trigger 3: SuiteScript and SuiteBundle Technical Debt

After five or more years on NetSuite, most accounts accumulate a forest of SuiteBundles, custom records, custom fields, saved searches, workflows, and scripts — often written by three different consultants who no longer work with the company. The original business logic is scattered across bundle dependencies, script libraries, and workflow state transitions. Nobody fully understands what still fires and what is dead code. A migration forces a clean slate: you document the actual business logic, rebuild it intentionally, and leave the dead code behind.

Trigger 4: Acquisition or Divestiture

M&A activity frequently triggers NetSuite exits. When a company is acquired, the parent often standardizes on a different ERP — sometimes Odoo, sometimes SAP, sometimes a home-grown stack. When a division is divested, the new entity needs its own instance, and a fresh NetSuite instance means a fresh NetSuite contract at full list price. At that point, comparing the TCO of a second NetSuite instance against a full Odoo implementation becomes straightforward arithmetic.

Trigger 5: Operational Scope Outgrowing the Base Modules

NetSuite bills by module. Expanding into manufacturing means buying Advanced Manufacturing. Adding a webstore means buying SuiteCommerce. Adding field service means a third-party integration or a bundle. Each addition is another line on the invoice and another integration point to maintain. Odoo's bundled application model — where MRP, eCommerce, Field Service, Project, and Helpdesk are all part of the same platform — becomes attractive once you're running more than three or four NetSuite modules.

If one of these triggers matches your situation, the next question isn't whether to move — it's whether you can actually move cleanly. That's a feasibility question, and it's the next section.

Extracting Data from NetSuite: Saved Searches, CSV, REST, and SuiteQL

NetSuite does not have a one-click "export everything" button. Data extraction is a multi-day process using four different mechanisms — each with its own quota limits, format quirks, and failure modes. The goal is to produce a clean, reproducible extract that you can re-run on cutover weekend with confidence. Here is the playbook we use, broken down by data domain.

Extraction Mechanism 1: Saved Searches with CSV Export

Saved Searches are the most approachable tool. Build a search in the NetSuite UI, add every field you need as a result column, and export as CSV. This works for record counts up to about 50,000 rows per export before the UI times out. For customers, vendors, items, and small transaction sets, Saved Searches are fast and reliable. The gotcha: CSV exports lose hierarchy — a sales order with 20 line items exports as 20 rows, and you have to reconstruct the parent-child relationship on import.

Extraction Mechanism 2: REST Web Services (SuiteTalk REST)

For structured record extraction with full relational integrity, use NetSuite's REST API. Authenticate via OAuth 2.0, paginate through record types, and pull the full JSON representation including sublists. This preserves parent-child relationships (sales order header + lines, invoice header + lines) as nested objects. REST is the right tool for transactional records. Watch governance: REST calls cost governance units, and large extracts can burn your daily quota.

import requests
from requests_oauthlib import OAuth1

# Token-based authentication (TBA)
auth = OAuth1(
    client_key='CONSUMER_KEY',
    client_secret='CONSUMER_SECRET',
    resource_owner_key='TOKEN_ID',
    resource_owner_secret='TOKEN_SECRET',
    signature_method='HMAC-SHA256',
    realm='ACCOUNT_ID',
)

BASE = 'https://ACCOUNT_ID.suitetalk.api.netsuite.com/services/rest/record/v1'
url = f'{BASE}/salesOrder?limit=1000&offset=0'
all_orders = []

while url:
    r = requests.get(url, auth=auth, timeout=60)
    r.raise_for_status()
    data = r.json()
    # Expand each link to full record
    for item in data.get('items', []):
        detail = requests.get(item['links'][0]['href'], auth=auth)
        all_orders.append(detail.json())
    url = next(
        (l['href'] for l in data.get('links', []) if l['rel'] == 'next'),
        None,
    )

print(f'Extracted {len(all_orders)} sales orders')

Extraction Mechanism 3: SuiteQL (SQL-Style Queries)

SuiteQL is NetSuite's SQL-like query language, accessible via the REST /query/v1/suiteql endpoint. This is the best tool for GL extraction, trial balance reconstruction, and any reporting-style pull where you need joins across tables. SuiteQL is the only practical way to extract five years of transaction lines without writing 50 overlapping Saved Searches. The quirk: SuiteQL has a 100,000-row result cap per query. Chunk by date range (one month per query) to stay under the cap.

SELECT
  transaction.id            AS tx_id,
  transaction.tranid        AS tx_number,
  transaction.trandate      AS tx_date,
  transaction.type          AS tx_type,
  transactionline.accountid AS account_id,
  account.acctnumber        AS account_code,
  account.acctname          AS account_name,
  transactionline.debit     AS debit,
  transactionline.credit    AS credit,
  transactionline.memo      AS memo,
  transactionline.subsidiary AS subsidiary_id
FROM transaction
INNER JOIN transactionline
  ON transactionline.transaction = transaction.id
INNER JOIN account
  ON account.id = transactionline.accountid
WHERE transaction.posting = 'T'
  AND transaction.trandate BETWEEN TO_DATE('2025-01-01', 'YYYY-MM-DD')
                               AND TO_DATE('2025-01-31', 'YYYY-MM-DD')
ORDER BY transaction.trandate, transaction.id

Extraction Mechanism 4: CSV Bulk Export for Large Tables

For record types with hundreds of thousands of rows (transaction lines in large accounts, item demand plans, price levels), Saved Search export times out and REST becomes slow. The workaround: scheduled CSV exports via the NetSuite file cabinet. Configure a Saved Search to email or FTP a CSV on a schedule, then script the pickup. This is less elegant than REST but survives large volumes.

What to Extract, By Domain

Staging the Extract

Land every extract into a staging database (PostgreSQL is ideal — same engine as Odoo) with tables mirroring NetSuite record structures. This gives you a single source of truth to run transformations against, lets you re-run the extract multiple times without ambiguity, and provides a clean audit trail. Do not transform data in the extraction step. Extract raw, transform in staging, load into Odoo. E-T-L, not E-T-T-L.

Mapping and Loading into Odoo: Subsidiaries, Custom Records, Workflows

The import side is where the migration either lands cleanly or turns into a three-month reconciliation nightmare. Odoo's data model is similar to NetSuite's in shape — accounts, partners, products, orders, invoices, journal entries — but the naming and relational rules differ. The work is translating NetSuite's constructs into Odoo's equivalents without losing business meaning.

Subsidiaries → Companies

A NetSuite subsidiary maps to an Odoo res.company record. The elimination subsidiary in NetSuite OneWorld does not have a direct Odoo equivalent — consolidation happens through the Odoo Consolidation module, which uses mappings between each company's chart of accounts and a consolidated chart. Inter-company transactions use the native inter-company module, which automatically creates mirrored invoices and bills between companies.

Custom Records → Analytic Accounts or Custom Models

NetSuite custom records are the equivalent of Odoo custom models. For each custom record type in NetSuite, decide: is this a new Odoo model, or is it better expressed as an analytic account, tag, or extension field on an existing model? Simple classification records (cost centers, departments, projects) usually become account.analytic.account entries with analytic plans. Operational records (field inspections, asset logs, compliance certificates) become new Odoo models via a small custom module. Lightweight reference records often become Selection fields or Many2one targets on existing models.

SuiteScript Workflows → Odoo Server Actions and Automations

SuiteScript client scripts (fieldChanged, validateField, saveRecord) translate to Odoo's @api.onchange methods and web-client JavaScript widgets when genuinely needed. SuiteScript user event scripts (beforeSubmit, afterSubmit) map to Odoo model method overrides or ir.actions.server server actions triggered by base automations. Scheduled scripts become Odoo ir.cron jobs. Most SuiteScript business logic compresses to 30 to 60 percent of its original size in Odoo because you're no longer fighting the NetSuite execution model.

SuiteFlow Workflows → Studio Automations and Approvals

SuiteFlow state-machine workflows map to Odoo Studio's automation rules plus the Approvals module for request-based flows. Simple state transitions (draft → pending → approved → posted) are already built into Odoo's standard document flow and do not need to be rebuilt. Conditional approvals (amount thresholds, department-based routing) map to the Approvals module with approver assignment rules.

Approvals → Odoo Approvals Module

NetSuite approvals (purchase orders, expense reports, journal entries, bills) port cleanly to Odoo's Approvals module or the built-in purchase approval workflow. The one difference worth calling out: NetSuite's approval routing tends to be role-based and scripted in SuiteScript. Odoo's approval routing is configurable via Studio and stored in approval.category records, which is easier to maintain but requires mapping each approval type during the migration.

Load Order That Prevents Pain

Load data into Odoo in dependency order: company settings → chart of accounts → tax codes → partners (customers and vendors) → products → employees → opening balance journal → open AR → open AP → open sales orders → open purchase orders → custom records. Each load step validates the previous step. Never load transactions before master data is locked in, and never load opening balances before the chart of accounts is complete. Our checklist has 23 sequential steps, and we've never had a clean cutover with fewer than 20 of them.

Translating SuiteScript and SuiteFlow into Odoo Python

This is where honest estimation matters. Most migration proposals understate customization effort because nobody wants to quote the real number. A heavy SuiteScript estate — say, 80 to 150 scripts with business logic — will consume 40 to 80 additional engineering hours per major script to analyze, rebuild, and test in Odoo. Padding that number during sales will get you the deal and lose you the project.

Pattern 1: SuiteScript Client Script → Odoo onchange

Client scripts that update field values on the form (recalculating totals, defaulting values based on other fields) translate to @api.onchange methods in Odoo. The Odoo version is almost always shorter because the ORM handles persistence and UI refresh for you.

from odoo import api, fields, models


class SaleOrderLine(models.Model):
    _inherit = 'sale.order.line'

    @api.onchange('product_id', 'product_uom_qty')
    def _onchange_apply_volume_discount(self):
        """Auto-apply tiered discount based on quantity —
        equivalent to a SuiteScript client fieldChanged event."""
        for line in self:
            qty = line.product_uom_qty or 0
            if qty >= 100:
                line.discount = 15.0
            elif qty >= 50:
                line.discount = 10.0
            elif qty >= 10:
                line.discount = 5.0
            else:
                line.discount = 0.0

Pattern 2: SuiteScript User Event (beforeSubmit) → Odoo create/write override

User event scripts that validate or modify a record before save map to Odoo create() and write() method overrides. Odoo's ValidationError replaces SuiteScript's throw nlapiCreateError.

from odoo import api, models
from odoo.exceptions import ValidationError


class AccountMove(models.Model):
    _inherit = 'account.move'

    @api.constrains('invoice_line_ids', 'partner_id')
    def _check_customer_credit_hold(self):
        """Block invoice post if customer is on credit hold —
        replicates a classic SuiteScript beforeSubmit rule."""
        for move in self:
            if move.move_type != 'out_invoice':
                continue
            if move.partner_id.credit_hold:
                raise ValidationError(
                    f"Customer {move.partner_id.name} is on credit hold. "
                    "Resolve the hold or request a manager override."
                )

Pattern 3: SuiteFlow Workflow → Odoo Automated Action

SuiteFlow workflows that trigger emails, update fields, or call scripts based on record state changes map to Odoo's base.automation rules. These can be configured in the UI (Studio) or defined in XML for version control. For state changes that need to fire code, the automation runs a server action that calls a Python method.

Honest Effort Estimates by Customization Type

A typical mid-market NetSuite account with 60 to 120 active customizations translates to 400 to 900 engineering hours on the customization workstream alone. That's on top of data migration, configuration, training, and parallel run. Price accordingly.

Frequently Asked Questions About NetSuite to Odoo Migration