EspoCRM upgrades and support services

What EspoCRM upgrades and support involve

EspoCRM is licensed under AGPL-3.0, and the open-source edition can be self-hosted at no license cost, so your organization owns every upgrade. No vendor schedules releases, tests them against your instance or rolls back a failed change for you. Your team decides when to adopt a release, reads the changelog, checks PHP and database compatibility and runs the upgrade in your environment. Plan that effort as recurring work, not a one-time installation task.

Version 10.0.0, released July 2, 2026, disabled upgrades through the web interface by default. Upgrades now run from the command line on the server, so the people who perform them need shell access, a tested backup and a documented rollback path. Confirm what your install method provides. The installation script for Ubuntu, Debian and Linux Mint includes a command.sh utility for backups, restores and upgrades, but a server built by hand needs its own procedure. Check that your administrators have practiced the command-line path before you schedule the first upgrade.

Five events usually start an upgrade project: a release your team must adopt, a security fix that cannot wait, a PHP or database version change that the current build no longer supports, an extension that stops working after a core change, or a team that no longer has anyone who knows the instance. The last trigger is the one teams notice late. Record the server stack, cron setup and installed extensions now, so a new administrator can follow an upgrade without the person who built the system.

Many teams keep minor patches in-house and hand major upgrades, customization checks and ongoing monitoring to a partner. The split depends mostly on how much custom PHP, formula logic and extensions the instance carries. A lightly changed instance may be upgraded by a trained administrator. An instance with before-save formula scripts, custom code or third-party extensions needs each item reviewed against the new release first. Ask for a quote that lists the upgrade checks for each component separately, so you can see what each one costs to keep current.

What the service includes

Each item below is a work package in a fixed-scope engagement. Scope, deliverables and timelines are agreed in writing before work starts.

Version and environment inventory

Compare the installed release with the EspoCRM releases on GitHub, such as 10.0.10 (October 14, 2026), and confirm the upgrade path from your current line. Record the PHP version (8.3 to 8.5), the database (MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15), the web server, and the cron jobs for background work. For installer-built Docker stacks, record the container images and command.sh settings.

Customization and extension audit

Review Entity Manager formula scripts, custom PHP and front-end code in the custom directory, layouts, and installed extensions such as the Advanced Pack or Sales Pack. Flag anything that overrides core files or depends on a changed API, since these are the items most likely to break during an upgrade. Confirm each extension has a compatible release for the target version before the staging run.

Staging upgrade and test plan

Rehearse the upgrade on a copy of production using the command-line tools, with the database and files backed up first. The test plan covers formula before-save scripts, workflows and BPM rules, and every integration that reads or writes EspoCRM data, including REST API users. Each test records expected results, actual results, and the person who signed off.

Production cutover and verification

Schedule the production upgrade in an agreed window, using the backup and rollback path tested in staging. After cutover, verify login, background jobs, email, scheduled actions, and integration traffic against the test plan. Confirm the rollback steps can restore the previous release and data if a critical check fails.

Support scope and retainers

Ongoing support can cover monitoring, review of EspoCRM security advisories and releases, and patch windows for your environment. Confirm in writing which systems, response expectations, and upgrade frequency the retainer includes. Ask how out-of-scope requests such as new entities or integrations are quoted and scheduled.

Upgrade deliverables

The engagement produces an upgrade runbook with the exact command sequence and rollback steps, plus a change log of every modified file, setting, and extension version. Test evidence records the staging and production results. The updated configuration record reflects the new versions, so your team can run the next upgrade without rebuilding the baseline.

What drives cost and duration

This table lists the factors that change upgrade and support effort for an EspoCRM instance, why each one matters and how to keep it manageable.

Driver	Why it matters	How to keep it down
Custom entities, layouts and formula scripts	Each custom entity, layout and before-save formula script must be retested on every upgrade, and scripts can fail without visible errors.	Keep the data model lean, document each script's purpose and test formulas against sample records after each release.
Custom PHP and front-end code in the custom directory	Code that goes beyond supported extension points may need rework when core files change between releases.	Limit custom code, keep it inside the custom directory and review each file against release notes before upgrading.
Installed extensions and their age	The Advanced Pack and other official extensions each have their own version, so every one must be checked against the target release.	Remove unused extensions, keep the rest current and confirm compatibility for each before scheduling the upgrade.
Integrations through the REST API or OIDC	Each API user, role, webhook and identity provider setting is a dependency that needs testing after an upgrade.	Document every integration with its owner, authentication method and test cases, and keep that list current.
Environments and staging	Without a staging copy, upgrades are tested on production data or not tested at all, which adds risk and rework.	Keep a staging instance on the same version and database engine, refreshed from a recent backup before each upgrade.
Server layout	A single host, the Docker stack from the install script or separate database and application servers each need different upgrade steps.	Standardize on one documented layout and take a command.sh backup before each upgrade.
Database engine	MySQL 8.0 or newer, MariaDB 10.6 or newer and PostgreSQL 15 each need their own backup and upgrade procedures, and engine changes add migration work.	Confirm that the current engine version is supported by the target EspoCRM release before scheduling work.
Distance from the current release	Each skipped release adds changes to review, and a larger gap means more customizations to check at once.	Apply upgrades in regular steps and review the release notes for every version passed through.
Compliance evidence requirements	Assessors may ask for change records, test results and upgrade approvals, which adds documentation to every upgrade cycle.	Ask your assessor which records they expect and capture test results and approvals as part of each upgrade.

Project phases and outputs

The sequence moves from an inventory of your current instance to a tested, documented upgrade and a supported handover, with each phase closing on a written output.

Inventory the current installation
We record the installed EspoCRM version, PHP and database versions, web server, enabled extensions, cron or scheduled task setup for background jobs, and the date and status of the latest backup. You receive an inventory document, and we confirm the target version and any gaps in writing before moving on.
Review compatibility against release notes
We compare the target release notes and the server configuration requirements with your inventory, flagging PHP, database, web server and extension mismatches. The output is a compatibility report listing required changes, the customizations that need review, and the open questions your team must answer.
Build the customization and extension test plan
We list each custom entity, field, formula before-save script, workflow, layout change, custom code and extension, and define how each will be checked after the upgrade. You approve the test plan, which becomes the checklist for the staging rehearsal and the post-upgrade checks.
Rehearse the upgrade on staging
We restore a copy of production data into a staging environment and run the command-line upgrade there, logging each step and every error. The output is a rehearsal record with the exact commands, run times observed, issues found and fixes applied, which the production runbook will reuse.
Upgrade production in an agreed window
At the agreed window we take a fresh backup immediately before changing anything, run the command-line upgrade using the rehearsed steps, and confirm the application starts and cron is running. You receive confirmation of the backup identifier, the version now running and any deviations from the rehearsal.
Run post-upgrade checks
We test formulas, workflows, imports, user logins and integrations against the test plan, comparing results with the pre-upgrade behavior recorded in staging. The step closes when every item on the checklist is marked passed, fixed or accepted by you in writing.
Hand over the runbook and move to support
We deliver a documented runbook covering the upgrade procedure, backup and restore steps, rollback path and known customization risks, and walk your team through it. Ongoing support then begins under the retainer scope agreed in writing, which sets what is covered, how requests are raised and how future releases are assessed.

What usually goes wrong

Most EspoCRM upgrade problems follow a small set of patterns. Each card names the failure and the check to request from a partner before the upgrade starts.

Custom code breaks after a core upgrade

Extensions and custom PHP files in the custom directory can depend on internal classes or hooks that change between releases. Ask the partner for an inventory of every extension and custom file, with the EspoCRM version each was last tested against, and a staging run of the target release that exercises those code paths.

Formula scripts change behavior

Before-save Formula Script logic set in the Entity Manager, API before-save scripts, workflows and BPM can fire on saves the team no longer expects. A change to a field or a related entity can alter results without any code change. Ask for a list of every formula with test records showing the expected output before and after the upgrade.

Upgrading without a verified backup

The EspoCRM security docs note that upgrading through the UI is disabled by default from version 10.0, so the upgrade runs from the command line. A backup that has never been restored proves little. Ask the partner to show a dated backup of files and database, a restore into a separate environment, and the exact upgrade command.

Platform versions outside the supported range

The EspoCRM server configuration docs list PHP 8.3 to 8.5, MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15, on Apache, Nginx or IIS. A host running older components than the target release supports can fail once the new code is in place. Ask for a compatibility check against the target release docs and a record of PHP, database and web server versions before and after.

Cron stops and background jobs go silent

Background jobs, including idle imports, depend on cron or a scheduled task being configured for the application user. After an upgrade, a server rebuild or an account change, cron can stop without an error in the user interface. Ask the partner to show the cron entries on the new host, a log of recent job runs and an alert that fires when runs stop.

Rollback that has never been tested

A rollback is only as reliable as the restore it depends on. If the team has never run the reverse path against a copy of production data, the first attempt happens during an incident. Ask for a written rollback procedure covering code, database and files, along with evidence from a rehearsal on a copy of production.

Recurring costs after go-live

This table lists the recurring cost components after an EspoCRM go-live, who pays for each, what drives it and what to request in a quote, and a self-hosted total needs your own hosting and effort figures.

Component	Who pays	What drives it	What to ask for in a quote
Software license	Nobody. The AGPL-3.0 edition has no license fee	Official extensions such as the Advanced Pack may carry separate terms for self-hosted use	Licensing terms for each official or third-party extension you plan to run
EspoCRM Cloud subscription	Your organization, to the hosting vendor	Per user per month: 15 US dollars Basic (minimum 3 users), 25 Enterprise (minimum 5), 69 Ultimate (minimum 10), per EspoCRM pricing page	Per-user rate, minimum user count, which plan includes the features you need, and data location
Server and hosting	Your organization, to your cloud or data center provider	Instance size, PHP and database hosting, user load, and whether you run HA or a separate database server	Monthly compute, storage and network cost for each environment, plus reserved capacity terms
Backup storage	Your organization, to your storage provider	Attachment volume, database size, retention period and how often restores are tested	Storage price per GB per month, retention policy, off-site copy location and restore test scope
Staging environment upkeep	Your team, or a partner under a retainer	A full copy of the production stack, data refresh frequency and time to rerun upgrades	Cost of the staging stack, how often data is refreshed, and who runs each upgrade test
Release and advisory review	Your internal team, in staff time	Watching EspoCRM releases and security notices, then judging impact on your customizations and extensions	Who triages notices, how often review happens, and how each review is logged as evidence
Upgrade effort per release	Your team or a partner, per fixed-scope upgrade	Size of your customization set, extension count, version gap, and any command line upgrade rework	Fixed price or estimate per release, testing scope, rollback plan and what counts as a major upgrade
Extension updates	Your team, or the extension owner's terms	Number of official and custom extensions, their compatibility with each new core version	Which extensions are covered, compatibility testing scope, and whether custom code is included
Retainer support	Your organization, to a support provider, on a recurring fee	Included hours, business-hour coverage, number of environments and upgrades the retainer covers	Recurring fee, included hours, coverage hours, escalation path, and what falls outside the retainer

How the work differs by starting point

Instances with no custom code, or with changes made only through the Entity Manager and formula scripts, have the lightest upgrade path. Scope centers on release notes and a functional check of the entities, layouts and scripts your teams rely on.

Export a list of custom entities, fields, layouts and before-save formula scripts before the upgrade.
Read the release notes for every version between your current release and the target release, looking for changed formula or layout behavior.
Check whether workflows or BPM processes depend on those scripts. Advanced Pack items need a separate review.
Effort mostly follows the number of entities and scripts that need retesting, so ask the partner to base the quote on that inventory.

What you need to provide

Before an upgrade or support engagement starts, your team needs to supply administrative access to the EspoCRM server or container host and to the database, along with a backup method that has been tested. A backup that exists but has never been restored is not enough. Confirm that you hold a current backup of the database and the file directories, and if a dated restore test exists, share its result. The installation docs describe a command.sh utility for backups, restores and upgrades when the stack was deployed by script, so tell us early whether that is how your instance was built.

Inventory and environments. Provide a list of installed extensions, custom files under the custom directory, custom entities, formula before-save scripts, and integrations such as API users, webhooks or OIDC and LDAP configuration. If no inventory exists, say so and ask us to build one, since changes made through the Entity Manager and custom code are the most common source of upgrade failures. Also provide a staging environment that mirrors production in PHP, database and web server versions, with a copy of recent data. A named business owner must be able to sign off test results, and the same person should agree which users and workflows matter most.

Assign an owner for the API users, the OIDC or LDAP configuration, and the admin accounts, since these decide who can run the upgrade and who is locked out if an identity setting changes. Agree maintenance windows with users in advance, and confirm release timing and support windows with your own change process, because the release dates and version support you plan around must come from your vendor records and internal calendar. Finally, decide the support level: a one-off upgrade with a fixed scope, or a retainer covering ongoing releases and fixes. Your choice changes what is scheduled and who approves emergency work.

Frequently asked questions

Can our own team upgrade EspoCRM without a partner?

Often yes for minor patch releases, if your team has a tested runbook. Minor patches are usually handled in-house when the instance is close to stock and the team can roll back from a verified backup. Major upgrades, including the move to version 10, and instances with custom entities, formula scripts, custom PHP or extensions need a rehearsal on a staging copy and sign-off from the business owner before production. Review your customizations against the release notes first, because changes in the custom directory can behave differently after an upgrade.

How do we upgrade to version 10 when UI upgrades are disabled?

Use the command-line path described in the release notes for your exact version, because the UI upgrade is off by default as of version 10.0. The EspoCRM security documentation notes this default. For instances deployed with the installation script, the command.sh utility covers backups, restores and upgrades, so confirm its upgrade syntax and prerequisites for your version before running it. For other installs, the steps depend on how the instance was built, so take them from the release notes and test on staging first. Record the current version, take a full backup of files and database, and confirm your PHP and database versions meet the server requirements for the target release.

How long does an EspoCRM upgrade take?

No duration is published here, and a reliable estimate comes from the scope of your instance. The main drivers are the number of customizations and extensions to review, the size of the database and file storage that must be backed up and restored, whether a staging rehearsal is needed, and how many people must test and sign off. A stock instance with a tested runbook takes far less effort than a heavily customized instance with formula scripts, custom PHP and several extensions. Ask for the effort and timeline in a written scope that lists these items, and confirm any downtime window with your users.

What does an EspoCRM support retainer cover compared with a one-off upgrade?

A retainer covers ongoing work on agreed terms, while a one-off upgrade covers one defined project with a start and an end. Under a retainer, the agreement can include monitoring the instance, tracking security advisories and release notes, applying patch releases and responding to incidents within the response terms written into the agreement. A one-off upgrade covers review, rehearsal, cutover and handover for one version change. Cloud-to-self-hosted moves are not covered by either unless they are scoped in writing. Ask each proposal to state exactly what is included, which response terms apply and what is excluded.

What do we need to provide before an EspoCRM upgrade starts?

You need to provide access, an inventory, recent backups, a staging environment and a named owner who signs off. Access means administrator accounts or deployment access to the server, database and file storage, handled under your access policy. The inventory lists the current version, PHP and database versions, custom entities, layouts, formula scripts, extensions and integrations. Backups must be restorable, and a staging copy lets the team rehearse the upgrade and test key workflows. The business owner confirms the test results and cutover window before any production change. Missing items usually extend the schedule.

Does the free EspoCRM edition cost anything to keep current?

There is no license fee for the open-source edition, which is licensed under AGPL-3.0, but keeping it current has ongoing costs. Hosting, backups, monitoring, storage and the staff or partner time to apply patches and major upgrades recur over time. The size of each cost depends on your infrastructure, your team and how many customizations you maintain. Ask any provider to separate one-time costs, such as the first rehearsal, from recurring costs, such as hosting and patch cycles, and to state which items sit inside the quote.

How DeployOpen delivers upgrades and support

DeployOpen plans and performs EspoCRM upgrades inside your own infrastructure, checking customizations and extensions before any change reaches production. Ongoing support is available as a retainer once the work is handed over.

How we scope

The written scope states the current and target EspoCRM versions, the hosting platform and the PHP and database versions involved.
Custom entities, layouts, formula scripts, custom PHP and front-end code, and installed extensions are inventoried and checked for upgrade compatibility.
Engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts.

How we build

Upgrades are run from the command line on a staging copy of your instance, since UI upgrades are disabled by default in version 10.
Test plans cover login, the Advanced Pack workflows and reports, integrations and imports against the upgraded staging environment.
Backups are taken and restore steps are rehearsed before the production upgrade window is opened.

How we hand over

You receive a written record of the versions, configuration changes, extensions and custom code touched during the upgrade.
Rollback steps and the post-upgrade checks are documented so your own administrators can repeat the process later.
Handover includes a walkthrough with your team of the cron jobs, background tasks and monitoring that keep the instance healthy.

How we support

Ongoing support, upgrades and checks for new EspoCRM releases can be arranged as a retainer with a written scope.
Support covers reviewing release notes against your customizations, planning the next upgrade and applying security guidance.
Ask in any quote what response times, coverage hours and escalation paths the retainer includes, since these depend on the agreed scope.

EspoCRM upgrades and support