SAP Business One 10.0 end of maintenance: what the deadline forces you to decide
A partner has proposed moving your SAP Business One 10.0 system to Version 11, and the 10.0 maintenance window is closing. The deadline forces one decision: a path to a supported version, either a Version 11 upgrade delivered with your partner or a move to a self-hosted open-source ERP such as Odoo or ERPNext. SAP lists Business One 10.0 in mainstream maintenance until December 31, 2028 and says Version 11 follows, so the date itself is not the open question. The open question is which path your team can staff, test and support after that date. Odoo and ERPNext both publish dated support windows for their versions, which makes their lifecycles easier to compare with SAP's. This section sets out what the deadline asks of you, and the rest of the page compares the two paths by effort, lifecycle and data work.
The Version 11 path keeps your current processes, databases and add-ons, which is its main appeal, but the work sits in one project that your partner scopes and prices. Ask for the upgrade plan in writing, covering which add-ons and integrations are supported on Version 11, whether the underlying database platform changes, how testing runs against a copy of production data, and who owns rollback. Confirm the Version 11 release timing with SAP and your partner, since the proposal is only as firm as that date. Then ask what support horizon the new version carries. Odoo's standard and extended support documentation gives three years of standard support per major version, with 18.0 supported until September 2027, 19.0 until September 2028 and 20.0 until September 2029. ERPNext v15 is supported until the end of 2027 and v16 until the end of 2029. An upgrade buys time on the same kind of clock, so judge it against those windows.
What the end-of-maintenance date requires from your organization
The December 31, 2028 mainstream maintenance date for SAP Business One 10.0 is a decision deadline, not only an upgrade task. The cards below set out what your organization must produce and decide, whichever path you choose, and they show which items carry the most lock-in and cost.
A supported version in production
Confirm which Business One version, database platform (SAP HANA or Microsoft SQL Server) and operating system your live company runs today, and map each to the vendor's current support status. Ask your partner in writing which release line is the target and what it requires from your hardware and database versions. Record the answers in one document that finance, IT and the partner all sign off on.
Inventory of add-ons and customizations
List every add-on, custom report, stored procedure, integration and manual workaround your staff depend on, with its owner and the vendor or partner who built it. Note which items you could not rebuild from memory if the partner left. This inventory drives the upgrade test scope and, if you move platforms, the replacement effort.
Tested upgrade path with a rollback plan
Require a full copy of the production company, upgraded and tested before any go-live date is set. Agree in writing how you would return to the pre-upgrade system, how long the old database stays readable, and who signs the rollback decision. Without a tested rollback, a failed cutover becomes an open-ended outage.
Dated decision on data and licensing
Decide by a fixed date whether you stay on the SAP path or move to Odoo or ERPNext, because each choice changes what you extract, what you license and what you keep. Ask for the current license and maintenance terms for your user count and modules, and confirm whether any terms change at the next version. Your choice also determines when the data extraction work must start.
Staff who can run the target system
Name the people who will administer the target platform after go-live, including backups, user access, reports and month-end close. For Odoo, this includes the subscription and version upgrade schedule. For ERPNext, it includes server administration, scheduled jobs and the release cadence. Staff who only learned the old system will need training or a partner who stays on retainer.
Budget approval for recurring upgrades
Present the upgrade or migration as the first project in a lifecycle, not a one-time cost. Ask for a quote that separates licenses, partner labor, testing, hosting and support, and mark which lines recur. Odoo documents a three-year standard support window per major version, so plan funding for the next cycle before the current one closes.
What a Business One Version 11 upgrade involves
The first job in a Version 11 upgrade is to confirm what the company runs today, because every later decision depends on it. Record the database platform (SAP HANA or Microsoft SQL Server), the server operating system, the database server version, and the version of every Business One client that staff use, including any remote or branch installations. Then confirm the target Version 11 requirements for each of those components with your partner and SAP, since the supported combinations are set by the vendor and should be checked against current SAP documentation rather than assumed from the current installation. Ask the partner to state in writing which of these components will be changed, which will be left alone, and who buys any new licenses or hardware that the change requires.
The compatibility review is where most of the effort tends to sit. List every partner add-on, custom report, layout, query, DI API script and integration with a payment provider, bank file, eCommerce site or warehouse system. For each one, ask for a compatibility status: certified for Version 11, requires a new build, requires rework, or will be retired. Retest every integration end to end with copies of live data, not only the standard screens, and record which user roles and posting workflows were exercised. Also ask who pays for rework if an add-on fails in test or after cutover, and whether that cost sits inside the fixed fee or is billed separately.
The cutover plan needs a tested rollback procedure before anyone commits to a date. Ask for a backup taken immediately before go-live, the steps to restore the Version 10 database and clients, and the point after which rollback is no longer practical because new transactions have been posted. Retraining is part of the same plan: budget time for users to learn changed screens and any new features, and schedule it before the cutover. Read the partner's written proposal against this list. Scope, fees and timeline belong to that proposal, and a proposal that does not name the add-ons, the test plan and the rollback steps is not ready to sign.
Which option fits the deadline: upgrade, Odoo or ERPNext
This table compares five paths for a Business One 10.0 customer facing SAP's December 31, 2028 end of mainstream maintenance: a Version 11 upgrade, or a move to self-hosted Odoo or ERPNext. Read each row for how the option meets the support requirement, what the license and hosting cost, and the main trade-off. Confirm every Version 11 detail with your partner before you compare.
| Path | Support and upgrade path | License and hosting cost | Customization and main trade-off |
|---|---|---|---|
| Stay on Business One and upgrade to Version 11 | Mainstream maintenance on 10.0 runs to December 31, 2028 per SAP. Confirm the Version 11 timeline and upgrade steps in writing. | SAP licenses, maintenance and partner fees continue. Get the Version 11 subscription and upgrade fees itemized in the quote. | Confirm that each add-on is certified for Version 11. Trade-off: you stay dependent on the partner for every change. |
| Self-hosted Odoo Community | Community is licensed under LGPLv3 and has no access to Odoo's upgrade service. Your team or partner plans and tests every migration. | No license fee for the Community code. You pay for hosting, implementation, migration and ongoing support. | Custom modules are built and maintained in-house or by a partner. Trade-off: you carry the upgrade work without vendor tooling. |
| Odoo Enterprise on-premises | Standard support covers three years after each major release. Confirm your target version and its support end date before committing. | An Enterprise subscription is required on-premises, and on-premises use needs the Custom plan. Ask Odoo for the current fees. | Studio, multi-company and custom modules sit in the Custom plan. Trade-off: the subscription recurs and Enterprise source code is not public. |
| Self-hosted ERPNext via Docker | Version 15 is supported to the end of 2027 and Version 16 to the end of 2029. You schedule upgrades on your own timetable. | Self-hosting is free under GPL-3.0. You pay for servers, backups, monitoring and your own operations. | Server Scripts are disabled by default from version 15 and must be enabled. Trade-off: no Frappe warranty unless you hold a matching support plan. |
| ERPNext on Frappe Cloud | Frappe hosts supported versions. Warranty coverage requires a Frappe Cloud support plan that matches your version. | Shared sites start at 5 US dollars per month and dedicated servers at 125 US dollars per month, per the ERPNext pricing page. Support plans cost extra. | Public shared benches do not allow Server Scripts. Trade-off: Frappe operates the platform, so confirm data location and exit terms. |
How long Odoo and ERPNext versions stay supported
Odoo and ERPNext both publish dated support windows for their major versions, and those dates decide how often you must upgrade after a move off SAP Business One 10.0. Read the windows together with your partner's upgrade commitments before you sign anything.
Odoo standard support window
Odoo documents that each major version receives three years of standard support, followed by two more years to complete an upgrade. Standard support covers security updates and bug fixes on Odoo Online, Odoo.sh and on-premise. Plan your go-live date against the three-year window, not the two-year upgrade period, so the database is never running on an unsupported version while the team is still stabilizing it.
Odoo 19.0 and 18.0 end dates
Odoo 19.0 was released in September 2025 with standard support until September 2028. Odoo 18.0 was released in October 2024 and its standard support runs until September 2027. Odoo 17.0 standard support ended in September 2026. If you choose a version now, record its end date in your project plan and confirm it on Odoo's support page before the contract is signed.
Mandatory upgrades on SaaS and Odoo.sh
On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years. Odoo SaaS versions also ship every two to three months and cannot use extended support. Ask your partner who runs the upgrade test, how long a test copy is kept for validation, and whether upgrade effort is included in the support retainer or billed per project.
ERPNext 15 and 16 support dates
ERPNext and Frappe Framework version 15 is planned to be supported until the end of 2027, and version 16 until the end of 2029. These dates are the windows to compare against your internal upgrade calendar. Confirm the current dates on Frappe's supported versions page before committing, because the policy can change between releases.
ERPNext 14 end of life
ERPNext and Frappe Framework version 14 reached end of life on January 31, 2026. Any ERPNext instance still on version 14 no longer receives maintenance from the project. If a partner proposes a version 14 installation, treat that as a warning sign and ask for the version that will be live on the go-live date, along with its support end date.
Frappe warranty and support plan
Frappe's supported versions policy states that customers must run a listed version and hold a matching Frappe Cloud support plan to receive warranty coverage from Frappe. Self-hosting ERPNext is free, so the support plan is a separate cost to budget. Ask your implementation partner whether they will hold their own support contract, and what happens to warranty coverage if your version falls off the list.
When the upgrade is the right call and when to move
When most of the business runs through partner add-ons, the upgrade question is really an add-on question. Each add-on has to be confirmed for Version 11, and some will need rewriting rather than patching if they are old or built on older interfaces. The cost recurs with each vendor release cycle, so a company with many add-ons pays for the same dependency again every time the platform moves. Moving to Odoo or ERPNext usually fits better here, because many add-on functions exist as native modules or apps, and the remaining gaps are fewer to close.
- Add-on count: every add-on needs a written compatibility statement for the target version.
- Add-on age: older add-ons often depend on interfaces that the vendor no longer maintains.
- Vendor roadmap: ask each add-on vendor for its Version 11 date and support terms.
- Native coverage: check which add-on functions exist in Odoo or ERPNext before assuming a rebuild.
- Partner dependence: the partner who sold the add-ons may not be the lowest-cost option for a rebuild.
What would change the answer is a vendor commitment to Version 11 support for every add-on, in writing. Build a list of each add-on with its version, vendor status and any native equivalent in the target before requesting a quote from either path. The SAP Business One on SAP Learning page is a starting point for confirming the platform's current facts.
A company with a standard stock and accounting setup and few add-ons carries little customization into any project. In that case the upgrade is mostly a test-and-cutover exercise, and the cost centers on the chart of accounts, open items and staff retraining. A move is also manageable, but the work is in data mapping and reconciliation, not in rebuilding functions. The upgrade often fits a team that knows the system well and wants to keep the current process, while a migration fits a team that is already planning a broader change in its finance operations.
- Standard footprint: the less custom code and the fewer add-ons, the smaller any project becomes.
- Balances and history: opening balances, open items and audit trail requirements drive most of the effort in either path.
- Odoo edition: Odoo Community has no upgrade service, so the internal team carries that work. Enterprise on-premise requires a subscription.
- Data volume: ERPNext's Data Import documentation advises importing a few thousand records at a time, which affects the load plan.
- Staff capacity: a standard upgrade may need less time from the finance team, but only if the same people can test it.
What would change the answer is a plan to add functions in the next two or three years that the current setup does not cover. Ask the partner to quote the upgrade with a test cycle that includes your month-end and audit steps, and ask the replacement candidates to show the same reports from a migrated sample database.
Manufacturers and distributors usually carry the heaviest integration load: warehouse equipment, e-commerce, shipping, EDI, and custom reports for production and purchasing. Those interfaces are the main cost in either path. An upgrade keeps the existing integration design and requires retesting it, while a move requires rebuilding each interface against the new platform's API and data model. This tab suits companies whose integrations are stable and well documented, and where the reporting is stable too. It suits a move when the company wants to retire point-to-point integrations in favor of a single data model.
- Integration count: each interface is retested in an upgrade and rebuilt in a migration.
- Custom reports: confirm which SAP reports need a direct equivalent and which can be rebuilt with the target's reporting tools.
- Server-side logic: ERPNext disables Server Scripts by default from version 15, and they must be enabled with the server_script_enabled setting. Frappe Cloud public shared benches do not allow them.
- API access: Odoo external API access is included only in the Custom plan, so confirm this before designing integrations.
- Manufacturing depth: test bills of materials, routings and costing on real data before deciding.
What would change the answer is a full integration inventory showing that most interfaces are older than the planned upgrade window. Ask for a list of every interface with its owner, data direction and test cases, and check that each target can support the same server-side logic and API access.
Groups with several legal entities depend on shared masters, intercompany transactions and consolidated reporting. An upgrade keeps this structure intact and asks the team to retest intercompany flows and consolidation. A move forces the company to decide how the group is modeled on the new platform, which is a design decision as well as a data project. The tab fits companies that already run a clear entity structure and want that structure preserved, and it fits a move when the group also plans to simplify entities.
- Entity count: each company in scope adds mapping, reconciliation and cutover work.
- Shared masters: decide early whether customers, vendors and items are shared across entities or duplicated.
- Intercompany flows: test every intercompany posting, approval and elimination end to end after any change.
- Licensing: the pricing page ties Odoo multi-company to the Custom plan, so confirm the cost of that tier against the group's needs.
- Consolidation: confirm how consolidation and reporting per entity map to the target, and ask for a gap list.
What would change the answer is a plan to merge or reduce entities within the next few years, which can make a single migration cheaper than an upgrade followed by a second project. Map each entity, its intercompany flows and the people who approve cross-entity postings before requesting any quote.
How a move to Odoo or ERPNext runs alongside the current system
This sequence moves masters, open documents and custom logic out of SAP Business One in controlled stages, so the business keeps running on its current system until a tested cutover. Each step ends with a check that shows whether the next step can start. Durations depend on scope and must come from the written plan.
Inventory add-ons, reports and integrations
Start by listing every add-on, user-defined field and table, Crystal or other report, scheduled job, and integration that touches Business One, including bank files, e-commerce connectors, shipping links and tax or payroll feeds. Your internal IT lead and the current partner should own this list together, and the business process owners should confirm which items are still used. The output is a signed inventory that marks each item as retire, replace, or rebuild. You know the step is done when every item has an owner and a decision, and no integration is left without a named destination.
Extract masters and open documents
Extract business partners, items, price lists, warehouses, chart of accounts, bills of materials, and open sales, purchase and inventory documents from the Business One database or through its Service Layer. Confirm with the partner which database (SAP HANA or Microsoft SQL Server) and which access method your version supports, and whether the extraction runs on a copy rather than the production database. Store each extract in a versioned location with a record count and a checksum. The step is complete when row counts in each extract match the source reports you agreed on.
Map items, partners and bills of materials
Map Business One fields to the target model, for Odoo or ERPNext. Business partners need roles for customers, vendors and contacts, items need unit-of-measure and valuation rules, and bills of materials need levels, scrap and routing data where manufacturing is used. Decide which codes are kept as external identifiers so that open documents and history can still be traced back. The finance and operations owners should sign off the mapping sheet. The step is done when every source field has a target or a recorded decision to drop it.
Load test data with the import tools
Load the mapped data into a non-production instance. In Odoo, use the import function with Excel (.xlsx) or CSV files and External IDs for records coming from a third-party system, so later loads update rather than duplicate them. In ERPNext, use the Data Import templates, and load in batches of a few thousand records at a time, as the ERPNext documentation advises. Keep a log of rejected rows and their causes. The step is done when a load completes with no unexplained rejections and sample records match the source on balances, stock quantities and open order totals.
Rebuild custom logic on the target platform
Rebuild only the custom logic the inventory marked for replacement, as Odoo modules or ERPNext customizations. In ERPNext, Server Scripts 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, so confirm the hosting model before design starts. Review each rebuilt item with the business owner and record how it is tested. The step is done when every replacement item has a test case, a documented owner and a deployment record in the environment that will run production.
Run a parallel test on a neutralized copy
Build a test environment from a copy of the migrated data with outgoing email, payment gateways and external integrations disabled or redirected. Odoo documents database duplication with neutralization for test copies on-premise, and the same discipline applies to ERPNext. Run a full close cycle, a set of sales and purchase orders, and a stock count in parallel with Business One, then compare results line by line. The step is done when the differences are explained, approved and fixed, and the finance owner accepts the trial balance.
Cut over to production
Agree a cutover window in the written plan, freeze transactions in Business One, run a final delta extract of documents entered after the first load, and load the delta into production. Repeat the reconciliation against the frozen source, switch users and integrations, and keep the Business One environment read-only for the agreed retention period. Confirm the rollback path before the window opens. The step is done when balances, open documents and integrations reconcile, signed off by finance and operations, and the old system is archived.
What buyers ask before moving off Business One 10.0
What drives upgrade cost versus a move to Odoo?
The partner quote sets the figure, and the scope behind it drives most of the difference. A Version 11 upgrade is priced mainly by the add-ons and custom reports that must be re-tested, the data volume, the integrations with other systems, and the hosting on SAP HANA or Microsoft SQL Server. A move to Odoo or ERPNext carries the same inputs plus module mapping, data cleansing and rebuilding add-ons as new modules. Training and ongoing support recur in both paths. Ask the partner to price each component separately so the two options can be compared line by line.
How long does each path take and what sets the length?
The length depends on the scope agreed with your partner, because no single timeline fits every company. SAP lists Business One 10.0 in mainstream maintenance until December 31, 2028, so that date is a planning deadline rather than a project duration. Each path adds test cycles with business users, and each add-on that needs rebuilding adds time. A move to Odoo or ERPNext also adds data extraction and mapping work. Ask for a plan with milestones and dates in writing before work starts.
What must our company provide during the project?
Your company must supply people who can make decisions and check results, and the project stalls without them. Name these roles before the engagement begins:
- A data owner who signs off the master data, such as business partners, items and open documents
- Process owners for finance, sales, purchasing, inventory and production who confirm the workflows
- Test users who run realistic transactions in each test cycle
- A decision-maker who approves scope changes, cutover timing and go-live
These roles are needed whether you upgrade or move, so budget the staff time as part of the project.
Can our internal IT team migrate without an outside partner?
An internal team can do it only if it has hands-on skill with the source database, the target platform and the data mapping, and the capacity to run repeated test cycles. Odoo imports data from Excel and CSV files and recommends External IDs when importing from a third-party application, which makes later updates easier. ERPNext Data Import works from templates, but its documentation advises importing only a few thousand records at a time. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own infrastructure, under a fixed scope agreed in writing. Compare that scope with your team's capacity before deciding.
Can Odoo Community use the upgrade service?
No. Odoo's upgrade service moves a database to a newer supported version by creating an upgraded test database, which you should test before production. On-premise use of that service requires an Enterprise subscription, and the Community edition has no access to it. If you run Community, you must plan and test each version change yourself, including data backups and custom module checks. Odoo's upgrade documentation describes the service and its requirements.
Do we need Odoo Enterprise to run it on premises?
For on-premises use, the Enterprise subscription is the route Odoo documents for the upgrade service, and the pricing page places on-premise hosting in the Custom plan. Odoo Community is licensed under LGPLv3, and the Enterprise source code is not publicly available. The pricing page also states that only the Custom plan includes multi-company, Odoo Studio, external API access and custom modules. Check each of those features against your processes, then review the per-user monthly prices and yearly discount on the Odoo pricing page before comparing totals.
What happens if we stay on 10.0 after December 31, 2028?
After December 31, 2028, Business One 10.0 leaves mainstream maintenance, and SAP's own materials point to Version 11 as the successor. Confirm with SAP or your partner which extended support options exist, what they cost and what conditions apply. Also confirm whether your SAP HANA or Microsoft SQL Server versions remain supported on 10.0. Your compliance and security obligations may require documented risk acceptance if you stay on an unsupported release. The SAP Business One product page is a starting point for current product information.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure. For a Business One 10.0 decision, we start with a written scope that compares the Version 11 upgrade path with a move to Odoo or ERPNext, so the decision rests on your data, your add-ons and your timeline.
How we scope
- We inventory the Business One 10.0 company databases, add-ons, reports, integrations and user roles before any recommendation is made.
- We confirm with your partner which Version 11 upgrade steps, add-on certifications and data conversions apply to your environment.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We build a target environment for Odoo or ERPNext inside your cloud account, data center or air-gapped network.
- We map master data, open documents and balances, then load test extracts with External IDs or Data Import templates.
- We test the rebuilt add-on functions against sample transactions and record the results for sign-off.
How we hand over
- We deliver architecture notes, data mapping sheets, runbooks and test records so your team can run the new system.
- We document the cutover plan, rollback steps and the reconciliation checks used to confirm balances match.
- We train named administrators on access control, backups, upgrades and the vendor release calendar you must follow.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after go-live.
- We schedule upgrades against each platform's published support windows so your team plans ahead of end of support.
- We can keep the Business One environment reachable for read-only reference while historical records are verified.
