ERPNext upgrades and support services

How ERPNext upgrades and support work once you are live

Upgrades and support are recurring work for a self-hosted ERPNext, and they continue for as long as the system runs on your servers. Most teams keep routine minor updates in-house and hand major upgrades, testing of custom apps and support coverage to a partner when internal skills are thin. Your likely situation is a live ERPNext on v15 or v16 with custom apps and Server Scripts that may break when the framework or ERPNext changes underneath them. Each of those components needs a named owner before the next release arrives, and the first step is knowing which version you run and when it stops receiving fixes.

Frappe's supported versions page states that version 14 reached end of life on January 31, 2026. Version 15 is planned to be supported until the end of 2027, and version 16 until the end of 2029. Those dates set the outer limit of your planning horizon, while the release cadence sets the rhythm of day-to-day work. Both supported versions receive frequent minor releases. The frappe/erpnext releases page lists v15.123.0 from October 14, 2026 and v16.51.1 from October 15, 2026. Minor releases carry fixes that a live company should apply steadily, so a long gap without updates should prompt a review of what you have missed. The move from v15 to v16 is covered in the sibling upgrade topic.

Four events usually start upgrade work. The first is an approaching end of support, when the planning window closes and a major upgrade becomes unavoidable. The second is a security advisory, which may require a minor release applied within days, so the team needs a standing route to test and deploy it. The third is a needed feature that exists only in a newer release. The fourth is a failed update, where bench update or bench migrate stops partway and leaves the site needing a restore. Each trigger should map to a short runbook that names the decision maker, the backup taken first and the staging site that proves the change. A failed update is the trigger most teams underestimate, because recovery depends on backups you have already verified.

For routine minor updates, the in-house job is predictable: take a verified backup, pull the new code with bench update, run bench migrate on a staging copy of the site, check custom apps and scripts, then promote the change to production in a window your users accept. Server Scripts need particular attention. Starting from version 15 they are disabled by default and must be enabled with the server_script_enabled setting, so confirm that setting on every site before an update and record which scripts depend on it. Cost sits mainly in internal admin time, which recurs with every release. When you ask a partner for a quote, request a split between one-time items, such as the first staging test of each custom app, and recurring items, such as monthly update rounds and response coverage.

Support comes from three sources, and each carries different obligations. Frappe's supported versions policy ties warranty coverage to running a listed version and holding a Frappe Cloud support plan that matches that version. Certified implementation partners, referenced on the ERPNext pricing page, can take over upgrade and support work for self-hosted sites, with the scope set in writing. Internal admin time is the third source and the one most often underestimated. Before you choose, confirm which versions and custom apps the coverage includes, the response expectations for security fixes, and who performs restores if an update fails. DeployOpen can run upgrades, custom app testing and support retainers on systems you own, with scope agreed in writing before work starts.

What an ERPNext upgrade and support engagement includes

An upgrade or support engagement moves a live ERPNext system through a sequence of checks, test runs and handover steps, each producing a record your team can keep. The cards below cover the upgrade work itself, the retainer that keeps minor releases applied between upgrades, and the deliverables you receive at the end.

Version and support status review

We confirm which ERPNext and Frappe Framework versions you run, which versions are listed as supported, and when each reaches end of life. Frappe's supported versions page sets the dates, and we check them against your installed version before planning. Ask for the review to state the target version, the support end date you are planning against, and whether your current Frappe Cloud support plan, if any, matches your version.

Staging copy of the production site

We create a staging site from a recent production backup, kept in your own infrastructure, so upgrade runs never touch live data. The copy should match production in database contents, installed apps and site configuration. Confirm how often the copy is refreshed, who can access it, and how it is kept separate from production email and integrations so that test runs do not send real documents or messages.

Bench update and bench migrate runs

We run bench update and bench migrate on staging and record each step's output in a log that is kept with the upgrade record. The logs show which patches ran, which failed, and how long each step took. Ask for every failed patch to be investigated and documented before the production run is scheduled, not retried until it passes.

Custom app compatibility testing

Custom apps and server scripts are the most common source of upgrade failures, so each one is tested against the target version before the core upgrade. We check its declared compatibility, run its tests, and exercise the DocTypes and hooks it extends. Server Scripts need separate attention: from version 15 they are disabled by default, so confirm whether your site has them enabled and whether they must be re-enabled after the upgrade.

Post-upgrade checks of core modules

After migration we test the workflows that carry financial and operational risk: accounting entries and ledger balances, stock movements and valuation, and print formats used on invoices, delivery notes and statements. Each check compares outputs before and after the upgrade using agreed sample documents. Ask for the test list to name the accounts, warehouses and print formats covered, and for your finance and stock owners to sign off the results.

Backup and rollback preparation

Before any production run we take a full database and file backup and confirm it can be restored onto a separate host. The rollback plan states who decides to roll back, the time window in which a rollback is still practical, and the exact restore steps. Ask for a restore test on a copy of the backup, because a backup that has never been restored is not yet proof of recovery.

Routine minor update runbook

Minor releases arrive often, so we write a runbook for routine updates that covers backup, the update command sequence, smoke tests on the key modules, and the rollback decision point. The runbook is written for your internal admin to follow, with the commands, expected log output and named contacts. Confirm that it is reviewed whenever the target version or hosting model changes.

Support retainer for monitoring and upgrades

A retainer covers monitoring of minor releases for your supported version, incident response within hours agreed in writing, and scheduled upgrades applied to your environment. The cost depends on the number of sites, custom apps and hosting model, and it recurs for as long as the retainer runs. Ask for the response hours, escalation path, and what is excluded, such as new feature development or work on code outside the agreed apps.

Deliverables and internal handover

At the end you receive a tested upgrade record with logs and test results, an updated runbook, and a list of custom app versions with their compatibility status. We also hand over operating knowledge to your internal admin in a working session. Confirm that the deliverables are named in the written scope, that the custom app list matches your repositories, and who keeps the records after the engagement closes.

What drives the effort and cost of ERPNext upgrades

This table compares the factors that change how much work an ERPNext upgrade takes and what it costs to run. Read each row as a question to answer about your own installation before requesting a quote. The main takeaway is that custom apps, server-side scripts and integrations often shape the effort more than the core upgrade does, so inventory them early.

Driver	Why it matters	How to keep it down
Custom apps and their age	Each custom app must be tested against the target version, and older apps often need changes to APIs and hooks.	Inventory each app, record its last update, and retire unused apps before planning the upgrade.
Server Scripts in use	Disabled by default from version 15 and enabled only with server_script_enabled. Frappe Cloud public shared benches do not allow them.	Keep Server Scripts to a minimum and move lasting logic into version-controlled custom apps.
Integrations (LDAP, Social Login Keys, REST API consumers)	Each login provider and API consumer needs retesting after upgrade, and field mappings or group roles can change.	List every provider and consumer, document its settings, and keep a smoke test for each one.
Data volume and records affected by schema changes	Migrations rewrite tables, so large tables lengthen the migrate window and the test effort.	Measure table sizes and row counts in staging, and archive closed historical data before upgrading.
Number of sites and environments	Every site runs its own migrate, and each environment needs its own test pass before production.	Standardize bench layouts and configuration, and script the update sequence across all sites.
Hosting model	Self-hosted benches, frappe_docker images and Frappe Cloud each change who runs the update steps and how rollback works.	Confirm who owns each step for your hosting model and document the rollback path in advance.
Compliance evidence for change records	Assessors expect dated, approved records showing what changed, who tested it and how it could be rolled back.	Agree the evidence list before work starts, and attach test results and migrate logs to each change ticket.

How the upgrade phases run from assessment to handover

The sequence confirms what the current ERPNext site depends on, proves the upgrade on a faithful copy of production, and leaves the client with a tested rollback point, monitored go-live and a runbook their own team can operate. Each phase closes with a written output that the client signs off before the next phase starts.

Assess the current version and custom code
We review the running ERPNext and Frappe Framework versions, every installed custom app, and each Server Script, Client Script and scheduled job on the site. We check the version against Frappe's supported versions list and confirm which support plan applies, because warranty coverage from Frappe depends on being on a listed version with a matching plan. The output is a written assessment listing each app, its source repository, its owner and its version, with a risk note for any code that has no automated tests. The step is complete when the client signs off the list.
Check inventory and dependencies
We map third-party apps, pinned Python and Node packages, and every integration that calls the REST API or reads the database directly. Each custom app is checked against the target release for deprecated calls and breaking changes. We also record where Server Scripts run, since they are disabled by default from version 15 and must be enabled per site. The output is a compatibility matrix with a keep, fix or replace decision for each item, reviewed with the client's finance and operations leads before any change is made.
Build staging from a restored backup
We take a fresh backup of production, including the database and site files, and restore it to a staging server with the same operating system, database engine and bench layout as production. Email, payment and outbound integration endpoints are pointed at test targets so staging cannot send customer messages or post live transactions. Staging must mirror production because schema patches and data fixes only prove something against the data they will change. The output is a reconciliation report showing that record counts and last posting dates match the backup.
Run bench update and bench migrate on staging
Bench update upgrades the bench tool and the installed apps: it pulls the target branches, installs their dependencies, rebuilds assets and restarts services. Bench migrate then applies each app's schema changes and data patches to each site on the bench. We run both on staging with full console output saved to the change record, note every patch that runs and every warning, and repeat the run from a fresh restore if a patch fails. The output is a clean log set, a patch list and a repeatable run from the same backup.
Test accounting, stock, selling, buying and integrations
The client's process owners run scripted test cases on the upgraded staging site. Accounting tests cover payment entries, ledger postings and period closing. Stock tests cover stock entries, valuation and reconciliation. Selling and buying tests run a full cycle from quotation to invoice and delivery, and from purchase order to receipt and bill. Integration tests cover LDAP or social login, API calls, webhooks and any bank or e-commerce connector. The output is a pass and fail log with each defect either fixed and retested or accepted in writing by the process owner.
Schedule the cutover window with a rollback point
We agree the cutover window in writing with the client, using the scope to set its length. Before the change, we take a final production backup, record its identifier as the rollback point, and put the site into maintenance mode so no new transactions are written. We then run the same bench update and bench migrate sequence proven on staging, while the client keeps the previous app versions and backup available. Rollback means restoring that backup and reverting the apps. The output is a signed go or no-go record and a timed cutover log.
Monitor production after the upgrade
After go-live we watch application and worker error logs, failed background jobs, scheduler runs and slow database queries. Finance and operations staff check key balances, stock figures and open documents against the pre-upgrade reconciliation report. Issues raised by users are logged, triaged and resolved within the support terms in the written scope. The output is a monitoring report at the agreed intervals and a list of closed issues, with any remaining items assigned an owner and a date.
Hand over the runbook
We deliver a runbook that the client's own administrators can follow. It records the ERPNext, Frappe and app versions in use, pinned dependencies, the backup and restore procedure with the last restore test date, the rollback procedure, monitoring checks, contacts and the support plan. It also notes planning dates for the next upgrade: Frappe's supported versions page lists version 15 support until the end of 2027 and version 16 until the end of 2029. The output is a runbook accepted by the client's operations owner.

Which upgrade and support tasks to keep in-house and which to outsource

This table lists the upgrade and support tasks for a self-hosted ERPNext site, with the team that usually owns each one and the skills it requires. A team with Python, Frappe framework and Linux administration skills can usually keep routine minor updates in-house, while major upgrades that touch custom apps usually benefit from a partner. Before deciding, confirm that your version is on Frappe's supported list and that you hold a matching Frappe Cloud support plan for warranty coverage.

Task	Usually owned by	Skills needed
Routine minor release updates on a staging site	Internal ERP administrator or DevOps engineer	Bench update commands, Linux administration, Git, staging site setup
Custom app code changes	In-house Frappe developer, or a partner for major versions	Python, Frappe DocType and controller APIs, Git, code review
bench migrate troubleshooting	In-house for minor releases, partner for major upgrades	Frappe framework internals, MariaDB, reading migration logs, Linux
Post-upgrade functional testing by finance and operations users	Finance and operations process owners, with IT coordinating	Accounting, stock and production workflow knowledge, written test cases
Backup and restore verification	Internal infrastructure or DevOps team	Bench backup commands, MariaDB restore, scheduled restore tests, storage administration
Security patch monitoring	Internal IT or security team, with partner advisories	Reading ERPNext and Frappe release notes, risk assessment, change scheduling
Incident response	Internal on-call team, with Frappe support or a partner for escalation	Linux and database troubleshooting, log analysis, knowledge of your Frappe support plan

What support and upgrades cost over the life of ERPNext

ERPNext itself carries no license fee. It is licensed under GPL-3.0, according to the license metadata of the frappe/erpnext GitHub repository, so the recurring cost of running it comes from four places: hosting, internal staff time, maintenance of any custom apps you build, and the support coverage you choose. Each of these has a different payer. Hosting is paid to your cloud provider, your data center, or Frappe Cloud. Staff time is your own payroll. Custom app maintenance and upgrade testing are usually paid to a partner or to your developers. Support coverage is paid to Frappe or a partner, depending on the option you pick. Before you compare offers, separate these lines so you can see what recurs every year and what is a one-time project cost.

Hosting is the most visible line item, and the figures are concrete. According to the ERPNext pricing page, self-hosting ERPNext is free, so the cost is your own infrastructure and the people who run it. On Frappe Cloud, the same pricing page lists shared site hosting from 5 US dollars per month, Frappe Cloud servers from 20 US dollars per month for shared instances, and dedicated servers from 125 US dollars per month. These are starting points, not totals. Confirm with Frappe which plan fits your database size, user count and background job load, and whether backups, staging sites and custom apps are included.

Frappe warranty coverage has a condition that affects how you budget upgrades. According to Frappe's supported versions policy, you must be on a listed version and subscribed to a matching Frappe Cloud support plan to receive warranty coverage from Frappe. Check the current supported versions page before you commit to a version, because a deployment on an unlisted version may fall outside the coverage you assumed. Implementation is available through certified partners, according to the ERPNext pricing page, so a partner can be engaged for upgrades or support even if you host the system yourself. Ask Frappe directly whether a self-hosted deployment qualifies for any support plan, since the policy as described ties coverage to a Frappe Cloud plan.

When you request a quote from a partner for upgrades and support, ask for the following in writing. Ask for a fixed upgrade scope that names which versions are covered, which custom apps and scripts are tested, and what happens if a major upgrade reveals incompatible code. Ask how many minor updates are covered per year and whether security patches are counted separately. Ask for the testing hours included, split between staging runs of bench migrate, regression checks on custom apps and data verification, and the hourly rate for work beyond that allowance. Ask for response expectations: who answers, the channels, the hours covered and the target times for each severity level. Verbal assurances on responsiveness are hard to enforce, so get them into the contract.

Upgrades and support cost more over time when custom apps grow, because each Frappe release can change APIs your code depends on. Keep custom logic in a packaged custom app rather than scattered across the UI, and keep a record of every customization so the upgrade estimate reflects the real surface area. For multi-year figures that combine hosting, staff time, support and implementation, read the sibling topic on ERPNext cost of ownership and editions, which models these lines over several years.

What usually goes wrong with ERPNext upgrades and how to prevent it

Most ERPNext upgrade problems do not come from the new release itself. They come from custom code, untested backups, deferred updates and integrations that nobody checked against the target version. Each card below names a symptom and the prevention step to complete before the maintenance window opens.

Custom apps pinned to old versions

Custom Frappe apps and their hooks are often written for the version they were built on. After bench update and migrate, they can fail at import, at startup or during a DocType change, and the error can block the whole site. Before a major upgrade, check each app's compatibility with the target version, update its dependencies and run its tests against a copy of the site. Ask your internal team or partner to list every installed app with its pinned branch.

Server Scripts that stop running

Server Scripts run Python on document events or as API endpoints. From version 15 they are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. A validation or endpoint that worked before the upgrade can silently stop running. Inventory every Server Script, record where it is enabled, and confirm with your host that the setting can be changed before go-live.

Staging skipped or unlike production

Problems that appear only in production usually trace back to a staging run that was skipped, used too little data or ran on a different server size. Schema patches can take far longer on a full production database than on a small test copy, so bench migrate may overrun the maintenance window. Restore a recent production backup to staging, time the migrate, and compare record counts and key reports. Repeat the run whenever the cutover plan changes.

Backups never restored before upgrade

A backup that has never been restored cannot be trusted as a rollback point. Before the upgrade, take a full bench backup of the database and files, copy it off the server and restore it to a separate bench. Confirm the site opens and that the data matches the source. Record how long the restore took and name the person who runs the rollback. For container deployments, confirm that both the database and the file volumes are included.

Minor updates deferred into gaps

ERPNext v15 and v16 both receive frequent minor releases, including v15.123.0 on October 14, 2026 and v16.51.1 on October 15, 2026. A site that stays several minor versions behind misses security fixes and bug corrections, and each skipped step makes the next upgrade larger. Agree on a regular minor update cadence, read the release notes for each step and test it on staging first. Check the Frappe support versions page to confirm your major version is still listed.

Integrations break after auth or API changes

LDAP logins, Social Login Keys and REST API consumers depend on settings and authentication flows that can change between releases. An LDAP connection may fail on TLS settings or group to role mapping, a Social Login Key may receive a different callback, and an external system using an API key may get unexpected responses. List each integration with its owner, then test login and a sample API call on staging before cutover.

How upgrade and support work differs by hosting model and starting point

A bench installation runs ERPNext through the bench command line tool on servers your team or partner manages. Upgrades move the frappe and erpnext apps together with the custom apps, sites, Python and Node environments that the bench holds, so every component is updated in one controlled sequence.

Upgrade path: Update the frappe and erpnext apps to the target version with bench update, then run bench migrate on each site.
What to verify: Confirm that each custom app installs and imports cleanly on the new version, that scheduled jobs run, and that a restored copy of production migrates without errors.
What to provide: Server access, a current backup of every site, a staging server that mirrors production, and a list of installed apps with their repository locations.
Release cadence: Agree with your team how often minor releases will be applied, since both supported major versions receive frequent minor releases.

Before the first production migrate, confirm that a rollback path exists, including a database backup and the previous app commits.

What the client needs to provide before an upgrade or support plan starts

Before a support plan or upgrade begins, the client needs to provide the access, the data safety net and the decision owners that the work depends on. Start with administrative access. For a self-hosted ERPNext, that means shell access to the servers running the bench, the ability to run bench commands as the bench user, and read access to the MariaDB and Redis hosts. For Frappe Cloud, it means a team account with an administrator role on the bench and sites. Confirm in writing which environments the partner can work in, who holds the database credentials and how those credentials are rotated. Access that is only granted on the day of the upgrade usually delays the first staging run, so agree it at the start.

Next, confirm the current backup and a place to test it. A backup is only useful after a restore has been run against it, so the client should provide a recent backup of the database and files, plus a restore test environment that matches the production version, site count and installed apps. The test environment should not send email, post payments or call live banking or payroll endpoints during testing. Ask the client to confirm the backup schedule, the retention period and the person who can authorize a restore. Backup design and disaster recovery are covered separately, so this input is about evidence that a restore has worked on the version being upgraded.

The third input is an inventory of everything that sits on top of standard ERPNext. List each custom Frappe app with its repository and the version it targets, every Server Script and Client Script, custom fields and DocTypes, print formats, reports, and each integration such as LDAP login, Social Login Keys, API consumers, webhooks, banking feeds or payroll exports. For Server Scripts, record whether server_script_enabled is set, since from version 15 these scripts are disabled by default. Each item needs a named owner. Finance, stock and integrations owners matter most, because they sign off test results for posting, valuation and external data exchange. A test result without a named signer cannot close a test.

The last inputs cover decisions and timing. Provide a list of business-critical workflows for functional testing, such as sales invoice submission, payment entry, stock entry and reconciliation, work orders and job cards, and month-end period closing, with the expected result for each. Name the decision makers who will call go or no-go, with their roles and a deputy, and agree the criteria before testing ends. Book a maintenance window long enough for the production upgrade and a rollback, and confirm whether the client's change process requires an entry in its change record system. If an auditor will review the change, the client must give the partner access to that system so the record matches what was done.

Common questions about ERPNext upgrades and support

How much does an ERPNext upgrade cost and what drives the price?

The cost depends on the written scope, and DeployOpen does not publish a price list. ERPNext has no license fee under GPL-3.0, so the upgrade cost is mainly effort: planning, a staging run, testing custom apps and scripts, the production migration, a rollback plan and post-upgrade checks. Main cost drivers:

Number and complexity of custom apps, scripts and integrations
Data volume and how many sites or companies are affected
Whether a staging environment already exists
Hosting, which is separate: the ERPNext pricing page lists Frappe Cloud shared sites from 5 US dollars per month and servers from 20 or 125 US dollars per month

The upgrade itself is one-time work, while hosting and support plans recur. Ask any quote for line items, assumptions, exclusions and who tests business workflows.

How long does an ERPNext upgrade take to complete?

The duration depends mainly on custom apps and data volume, so it cannot be stated without reviewing your environment. Time is driven by how many custom apps need compatibility fixes, how large the database is, how many integrations must be retested, and how many business processes need sign-off, such as accounting close, stock and production. A staging copy of production data is the best way to measure how long the migration step takes. Ask for a timeline in the written scope that lists the assumptions behind it, the testing window, the change window agreed with operations, and the rollback point if go-live is not approved.

Can an internal admin run ERPNext minor updates alone?

Yes, routine minor updates are usually manageable for an internal admin who follows a tested runbook. The runbook should cover taking a verified backup, running the update on staging first, running the migrate step, checking key documents and reports, and only then updating production. Major upgrades, such as moving from version 15 to version 16, usually need partner help. They involve custom app compatibility, scripts that may behave differently, data checks and rollback planning. Server Scripts have been disabled by default since version 15, so teams that depend on them should check their settings before any upgrade. Your admin should own the runbook either way.

What do we need to provide for an ERPNext upgrade project?

The client provides access, information and decisions. Before work starts, the project needs access to the current site and bench or container setup, recent verified backups, and a staging environment that resembles production. It also needs an inventory of custom apps with source code location, version and owner, plus a list of customizations such as custom fields, scripts, print formats, reports and workflows. Integrations with banking, e-commerce, payroll or other systems require documentation and test credentials. Business users should provide test cases and sign-off contacts, and an approver should own the go or no-go decision. Confirm each item, its owner and the date it is needed in the written scope.

Does Frappe support cover ERPNext on our own servers?

Frappe warranty coverage depends on two conditions: the site must be on a listed version, and the organization must be subscribed to a matching Frappe Cloud support plan. Frappe's supported versions policy sets out these conditions. Self-hosting ERPNext is free under GPL-3.0, but Frappe support is a separate subscription. Confirm with Frappe which version is listed and which plan matches your site before relying on coverage. Separately, DeployOpen can provide ongoing support, upgrades and testing as a retainer or as fixed-scope work, which is a different arrangement from Frappe's warranty. Ask for the terms in writing before assuming either covers a specific issue.

When should we plan the move from ERPNext v15 to v16?

Start planning now so the move is not rushed near the end of support. Frappe plans to support version 15 until the end of 2027 and version 16 until the end of 2029, according to its supported versions page. Work backward from the end of 2027: first inventory custom apps and scripts, then test compatibility on staging, then schedule the production upgrade with a buffer for fixes and sign-off. Both lines receive frequent minor releases, so keep version 15 current in the meantime. Support dates can change, so check the supported versions page before committing to a schedule, and confirm the plan with your partner in writing.

What usually breaks during an ERPNext major upgrade?

The most common failures come from custom code and configuration rather than core ERPNext. Custom apps may depend on functions that changed between versions, client and server scripts may behave differently, and custom reports or print formats may reference fields that were renamed or removed. Data Import mappings and REST API integrations can also fail silently if field names or permissions change. On Frappe Cloud public shared benches, Server Scripts are not allowed, so scripts must be moved elsewhere. Check each failure against a written list of business test cases covering invoicing, stock movements, payroll postings and integration messages. Keep a rollback path from the verified backup until sign-off is complete.

How DeployOpen scopes, runs and hands over ERPNext upgrades and support

DeployOpen plans and carries out ERPNext upgrades and support inside your own infrastructure, starting from a written scope that names your versions, custom apps and integrations. Work moves through staging before production, and the handover includes documentation your team can operate. Ongoing support is available as a retainer.

How we scope

The written scope lists the ERPNext version, site count, custom apps and integrations in place today.
The scope records which version you run, since v15 support ends in 2027 and v16 in 2029.
Scope, deliverables and timelines are agreed in writing before work starts.

How we build

Custom apps and scripts are tested against the target version on a staging copy of production data.
Server Scripts are checked against the setting that disables them by default from version 15.
Upgrades run bench update and bench migrate in staging first, with logs kept for each step.

How we hand over

The handover covers the upgrade runbook, rollback steps and the list of tested custom apps.
Your team receives documented bench commands, backup checkpoints and the configuration used on each environment.
The handover records which support plan covers each site, so warranty terms stay clear.

How we support

Ongoing support is available as a retainer, scoped in writing for your version and apps.
Minor releases arrive often for both supported majors, so a retainer plans regular patch reviews.
Ask each quote to state response expectations and service levels in writing before signing.