Why a v14 site needs an ERPNext 14 to 15 upgrade now
If your self-hosted ERPNext site still runs version 14, you must move, and version 15 is the supported step to move to. ERPNext and Frappe Framework version 14 reached end of life on January 31, 2026, so it no longer receives the fixes your site depends on. According to Frappe's supported versions page, version 15 is planned to be supported until the end of 2027 and version 16 until the end of 2029. Choosing 15 is a shorter runway than 16, but it is the nearest supported step from 14 and the one this upgrade path targets. Confirm the current status of each version on that page before you set a plan, since support dates are the vendor's to change.
Frappe's warranty coverage depends on two conditions. Your site must run a listed version, and you must hold a Frappe Cloud support plan that matches that version. If you host on your own infrastructure, ask Frappe directly how these conditions apply to your contract and whether an unsupported site has any remaining coverage. Your internal owner should write down the answer, because it determines whether a failed upgrade becomes a vendor escalation or an internal recovery task.
The v14 to v15 hop is a major upgrade, not a routine patch. Version 15 changes how apps are installed and split, and it turns Server Scripts off by default, so any custom automation you rely on must be checked and re-enabled deliberately. Plan for the breaking changes listed in the release notes, the apps that moved out of the core, and your own customizations, print formats and reports. Treat the upgrade as a project with a test site, a rollback point and retesting of every customization before production cutover. The sections below cover each of these steps.
What changes between ERPNext v14 and v15
This table lists the changes that affect a v14 to v15 move, with the impact of each and the action your team needs to take. Read the support window and Server Scripts rows first, because they shape the timeline and the customizations you must retest. Confirm exact breaking changes against the v15 release notes and each app's branch before you plan the cutover.
| Change | Impact | Action needed |
|---|---|---|
| ERPNext and Frappe v14 end of life | Version 14 reached end of life on January 31, 2026 according to Frappe's supported versions page, so self-hosted v14 sites no longer receive support. | Decide the target version and schedule the upgrade. Confirm current support terms for your setup with Frappe. |
| v15 support window | Frappe plans to support version 15 until the end of 2027 according to the same supported versions page, which sets the planning horizon for a v15 landing. | Compare this window with the version 16 option before you commit. Confirm the dates on the supported versions page at planning time. |
| Server Scripts disabled by default | Starting from version 15, Server Scripts are off unless enabled, so existing document hooks and API endpoints may stop running after the upgrade. | Inventory every Server Script, then enable server_script_enabled only where your policy allows it and retest each script. |
| Server Scripts on Frappe Cloud public shared benches | Public shared benches on Frappe Cloud do not allow Server Scripts, so customizations that depend on them cannot run there. | Move affected logic to a dedicated bench or a custom app, or confirm the hosting plan supports your scripts. |
| Lending, Payments and E-commerce split into separate apps | These features no longer ship inside the core ERPNext install, so sites that use them need the companion apps installed before migrating. | List which features you use, install the matching app branches, and verify they are compatible with the target ERPNext version. |
| WooCommerce integration replacement | Your WooCommerce connector must be replaced or reconfigured for the v15 app layout, which changes how orders and stock sync. | Confirm the replacement app and its supported version with the vendor, then test order and stock sync on a copy of production data. |
| Serial and Batch Bundles | Serial and batch tracking moves to Serial and Batch Bundles, so stock entries that reference older serial and batch fields need checking. | Run a data check on serial and batch balances before and after the migrate, and confirm the exact conversion steps in the release notes. |
| Print formats and reports | Custom print formats and reports can break when fields, templates or query code change between versions. | Retest every custom print format and report on the staging site, and fix any field references that no longer resolve. |
| Release notes and app branches | Exact breaking changes are listed in the v15 release notes and in each companion app's branch, not in this summary. | Read the v15 release notes and the branch of every installed app, and record each breaking change against your customizations. |
What to back up and inventory before the ERPNext upgrade starts
The upgrade from v14 to v15 changes the database schema, the app versions and the code your site depends on. Each item below is something you can restore, compare or test before the upgrade starts, so a failed step has a known way back. Work through them in order, because the backup is only useful if the inventory is complete enough to rebuild the site on a clean host.
Full database and files backup
Take a complete database dump and a copy of the site's private and public files, taken together so they match the same point in time. The backup is only proven once you restore it to a separate host, log in, open a sales invoice and check that attachments open. Confirm who holds the backup keys, where copies are stored and how long they are retained. Repeat the restore test on the final backup you will roll back to.
Custom apps and their versions
List every custom Frappe app installed on the site, the commit or tag each one is pinned to, and the Git remote it comes from. Check that each app declares compatibility with version 15 before you plan its changes, since an app that runs on v14 can still break during migrate. Record apps installed on the bench but not attached to the site, because they can still be loaded by hooks.
Customizations and scripts
Export customizations so they live in version control instead of only in the database. Inventory custom fields, property setters, client scripts, server scripts, web forms, print formats and custom reports. Server scripts are disabled by default from version 15 and must be enabled with the server_script_enabled setting, so note which ones your processes depend on before you upgrade.
Companion apps and their branches
Write down each companion app that splits out of ERPNext in version 15, such as Lending, Payments and E-commerce Integrations, along with the branch and version it currently runs. Confirm that a matching branch exists for version 15 before the upgrade, and install those apps in the same window as the core upgrade. A mismatched companion app is one of the most common reasons a migrate stops partway.
Production-like test copy
Restore the production backup to a separate test site with the same app set and a comparable volume of data. Use it to run the full sequence of steps, time them, and record every warning and error. Keep the test site's data current enough that its results reflect the production site. Treat a test that uses a small or synthetic dataset as a partial check only.
Hosting access and support route
Confirm who can run the upgrade, who can roll back, and who owns the server, database and DNS. If the site runs on Frappe Cloud, check your support plan matches the version you are moving to, because Frappe's supported versions policy ties warranty coverage to a listed version and a matching plan. If you self-host, name the internal team or partner responsible for the window and agree on the escalation route before you start.
How the split-out apps and Server Scripts change the plan
Several apps that were part of ERPNext before version 15 now ship as separate Frappe apps, including Lending, Payments and E-commerce Integrations. A v15 site will not run the features those apps provide unless the matching app is installed on the same branch as ERPNext. Before you run migrate, list every app on your current v14 bench, map each one to its v15 counterpart, and confirm the branch with your team. A missing app rarely stops the upgrade. Instead, loan schedules, payment gateway doctypes, or ecommerce sync jobs fail quietly, documents show up with broken links, and scheduled jobs log errors nobody reads. Test each workflow that depends on a split-out app and check that its data is present after migration, not only that the site loads.
Server Scripts are a second area where the upgrade changes behavior without a visible error. From version 15, Server Scripts are disabled by default, so any document event hook, validation or API endpoint written as a Server Script will stop running until it is enabled. Inventory every Server Script on the site, record what it does and who depends on it, then decide for each one whether to keep it, move the logic into a custom app, or retire it. To keep a script running, enable it deliberately through the server_script_enabled setting and document the reason, since the script executes Python with broad access to the site. If the site runs on Frappe Cloud public shared benches, Server Scripts are not allowed at all, so those scripts must be moved before the upgrade. The Frappe Framework documentation for Server Script describes the setting and its limits, and you should confirm them against the exact version you plan to run.
The staged bench migrate and where to roll back
This sequence moves a self-hosted ERPNext v14 site to v15 on a rehearsal copy first, so each error is found and fixed before production is touched, and every step has a defined point to return to the pre-upgrade state.
Confirm target version and app branches
Before running any command, record the ERPNext and Frappe version you are moving to, and list every installed app with the branch or tag that matches it. Confirm the v15 line is the one you intend to run, since Frappe's supported versions page lists v15 as supported until the end of 2027 and v16 until the end of 2029. Ask your partner or internal team to confirm each companion app has a v15 branch. Done when you have a written matrix of app, current branch and target branch, signed off by the application owner. Rollback point: none needed, nothing has changed yet.
Take a backup and prove it restores
From the bench directory on Linux, run the backup command with the database and files included, then copy the archive off the server. A backup that has not been restored is not a rollback point, so restore it to a separate machine or bench and confirm the site loads, that a sample of recent invoices and stock entries open, and that file attachments display. Done when the restore test passes and the archive checksum is recorded. This archive is the pre-upgrade rollback point for every later step.
Clone production to a test bench
Create a rehearsal bench on separate infrastructure, restore the production backup into it, and point it at a non-production mail and integration configuration so no outbound emails, payment requests or bank feeds fire from the copy. Confirm the bench runs on the current v14 version and that the data matches production record counts for key DocTypes. Done when the test site is a faithful copy that can be reset from the same archive. Rollback: discard the test bench and restore again from the archive.
Install split-out and remaining apps on matching branches
On the test bench, fetch the apps that v15 separates from ERPNext, including Lending, Payments and E-commerce, plus any other apps you run, using the branches confirmed in step one. Install each app on the site with the bench install-app command, and confirm the bench lists every app with the expected version. Done when all apps install without errors and the site loads with each app visible in the apps list. Rollback: uninstall the app from the test site or restore the archive.
Run bench migrate on the test site and fix errors
Run the bench migrate command against the test site from the bench directory. Read the full output rather than only the final line, because failed patches and sync errors are often logged mid-run. Fix each failure in code or data, then restore the archive and rerun from the beginning, so each attempt starts from the same state. Done when the migrate completes with no patch errors, the site restarts cleanly, and a sample of accounting, stock and manufacturing transactions open and reconcile against the v14 numbers. Rollback: restore the archive to the test bench.
Check Server Scripts, print formats, reports and integrations
Review each custom script, print format, report and integration against its behavior on v14. Note that from version 15 Server Scripts are disabled by default and must be enabled with the server_script_enabled setting, so confirm whether your site depends on them and whether your hosting permits that setting. Print the key invoices, delivery notes and statements, run the standard financial and stock reports, and test each connector end to end on the test site. Done when each item has a recorded pass or a documented fix. Rollback: revert the fix in your custom app or restore the archive.
Repeat the full run on a rehearsal copy
Once the test bench migrates cleanly, repeat the whole sequence from a fresh production backup on a second copy, with the same app branches and the same commands, and time the steps for your own planning. Confirm that the fixes made in the first rehearsal work without manual intervention. Done when the second run reproduces the first with no new errors and the reconciliation checks match. Rollback: restore the archive to the rehearsal copy.
Schedule the production window with a fresh backup
Agree a maintenance window with the business, communicate that users will be locked out during migration, and freeze new transactions for the duration. Take a fresh backup of production immediately before the window opens, verify it restores as in step two, then run the same bench migrate sequence used in rehearsal. Done when the site loads on v15, the post-upgrade checks pass, and users confirm their key workflows. Rollback: if a blocking error appears, restore the fresh pre-upgrade backup to production and keep v14 running until the cause is fixed and rehearsed again.
How the hosting path changes the upgrade work
On Frappe Cloud, the platform team operates the bench, so the migrate step and app installation are driven through the Frappe Cloud dashboard rather than from a shell you control. Your team chooses the target version and the companion apps for each bench, and Frappe Cloud handles the server side of the upgrade. Confirm with Frappe what the current support plan covers, because the supported versions policy ties warranty coverage to a listed version and a matching Frappe Cloud support plan. Hosting prices are listed on the ERPNext pricing page and should be compared against your own sizing and support needs.
- Who runs migrate: Frappe Cloud runs the migration as part of the bench upgrade, and you watch the job status and logs.
- How apps are pinned: Each bench records the branch or version of ERPNext and each companion app, so you select matching versions before the upgrade.
- Where the backup lives: Frappe Cloud takes a site backup before the change, and you should confirm retention and restore steps with the vendor.
- What rollback looks like: Rollback is a restore of the pre-upgrade backup to a site on the previous bench, which takes time and loses writes made after the backup.
Before the upgrade, check that your custom server scripts still run, since Server Scripts are disabled by default in version 15 and Frappe Cloud public shared benches do not allow them.
With frappe_docker, the image is the unit of change. You do not patch a running container in place. Instead, you build new images that include the target ERPNext and companion app versions, then run the migration as a separate step against each site. The frappe_docker repository provides production Compose files with MariaDB, Redis, workers, the scheduler and Nginx, and its single-file demo setup is intended for short-lived evaluation only, so do not use it as the base for production.
- Who runs migrate: Your team runs bench migrate or the migrator service after the new images are deployed.
- How apps are pinned: App versions are fixed in the image build arguments, so every upgrade starts with a new image tag.
- Where the backup lives: Database and site file backups sit in volumes or storage you manage, and must be taken before the migrator runs.
- What rollback looks like: Rollback means redeploying the previous image tag and restoring the database backup, because a migrate that has already altered the schema cannot be reversed by the old image alone.
Run the upgrade first against a copy of production data to confirm the migrator completes and the cache rebuilds correctly.
A manual bench install gives your team direct control over every step. You update the bench and the app checkouts on the server, then run the migrate command for each site. This path also has the most room for drift, because app branches, Python and Node versions and custom patches live on the host and are easy to change without a record. Keep the bench configuration and app list in version control so the upgrade can be reproduced.
- Who runs migrate: Your team runs bench migrate for each site, usually after updating the apps and restarting workers.
- How apps are pinned: Each app is checked out on a branch or tag, and the apps list in the bench directory records what is installed.
- Where the backup lives: Your team takes the backup with bench backup before migrating, and stores it outside the bench directory.
- What rollback looks like: Rollback means checking out the previous app versions, restoring the database and files from backup, and restarting services.
Confirm your Python and Node versions against the release notes for the target version before you start, and test the full sequence on a staging site.
What makes an ERPNext 14 to 15 upgrade take longer
This table lists the factors that typically extend a v14 to v15 upgrade and what to check for each one. Read it against your own site inventory, since the same driver can be minor on one bench and dominant on another. The main takeaway is that custom code, companion apps and data quality usually set the pace more than the migrate command itself.
| Driver | Why it matters | What to check |
|---|---|---|
| Server Scripts and hooks | From version 15, Server Scripts are disabled by default and must be enabled with the server_script_enabled setting, so scripts that ran silently on v14 can stop firing until they are reviewed. | Inventory every Server Script, document event and API endpoint, confirm which are enabled on each site, and retest each one on a staging copy. |
| Custom apps and hooks | Custom Frappe apps depend on hook names, whitelisted methods and document lifecycle behavior that may have changed between majors, which can break at install or at first use. | Pin the custom app to a v15-compatible branch, run its tests against v15, and confirm every hook it registers still exists. |
| Companion apps split out in v15 | Apps such as Lending, Payments and E-commerce must be installed and version-matched with ERPNext, and a missing or mismatched app can block bench migrate. | List every installed app on the bench, map each to its v15 branch, and confirm the install order before the first migrate. |
| Number and type of installed apps | Each extra app adds its own patches, dependencies and possible conflicts, so effort grows with the count and the degree of customization in each one. | Count apps per site, note which are maintained by a third party, and check whether each has a published v15 release. |
| Database and file store size | Migration patches rewrite tables and may rebuild indexes, so large transaction history and attachments extend the window needed for backup, migrate and restore. | Measure database size and the number of rows in the largest DocTypes, measure the private and public file store, and time a full restore from backup on a test host. |
| Number of sites on one bench | Every site runs its own migrate and patch set, and a failure on one site can hold up the others on the same bench. | Count sites per bench, decide whether they migrate in sequence or separately, and plan a rollback path for each site. |
| Print formats and reports | Custom print formats, Jinja helpers and script reports can render differently or fail after upgrade, and they are easy to overlook because they are not part of the data. | Export every custom print format and report, render a sample of each against known v14 output, and check currency, date and tax layouts. |
| Payment, e-commerce and bank integrations | Gateway callbacks, webhook URLs, marketplace connectors and bank feed mappings rely on app versions and settings that the split apps change, and errors may only appear with live traffic. | List each external system, its connector app and version, and test callbacks and syncs in a sandbox before cutover. |
| WooCommerce or other legacy connectors | Replacing a WooCommerce connection with the v15 e-commerce path means remapping items, orders and tax data, which takes longer when product catalogs are large or inconsistent. | Compare item and order counts between systems, confirm the mapping for taxes and variants, and agree what history is moved and what stays in the old system. |
| Serial and Batch Bundles | Moving stock records to Serial and Batch Bundles changes how serial and batch numbers are stored, so sites with heavy stock history or partial batch data need more checks. | Run stock reconciliation reports on v14, identify items with missing or duplicate serial and batch numbers, and clean them before migrating. |
| Current site state | Heavy custom data, manual edits to core records, or missing or unverified backups raise the risk of a failed migrate and extend recovery work. | Confirm the latest backup restores cleanly, review custom data outside standard DocTypes, and record a known-good state before starting. |
| Number of test cycles | Each full test run on a staging copy exposes a new set of issues, so the number of rounds needed depends on how many areas above apply to your site. | Agree the test scripts and sign-off owners in writing before the work starts, and ask any partner to state how many rounds the fixed scope includes. |
What buyers ask before hiring help with the ERPNext 14 to 15 upgrade
What drives the cost of an ERPNext 14 to 15 upgrade?
The main cost drivers are the number of sites and companies, how much custom code and how many custom apps the site runs, and how many of the apps split out in v15 the site depends on. Lending, Payments and Ecommerce each add installation and testing work, and replacing WooCommerce adds integration work of its own. Data volume matters too, because stock history, valuation and batch or serial records take longer to check and reconcile. Upgrade work is usually a one-time cost, while the upgraded site then carries recurring costs for hosting, minor updates and any support retainer. Ask any provider for a quote that lists each app, each custom component, each test cycle and the rollback plan as separate lines, so you can see what is one-time and what recurs.
Can our own team do the ERPNext 14 to 15 upgrade without a partner?
Yes, a capable in-house team can do it, provided it has Linux and bench experience, a staging environment that mirrors production, and someone who understands your accounting, stock and production configuration. The work that most often gets underestimated is not the command itself but the retesting of customizations, print formats, reports and reconciliations after each step. Ask whether your team has done a major ERPNext upgrade before, whether it can run a full test migration on a copy of production, and who will sign off each check. If any of those answers is uncertain, a fixed-scope engagement can cover the parts your team does not have time or experience to cover.
What does the upgrade need from our side?
The upgrade needs four things from your side. First, access to the servers, bench, database credentials and any cloud or data center accounts that host the site. Second, a named owner for each business check, such as the controller for ledger balances, the warehouse lead for stock valuation and the production lead for work orders and BOMs. Third, representative test data, ideally a recent copy of production that can be restored into a test environment, with personal data handled under your own policies. Fourth, time from those owners during testing, because they are the people who can say whether a printed invoice, a report total or a stock balance is correct. Agree these responsibilities in writing before the scope is signed.
How long does an ERPNext 14 to 15 upgrade take?
The duration depends mainly on the same factors as cost: the size and complexity of the site, the amount of custom code, how many companion apps must be installed, and how quickly business owners can complete their checks. Plan for several cycles of test migration and fixes before any production cutover, because each test run usually reveals issues in customizations or data. The production migration itself is a short window compared with the testing that comes before it. Ask for a timeline that separates discovery, the staged test migrations, the business sign-off period and the cutover, and ask what each phase depends on from your side.
Can we stay on ERPNext version 14 after its end of life?
You can keep running a version 14 site, but it will no longer receive releases from Frappe. Frappe's supported versions page lists version 14 as reaching end of life on January 31, 2026, and it also says customers must be on a listed version and subscribed to a matching Frappe Cloud support plan to receive warranty coverage from Frappe. For a self-hosted site, staying on v14 means carrying security and compatibility risk yourself, along with the cost of any patches you write or source. Confirm with your security and compliance leads whether an unsupported version is acceptable for the systems that hold your financial data, and document the decision and any compensating controls.
What happens if the bench migrate fails during the upgrade?
A failed migration should never reach production unrehearsed. The upgrade is staged on a copy of the site, so a failed migrate is an issue to fix on that copy, not a live incident. Before the production run, take a verified database and file backup, record the current app versions and commits, and agree a rollback procedure that restores that backup and the previous app versions. Rollback time and its effect on users, integrations and any transactions entered during the window should be written into the plan. Ask any provider to show the rollback steps they will rehearse, and to confirm who decides whether to roll back and within what window.
Should we upgrade to version 16 instead of version 15?
Version 16 is worth evaluating, but it is a different decision from a v14 to v15 step. Frappe's supported versions page says version 15 is planned to be supported until the end of 2027 and version 16 until the end of 2029, so v16 gives a longer support window. Version 16 also brings its own changes, such as the Python and Node requirements and changes that affect custom apps, so custom code may need more work than a move to v15. Compare the two paths by support window, the readiness of each companion app you use, and the amount of custom code to retest. Ask your provider to cost both options so the decision rests on your own scope.
Does the upgrade include a security review of the upgraded site?
The upgrade itself focuses on functional correctness and data integrity. Whether a security review is included depends on the written scope. A review of access controls, server scripts, integrations and the configuration of the upgraded site is a separate piece of work that you can add to the engagement or buy from DeployOpen's security testing service. Note that Server Scripts are disabled by default from version 15 and must be enabled with the server_script_enabled setting, so any script-based customization needs a deliberate decision. Confirm in the quote exactly what is covered, and what is left for your own team or a later engagement.
How DeployOpen scopes, delivers and supports the ERPNext upgrade
DeployOpen approaches the ERPNext 14 to 15 upgrade as a planned, staged change to your own infrastructure, starting with an inventory of your apps, customizations and data. Engagements are fixed-scope, so the written scope sets which apps, print formats, reports and migration steps are included before work begins.
How we scope
- Inventory your installed apps, custom apps, client and server scripts, print formats and reports against the v15 changes.
- Confirm which companion apps (Lending, Payments, E-commerce) your site needs and which WooCommerce flows must be replaced.
- Agree in writing the staging environments, backup and rollback approach, and the cutover window before any work starts.
How we build
- Restore a copy of production to a staging site and run the upgrade there first, with the apps matched to v15 branches.
- Convert stock records to Serial and Batch Bundles and check valuation and stock ledger totals after each migrate step.
- Retest custom scripts, print formats and reports on staging, and log every fix against the scoped list.
How we hand over
- Document the upgrade sequence, app versions, migrate commands and the rollback procedure your team will reuse.
- Deliver a list of changed customizations, removed or replaced features, and open items that need a business decision.
- Run a joint acceptance check with your finance, stock and sales owners before the production cutover is signed off.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the upgrade.
- Confirm with your team how minor releases will be applied with bench update on a test site before production.
- Ask during scoping which support window and Frappe Cloud support plan, if any, apply to your site after the upgrade.
