SYSPRO to SAP Business One Migration: A Technical Guide

SYSPRO to SAP Business One Migration: A Technical Guide

Migrating from SYSPRO to SAP Business One is a structural data translation between two different ERP architectures — SYSPRO's module-prefixed SQL Server schema with separate company and system-wide databases, and SAP Business One's single Business Partner model with a Service Layer REST API. There is no vendor-provided migration path between the two. Every record must be extracted, transformed, and loaded through custom scripts or SAP's own import tools.

If you are still choosing between the two systems, start with SYSPRO vs SAP Business One: 2026 Comparison. For the pair-specific migration scope, see our SYSPRO to SAP Business One migration page.

Why Companies Move from SYSPRO to SAP Business One

Three patterns drive this migration:

1. The subscription-model reset. SYSPRO is moving to a named-user subscription and publishes no subscription price (syspro.com). Companies facing the licensing transition are re-evaluating total cost of ownership across all ERP options.
2. Operational simplification. SYSPRO's deep manufacturing features (lot traceability, serial tracking, WIP job costing) carry complexity that some mid-market distributors and light manufacturers don't need.
3. Ecosystem alignment. Companies already running SAP products at a parent-company or group level consolidate on SAP Business One to reduce integration overhead.

How Do the SYSPRO and SAP Business One Data Models Differ?

The fundamental mismatch is entity design. This is not a table-to-table copy — it is a schema redesign.

SYSPRO stores data in Microsoft SQL Server. Each company's data lives in its own database, with a separate system-wide database for information that is not specific to any company (help.syspro.com). Customers sit in ArCustomer, suppliers in ApSupplier, inventory in InvMaster, and sales orders split across SorMaster (headers) and SorDetail (lines). Custom form fields are stored in "plus tables" — ArCustomer+ holds the custom form data for ArCustomer (help.syspro.com).

SAP Business One holds customers, vendors and leads in one Business Partners table, OCRD. Its CardType field takes C (Customer), S (Vendor) or L (Lead), and CardCode is up to 15 characters (help.sap.com). Through the Service Layer, sales orders, purchase orders and invoices are documents with embedded DocumentLines. Customization happens through user-defined fields, managed by the UserFieldsMD object "in user and system tables" (help.sap.com), and through user-defined tables.

Core Object Mapping

SAP table names and descriptions below come from the SAP Business One SDK 10.0 Database Tables Reference, one page per table (for example, help.sap.com for OCRD). Service Layer entity names come from the Service Layer API Reference (help.sap.com).

SYSPRO Table	SAP Business One Service Layer entity (SQL table)	Structural Change
ArCustomer	BusinessPartners (OCRD, CardType C)	Customers and suppliers merge into one table
ApSupplier	BusinessPartners (OCRD, CardType S)	Same table, different type value
InvMaster + InvWarehouse	Items (OITM Items + OITW Items - Warehouse)	Warehouse data sits under the item
SorMaster + SorDetail	Orders (ORDR + RDR1 Sales Order - Rows)	Header/detail rows become one nested document
PorMasterHdr + PorMasterDetail	PurchaseOrders (OPOR + POR1 Purchase Order - Rows)	Same nesting pattern
ArInvoice	Invoices (OINV A/R Invoice)	Tax and posting logic changes; see tax code section
ApInvoice	PurchaseInvoices (OPCH A/P Invoice)	Supplier invoice structure differs
GenMaster + GenTransaction	ChartOfAccounts (OACT G/L Accounts) + JournalEntries (OJDT + JDT1)	GL structure remapped
InvSerialHead	SerialNumberDetails (OSRN Serial Numbers Master Data)	Serials linked to items
LotDetail	BatchNumberDetails (OBTN Batch Numbers Master Data)	Lots become batches
TblCurrency + TblCurrDatedRates	Currencies (OCRN Currency Codes) + ORTT (CPI and FC Rates)	Dated rates move to a rate-per-date table
WipMaster	ProductionOrders (OWOR Production Order)	Job detail must fit SAP's production order
BomOperations + BomWorkCentre	ProductTrees (OITT Product Tree)	Routing and BOM structures differ
Plus tables (custom fields)	User-defined fields on the parent object	Requires field-by-field creation before load

Handling Custom Fields (Plus Tables)

SYSPRO stores custom form fields in separate "plus" tables linked to the main record. SAP Business One uses user-defined fields attached to existing objects, created through UserFieldsMD. SAP's SDK help notes that if you add a mandatory user-defined field, "you must also define a default value" (help.sap.com). Create all user-defined fields before loading data, and settle their definitions during sample migrations. Map each SYSPRO plus-table column to a corresponding field on the appropriate SAP B1 object. For how to find every plus table, see Migrating SYSPRO Custom Form Fields (Plus Tables).

How to Extract Data from SYSPRO

Direct SQL Server access is the route we recommend first. You can read every table — including plus tables for custom fields — with standard SQL queries against the company database.

Business Activity Queries (BAQs) are SQL views created in the company database. Any SQL user with db_datareader permissions can retrieve data using them (help.syspro.com). They're useful as pre-built views but add no extraction capability beyond what direct SQL provides.

The SYSPRO OData Service provides read-only access and is "the only mechanism available when applications need access to SYSPRO data in the Syspro Cloud ERP environment" (help.syspro.com). Use it where direct SQL is not possible. SYSPRO's help says it limits calls "to 5000 rows under the Microsoft best practice guidelines for performance and fair use", with paging through $top and $skip (help.syspro.com). Plan for longer extraction windows if you are on Syspro Cloud ERP.

e.net business objects (query objects like ARSQRY, INVQRY, SORQRY) return XML for individual records or filtered sets. They suit integration, not bulk extraction. Note that archived sales orders cannot be queried through SORQRY (help.syspro.com).

How to Load Data into SAP Business One

Three load routes exist.

Data Transfer Workbench (DTW)

SAP's Data Transfer Workbench (DTW) is a template-based import tool. SAP's DTW documentation is not on a public page we could read for this guide, so we do not state its limits here. Ask your SAP partner which objects DTW can load in your release, and how it reports errors. Many teams use it for master data and the Service Layer for everything that needs scripted control.

Service Layer REST API

The SAP Business One Service Layer is a REST API that "follows OData protocol Version 3 and 4". As of SAP Business One FP 2405, "OData Version 3 is deprecated and OData Version 4 is the primary protocol supported in Service Layer". SAP's reference examples use the base URL https://localhost:50000/b1s/v2/, and it covers entities such as BusinessPartners, Items, Orders, Invoices, JournalEntries and ProductionOrders (help.sap.com).

Authentication is session-based. You POST to /Login, and the Service Layer sets two cookies, B1SESSION and ROUTEID. You must send B1SESSION on every later call. "By default, a login session will expire and the user will be logged out automatically if there is no new request within 30 minutes." The timeout is set by SessionTimeout in b1s.conf (help.sap.com). Reuse sessions across a migration run and log in again when one expires.

Pace bulk loads, page your requests, and retry with backoff. Measure throughput on your own SAP B1 server during sample migrations rather than planning from published figures.

When to use the Service Layer: Programmatic migrations, delta syncs, or any load that needs control over error handling and retry logic.

DI API (SDK)

The DI API is SAP's COM-based SDK (SAPbobsCOM) for programmatic access to SAP Business One objects (help.sap.com). Use it when the Service Layer is unavailable, and confirm licensing for it with your SAP partner.

Migration Approaches Compared

Approach	Complexity	Best For	Limitations
DTW (template import)	Low	Master data loads your SAP partner has confirmed DTW supports	Confirm object coverage and error handling with your SAP partner
Service Layer API	Medium–High	Programmatic bulk migration, delta sync	Session handling; throughput depends on your server
DI API (SDK)	High	Deep custom logic	COM-based; confirm licensing with your SAP partner
Custom ETL (ADF, AWS Glue)	Very High	Enterprise data volumes with data warehousing needs	Expensive to build and maintain
Middleware (Zapier, Make)	Low	Not recommended for ERP migration	Not built for ERP-to-ERP data volumes or dependency order
Managed migration service	Low (for you)	Complex data, limited engineering bandwidth	Cost; vendor must understand both platforms

Middleware platforms like Zapier or Make are built for lightweight triggers on simple objects, not ERP-to-ERP data migration. Prefer API or direct SQL over CSV for data integrity.

Load Order and Dependency Chain

The order in which you load data is not arbitrary. A document that references a business partner, item, warehouse or tax code that does not exist yet will be rejected. A workable dependency chain, with SAP table names from the SDK reference:

1. Configuration objects (no dependencies)
   └── Currencies / OCRN
   └── Countries / OCRY
   └── ItemGroups / OITB
   └── BusinessPartnerGroups / OCRG (Card Groups)
   └── PaymentTermsTypes / OCTG
   └── Warehouses / OWHS
   └── Tax codes (SalesTaxCodes / OSTC or VatGroups / OVTG)  ← must exist before any document
   └── Document numbering series / NNM1  ← must be configured before transactional load

2. Master data (depends on configuration)
   └── ChartOfAccounts / OACT  ← required before JournalEntries
   └── Items / OITM  ← requires ItemGroups, Warehouses
   └── BusinessPartners / OCRD  ← requires BP groups, payment terms, currency
   └── PriceLists / OPLN  ← required before document price references

3. Opening balances
   └── JournalEntries (opening GL balances)  ← requires ChartOfAccounts
   └── Opening stock (an inventory document agreed with your SAP partner)  ← requires Items, Warehouses

4. Transactional data (depends on master data and opening balances)
   └── PurchaseOrders / OPOR  ← requires Suppliers, Items, Warehouses, tax codes
   └── Orders / ORDR  ← requires Customers, Items, Warehouses, tax codes
   └── PurchaseInvoices / OPCH  ← requires Suppliers, Items, tax codes
   └── Invoices / OINV  ← requires Customers, Items, tax codes
   └── IncomingPayments  ← requires Customers, open Invoices
   └── VendorPayments  ← requires Suppliers, open PurchaseInvoices

The most common failure sequence is loading items before item groups exist, or loading sales orders before tax codes are configured. Every configuration object in step 1 must exist before any master data import begins.

Field-Level Transformation Notes

Build the mapping from your own SYSPRO schema, not from a template. Read the column list of each SYSPRO table in your company database, then map it to the target fields listed in the SAP SDK reference for that table. A few rules hold for every business partner load:

• Key collisions. CardCode is one field for customers and vendors, up to 15 characters (help.sap.com). If a SYSPRO customer and supplier share a code, add a prefix (for example C and S). If you consolidate several SYSPRO companies, add a company prefix too, and check the result still fits 15 characters.
• Lookups, not strings. In OCRD, GroupCode is an integer that relates to OCRG (help.sap.com). Build lookup tables that map SYSPRO customer classes and payment terms to the SAP B1 groups and payment terms you created in step 1.
• Keep the source key. Store each SYSPRO customer, supplier and document number in a user-defined field. It gives you a cross-reference for validation and for looking up history after go-live.
• Custom fields. Map each plus-table column to its user-defined field.
• Tax codes do not map directly — see the next section.

Tax Code Migration

Tax code migration is one of the most common failure points in a SYSPRO to SAP Business One migration and is frequently underestimated.

In SYSPRO, tax codes are assigned to customers, suppliers and stock items, and the rates sit in SYSPRO's tax setup, which varies by region and configuration.

In SAP Business One, the SDK reference lists a Sales Tax Codes table (OSTC) (help.sap.com) and a Tax Definition table (OVTG) (help.sap.com). Which one your company uses depends on its SAP B1 localization, so confirm it with your SAP partner.

Migration steps for tax codes:

1. Extract the distinct set of tax codes used across SYSPRO customers, suppliers and stock items.
2. Create corresponding tax codes in SAP B1 with correct rates before any document import.
3. Build a lookup mapping SYSPRO tax codes to SAP B1 tax codes.
4. Apply this mapping at the document line level during transformation.
5. Validate that the effective tax rate on a sample of imported invoices matches the source.

Why this fails: If tax codes are not set up in SAP B1 before document import, documents that reference them are rejected. If the mapping is wrong, invoices post with wrong tax amounts, causing GL reconciliation failures that are hard to unwind after go-live.

Number Series Configuration

SAP Business One controls document numbering through numbering series, held in NNM1 (Documents Numbering - Series) (help.sap.com). Configure series before any transactional data is loaded.

Options:

• Accept SAP B1 numbering. Let SAP B1 number new documents and store the SYSPRO original document number in a user-defined field. This is the cleanest approach and avoids future numbering conflicts.
• Preserve SYSPRO document numbers. This needs series ranges planned around your SYSPRO numbers. Confirm with your SAP partner how manual numbering works for each document type before you choose it.

In either case, configure numbering for every document type you load — sales orders, purchase orders, invoices, journal entries and production orders — before the transactional load begins.

Opening Balances

Opening balances need specific handling to avoid double-counting source transactions in SAP B1.

GL opening balances are loaded as journal entries dated at the cutover date, carrying the net balance of each SYSPRO GL account. Do not load individual historical GL transactions unless finance asks for them. Journal entries post to OJDT (header) and JDT1 (rows) (help.sap.com).

Customer and supplier balances can be loaded as open invoices (better for aging and payment allocation) or as summary opening balances. If you load individual open invoices, the sum of those balances must reconcile to the AR/AP control account balance in the GL opening entry.

Inventory opening balances are loaded through an inventory document, not through sales or purchase orders. Agree with your SAP partner which document to use, for example a Goods Receipt (OIGN) (help.sap.com). Quantities and values come from SYSPRO's per-warehouse stock. Items and warehouses must exist first.

Reconciliation check: After loading all opening balances, run a trial balance in SAP B1 and compare it against the SYSPRO trial balance at the same date. Any variance indicates a transformation or loading error. Resolve it before loading transactional data.

Pre-Migration Planning

Before touching the data, define scope and audit the source system.

• Data audit. Identify the exact SYSPRO tables you need. Do you need historical SorDetail (sales order lines), or just open orders? Are you migrating WipMaster (WIP jobs), or closing them out before cutover?
• Archive what you leave behind. History that SAP B1 does not need can go to an archive you can still query.
• Ensure direct SQL access. Report Writer exports are a poor basis for a migration. Direct SQL is the first choice, and OData is the fallback where SQL is not possible.
• Migration strategy. Bulk load in the days before go-live while SYSPRO stays live, then a final delta sync at cutover. Run sample migrations to validate mapping before the production cutover.
• Number series planning. Decide before the first sample migration whether to preserve SYSPRO document numbers or accept SAP B1 numbering. This decision affects every document payload.
• Tax code inventory. Extract all distinct tax codes from SYSPRO customers, suppliers and stock items, and map them to SAP B1 equivalents before any document is loaded.

For a complete planning framework, review The Ultimate ERP Data Migration Checklist (10-Point Plan).

Step-by-Step Migration Process

1. Extract from SYSPRO

Run SQL queries against the company database for each entity: ArCustomer, ApSupplier, InvMaster, InvWarehouse, SorMaster, SorDetail, PorMasterHdr, PorMasterDetail, GenMaster, GenTransaction, LotDetail, InvSerialHead, and all relevant plus tables. Export to structured files — JSON preferred, CSV as fallback. For Syspro Cloud ERP, where only OData access is available, plan for paged extraction within SYSPRO's 5,000-row limit per call.

2. Transform

Merge customer and supplier records into the Business Partner schema (prefix CardCode with C/S where codes collide). Remap GL accounts. Nest SorMaster + SorDetail rows into order documents. Map plus-table values to user-defined fields. Map currency codes and dated exchange rates from TblCurrDatedRates to SAP B1's ORTT table, which holds a rate per currency per date (help.sap.com). Apply the tax code lookup to all document lines, and the group and payment-terms lookups to all business partners.

3. Create target structures in SAP B1

Define all required user-defined fields and tables before loading data. Configure the chart of accounts, tax codes, warehouses, price lists, item groups, business partner groups, payment terms, currencies and numbering series. This step must finish before any data import begins.

4. Load master data first

Follow the dependency chain: currencies and countries, then item groups, BP groups and payment terms, then warehouses and tax codes, then the chart of accounts, items, business partners and price lists. A record that references a missing parent will be rejected.

5. Load opening balances

Load GL opening balances as journal entries. Load opening stock through the inventory document you agreed with your SAP partner. Load AR/AP opening balances as open invoices or summary balances, depending on whether payment matching is needed. Reconcile the trial balance before proceeding.

6. Load transactional data

Open sales orders, then open purchase orders, then open invoices, then payments. Store the SYSPRO source document number in a user-defined field on each record for cross-reference.

7. Run delta sync at cutover

Run the bulk load in the days before go-live while SYSPRO stays live. Go live on a Monday, never a Friday. Freeze SYSPRO before Monday's working day starts, extract records changed since the bulk load, and push the delta through the Service Layer. The final delta covers changed records only and takes about 30 minutes.

8. Validate

Record-count parity between source and target. Field-level spot checks. GL balance reconciliation. Tax amount verification on sampled invoices. Referential integrity checks. See the validation section below for specifics.

Edge Cases That Break Migrations

Multi-company database collisions. SYSPRO holds each company's data in a separate database. If you are consolidating several SYSPRO companies into one SAP B1 company, prefix primary keys such as customer codes to prevent collisions, within the 15-character CardCode limit.

SYSPRO's WIP depth. SYSPRO tracks materials allocated to jobs (WipJobAllMat) and labour allocated to jobs (WipJobAllLab), and holds routing steps in BomOperations and work centres in BomWorkCentre. Check with your SAP partner how much of that SAP B1 production orders and product trees can hold in your release. Your options are: (a) close open WIP jobs in SYSPRO before cutover and carry their net WIP value as a journal entry; (b) add a manufacturing add-on that your SAP partner recommends; (c) migrate BOM structures without routing detail and archive the routing history. For the trade-offs, see SYSPRO WIP and Job History: Migrate or Archive?.

Multi-currency rounding. Foreign-currency amounts can round differently once recalculated in SAP B1. Run a sample of historical foreign-currency invoices through the transformation and compare base-currency amounts before you commit to a rounding approach.

Multi-currency dated exchange rates. SYSPRO holds exchange rates in TblCurrency and dated rates in TblCurrDatedRates (help.syspro.com). SAP Business One stores a rate per currency per date in ORTT. Map these explicitly or historical foreign-currency transactions will reconcile incorrectly.

Archived lot transactions. SYSPRO's purge program archives lot transaction details while keeping the header record in the live table. If full lot traceability is required in SAP B1, extract from both live tables and archive files.

Plus table custom fields. Each SYSPRO plus-table column needs a user-defined field in SAP Business One. Get the definitions right in the sample migration, not in production.

Tax code mismatches. SYSPRO tax codes do not map 1:1 to SAP B1 tax codes. A document that references a tax code SAP B1 does not have will be rejected. See the tax code section above.

Number series rejections. Plan numbering series for every document type before you load any transactional data.

Validation and Testing

Validation is not a final step — it runs during every sample migration.

• Record-count parity: Total records extracted from each SYSPRO table must match total records loaded into the corresponding SAP B1 table. If ArCustomer has 4,500 records, OCRD (where CardType = 'C') must have 4,500 records from that source.
• Field-level sampling: Spot-check 5–10% of records across every mapped field, comparing source and target values. Pay special attention to dated exchange rates (TblCurrDatedRates → ORTT), tax codes, and custom plus-table fields.
• GL balance reconciliation: The trial balance in SYSPRO must match the opening balances loaded into SAP Business One to the penny. Common sources of variance are rounding in foreign currency balances, missed accounts in the chart of accounts mapping, and intercompany accounts with no equivalent in the SAP B1 structure.
• Tax amount verification: For a sample of invoices, compare the tax amount in SYSPRO against the tax amount in SAP B1. Discrepancies indicate a tax code mapping error.
• Referential integrity: Every sales order must reference a valid business partner and valid items. Every journal entry must reference a valid GL account. Every document must reference a valid tax code.
• Open document verification: Finance should verify open POs, open SOs and unpaid invoices individually. Confirm that the open balance on each document in SAP B1 matches the source.
• Number series continuity: Verify that loaded document numbers do not collide with the numbers SAP B1 will issue after go-live.

For a complete validation framework, see How to Build a Data Migration Playbook.

When to Use a Managed Migration Service

Build in-house when you have engineers who know both SYSPRO's SQL schema and SAP Business One's Service Layer, and the data is straightforward — master data, simple transactions, few custom fields.

Use a managed service when:

• SYSPRO's plus tables hold business-critical custom data that must be preserved
• Production data (WIP jobs, BOM structures, lot traceability) needs careful structural translation
• Tax code and number series configuration is complex across multiple jurisdictions
• Your team lacks SAP B1 Service Layer experience and the licence deadline is approaching
• You need delta sync capability to avoid downtime during cutover

ClonePartner is an engineer-led data migration service — not an ERP reseller or implementation partner. We move data out of SYSPRO into whichever system you choose and validate the result with record-count parity, field-level checks, and reconciliation reports. We do not implement SAP Business One; your SAP partner does that. We handle the data layer.

• Fixed Pricing: One fixed price per project, starting at $500 (clonepartner.com). No hourly billing, no per-record metering.
• Predictable Timelines: Most data migrations complete within 1–5 business days, depending on data volume, complexity, and API rate limits. Small datasets (under 10,000 records) can finish in under 24 hours.
• Unlimited Sample Migrations: We run test migrations until the data mapping is right, at no additional cost.
• Security: SOC 2 Type II and ISO 27001. Staging data is purged within 30 days of project close.