SAP Business One to NetSuite Migration

The problem with a CSV-only cutover

Most SAP Business One to NetSuite projects begin the same way: someone exports the item master, the business partner master and the open document tables to spreadsheets, then feeds them into the NetSuite CSV Import Assistant. It works for a few hundred simple records. It falls apart the moment the data reflects a real manufacturing or distribution business.

The failure points are predictable. B1 item masters carry a unit-of-measure group with multiple purchasing, sales and inventory UoMs plus conversion factors, which has no single-column equivalent in a NetSuite item record. Warehouse-level rows in B1 (OITW-style per-warehouse item settings) hold their own price, planning data, minimum stock and G/L account determination — flatten them into one NetSuite item and you lose the per-location reorder logic. Multi-level bills of material must be loaded parent-last or the component references fail, and phantom/template BOM types do not map one-to-one to NetSuite assembly items. Serial and batch records need to arrive with the correct on-hand quantity per bin and per warehouse or the first inventory count reveals a mess. Open A/R and A/P documents have to land as transactions that reconcile to a trial balance, not as an opening-balance journal that hides the ageing. And every foreign-currency open document needs an exchange rate consistent with the rate table you load, or the first revaluation posts nonsense.

What makes it worse is that these errors are silent. A CSV import that reports "succeeded" while mapping a UoM to the wrong base unit does not throw an error — it quietly halves your inventory value.

What ECOSIRE builds

ECOSIRE builds you a migration toolkit inside your own NetSuite account, delivered as an unmanaged bundle or SDF project you own outright. It is not a generic importer; it is scripted for your specific B1 configuration, your chart of accounts and your subsidiary structure.

Staging layer with custom records

We create custom record types that mirror your B1 source structures — a staging record per entity (items, business partners, BOM headers and lines, warehouses/bins, open A/R, open A/P, open sales and purchase orders, GL opening balances, serial/lot rows, price lists). Each staging record carries the original B1 key, the proposed NetSuite target, a validation status field, and an error text field. Nothing touches a real NetSuite record until its staging row validates clean.

Extraction and load pipeline

A SuiteScript 2.1 RESTlet accepts batched payloads from your B1 export (SQL views or a service-layer pull produced on your side, or by us during scoping) and writes them into staging. Map/Reduce scripts then run in phases: validate, transform, load, reconcile. Map/Reduce is used deliberately — it is the only governance-safe way to process tens of thousands of rows without hitting usage limits mid-run, and it gives you a per-key summary of what failed.

Mapping tables you control

All mapping lives in custom records you can edit without touching code: B1 G/L account to NetSuite account, B1 warehouse to NetSuite location, B1 UoM group to NetSuite unit type and base unit, B1 item group to NetSuite class or custom segment, B1 BP group to customer/vendor category, B1 tax code to NetSuite tax code or tax group, B1 payment terms to NetSuite terms. Because the mapping is data rather than hardcoded logic, a mid-project chart-of-accounts change is a record edit, not a rebuild.

Item, BOM and inventory handling

Items are created with the correct NetSuite item type per row — inventory item, assembly/bill of materials, non-inventory, service, kit/package — driven by your mapping table rather than assumed. Multi-level BOMs are topologically sorted so components exist before parents, and revisions are created as NetSuite bill of materials and bill of materials revision records linked to the assembly. Per-warehouse B1 data is written to the item's location-specific settings (preferred stock level, reorder point, location-level pricing where applicable) instead of being collapsed. Opening stock loads as inventory adjustments per location — and per bin and lot/serial number where you use them — so the resulting inventory value and quantity are auditable line by line.

Open transactions and balances

Open A/R and A/P load as individual invoices and bills carrying original document dates, numbers and currencies so ageing reports are correct from day one. Open sales and purchase orders load with remaining quantities so fulfilment and receipt continue mid-stream. GL opening balances post as journal entries per subsidiary, per currency, tagged with a custom segment so the migration is separable from live activity forever.

OneWorld and subsidiaries

If you run NetSuite OneWorld, every staging row carries its target subsidiary. Intercompany relationships, per-subsidiary accounting periods, base currencies and elimination accounts are respected during load, and reconciliation runs per subsidiary rather than as one blended total.

Reconciliation reporting

Saved searches ship with the build: source count versus loaded count per entity, source value versus loaded value for inventory and GL, unmatched keys, and a per-run error log. These are the artifacts you hand your auditor to prove the cutover balanced. A rollback routine can void or delete a run's loaded transactions by run ID, so a failed rehearsal is not a dead account.

Who this is for

Companies leaving SAP Business One where the data is genuinely complex: manufacturers with multi-level BOMs, distributors with several warehouses and bin management, businesses running batch or serial traceability, and groups consolidating multiple B1 databases into one NetSuite OneWorld instance. It also suits partners and internal IT teams who want a repeatable, rehearsable, auditable cutover instead of a weekend of spreadsheet surgery.

It is not for a single-entity company with a few hundred simple items and no open manufacturing — the standard CSV Import Assistant handles that, and we will tell you so on the call.

How delivery works

1. Scoping call. We review your B1 database structure, entity volumes, UoM groups, BOM depth, warehouse and bin setup, batch/serial usage, currencies, subsidiary structure and cutover date. We agree what migrates, what stays in B1 as historical archive, and what the reconciliation targets are. 2. Fixed quote. A written scope with the entity list, mapping responsibilities, rehearsal count and timeline. Price is fixed against that scope; anything discovered later is quoted separately before work starts. 3. Build. We develop the staging records, RESTlet, Map/Reduce phases, mapping records and reconciliation searches against your configuration. Typical lead time is one working week depending on entity count and BOM complexity. 4. Install in your sandbox. The bundle deploys to your NetSuite sandbox or a Release Preview account first. We run at least one full rehearsal against real extracted data, reconcile it, hand you the variance report, correct mappings and rerun. Rehearsals are the point — this is where mapping errors surface cheaply. 5. Production cutover. Once a rehearsal reconciles to your satisfaction, we install into production and run the load on your agreed cutover window, with reconciliation reports produced live. 6. Support window. Post-go-live support covers defects in what we built, rerun assistance and mapping corrections. You own the source, so your team or ours can extend it afterwards.

We do not read from your SAP Business One database directly unless you explicitly grant access and a method during scoping; the default is that your team or your B1 partner produces the extract and our pipeline consumes it.