Migrate from SAP Business One to ERPNext: what the move involves
A manufacturer or distributor on SAP Business One that faces a license renewal, a partner rate change or new hosting terms should treat the move as a staged project: data, processes and add-ons migrated in phases, run in the company's own infrastructure, usually with an implementation partner doing the technical work. The finance and operations owners decide what moves, defining what a valid business partner, item or open order looks like in the new system. IT owns the database servers, backups, network access and the environment where ERPNext runs, which can be installed with Docker Compose or manually with the bench command line tool. The implementer maps the data and builds the replacements. ERPNext is licensed under GPL-3.0, and the ERPNext pricing page states that self-hosting is free, so the recurring cost shifts to infrastructure, support and staff time.
Effort depends mainly on three things you can measure before any quote: the number of add-ons in use, the complexity of bills of materials, and the volume of open documents. Each add-on needs a functional decision: keep the same behavior through ERPNext configuration, rebuild it as custom code, or retire it. Server Scripts run Python on document events, but from version 15 they are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them, so self-hosting is the practical place for that logic. Multi-level BOMs, sub-assemblies and scrap rules need validation against real production orders. Open sales orders, purchase orders and invoices must carry across so receipts and payments still match. Ask for an inventory of add-ons, custom fields, reports and printed forms, with a count of open documents per type, before agreeing the scope in writing.
Master data loads through the Data Import tool, which reads CSV or Excel files built from downloadable templates and handles child table rows such as BOM items or order lines. The documentation advises importing only a few thousand records at a time, so load business partners and items first, then BOMs, then open documents, and check each batch on a test site before the production load. Keep the SAP Business One identifiers in a searchable field so balances and open items can be reconciled back to the source. Confirm the ERPNext version you select against Frappe's supported versions: version 14 reached end of life on January 31, 2026, version 15 is planned for support until the end of 2027 and version 16 until the end of 2029. Agree a parallel run, a cutover date and a tested database rollback procedure with the partner in writing before the final load.
Which SAP Business One capabilities map to ERPNext, and where rework is needed
This table maps the main SAP Business One areas to their closest ERPNext equivalents and marks each as clean, needs rework or gap. Use it to decide where a data migration is mostly loading and where your team will rebuild logic, then confirm each row against your own SAP Business One version, database and localization before you commit to a scope.
| Business One area | ERPNext fit | Status | Confirm before scoping |
|---|---|---|---|
| Business partners | Customers and suppliers with contacts and addresses, loaded through Data Import templates | Clean | Card codes you want to keep as IDs, and how contacts and multiple addresses map to child rows |
| Items and item groups | Item records with variants and item groups, loaded from CSV or Excel | Needs rework | Item attributes, UoM conversions and any user-defined fields that need custom fields in ERPNext |
| Bills of materials and production | Manufacturing module covers BOMs, work orders and production planning | Needs rework | Routing, costing method, scrap and by-product handling. Verify manufacturing and costing depth with a scoped test using your own BOMs |
| Inventory and warehouses | Stock ledger, bins, batch and serial tracking in the stock module | Needs rework | Opening stock valuation, bin structure and whether batch or serial rules match your current practice |
| Open sales and purchasing documents | Quotations, sales orders, deliveries, purchase orders and receipts can be created as open records | Needs rework | Which open documents to carry over versus close in SAP, and how partial deliveries and receipts map |
| Accounting and open balances | Double-entry general ledger with receivables and payables, loaded with opening balances | Needs rework | Chart of accounts structure, fiscal years, cut-off date and reconciliation of opening balances to the trial balance |
| Localization and statutory reporting | Country-specific chart of accounts and tax templates depend on available localization apps | Gap | Whether a localization app exists for your country and tax regime, and whether your statutory reports are covered |
| User roles and permissions | Role-based permissions and user accounts, with SSO options through LDAP or social login | Needs rework | How SAP authorizations map to ERPNext roles and document-level permissions, and who signs off the new matrix |
| Add-ons and custom reports | Server Scripts and custom fields replace many add-on behaviors, but are disabled by default from version 15 | Gap | Each add-on's function, whether Server Scripts are enabled on your hosting, and which reports need rebuilding |
What moves cleanly and what does not
Business partners, items, units of measure and price lists map one to one from SAP Business One into ERPNext, so they are the safest place to start a migration. The work is mostly field mapping and clean-up: deduplicating business partners, confirming item codes stay unique, and checking that every unit of measure and price list has an equivalent in the ERPNext setup. The key risk in this group is not the load itself but the ID scheme, so decide before extraction whether SAP codes become ERPNext names or whether the old codes are kept in a separate reference field for traceability. ERPNext Data Import works from CSV or Excel templates, so you can test each master type on a small sample before loading the full set.
BOM versions, open sales and purchase documents, stock valuation, chart of accounts mapping and custom user-defined fields need transformation rather than a straight copy. A bill of materials that exists in several versions in Business One must be rebuilt as ERPNext BOMs with a clear rule for which version is active. Open documents carry quantities, prices and delivery status that must reconcile with inventory and the general ledger. Stock valuation and the chart of accounts usually require a decision with your accountant and auditor. ERPNext Data Import supports child table rows, so multi-line BOMs and documents can load from one template, but the documentation advises importing only a few thousand records at a time, so plan batches and reconcile totals after each one.
Add-ons and Service Layer customizations are the highest-risk category. Each add-on's logic, from pricing rules to approval flows, has to be identified, documented and either replaced with standard ERPNext functionality or rebuilt as a custom app. Custom Server Scripts need attention: according to the Frappe Framework documentation, they are disabled by default from version 15 and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. Ask your partner for a list of every add-on and every Service Layer script that writes data, and confirm early which of them your target hosting permits.
Which exports and integrations to plan for extraction
Moving from SAP Business One to ERPNext means choosing an extraction path for each data set and rebuilding every system that reads from or writes to the database today. The cards below cover the documented paths and the integrations that most often get missed. Confirm each path against your exact SAP Business One version, database and partner before you commit to a plan.
Service Layer for business objects
The Service Layer REST and OData interface exposes business objects such as business partners, items, bills of materials and open documents through a supported API. It is the cleanest source for master data and open transactions because it applies SAP's business logic rather than raw table structures. Ask your partner which Service Layer version and entities your installation exposes, and test paging and filtering on a copy of the company database before you rely on it for a full extraction.
Direct reads for bulk data and history
Direct reads from SQL Server or SAP HANA are the practical route for large volumes, posted history and fields the Service Layer does not expose. The schema is SAP's internal design, so any query must be read-only, run against a restored copy and reviewed with your partner. Confirm how SAP and your partner handle support for custom queries before you build migration logic on top of them, and document each query so it can be rerun for the final cutover.
CSV and Excel staging for Data Import
ERPNext's Data Import tool loads records from CSV or Excel files built from downloadable templates, and it supports child table rows, so BOM lines and document items can come in with their parents. The documentation advises importing only a few thousand records at a time, which makes batching and reconciliation part of the plan. Stage each file with a record count and a control total taken from the source, and keep the staging files as an audit trail of what was loaded.
Bank and payroll file exchanges
Bank statement files, payment files and payroll journals often run on schedules that nobody has documented in full. Inventory every file in and out, including its format, encoding, cut-off time and owner, before you map it to ERPNext. Confirm the exact formats with each bank and payroll provider, then decide whether each file is rebuilt as an ERPNext import or export, or handled by a middleware step that stays outside the ERP.
E-commerce, barcode and shop-floor connectors
Web shops, barcode scanners and shop-floor terminals often write to Business One through add-ons or the Service Layer, and those connectors do not move with the data. Rebuild them against ERPNext's API or as custom logic, and plan the testing around stock counts and order flow. Server Scripts run Python on document events, but from version 15 they are disabled by default, must be enabled with server_script_enabled, and are not allowed on Frappe Cloud public shared benches, so check that choice before you design the connector.
Identity with LDAP and social login
Users in Business One are usually separate accounts, so access to ERPNext needs its own design before go-live. ERPNext supports LDAP integration and Social Login Keys, which means sign-in can follow your directory instead of a local password list. Map each Business One role to an ERPNext role with the same permissions, remove users who have left, and test sign-in and permission checks with each department before cutover.
The migration sequence from inventory to decommission
The sequence moves a manufacturer or distributor from SAP Business One to ERPNext in controlled stages, so each stage produces a checked artifact before the next one starts. It ends with SAP Business One switched off and its data kept in a retained archive.
Inventory data, add-ons and integrations
Your team and the migration lead list every master data object, open document, report, add-on and integration that touches SAP Business One, including the owner of each. Each item is marked as migrate, rebuild, retire or keep as archive. The output is a mapping workbook that lists source tables or Service Layer entities, target ERPNext doctypes and the business owner for each row. It is done when finance, sales, purchasing, warehouse and production leads have each signed off their rows.
Design the target model and run a scoped pilot
The team confirms how items, units of measure, BOMs, warehouses, price lists and chart of accounts will be modeled in ERPNext, then loads a small pilot set of business partners and items that covers the main product and customer types. Server Scripts and custom fields are designed here, with a note that Server Scripts are disabled by default from version 15 and need the server_script_enabled setting. The output is a design record and a pilot load log. Sign-off comes from the finance lead and the operations lead.
Run trial loads with Data Import templates
Extracts from SAP Business One are cleaned and placed into the ERPNext Data Import templates, with child table rows for BOM components and item variants. Loads are kept to a few thousand records per file, as the ERPNext documentation advises. After each trial, the team reconciles record counts, item quantities, customer and supplier balances and open document totals against the source. The output is a reconciliation report per trial, with every variance explained. Each trial is repeated until the variances are zero or accepted in writing.
Operate a parallel run with agreed checks
Both systems run side by side for an agreed period, with new orders, purchase receipts, production orders and payments entered in ERPNext and SAP Business One kept as the record of truth until cutover. Daily checks compare stock on hand, open sales and purchase orders, general ledger balances and the BOM explosion for a sample of finished goods. The output is a parallel run log and a list of defects with owners. The finance lead and the controller sign off the reconciliation checks before the run closes.
Execute cutover in a frozen window
Transactions are frozen in SAP Business One, the final delta extract is loaded into ERPNext, and the reconciliation checks are repeated on the frozen data. Users, roles, permissions and any integrations are switched to ERPNext, and the rollback path is tested before the window opens. The output is a signed cutover checklist covering data counts, balances, access tests and the rollback decision point. The steering group and the finance lead sign it, and the business owners confirm go-live in writing.
Decommission SAP Business One and retain archives
After the post-cutover stabilization period agreed in the plan, SAP Business One is set to read-only, its database and file archives are exported and stored under the retention rules your auditors and tax advisers require, and the licenses and partner support agreements are closed according to their terms. Confirm with your partner and your license contract what notice is needed. The output is a decommission record with archive locations, retention periods set by your policy, and checksums for each export. The CFO and the IT owner sign off.
Running both systems in parallel and cutting over
Decide in the written scope which system is the book of record for each document type before the first parallel transaction. A common split is to keep sales orders, purchase orders, goods receipts and production orders in SAP Business One until cutover, while ERPNext receives only the test copies needed to validate the Data Import templates and the BOM structures. Write the parallel period, the owner of each reconciliation and the criteria for ending it into the scope so that the decision is contractual rather than informal. Confirm with your partner and with the team who runs your SAP Business One instance whether any transactions will be dual-entered, and if so, who approves a discrepancy.
Reconcile stock and the general ledger on a fixed schedule during the parallel run. For inventory, compare item quantities and valuation by warehouse in SAP Business One against the ERPNext stock ledger after each test load, and investigate every variance before the next load. For the general ledger, compare trial balances by account and period, including open receivables and payables by business partner. Treat each reconciliation report as an audit artifact and file it with the migration evidence. Keep the cutover date away from month-end close and from the window in which production orders are released, since open work-in-progress and partially received purchase orders are the items most likely to be duplicated or dropped.
Retain a read-only archive of the SAP Business One database before you switch off write access. Ask your SAP Business One partner and database administrator to take a full backup of the SQL Server or SAP HANA database, record its restore procedure, and confirm that a restored copy can be opened by the licensed application version. Keep the archive under the same access controls as production data, because it contains personal data of customers and employees. Document which reports and queries the finance and audit teams need from history, and test those before cutover so that retrieval does not depend on a single person's knowledge.
How the migration changes by starting point
Illustrative example: one legal entity, one company database, a production floor that runs on item masters with BOMs, and a handful of add-ons such as a label printing tool and a shipping connector. Extraction is the most contained case here, because the scope is one database and a single cutover point for open purchase orders and work orders.
- Extraction scope: Export items, BOMs, business partners and open sales and purchase documents in one pass, then reconcile record counts against the Business One screens before anything is loaded.
- Add-ons: List each add-on and decide whether ERPNext covers the function natively, needs configuration, or needs a custom app. Label printing and shipping often stay as separate services that read ERPNext data.
- Import pacing: The Data Import documentation advises a few thousand records at a time, so plan the loads for items, BOMs and open documents as separate batches with their own checks.
- Testing: A short test cycle can cover one production week: create a work order, issue materials, post completion, and compare stock valuation with the old system.
- Who leads: The operations or finance lead usually signs off, while an implementation partner handles extraction and loading. Confirm who holds the existing Business One partner relationship and who owns the cutover decision.
Before the data load starts, confirm that every add-on has a named owner and a written replacement decision.
Illustrative example: a distributor with several legal entities, intercompany stock transfers, shared price lists and company databases on Microsoft SQL Server. Here the extraction work multiplies by the number of entities, and the main design question is how shared masters map into ERPNext company records before any data moves.
- Per-company extraction: Run the export against each company database separately, and keep a mapping table from each source company code to its ERPNext company.
- Shared masters: Decide which business partners and items are global and which belong to a single entity. The same partner code often exists in more than one database, and duplicates create reconciliation errors that surface late.
- Intercompany flows: Test transfers and intercompany invoices end to end, because they touch stock, receivables and payables in more than one entity at once.
- Pricing and discount add-ons: Price and discount logic on SQL Server often sits in tables or stored procedures. Rebuild it as ERPNext pricing rules, and remember that Server Scripts are disabled by default from version 15 and must be enabled before they can run.
- Repeated cycles: Run the full load and reconciliation for each entity in turn, so that problems in one company do not hide problems in another.
Confirm the sign-off owner for each entity and whether a parallel run covers every company, not only the largest one.
Illustrative example: a company on SAP HANA with dozens of custom reports, SQL-based queries and external tools that read Business One views. The extraction problem shifts from moving tables to deciding which reports and consumers still matter, because most of the business logic lives in reporting layers rather than in transactional data.
- Report inventory: List every report, query and external consumer, record who uses each one, and retire unused items before extraction starts.
- Reporting rebuild: Map each retained report to an ERPNext standard report, a Report Builder report or a custom report, and check totals against the HANA output for the same period.
- Extraction method: Use the Service Layer for transactional and master data where it covers the object. Confirm with SAP and your partner whether direct database reads are needed for anything else, and document any read-only access.
- History: Decide how much transaction history moves into ERPNext and how much stays in a read-only archive for audit queries.
- Testing: Compare trial balances and inventory valuation across at least two closes, because reporting differences tend to appear there first.
Confirm who in the business owns each retained report and whether finance has signed off the test totals before the cutover.
What usually goes wrong in this migration
Most failed SAP Business One to ERPNext moves break at the same few points: custom code that was never inventoried, stock values that never reconciled, and product structures discovered late. The cards below name each risk and the check that prevents it, so the cutover plan reflects what the old system actually does.
Add-ons and Service Layer code assumed portable
Add-ons, DI API or Service Layer scripts, and SQL reports built for SAP Business One do not move to ERPNext. Each one has to be listed with its business owner, the data it reads and writes, and whether the function still matters. Treat each item as a rebuild or a retirement decision, not a port. Ask the partner for a written inventory before any build estimate is accepted.
Unreconciled stock valuation
Inventory quantities and values often diverge between the item master, warehouse balances and the general ledger in the source system. If those differences are carried into ERPNext opening stock, valuation errors appear at the first period close. Before extraction, reconcile quantity and value by item and warehouse, then load opening balances as a documented entry that finance signs off.
BOM and routing gaps found late
Bills of materials, alternate components, scrap factors and operation routings are often maintained in spreadsheets or in custom fields. Gaps tend to surface during the first production order run, after go-live. Build a test set of ten to twenty finished goods chosen by production, then compare the ERPNext BOM and work order output line by line against the current shop-floor records.
User roles and approvals not rebuilt
SAP Business One authorizations, approval templates and document-level restrictions rarely map one to one onto ERPNext roles and workflows. Permissions that were never documented can disappear, or open up sales and purchasing actions that should need approval. Export the current authorization matrix, define ERPNext roles and workflow states from it, and test each approval path with a user from every department.
Server Scripts disabled by default
From version 15, ERPNext Server Scripts are disabled by default and must be enabled with the server_script_enabled setting. Frappe Cloud public shared benches do not allow them at all. Any validation or document event logic moved from SAP Business One must run on a deployment where that setting is enabled, such as a self-hosted Docker or bench installation. Confirm the hosting target before rebuilding any scripted logic.
Testing and training underestimated
Parallel runs, reconciliation of open documents and user acceptance testing take longer than the data load itself. Staff also need to relearn purchasing, inventory transfers and month-end steps. Plan a parallel run covering at least one full closing cycle, write test scripts from real transactions, and schedule role-based training before cutover. Ask any implementation partner to show how they track test defects to closure.
Questions buyers ask before moving from SAP Business One to ERPNext
What does a move from SAP Business One to ERPNext cost?
The ERPNext software itself carries no license charge, because ERPNext is GPL-3.0 licensed and the ERPNext pricing page states that self-hosting is free. The cost sits in the components around it: hosting, implementation, data extraction and cleansing, rebuilding add-ons as ERPNext customizations, testing, training and ongoing support. Hosting recurs, while migration work is largely one-time. Ask any quote to show each component separately, including who carries each one: your staff, your SAP Business One partner, an ERPNext certified partner, or DeployOpen under a written, fixed scope. Your current SAP Business One license and maintenance fees are the baseline to compare against, and they should be pulled from your own contract.
How long does an SAP Business One to ERPNext migration take?
Duration depends on the size and shape of your data and the number of customizations to rebuild, not on a fixed template. The main drivers are the number of business partners, items and bills of materials, how many years of open documents and history you carry over, how many SAP Business One add-ons and reports must be replaced, and how many sites, companies and currencies are involved. Testing with real month-end and open-order scenarios usually takes longer than the load itself. No supplied source gives a duration for this migration, so ask any implementer for a timeline tied to a written scope, with milestones for extraction, a test load, user acceptance and cutover.
What does the migration need from our finance, operations and IT staff?
Each group owns a different part of the work:
- Finance confirms the chart of accounts, tax setup, opening balances and which open invoices, payments and credit notes must carry over.
- Operations confirms item master rules, units of measure, warehouses, bills of materials, routing and the open purchase and sales orders that must continue after cutover.
- IT provides database access to the SAP Business One environment, the target server or Docker host, backup windows, user accounts and access to the identity provider if single sign-on is planned.
All three groups need to sign off test loads. Plan for subject matter experts to review extracted records, because errors in master data are easiest to catch before the production load.
Can our internal team migrate from SAP Business One to ERPNext alone?
A capable internal team can handle parts of the work, especially the business review of master data and the testing. Whether the team can carry the whole migration depends on its experience with SQL extraction, ERPNext data models, Python-based customization and Frappe server operations. ERPNext's Data Import uses CSV or Excel templates, but reshaping SAP Business One data into those templates, handling child table rows for bills of materials and documents, and reconciling totals still require skilled work. Check the team's capacity against cutover dates and ongoing operations. Many companies split the work, keeping business review internal and buying fixed-scope engineering support for extraction, loading and integration.
Can ERPNext's Data Import handle our data volume?
ERPNext's Data Import tool imports and updates records from CSV or Excel files, or public Google Sheets, using downloadable templates, and it supports child table rows. The ERPNext documentation advises importing only a few thousand records at a time, so large masters and years of transactions should be loaded in batches, in dependency order: customers and suppliers, items, then bills of materials, then open documents. Plan batch sizes, error logs and reconciliation totals in advance. For full history, you may choose to load only open items and summarized balances, and keep older records in an archive. Test the batch approach on a copy of production data before cutover.
What happens to our SAP Business One add-ons in ERPNext?
Each add-on must be inventoried and classified before migration. Some functions may already exist in standard ERPNext modules, some can be configured through custom fields, workflows and print formats, and others need custom code. ERPNext Server Scripts run Python on document events or as API endpoints, but from version 15 they are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. Confirm this early, because it decides whether custom logic runs on a self-hosted bench or needs a different design. Also check whether any add-on exposes integrations to other systems you must keep.
What support and upgrade options exist for ERPNext after go-live?
ERPNext is free to self-host, and you can keep it current yourself or use a paid service. Frappe's supported versions page lists version 14 as end of life since January 31, 2026, version 15 supported until the end of 2027, and version 16 until the end of 2029. Frappe's supported versions policy says a customer must run a listed version and hold a matching Frappe Cloud support plan to receive warranty coverage from Frappe. Frappe Cloud shared hosting starts at 5 US dollars per month and servers at 20 US dollars per month for shared instances, according to the ERPNext pricing page. Ask any implementer which version they will deploy, how minor releases are applied, and who handles security patches, backups and restore tests after go-live.
Does moving to ERPNext remove our dependence on a single partner?
ERPNext's source code is GPL-3.0 licensed, and it runs on MariaDB or PostgreSQL with Docker or the bench tool, so you are not bound to a single vendor license to keep running it. Dependence still exists in practice: your team needs staff or a contractor who understands the customizations, the upgrade path and the backups. Document every customization, keep the code in your own repository, and make sure the migration hands you runbooks, configuration records and test evidence. Those artifacts matter more than the license when you later change implementers.
What drives cost and duration in this move
The largest cost in this move is usually the implementer's time, not the software. ERPNext itself is free to self-host under GPL-3.0, according to the ERPNext pricing page, so the budget is spent on people and infrastructure. Implementation effort covers mapping SAP Business One business partners, items, bill of materials structures, warehouses and open purchase and sales documents onto ERPNext doctypes; scripting the extraction from the Service Layer or the SQL Server or SAP HANA database; rebuilding each add-on as ERPNext functionality, Server Scripts or a custom app; and testing manufacturing and costing results against SAP Business One figures. Add-on rebuilding is the most variable line. Ask the partner to list every add-on in use and classify each as standard, configuration, custom code or retire, because that list sets most of the effort.
Infrastructure is the second component, and it splits by hosting choice. Self-hosting with Docker Compose, using the production images and Compose files in the frappe_docker repository, or with the bench command line tool puts the cost on your own servers, backups, monitoring and staff time for patching. Frappe Cloud is the optional managed alternative. Per the ERPNext pricing page, Frappe Cloud shared site hosting starts at 5 US dollars per month, shared servers start at 20 US dollars per month and dedicated servers at 125 US dollars per month. Confirm current tiers with Frappe before budgeting, since these are starting prices. Recurring costs include hosting, support plans and the upgrade work each supported major version requires. Ask any implementer for a quote that separates one-time migration work from these recurring lines.
Which factors raise or lower migration effort
This table lists the factors that most change the effort of moving from SAP Business One to ERPNext, why each one matters and how to keep it under control. Read it before scoping, because most of these drivers are visible in the current system before any data is extracted.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number and complexity of add-ons | Each partner add-on holds its own tables, screens and logic, and none of it transfers to ERPNext. Each one needs a replacement, a custom app or a manual process. | Inventory every add-on and its business use, retire those no longer used, and map the rest to standard ERPNext features before design starts. |
| BOM depth and routing | Multi-level bills of materials, alternative items and operation routings must be rebuilt in ERPNext's manufacturing setup and validated against shop-floor practice. | Flatten unused levels, freeze engineering changes during the extract window and validate a sample of finished goods with production staff. |
| Volume of open documents | Open sales orders, purchase orders, deliveries and invoices must be carried over with correct quantities and statuses, which is slower than loading masters alone. | Close or complete as many documents as possible before cutover and load only the remaining open items, keeping closed history in an archive. |
| Number of companies and currencies | Each company needs its own chart of accounts, fiscal settings and currency handling, and intercompany balances must reconcile across entities. | Confirm the company structure early, consolidate entities where the business allows and agree the currency treatment for historical balances. |
| Localization needs | Tax codes, statutory reports, numbering rules and payroll or e-invoicing links depend on the country and may not match ERPNext defaults. | List every statutory output the business produces today and confirm with an ERPNext localization or partner which ones exist before migration. |
| Reporting and custom fields | Custom user-defined fields and queries in SAP Business One must be matched to ERPNext custom fields and reports, and missing reports slow sign-off. | Prioritize the reports that finance and operations use daily, retire unused fields and document the rest as known gaps. |
| Integration count | Each link to a warehouse system, e-commerce store, bank feed, shop-floor device or tax portal needs a new connector or rework, and each one needs its own tests. | Count the integrations and replace point-to-point links with a small set of documented interfaces, then test each one against the new data model. |
| Data quality | Duplicate business partners, inconsistent item codes, unit-of-measure errors and missing tax settings cause import rejects and reconciliation work. | Cleanse masters before extraction, enforce a unique code rule and run test imports to find errors early. |
| Parallel-run length | Running both systems in parallel doubles entry work and creates reconciliation effort, and a longer run needs more staff time to keep the two aligned. | Agree the parallel period and exit criteria in writing, limit the run to the scope that needs it and reconcile stock and ledger balances at fixed points. |
How DeployOpen scopes and runs an ERPNext migration
DeployOpen plans and runs the move from SAP Business One to ERPNext inside your own infrastructure, from extraction through cutover. Engagements are fixed-scope, so the written scope sets the business objects, add-ons and deliverables before any build work starts.
How we scope
- Inventory every SAP Business One database, company, add-on and report your team relies on today.
- Agree in writing which business partners, items, BOMs and open documents move, and which history stays archived.
- Confirm the target ERPNext version, hosting model and database choice before any data extraction begins.
How we build
- Map SAP Business One fields and item groups to ERPNext doctypes, Data Import templates and child table rows.
- Script extraction through the Service Layer or direct database reads, then load test batches of a few thousand records.
- Rebuild each add-on function as configuration or reviewed custom code, and test it against copied production data.
How we hand over
- Document the mapping, load order, reconciliation checks and cutover runbook so your team can repeat or audit them.
- Reconcile item counts, stock quantities, open balances and BOM structures between the old and new systems before sign-off.
- Transfer administration of the Docker or bench deployment, backups and access controls to your named staff.
How we support
- Agree post-cutover support, bug fixes and ERPNext upgrade work as a retainer, scoped separately from the migration.
- Plan minor and major ERPNext releases with your team, testing customizations against each supported version first.
- Run ongoing security testing and backup restore checks on the production environment when you request them.
