Exporting SAP Business One data before you change platforms
The Service Layer is the documented way to extract SAP Business One business objects, and the company database is the complete but unsupported fallback. If you face a renewal, a partner change, a licensing shift or a data residency requirement, start by mapping which objects you need through the Service Layer and which ones only exist in the database. The Service Layer is an application server that exposes SAP Business One services and objects over HTTP and OData with JSON, and it supports Basic and OAuth authentication. It runs on SUSE Linux Enterprise and, since SAP Business One 10.0 PL01, on Microsoft Windows, and it works with both Microsoft SQL Server and SAP HANA. Confirm your exact patch level and operating system with your partner before you plan the extraction, because the supported combinations decide where your extraction server can sit.
Expect the Service Layer to return business objects such as business partners, items and documents, but do not assume it returns everything you need. Custom user-defined fields, add-on tables, certain configuration and historical audit detail may require direct database access or a partner-built report. Ask your partner to list every object type in scope and to show, for each one, whether it comes through the Service Layer, a query against the database, or both. Treat the database route as the complete source of truth, but a route SAP does not support for third-party extraction. Check with SAP or your partner whether reads against the database are covered by your license and support terms before anyone runs them on production. SAP's own documentation governs the Service Layer details, including endpoints, authentication and paging behavior, so verify each step against it rather than against this page.
Which SAP Business One data the Service Layer exposes and how to pull it
This table maps the main master data and transaction types to the Service Layer entities you should test first, with the output format and access method for each. Treat the entity names as starting points to verify on your own SAP Business One version, since availability can vary by release and add-on. The main takeaway is that most extraction work lies in confirming fields, filters and load limits before you write any import mapping.
| Data type | Service Layer entity | Extraction notes | Confirm in your environment |
|---|---|---|---|
| Business partners | BusinessPartners | JSON over OData; addresses and contacts may need expansion | Which contact and address collections return in your version |
| Items and price lists | Items, PriceLists | Item master returns JSON; price lists may need a separate call | Whether price lists and partner-specific prices are exposed |
| Warehouses and chart of accounts | Warehouses, ChartOfAccounts | Account hierarchy and active status should be exported together | Account hierarchy fields and handling of inactive accounts |
| Open and posted sales and purchase documents | Orders, DeliveryNotes, Invoices, PurchaseInvoices | Document lines arrive as nested collections in JSON | Status filters for open documents and line-level fields |
| Journal entries | JournalEntries | Journal lines are nested; keep transaction numbers for balance checks | Completeness of posted entries and whether balances need a report |
| User-defined fields and add-on data | Entity UDF properties, add-on tables | UDFs appear as extra properties; add-on tables may need database access | Each UDF and add-on table, and the database access you have |
| Paging and load limits | Any collection, using OData query options | Use top, skip and filter; large pulls should run in batches | Maximum records per request, timeouts and recommended batch size with SAP |
How the Service Layer reaches your data without direct database access
The Service Layer is the component you should plan around for extraction, because it sits between any client and the SAP Business One company database. According to SAP, the Service Layer is an application server that exposes SAP Business One services and objects over HTTP and OData with JSON, and Apache HTTP Server handles load balancing in front of it. The request path is therefore a client, then Apache HTTP Server, then the Service Layer application server, then the company database on Microsoft SQL Server or SAP HANA. The Service Layer supports Basic and OAuth authentication and runs on SUSE Linux Enterprise or, since SAP Business One 10.0 PL01, on Microsoft Windows. Ask your partner to confirm which operating system, load balancer configuration and database engine your installation uses, and whether the Service Layer is reachable from your extraction network segment at all.
A Service Layer extract reads business objects, not storage tables. An object such as a business partner or sales order is returned with its related lines and fields as the application defines them, so the export reflects the rules the application applies when it saves and reads those objects. A raw table read on SQL Server or SAP HANA returns rows and internal keys that have to be reassembled by hand, and it can miss logic held in the application layer or in add-ons. The trade-off is that the Service Layer returns data in the shape of the object model, so you still need a mapping from SAP object fields to ERPNext or Odoo fields before any import. Test that mapping on a copy of the company database, not on production.
Use a dedicated extraction user with the smallest set of authorizations that covers the objects you need, and do not reuse an administrator or a personal account. Confirm with your partner which SAP Business One roles and permissions the account needs, whether OAuth or Basic authentication fits your security policy, and where credentials are stored and rotated. Log each session, restrict the account to the extraction network, and remove or disable it when the migration ends. These controls matter more than the choice of protocol, because the extraction account can read most of the company's commercial data in one pass.
What does not export cleanly and the workarounds
The Service Layer covers business objects well, but several kinds of data sit outside it: custom tables, files, credentials, layouts and anything your installed version does not expose. Each card names one gap, the workaround that is usually used, and what to confirm with your partner before extraction starts.
Add-on tables and user-defined fields
Add-ons and user-defined fields (UDFs) often hold business rules, pricing logic or partner-specific references that never appear in standard objects. Ask your partner to list every custom table and UDF with its owner, purpose and whether the Service Layer returns it. Where it does not, a database-level read under a change-controlled process is the usual route, with the partner documenting the schema and the query used. Also confirm whether any add-on stores data outside the company database.
Attachments and document files
Scanned invoices, drawings, certificates and other files linked to documents are often stored outside the table rows that reference them. Confirm with your partner where the files live, whether the attachment path is a network share or a database field, and whether the file names still match the links. Plan to copy the files in a separate pass with checksums, then map each file to its new record in the target system so that document history stays traceable.
User passwords and authorization roles
Password hashes and authorization settings should not move between systems. Users cannot be migrated with their old credentials, and role definitions rarely map one to one onto ERPNext or Odoo permissions. Export the user list and role assignments as reference data, then recreate accounts in your identity provider and rebuild roles in the target system. Ask your partner to confirm which fields the Service Layer returns for users, since that determines how much of the access model you must document by hand.
Reports and print layouts
Crystal Reports, print layouts and report templates are tied to SAP Business One's own rendering and do not export as data. Treat them as specifications rather than files to convert. Inventory the reports used for invoices, delivery notes, statements and month-end, then ask the business owners which outputs they actually need. Rebuild those in the target system using its report or print tools, and test each one against a copy of real transactions before cutover.
Objects missing from the installed version
Not every business object is exposed by every Service Layer version, and the list of available entities depends on your SAP Business One release and installed add-ons. Before extraction, ask your partner for the entity list from your exact version and compare it against your data inventory. Any object that is missing needs a documented alternative, usually a database read or a standard report export, and the partner should confirm that path in writing.
Workflows, approvals and alerts
Approval chains, alerts and event-driven rules configured in SAP Business One rarely appear in the data itself. They run as configuration and, in some installations, as custom code. Document each active rule with its trigger, approver and recipients, then decide whether the target system will reproduce it with native workflow features, a server-side script or an integration. Confirm with your partner which rules depend on add-on code, since that code will not transfer on its own.
The export sequence from freeze to verified staging
This sequence turns a live SAP Business One company into a frozen, complete and checked set of extracts that an ERPNext or Odoo import can rely on. Each step ends with a check, so problems surface in staging rather than after go-live.
Inventory objects, add-ons and reports
Your partner or internal SAP administrator lists every business object in use, including business partners, items, bills of materials, warehouses, chart of accounts, price lists, open sales and purchase documents, and the user-defined fields and tables added by partner add-ons. Record which Service Layer entities each object maps to and which add-ons write data that no standard entity exposes. The output is a signed inventory with one row per object, its source (Service Layer, database query or SAP report) and its owner. Done when every custom field has a named target field in the new system or a documented decision to retire it.
Set and communicate the data freeze
Agree a freeze date and time with finance, sales, purchasing and warehouse leads, and stop posting in SAP Business One for the extraction window. Confirm in writing that no scheduled jobs, integrations or add-ons will write to the company database during extraction. Take a full database backup before the first extract so the source can be restored if an extract needs to be repeated. Done when the backup has been restored to a separate test location and opened successfully, and the freeze notice has been acknowledged by each department.
Export master data before transactions
Extract business partners, items, units of measure, warehouses, accounts and employees first, through the Service Layer entities over HTTP with JSON or through read-only database queries on SQL Server or SAP HANA where a Service Layer entity is missing. Export in dependency order so parent records exist before the transactions that reference them. Keep a stable SAP key, such as the card code or item code, on every row, because it becomes the External ID or the import key later. Done when each master file has a row count that matches the count returned by the source query.
Export open documents and balances
Extract open sales orders, open purchase orders, unpaid invoices, open deliveries and receipts, and the trial balance as of the freeze date. Include line-level detail for documents that stay open, and keep closed history as a separate, lower-priority extract so it can be archived. Record document numbers, dates, quantities, open amounts and tax codes exactly as they appear in SAP. Done when open balances per business partner and per account agree with the SAP aging and trial balance reports for the same date.
Extract attachments separately
Pull attached files, scanned documents and drawings from the attachment folder configured in SAP Business One, not through the transaction extracts, and store each file under its original name with a manifest that links it to the owning document type and key. Confirm the attachment path in the company settings before copying, since moving the folder can break links. Keep the manifest in the same controlled location as the data files. Done when the file count and total size in the manifest match the attachment folder, and a sample of files opens correctly.
Store extracts in a controlled location
Place all extracts, the attachment manifest, the object inventory and the backup in a restricted, encrypted location inside your own infrastructure. Limit access to named staff, log who copies or opens the files, and record a checksum for each file so later copies can be proven identical. Keep the extraction scripts and their version under change control so the run can be repeated. Done when the checksums have been recorded and a test read from a second authorized account succeeds.
Reconcile counts and control totals before loading
Load the extracts into a staging instance of ERPNext or Odoo, then compare record counts, sums of quantities and values, and open balances against the SAP Business One reports taken at the freeze time. Investigate every difference, classify it as a mapping issue, a data quality issue or an extraction error, and correct it at the source or in the transform. Repeat the run until the differences are zero or explicitly accepted by the business owner. Done when a signed reconciliation sheet shows each control total matched, with the staging load ID and the date of the final clean run recorded.
Planning extraction for an ERPNext or Odoo import
Plan the target import before you run any SAP Business One export, because the extraction format depends on how each target loads data. ERPNext's Data Import tool takes CSV or Excel files built from downloadable templates, and it accepts child table rows, so sales order lines, purchase order lines and bill of materials components can sit beside their parent documents in the same file. The ERPNext documentation advises importing only a few thousand records at a time, which means each Service Layer extract should be split into files of that size, with masters loaded before the documents that reference them. Odoo imports any business object from .xlsx or .csv files, and its documentation recommends External IDs when the source is a third-party application. Confirm the current batch guidance for your Odoo version with Odoo, since the import documentation does not give a fixed row limit in the material supplied for this page.
Keep the SAP key on every record you export. Business partner codes, item codes, warehouse codes and document numbers should land in a dedicated legacy code field in ERPNext or as an External ID in Odoo, so that open invoices, payments and inventory movements exported in later batches can be matched to the master records already loaded. Choose the key format once, document it, and never reuse a code for a different object. The Service Layer exposes these objects over HTTP and OData with JSON, so your export scripts can write the key column directly from the same field names that SAP uses. Run a reconciliation after each batch by comparing record counts and key lists against the SAP extract, and treat any missing or duplicate key as a blocking defect before the next batch starts.
Decide early who owns the mapping and who signs off each batch. A finance lead should approve the account, tax and currency mappings, while an operations lead approves items, units of measure and warehouse structure. Record every decision in a mapping workbook that lists SAP fields, target fields, transformations and exceptions. Ask your implementation partner and the platform vendor which custom fields and add-on data need a home in the target schema, because SAP add-on tables are not part of the standard Service Layer objects and will need their own extract. Confirm these points in a written scope before extraction starts, so the batch plan reflects your actual data volumes and your chosen Odoo edition or ERPNext hosting model.
What to plan before renewal or termination
A move off SAP Business One is easier when the contract, the database and the add-ons are settled before extraction starts. The cards below cover the decisions and checks that come first, so the export runs against a known data set and a read path stays available until the new system is verified.
Build the notice and renewal calendar
List every contract, maintenance and partner support agreement with its renewal date and the notice period each one requires. Work backwards from the date you want the new system live to find the last point at which you can still extend the current arrangement. Note which agreements cover the database licence and which cover the partner's services, because they often renew on different dates.
Confirm export rights in writing
Ask the vendor or partner, in writing, which export rights and data copies the contract grants you, including whether you may extract data through the Service Layer, by direct database access, or both. Ask what format, scope and timing apply to a full copy at termination. Verbal assurances from a sales or support contact are not enough for a data migration.
Keep a licensed read path open
Keep the current system and a licensed user available for read access until the new ERP has passed reconciliation of masters, open documents and balances. Once the licence lapses, you may lose the ability to reopen historical transactions that auditors or tax authorities ask for. Confirm with the partner whether a read-only or limited licence is available after the end date.
Document add-on dependencies
Inventory every add-on, custom user-defined field, report, stored procedure and integration that writes to or reads from the company database. Record who built each one, which version it targets, and whether its source is available to you. Each item becomes a rebuild task in ERPNext or Odoo, or a retirement decision, and missing items usually surface only after go-live.
Take a full database backup first
Before any export, schema change, upgrade or licence change, request a full backup of the company database from the team that hosts it, and store a copy outside the production environment. Confirm the backup format, that it can be restored on the same database engine, and who holds the restore keys. Test the restore on a separate server before relying on it.
Confirm the database and platform
Record whether the company database runs on Microsoft SQL Server or SAP HANA, and which operating system hosts the Service Layer, SUSE Linux Enterprise or Microsoft Windows. These details decide which extraction tools and access accounts you need, and whether a read-only database user can be created. Ask the partner to confirm the authentication method, Basic or OAuth, used by existing integrations.
Questions buyers ask before exporting SAP Business One data
Can we export our SAP Business One data without a partner?
Yes, in principle, if your team has someone who can read the Service Layer documentation, write extraction scripts and reconcile the output against SAP Business One reports. The Service Layer exposes SAP Business One services and objects over HTTP and OData with JSON, so the technical barrier is mostly skill and time rather than licensing. What is harder to do alone is validating the result: confirming that open orders, stock valuation, open invoices and balances match the source system on a fixed cut-off date. Ask your SAP Business One partner whether they will provide the Service Layer access and the data dictionary for your version, and confirm any licensing or support terms that apply to your installation before you assume you can extract freely.
What drives the effort of an SAP Business One data export?
Four factors drive most of the effort: the number of add-ons, the volume of transactional history, the amount of customization in user-defined fields and tables, and the number of company databases. Each add-on usually adds its own tables or objects that the standard Service Layer may not expose, so every add-on needs a mapping decision. Large transaction histories extend extraction and validation time, and multiple company databases multiply the work because each one needs its own cut-off and reconciliation. Ask any provider to itemize the work by these four factors in a written scope before agreeing to a fixed price or timeline.
Is the Service Layer enough, or do we need direct database reads?
The Service Layer is often enough for business partners, items, price lists and many transaction documents, because it exposes standard objects with a documented OData interface. A direct database read is usually needed for custom tables created by add-ons, some historical or audit data, and any object the Service Layer does not expose in your version. Reading the database directly means working with SQL Server or SAP HANA schemas that SAP does not present as a public integration contract, so confirm with SAP and your partner which approach is supported for your installation. Run a proof of extraction on one company database before deciding the method for the full dataset.
What must our team provide before the export starts?
Four things need to be in place before extraction begins. You need SAP access with an account that can authenticate to the Service Layer, using Basic or OAuth authentication, and a database account if direct reads are part of the plan. You need a named business owner who decides how each master data record and open document is treated. You need a freeze date, after which users stop changing data or the team captures later changes in a delta run. Finally, you need sign-off on the reconciliation: the agreed totals, counts and balances that must match between SAP Business One and the extracted files before cut-over.
How long does an SAP Business One data export take?
No reliable duration can be given without a scope. The timeline depends on the four drivers above, on how many rounds of validation the business requires, and on how quickly decisions about open documents and data quality are made. A single company database with standard objects and few add-ons is a different project from several databases with custom tables and years of history. Ask for the timeline as a set of milestones tied to the written deliverables: proof of extraction, full extraction, reconciliation, and a dated freeze and cut-over plan. Confirm any dependency on SAP or partner availability in the same document.
Does SAP Business One 10.0 PL01 on Windows change the export plan?
SAP's documentation says the Service Layer runs on SUSE Linux Enterprise and, since SAP Business One 10.0 PL01, on Microsoft Windows. For the export, this matters mainly for where you run the extraction and how you reach the Service Layer, because the API contract stays the same. Confirm with your partner which patch level and operating system your production installation uses, whether the Service Layer is hosted on the same server as the database, and whether the extraction host can reach it securely. Keep the extraction runbook specific to your operating system and database version so the same steps can be repeated for the test run and the final run.
Can we extract into ERPNext or Odoo directly after the export?
The extracted files still need mapping and loading, and that step is separate from extraction. ERPNext's Data Import tool loads records from CSV or Excel templates, supports child table rows, and its documentation advises importing only a few thousand records at a time, so large sets are split into batches. Odoo imports data into business objects from Excel or CSV files and recommends External IDs when importing from a third-party application, which lets you reload or correct records without creating duplicates. Plan the mapping of business partners, items and open documents to each target before the test import, and treat the import logs as part of the reconciliation evidence.
Verifying a complete SAP Business One export
An export is only complete once you can prove it matches the source. Before any record reaches ERPNext or Odoo, agree a reconciliation plan with the project owner, finance lead and the people who run the SAP Business One database. The plan should cover three checks: record counts per object, control totals for open balances and stock values, and sample-based field comparisons. Record counts compare the number of business partners, items, bills of materials, open sales and purchase documents, and journal entries in the source against the extract. Control totals compare receivable and payable balances, open order values and inventory valuation by warehouse against the figures in the source ledger at the same cut-off date. Confirm the cut-off date and the currency basis in writing, because a count taken on a different day will never match.
Sample-based comparison catches problems that totals miss, such as truncated text, swapped unit of measure codes, or dates shifted by a time zone. Pick a mix of records, including a few with child rows, a few with multiple currencies and a few closed documents, and compare every exported field against the source screen or the Service Layer response. Keep the query, the export file name, the row count and the checksum for each extract so the run can be repeated. Ask your partner to confirm which fields the Service Layer exposes for each object in your version, since custom user-defined fields and add-on tables often need a separate extract from the database.
Finish with a signed reconciliation report stored with the project records, listing each check, its result, every known difference and who accepted it. DeployOpen prepares this evidence as part of an implementation, but compliance attestations and audit opinions come from independent auditors and certification bodies, not from the implementer. If your organization is preparing for an assessment, give the auditor the reconciliation report and the extraction queries early so they can judge the controls around the data rather than the data alone.
How DeployOpen scopes and delivers an SAP Business One data exit
DeployOpen plans and runs the extraction of SAP Business One master data and transactions inside your own infrastructure, so the data stays under your control throughout. We agree the scope, the target platform and the evidence you need in writing before any extraction work starts.
How we scope
- Inventory which master data, open documents and history your ERPNext or Odoo target needs, and which can stay archived.
- Confirm the SAP Business One version, the database (SAP HANA or Microsoft SQL Server) and the operating system hosting the Service Layer.
- Agree in writing whether extraction runs through the Service Layer, direct database reads, or a combination, and who holds the credentials.
How we build
- Build extraction scripts against the Service Layer REST and OData endpoints, with Basic or OAuth authentication configured for a read-only service user.
- Map SAP Business One business partners, items and open documents to the import templates of the target platform, including child table rows.
- Run test extractions on a copy of the company database and reconcile record counts and control totals against SAP Business One reports.
How we hand over
- Deliver the extraction scripts, field mappings and reconciliation reports as documented artifacts that your team can rerun and audit.
- Provide load batches sized for the target import tool, with a runbook describing order of loading, validation checks and rollback steps.
- Record every access grant, extraction run and retained copy so your security and compliance teams can review the exit evidence.
How we support
- Fixed-scope engagements have deliverables, timelines and acceptance criteria agreed in writing before work begins, and we quote from that scope.
- Ongoing support, upgrades and repeat extraction runs for final cutover are available as a retainer, if your timeline needs them.
- Ask your DeployOpen contact to confirm retention rules for extracted copies, the access model and the cutover checkpoints before signing the scope.
