ERPNext version 14 end of life: upgrade options

Customization is usually the largest driver, because every custom app, script and report has to be retested against the target version. Each custom app needs a branch or release that matches the new Frappe Framework version, and any code that calls changed or removed methods needs rework. Custom print formats and reports are easy to overlook, but they often break in subtle ways and need visual and numeric checks. Ask for a full inventory of custom code, fields, print formats and reports before agreeing on scope, since that inventory sets most of the test effort.

Server Scripts run Python on document events or as API endpoints, and from version 15 they are disabled by default. A site that relied on them will stop behaving as before until the server_script_enabled setting is turned on, and that change needs an explicit decision on your side. Hosted shared environments may not allow Server Scripts at all, so confirm your hosting model early. Each script also needs review against the new document lifecycle, which adds effort in proportion to how much logic lives in scripts rather than in standard configuration.

Several apps were split out of ERPNext in later releases, and they must be installed at versions that match the target Frappe and ERPNext versions. Typical examples include Frappe HR, Lending, Payments, India Compliance and Ecommerce Integrations, depending on what your site uses. Each one adds an installation, a migration step and its own test cycle. Ask for a list of every installed app and its current branch so the matching targets can be planned before the first migration runs.

Yes. Identity integrations are easy to assume will keep working, yet they depend on configuration that can change between versions. LDAP Settings, including SSL/TLS options and the automatic mapping of LDAP groups to ERPNext roles at login, should be verified with test accounts from each group. Social Login Keys for providers such as Google, Microsoft or a custom OpenID Connect endpoint need a test sign-in and a check that users land with the right roles. Plan these checks as a separate test set, because a login failure blocks every user at once.

The migration itself runs against your database, so larger sites with more history, stock ledger entries and submitted documents need more time for the migrate step and for verification afterward. Data import is a separate concern when you load records during or after the move. The Data Import tool is documented for importing only a few thousand records at a time, so bulk corrections should be batched and checked. Ask for database size, record counts for the main accounting and stock doctypes, and a timed run of the migration on a copy of production.

Every site on a bench is migrated, tested and rolled back as a unit of work, so the effort grows with the number of sites and with how different they are. Sites that share the same apps and customizations can follow one checklist, while sites with different companies, currencies or custom apps need separate test passes. Shared benches also mean that one app upgrade affects all sites at once. Confirm the site count, the apps each one uses, and whether any site must stay on the old version for a period.

A test environment that mirrors production is the single most useful way to shorten risk and rework. It should use a recent copy of the production database, the same apps at the same versions, the same identity settings and the same hosting model, so that errors surface before cutover. Without one, problems surface in production and the rollback plan becomes the main activity. Confirm whether you can provide a separate server or cloud account, how fresh the data copy can be, and who signs off on test results.

A team with Linux, Frappe bench and database experience can perform an upgrade, and the upgrade path is documented in the Frappe ecosystem. The effort is still driven by the factors above, especially custom code, companion apps and test coverage. Teams without that experience often underestimate the time spent on retesting and rollback rehearsal. DeployOpen plans, implements and documents this kind of work under a written, fixed scope, so you can compare an internal estimate with an agreed scope before deciding.

The cost follows the size and shape of your installation, not the version number alone. The main drivers are the number of sites and companies, how much custom code and custom apps you run, how many companion apps (such as Frappe HR, Lending, Payments or India Compliance) must be installed, the volume and quality of data to check, and how many integrations need retesting. Self-hosting ERPNext itself is free under GPL-3.0, so the cost is labor: planning, the staged upgrade, testing, fixes and handover. Ask for a quote that lists each of these as a separate line, with what is one-time (the upgrade and cutover) and what recurs (minor updates and support retainers, if you choose them).

Duration depends on how much needs to be checked, not on the upgrade command itself. Plan for time to inventory apps and customizations, build a test site from a recent backup, run the migration, fix print formats, reports and scripts, validate data, and rehearse the production cutover. Scope and timelines are agreed in writing before work starts, so ask for a written schedule with milestones and the assumptions behind it. The Frappe version support dates are a fixed input: version 14 reached end of life on January 31, 2026, according to Frappe's supported versions page.

The work needs access and information that only your team can supply. Typically this includes:

• Administrative access to the servers, bench or container hosts, and the database for a test copy of production
• A current, verified backup and a list of sites, companies and installed apps
• Test data that reflects real transactions, including accounting, stock and production records
• Named business owners who can sign off on finance, stock, manufacturing and reports
• Any custom apps, scripts and integration credentials, plus the vendors you depend on

Without timely business sign-off, the test phase tends to stretch, so agree on the approvers and the acceptance criteria early.

Yes, if your team has Linux, database and Frappe bench experience and time to test properly. The upgrade is a sequence of steps you can run yourself, but the risk sits in the details: companion apps split out in version 15, custom code that breaks, and reports or print formats that change. Decide by comparing your team's capacity and experience with the list of customizations and integrations you run. A partner is most useful when the scope is large, the timeline is fixed, or no one has rehearsed the rollback. DeployOpen plans, implements, customizes, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, so either path can be scoped in writing.

Warranty coverage from Frappe depends on your subscription, not only on the version you run. According to Frappe's supported versions policy, customers must be on a listed version and subscribed to a matching Frappe Cloud support plan to receive warranty coverage from Frappe. Version 15 is planned to be supported until the end of 2027 and version 16 until the end of 2029, per the same page. If you self-host, confirm with Frappe which support plan, if any, matches the target version before you commit to a date, and record that answer in the project file.

A useful quote states the scope in terms you can check. Ask for the list of sites, companies, apps and custom code in scope, the target version (15 or 16), and the exclusions. Each deliverable should be named: test environment, migration runs, fixes to customizations, data validation, cutover runbook, rollback plan and handover documentation. Ask how testing is counted, who signs off, what happens if the scope changes, and how minor updates after go-live are handled. Confirm whether the price is fixed for the agreed scope and which items are optional, so you can compare offers on the same basis.

Choose based on support windows, your custom code and how much change your team can absorb. Version 15 is planned to be supported until the end of 2027 and version 16 until the end of 2029, according to Frappe's supported versions page. Version 16 gives you the longer runway, but it brings more changes for custom apps. Check each custom app against the version 16 requirements, confirm companion app availability, and ask for a test migration to both targets before deciding. Document the choice and the reasons in the project record so auditors and future maintainers can follow it.

Data is migrated in place by the migration process, which is why a verified backup and a test copy come first. Each run should be checked against accounting totals, stock balances, open documents and key reports before anyone trusts the new site. Ask for the validation checks, the rollback point, and who holds the backups and their retention period. Keep the production site read-only or frozen during cutover if your process allows it, so that no transactions are lost between the final backup and the switch.