Business Central on-premises release waves: what the constraint requires
On-premises Business Central owners face a release wave every six months, and each wave has a fixed end date after which Microsoft stops supporting it. Extensions written in AL often need retesting and rework on each wave, so the upgrade calendar becomes a standing cost. The short answer is one of two options: keep the installation current on a planned upgrade cadence, or move to self-hosted Odoo or ERPNext, where your team sets the upgrade window. Confirm the wave end dates and on-premises support terms directly with Microsoft. The Business Central facts available for this page cover deployment options and BACPAC limits, not those dates, so do not plan around an assumed date.
The decision turns on cost by component, and no single price settles it. Keeping current recurs: user licenses, partner time for regression testing and extension fixes on every wave, test environments, and internal staff hours to coordinate each cutover. Moving to a new platform is mostly one-time work: data migration, reimplementation, retraining and cutover, followed by recurring hosting and support. Ask any partner to price each wave as a separate line item, with the extension count and test scope written out. For Odoo, the upgrade service requires an Enterprise subscription on-premise, and the Community edition has no access to it, so budget that line separately. Review Odoo's upgrade documentation before comparing its cadence with Microsoft's.
Before choosing, run a short inventory. Count the AL extensions, mark which ones touch posting, reporting or integrations, and record how many waves your installation sits behind. Then check your data path. A BACPAC export from Business Central online requires a paid subscription, is limited to 10 exports per month per environment, and Microsoft does not support creating a working on-premises environment from it, so an online-to-self-hosted move needs a different extraction route. The admin center export documentation sets out those limits. If extensions are few and a scheduled test window fits your team, keeping current is often the simpler path. If each wave keeps forcing rework, start scoping a migration early.
What staying on a supported Business Central release requires
On-premises Business Central stays supported only while you keep it on a current release wave, and each wave has a fixed end date. The obligations below connect in one calendar: each wave must be installed, tested against your extensions, supported by a current database and server stack, and scheduled before its end date.
Installing each release wave
On-premises owners must install each Business Central wave themselves to stay on a supported build. Plan a non-production environment, a restored copy of the production database, and a cutover window for every wave. Before you set the calendar, confirm with Microsoft which build and cumulative update your version requires and how long each wave stays supported. Your deployment team should own this checklist from the first wave onward.
Retesting AL extensions each wave
Every per-customer AL extension must be regression tested on each wave. Platform changes can alter behavior that custom objects, event subscribers, reports and integrations depend on. Keep an automated or scripted test suite, record which extensions each partner or internal team owns, and reserve time for fixes before the wave reaches production. Ask your partner which extensions have already been validated against the upcoming wave.
Keeping SQL Server and servers current
On premises you also own the database engine, the operating system and the server patch levels that the Business Central service runs on. A wave can drop support for an older base, so check the supported SQL Server and Windows Server versions for each wave before you upgrade the application. Rehearse backup and restore on the new stack, because a wave that installs cleanly still fails if recovery procedures were never tested on it.
Planning around wave end dates
Each wave has a fixed end of support, after which your instance runs an unsupported build. Map every on-premises environment to its end date in one shared calendar, and set a decision point well before each date. Ask Microsoft for the current lifecycle information for your version instead of relying on older articles. Include the time needed for extension fixes, testing and sign-off in every plan.
Test copies and rollback
Microsoft does not support creating a working on-premises Business Central environment from a BACPAC exported from Business Central online, so test and rollback copies must come from your own database backups. Confirm backup frequency, retention and restore timing with your database administrator. A tested restore point is what makes a failed wave a rescheduled upgrade rather than an outage.
Comparing open-source upgrade cycles
Odoo documents three years of standard support per major version, followed by two more years to complete the upgrade, with minor versions usually released every two months. ERPNext 14 reached end of life on January 31, 2026, ERPNext 15 is planned for support until the end of 2027, and ERPNext 16 until the end of 2029. Self-hosted Odoo on-premise upgrades use the upgrade service only with an Enterprise subscription, and Community users have no access to it.
Keep current on Business Central or replace with self-hosted Odoo or ERPNext
Keeping Business Central on premises means installing each release wave on your own servers before support for your current version ends. You choose the install date within the window, but the cycle repeats on Microsoft's six-month wave schedule, so the same people revisit the same work twice a year.
- Upgrade timing: You pick the install date, but a version that leaves support gives you no further fixes. Confirm the end date for your version in Microsoft's deployment documentation and your partner's written plan.
- Extension rework: Custom AL extensions and third-party apps must be retested against each new wave before go-live, and that effort recurs every cycle.
- Infrastructure: SQL Server, the application tier and patching stay under your control, so hardware, licenses and staff time to run them are your costs.
- Test data: Test copies must come from your own databases. Microsoft does not support building a working on-premises environment from a BACPAC exported from Business Central online.
Before committing, ask for a written list of every extension and integration that must be retested for each wave, and who performs that testing.
Moving to Business Central online removes the install cycle from your team, because Microsoft applies updates to the cloud service on its own schedule. Your data is stored in the Microsoft cloud, and your extensions still need testing against each update, but you no longer decide when the platform changes.
- Who runs the upgrade: Microsoft deploys updates to online tenants, so your team no longer schedules installs, though it still validates extensions and integrations.
- Control over timing: Your preparation window is set by the service rather than by your own calendar. Confirm the current update policy and any notice periods in writing.
- Data location: Records sit in the Microsoft cloud, which matters for residency reviews. Confirm the hosting region and who can access the environment.
- Exit path: Online databases can be exported as BACPAC files to Azure standard storage only with a paid subscription, up to 10 times per month per environment. Plan that export before you need it, since the file does not produce a working on-premises system.
Before you choose this path, check the subscription terms and the export limit against your migration timeline and your exit plan.
Odoo's cycle follows its own major version lifecycle. Each major version receives standard support for three years, and the documentation describes two more years to complete an upgrade. Minor versions usually arrive about every two months. Community is free under LGPLv3, while the upgrade service and some features need an Enterprise subscription.
- Support window: Standard support covers three years after a major release, including security fixes. For example, Odoo 18.0 standard support runs until September 2027, so plan the next major move before then.
- Upgrade path: The upgrade service moves a database to a newer version through an upgraded test database that you must test before production. On premises, this service requires Enterprise, and Community has no access to it.
- Hosted timing: On Odoo Online and Odoo.sh, major upgrades are mandatory every two years. On premises, you keep the timing within the support window.
- Customization: Python modules remain in your own repository, so each major version needs your modules ported to its APIs. That work recurs with every major move.
- Cost split: Community software is free, while Enterprise subscriptions, hosting and partner work are separate line items to request in a quote.
Before you start, confirm which edition and support plan cover your target major version in writing.
ERPNext releases follow Frappe's supported versions policy, which lists a support end date for each major version. Version 15 is planned to be supported until the end of 2027, version 16 until the end of 2029, and version 14 reached end of life on January 31, 2026. Self-hosting is free under GPL-3.0, and Frappe Cloud is available as a managed option.
- Version window: Check Frappe's supported versions page for your target version and set your move date before the support end date.
- Minor releases: Both supported major versions receive frequent minor releases, so patching is routine but should be tested in staging first.
- Install options: You can deploy with Docker Compose using the frappe_docker images, with the bench command line tool, or on Frappe Cloud. The single-file demo setup is for short-lived evaluation only.
- Custom logic: Server Scripts are disabled by default from version 15 and must be enabled. Frappe Cloud public shared benches do not allow them, so custom logic may need to live in a Frappe app on your own infrastructure.
- Warranty: Frappe warranty coverage requires a listed version and a matching Frappe Cloud support plan, so confirm what coverage your self-hosted setup has.
Before you commit, ask your implementation partner which version you will run, who applies minor releases and how warranty terms apply to your deployment.
How Odoo and ERPNext upgrade cycles compare with Business Central waves
This table compares Odoo Community, Odoo Enterprise on premise and self-hosted ERPNext on license, support windows, release cadence, upgrade path and who performs the work. Read it against Business Central's six-month waves: Odoo and ERPNext both publish fixed end-of-support dates per major version, and the open-source options let you choose when to take each upgrade within those windows.
| Dimension | Odoo Community | Odoo Enterprise (on premise) | ERPNext (self-hosted) |
|---|---|---|---|
| License | LGPLv3, source published in the odoo/odoo repository | Proprietary subscription, Enterprise source not publicly available | GPL-3.0 for ERPNext, MIT for the Frappe Framework |
| Major version support window | Confirm which Odoo support terms apply to Community-only installs | Three years standard support, then two years to complete the upgrade | Version 15 supported to end of 2027, version 16 to end of 2029 |
| Named end-of-support dates | Not applicable as a support subscription; confirm with Odoo | 18.0 to September 2027, 19.0 to September 2028, 20.0 to September 2029 | Version 14 ended January 31, 2026; 15 and 16 as above |
| Release cadence | Minor versions usually every two months | Minor versions usually every two months; security patches only during standard support | Frequent minor releases on both supported majors, such as v16.51.1 and v15.123.0 in October 2026 |
| Upgrade path | No access to Odoo's upgrade service | Upgrade service builds an upgraded test database to test before production | Migration run by your team or partner on your chosen supported version; confirm steps for each release |
| Who performs the upgrade | Your team or an implementation partner | Your team, a partner, or Odoo's upgrade service under an Enterprise subscription | Your team or an implementation partner; Frappe warranty needs a listed version and matching Frappe Cloud support plan |
| Forced upgrades | None set by Odoo for self-hosted installs; confirm | Major upgrades mandatory every two years on Odoo Online and Odoo.sh, not on premise | You set the schedule within each version's supported window |
What keeping Business Central current costs by component
Keeping on-premises Business Central current is paid for in five components: partner or internal labor for each release wave, retesting of extensions, test environments, SQL Server and infrastructure, and staff time for reviewing release notes and sign-off. Only the infrastructure and the test environments are fixed recurring costs. Labor is recurring, because each wave repeats the same cycle, and its size depends on how many AL extensions, integrations and custom reports you own. A one-time cost sits in the first upgrade, when extensions are inventoried and reworked for the platform. Ask the partner to price the first wave and the steady-state wave separately, so you can see which part shrinks as the extension estate is cleaned up.
Extension retesting is usually the largest variable. Each wave can change behavior that your extensions depend on, so the quote should list every extension, its owner, and whether it is a Microsoft app, a third-party app, or in-house code. Ask who runs regression tests, what test data is used, and whether a test environment with production-like volume is included. The number of test environments and how long they are kept also drives cost. SQL Server licensing, backup storage and monitoring are recurring, and they grow with database size. Confirm with your SQL Server licensing provider and your infrastructure team which of these you already pay for, because on-premises owners often double-count them.
For comparison, self-hosted Odoo and ERPNext move the upgrade cost into a different place, and the difference depends on your support model. Odoo documents that each major version is supported for three years, followed by two more years to complete the upgrade, and that minor versions usually arrive every two months. ERPNext's supported versions page lists a version 15 support period through the end of 2027 and version 16 through the end of 2029. Odoo's upgrade service is an Enterprise subscription item, so it is a recurring license cost. Ask any quote to name the version you would start on, the upgrade path, who tests the upgraded test database, and whether the price includes retesting of custom modules or Frappe apps.
How to deploy self-hosted Odoo or ERPNext with a planned upgrade cycle
This sequence turns an on-premises Business Central estate into a self-hosted Odoo or ERPNext system where you choose the upgrade timing, test each release before production, and keep patches on a recurring schedule.
Inventory extensions, data and integrations
Your team lists every AL extension, report, integration, scheduled job and data set in the current Business Central environment, and marks which ones are still used. An ERP partner or internal architect reviews the list with finance and operations owners. The output is a signed inventory that classifies each item as replace, rebuild or retire, so the migration scope is agreed before any platform choice is made.
Choose the Odoo or ERPNext version against its support window
Check the current support dates on Odoo's standard and extended support page and on Frappe's supported versions page before selecting a release. Confirm whether your edition, whether Odoo Community or Enterprise, and your Frappe support plan match the version you pick. The decision record should name the version, its end-of-support date and the date by which you expect to move to the next major release.
Deploy in your own infrastructure
Your platform team installs the chosen system in your cloud account, data center or air-gapped network. For Odoo, use the packaged installer or a source installation, and for ERPNext, use Docker Compose with the production images from frappe_docker or the bench command line tool. The demo single-file setup is for short-lived evaluation only, so production needs a separate database, Redis, workers, scheduler, Nginx and TLS configuration, with backups and monitoring. Done means the environment passes a health check and restore test.
Build a neutralized test copy
Create a copy of the production database in a separate environment. Odoo documents database duplication with neutralization for test copies, which disables outgoing mail, scheduled actions and payment connectors so the copy cannot affect live customers or suppliers. Confirm the neutralization steps with your Odoo or Frappe documentation for the chosen version. Done means the test copy is isolated, its outbound integrations are disabled, and access is limited to the test group.
Load and reconcile migrated data
Import master data and open balances using the Odoo import tool with External IDs, or the ERPNext Data Import tool with its templates, loading a few thousand records at a time as the ERPNext documentation advises. Rebuild retained AL logic as Python modules or server scripts, noting that Frappe server scripts are disabled by default from version 15 and must be enabled. Reconcile trial balances, open invoices and inventory valuation against the Business Central source. Done means each reconciliation difference is explained and signed off by finance.
Run upgrade and regression tests
Run the target version's upgrade path on the test copy, then execute regression scripts covering posting, reporting, approvals, integrations and user access. For Odoo, the upgrade service produces an upgraded test database that you should test before production, and on-premise use requires an Enterprise subscription. Record defects, fix them and repeat until the test cycle passes. Done means a written test report with pass results for every critical business process and an agreed go or no-go decision.
Cut over and set a recurring patch cadence
Schedule the production cutover with a rollback plan and a verified backup taken immediately before the change. After go-live, set a recurring calendar for minor releases: Odoo usually publishes minor versions about every two months, and ERPNext ships frequent minor releases on its supported branches. Assign an owner who reviews each release, applies it in the test copy first and records the outcome. Done means the patch calendar, owner and test-first rule are documented and the first minor update is completed on that cycle.
Common questions about Business Central release waves and self-hosting
What does staying current on Business Central on premises cost, and who pays?
Staying current costs your organization the internal and partner time spent on each wave, plus the Microsoft licenses that stay in place for every user. Confirm the on-premises licensing terms with your Microsoft partner before you budget. Most of this cost recurs, because a wave arrives twice a year and a skipped wave becomes a larger upgrade later.
The main cost drivers are:
- The number of AL extensions and customizations that need retesting
- The number of third-party add-ons and integrations that depend on them
- The depth of your regression testing and whether it is automated
- How much time finance and operations staff can give to sign-off
Ask your partner for a quote that prices each wave separately, names who performs regression testing, and states what extension updates are included.
How long does a Business Central release wave upgrade take?
The facts available here do not support a fixed duration, so confirm the timeline with your partner against your own environment. The length depends mainly on how many AL extensions you run, how many have changed since the last wave, how many integrations depend on them, and how complete your test coverage is.
A company with few extensions and a documented test script will usually finish faster than one with heavily customized code and manual checks. Ask for a plan that includes a compatibility review of each extension, a test environment built from recent production data, a defect list ranked by severity, and a go-live window agreed with finance and operations. Record how long your last wave took, because that figure is the most dependable baseline you have when you compare internal estimates with partner proposals.
Can our internal IT team handle Business Central upgrades alone?
Some teams can, but the answer depends more on skills and capacity than on the software. A wave touches Business Central administration, database and hosting operations, AL development for extension fixes, functional testing by business users, and a backup and rollback plan.
Teams with an in-house developer who knows the extensions and a tester who owns the regression script can often carry the work internally. Teams that depend on one person, or whose staff are busy during wave windows, usually need outside help at peak times. If you move to a self-hosted open-source ERP, DeployOpen can plan, implement, upgrade and support that platform inside your own infrastructure, either under a fixed-scope agreement or a retainer. Decide before the next wave which tasks your team owns and which you will outsource.
How do Odoo and ERPNext upgrade cycles compare with Business Central waves?
Odoo and ERPNext both publish support windows that you can plan around, which makes their cycles more predictable than an unscheduled forced change. For Odoo, the documentation states that each major version is supported for three years, followed by two more years to complete the upgrade, and that minor versions usually arrive about every two months. Odoo's upgrade service on Enterprise moves a database to a newer version through a test database that you should check before production.
For ERPNext, the supported versions page lists version 15 as supported until the end of 2027 and version 16 until the end of 2029. Both products release frequent minor updates, so the work is smaller but more frequent. Schedule a regular update rhythm in either case, and test every change against your own customizations.
Does self-hosting ERPNext carry a license fee?
Self-hosting ERPNext carries no software license fee, because ERPNext is licensed under GPL-3.0. Your costs are the infrastructure you run it on, the database and cache services, backups, monitoring, and the people who maintain and upgrade it. Those costs recur, and they grow with the number of sites, users and integrations.
If you prefer managed hosting, the ERPNext pricing page lists Frappe Cloud shared site hosting from 5 US dollars per month, shared servers from 20 US dollars per month, and dedicated servers from 125 US dollars per month. Those are list figures from that page and may change. Frappe's supported versions policy also says customers must be on a listed version and subscribed to a matching Frappe Cloud support plan to receive warranty coverage from Frappe, so check that condition before you commit to a self-hosted or support arrangement.
Can a BACPAC export from Business Central online seed an on-premises environment?
No. Microsoft states that it does not support creating a working on-premises Business Central environment from a BACPAC exported from Business Central online. Plan to use the export for data extraction only, not as a copy of the environment.
The export itself is limited. Microsoft Learn states that the BACPAC export requires a paid subscription, goes to an Azure standard storage account, and can run up to 10 times per month per environment. Once you have the file, you can load it into SQL Server to read the data for a migration. Ledgers, items, customers and other master data can then be mapped into a new system. Extensions, customizations and configuration are not carried over in a usable way, so you will need to rebuild them in the target platform.
Does Odoo Community include upgrades and support for on-premise use?
No. The Community edition has no access to Odoo's upgrade service, according to Odoo's upgrade documentation. For on-premise use, the upgrade service requires an Enterprise subscription. Odoo's pricing page also states that only the Custom plan can be hosted on Odoo.sh or on-premise, and that only Custom includes multi-company, Odoo Studio, external API access and custom modules.
Without that subscription, you own the upgrade work. You would take the source or packaged release, test a copy of your database, resolve module changes, and plan each move yourself. Standard support covers three years after a major release, and security patches are only provided during standard support. Confirm with Odoo whether your edition and plan meet your requirements before you decide between Community and Enterprise.
How do we confirm which ERP version is still supported before we commit?
Check the vendor's published support dates for the exact version you plan to run, and record them alongside your own upgrade calendar. For Odoo, the standard and extended support pages describe the support window for each major version, and the Odoo documentation describes how SaaS versions are released every two to three months and cannot use extended support. For ERPNext, the supported versions page lists which major versions are supported and when each ends.
Before committing, ask the vendor or partner to confirm three things: the end date of standard support for your target version, what happens to security patches after that date, and whether extended support is available for your deployment type. Put those answers in writing in the scope, because they set the deadline for your next upgrade.
Evidence to keep for an upgrade review
Each release wave on premises asks the same question: can you show that the upgrade was tested, that your extensions still work, and that you can recover if it fails? The cards below describe the records that answer those questions, and they are the same records an internal reviewer or external auditor will ask for when you move between Business Central releases or to a replacement platform.
Upgrade test records
Keep a dated record of each upgrade rehearsal against a copy of the production database, with the source and target build, the databases tested, the people who signed off, and the defects found and closed. Reviewers usually ask whether the test ran on data that resembles production and whether the result was accepted before the live upgrade. Confirm with your partner and Microsoft's current upgrade guidance which steps belong in the rehearsal for your version.
Extension compatibility notes
For each AL extension, record the version it was built against, the Business Central release where it was last validated, and any known breaking changes in the release notes you reviewed. Reviewers want to see that customizations were checked, not assumed to work. Note which extensions you plan to rebuild on Odoo or ERPNext instead of upgrading, since those rebuilds change the scope of the next review.
Support-window dates per version
Record the end-of-support date for the Business Central version you run and for each candidate target, taken from Microsoft's published lifecycle statements on the day you decide. For the open-source comparison, record the same dates for Odoo and ERPNext. Odoo publishes standard support windows per major version, and Frappe publishes supported versions, so both can be placed in the same table. Date the record so the review shows what was known when the decision was made.
Backup and restore tests
A backup is only evidence once a restore has been proven. Keep the date of each restore test, the backup set used, the time taken to bring the database back, and the result of the business checks run afterward, such as trial balance totals and open posting counts. For Business Central online, note that BACPAC exports are limited and cannot be restored into a working on-premises environment, so the restore path must be planned in advance.
Change records
Keep an approved change record for each upgrade, with the requester, the risk assessment, the rollback plan, the maintenance window, and the post-change verification. Reviewers check that changes followed the same path every time and that exceptions were approved. Link each change record to the test records and extension notes above, so one upgrade can be traced from request to verified production state.
Access and approval records
Keep the list of users and administrators who can run upgrades, export data and approve production changes, with the date each role was granted and reviewed. Upgrade work often runs under elevated accounts, so reviewers ask who held those rights during each wave. Record the same details for the staging and production environments, and for any partner staff who had access to the on-premises database.
When moving off Business Central on premises makes sense
Staying on Business Central on premises makes sense when the business can absorb a release wave on a predictable schedule and the custom work is small enough to retest each time. Start by writing down how often you are willing to upgrade, who signs off on each wave, and how many AL extensions the environment carries. If every wave means a test cycle across custom objects, integrations and reports, the recurring cost of staying current is the number that should drive the decision, not the license line. Ask your Microsoft partner to list the extensions that depend on events, APIs or features that changed in the last two or three waves, because that list shows the real rework load.
Data residency is the second test. Business Central on premises keeps the database on your own SQL Server, but a move to Odoo or ERPNext changes where the database, backups and file attachments live, so confirm which regulations, contracts and internal policies name the hosting location before you commit to a target. Budget is the third test. A fixed-scope migration has one-time costs for data extraction, mapping, rebuilding customizations and cutover, plus recurring costs for hosting, patching and support. Ask for these as separate lines in any written scope, and ask who carries the risk if a data load fails validation. Once these criteria point toward moving, the work splits into the paths covered in the Business Central vs Odoo and Business Central vs ERPNext comparisons and the migration guides for each platform.
Whichever way the criteria point, make the decision with a dated plan. Confirm the current Business Central version your environment runs and the support end date Microsoft publishes for it, then compare that date with the time a migration would realistically need for testing and parallel running. Odoo publishes a three-year standard support window per major version, and ERPNext publishes end-of-life dates for each Frappe major version, so both platforms require upgrades too, just on different terms. Use the same question on every option: how many upgrades will we run in the next five years, who performs them, and what does each one cost to test. The answer, written into a quote, is what separates a sound replacement decision from an expensive change of vendor.
