NetSuite Migration Toolkit

The problem

Leaving NetSuite is rarely a technical decision — it is a renewal-cost decision. But the moment the renewal is declined, the finance team discovers the real work: every customer, vendor, item, price list, open invoice, open purchase order, unapplied credit and trial-balance line has to arrive in SAP Business One intact, and the auditor will ask you to prove it did.

NetSuite does not hand you a migration package. It hands you saved searches and CSV exports built around internal IDs, sublists and custom record types that have no direct counterpart in SAP Business One. A spreadsheet-and-DTW approach usually survives the customer master and then collapses on the parts that matter: partially applied invoices, multi-currency open items, landed-cost history, tax codes that no longer map one-to-one, and a general ledger whose account numbering scheme was never designed for SAP B1's chart-of-accounts drawer structure.

The consequence is predictable — go-live slips, the opening trial balance does not tie, and someone spends the first month after cutover reconciling by hand.

What ECOSIRE builds

This is a build-to-order toolkit. Nothing is downloaded and nothing is pre-built: after a scoping call we build the migration engine against your NetSuite extract shapes and your target SAP Business One company database, then install and run it with you.

The toolkit is delivered as a SAP Business One add-on plus a staging layer:

Staging and mapping layer

We create User-Defined Tables (UDTs) inside your SAP B1 company database to hold the raw NetSuite extract exactly as exported, before any transformation. Every source row keeps its NetSuite internal ID in a User-Defined Field (UDF) on the created SAP B1 object, so any record in SAP Business One can be traced back to the row it came from. Mapping tables — account-to-account, tax-code-to-tax-code, item-group, payment terms, currency, subsidiary-to-company or branch — are maintained as UDO-backed forms so your controller can review and adjust the mapping without touching code or SQL.

Master data conversion

Business Partners (customers, vendors, leads) are created through the Service Layer BusinessPartners endpoint with their addresses, contact persons, payment terms, credit limits, price lists and control accounts. Items are created as Items with item groups, UoM groups, barcodes, purchasing/sales UoM, warehouse rows and planning data. Price lists, special prices and volume discounts, business partner catalogue numbers, and the item-to-warehouse assignment are all included.

Chart of accounts and opening balances

We convert the NetSuite account list into SAP Business One's segmented, drawer-based ChartOfAccounts, respecting active/title account structure and the five drawers. Opening balances are posted as balanced JournalEntries — by control account for AR and AP so subsidiary ledgers and the general ledger agree — with profit centres/dimensions and project codes carried where you use them.

Open transactions

This is where most migrations fail, so it is where most of the build effort goes. We migrate open A/R Invoices, A/R Credit Memos, A/P Invoices, A/P Credit Memos, open Sales Orders, open Purchase Orders, and unapplied incoming/outgoing payments. Partially paid documents are brought in at their remaining balance with the original document number and date preserved in UDFs, so ageing buckets in SAP B1 match the NetSuite ageing you signed off. Multi-currency open items carry their original document currency, local-currency amount and the rate used, so realised/unrealised FX behaves correctly after cutover.

Inventory

Stock is loaded per warehouse with valuation method respected — moving average, standard or FIFO layers, using Inventory Postings (or Goods Receipts against an opening-stock account) so that quantity and value both land correctly. Serial and batch numbers, including their attributes and expiry dates, are migrated where you track them. Bin locations are supported where bin management is enabled.

Reconciliation proof

Every run produces reconciliation output — not a log file, a proof. Source-versus-target counts and totals for every object, an AR/AP ageing comparison at the cutover date, a trial-balance comparison, an inventory quantity-and-value comparison per warehouse, and a full exception list of rows that did not convert with the reason. Where you use Crystal Reports, we deliver these as Crystal layouts inside SAP Business One so finance can re-run them at any point.

Who it is for

Companies of 10–250 users moving off NetSuite to SAP Business One 10.0, typically at a subscription renewal date, where finance will not accept a manual rebuild and where an auditor or parent company will want documented evidence that balances carried over correctly. It suits single-entity and multi-entity groups alike; for groups, we scope one SAP B1 company database per NetSuite subsidiary unless you have consolidated differently.

Technical basis

Built as a SAP Business One add-on using the Service Layer (REST/OData) for bulk object creation, the DI API where an object or field is not exposed through the Service Layer, and UDO/UDF/UDT extensibility for the staging, mapping and traceability layer. Compatible with SAP Business One 10.0 on Microsoft SQL Server and SAP HANA, on-premise or cloud-hosted. Delivered per tenant, installed into your test company database first and promoted to production only after you have signed off the reconciliation.

How delivery works

1. Scoping call — we look at your actual NetSuite saved-search exports, your record volumes, your currencies, your tax jurisdictions and your target SAP B1 configuration. You get a written mapping document. 2. Fixed quote — a fixed price and a delivery date based on that scope, not an hourly estimate. 3. Build — typical lead time is 2–4 weeks depending on object count and the number of custom records in scope. 4. Install in test — we install into your test company database and run a full trial migration, then hand you the reconciliation pack to review. 5. Iterate — mapping corrections and re-runs are part of the engagement, not a change request. The staging layer is designed so a re-run is a truncate-and-reload, not a rebuild. 6. Production cutover — a final delta run at the agreed cutover date, into the production company database, with reconciliation signed off before you open the system to users. 7. Support window — a post-go-live support period is included so that anything discovered in the first close is fixed by the people who built it.

The toolkit stays installed after cutover. If you later acquire a business still on NetSuite, the same mapping tables and the same reconciliation reports run again.