SuiteCRM upgrade to 8.10: who needs it and what it covers
If you run a production SuiteCRM 8 instance that must move to the 8.10 line, this page is for you. The upgrade moves your application through supported minor releases on a documented path, and it needs preparation, staged testing and a rollback plan before anyone touches production. Teams usually start this work for one of three reasons: a security fix in a release you have not yet taken, a PHP or database version that your current install no longer matches against the supported list, or the need to be on a current 8.x line before SuiteCRM decides on a future SuiteCRM 8 extended support release. SuiteCRM has not yet nominated that release, and its LTS page says it expects to name one by Q3 2027, so that decision is not yet made.
The current line at the time of writing is SuiteCRM 8.10.2, published on GitHub on July 31, 2026, the same day as SuiteCRM 7.15.2. Minor 8.x releases arrive roughly every eight weeks, and patch releases such as 8.10.2 contain only security and bug fixes, with no new features and no database changes. That matters for planning: a patch-level move within the 8.10 line is usually a smaller change than a move between minor releases, but you should still read each release's notes before you schedule it. Confirm the release you intend to target against the SuiteCRM-Core GitHub releases page on the day you plan the work, since newer patches may have shipped since this page was written.
This page covers the in-place upgrade of an existing SuiteCRM 8 instance to the 8.10 line, including the version path for older installs, the console upgrade and finalize steps, the change in SAML behavior from 8.7.0, background data migrations and the compatibility checks that come before any of them. It does not cover moving from SuiteCRM 7 to SuiteCRM 8, which SuiteCRM documents as a migration into a new environment rather than an upgrade, and it does not cover the SuiteCRM 7.15 upgrade for teams still on the 7 line. Those are separate pages in this group and have different prerequisites, so do not apply their steps here.
Before you schedule work, confirm three things with your own team. First, identify the exact SuiteCRM 8 version you run today, because the required path depends on it. Second, check that your PHP, web server and database versions appear on the 8.10 compatibility matrix, which lists PHP 8.2, 8.3 and 8.4, Apache 2.4, MariaDB 10.6, 10.11, 11.4 and 11.8, and MySQL 8.0 and 8.4 on Linux, Unix or macOS. Third, list every customization, custom module, theme change and file under the public/legacy folder, because those are the places where upgrades most often surprise teams. An upgrade that cannot be rolled back cleanly from a tested backup is not ready to run in production.
What the SuiteCRM 8.10 upgrade changes for your instance
This table lists what the 8.10 line changes for an existing SuiteCRM 8 instance, from release cadence and compatibility to the SAML logout change and support dates. Read each row against your current versions, your server stack and your sign-on setup. The main takeaway is that the compatibility matrix and the SAML logout behavior are the changes most likely to need work before cutover.
| Change | Impact | Action needed |
|---|---|---|
| 8.10 line and patch releases | 8.10.2 was published July 31, 2026, alongside SuiteCRM 7.15.2. | Confirm the target patch release on your staging instance before scheduling the change window. |
| Minor release cadence | Minor 8.x releases arrive roughly every eight weeks. | Plan upgrades on a recurring schedule and review each minor release note rather than skipping versions silently. |
| Patch releases | Patch releases contain only security and bug fixes, with no new features or database changes. | Apply patches in your normal change window, after a file and database backup and a release note review. |
| 8.10 compatibility matrix | PHP 8.2, 8.3, 8.4; Apache 2.4; MariaDB 10.6, 10.11, 11.4, 11.8; MySQL 8.0, 8.4 | Check each component version on your current servers against the matrix and confirm the OS is Linux, Unix or macOS. |
| SAML change at 8.7.0 | Logging out at the identity provider leaves the SuiteCRM session open. | If you use SAML, confirm the logout approach with your identity team and tell users to log out of SuiteCRM directly. |
| Extended support dates | SuiteCRM 7.15 receives security fixes until January 2028. | Set your SuiteCRM 8 support horizon against the extended support nomination expected by Q3 2027, and confirm dates on the LTS page. |
| Release-note items not covered here | Console commands, background data migrations and deprecations may apply to your target version. | Confirm each item against the release notes for your target version before the change window. |
Which upgrade path applies to an older SuiteCRM 8 install
The upgrade path to SuiteCRM 8.10 depends on the 8.x release the instance runs today. The topic identifies the 8.2.x line as the stepping stone for older installs, so the first decision is whether the current release sits before that point and must pass through it. The exact version sequence, the required intermediate stops and any console steps specific to each stop must be confirmed from the official release notes and the upgrade documentation published for every stop. Write the sequence down and have it reviewed before any change is made to the staging copy.
Skipping a stop carries a risk that is easy to underestimate. SuiteCRM minor 8.x releases arrive roughly every eight weeks, so an instance that has been left unpatched can sit several minor releases behind. Patch releases contain only security and bug fixes, with no new features or database changes. Minor releases are different, so the upgrade documentation for each stop should show whether it changes the database, whether any background data migration it starts must finish before the next stop, and whether a console step is required before the instance returns to users.
Before choosing a path, record the current state of the instance in writing. Capture the exact SuiteCRM 8.x version, the PHP version used by the web tier, the database engine and version (MariaDB or MySQL), the Apache version and the operating system. Check each value against the SuiteCRM 8 compatibility matrix. For the 8.10 line, that matrix lists PHP 8.2, 8.3 and 8.4, Apache 2.4, MariaDB 10.6, 10.11, 11.4 and 11.8, and MySQL 8.0 and 8.4, on Linux, Unix or macOS. If a current component falls outside the list for the target or for an intermediate stop, the platform upgrade must be sequenced alongside the application path. The matrix describes the 8.10 line only, so confirm the supported versions for each stepping stone separately.
Confirm first that the instance is a SuiteCRM 8 install at all. SuiteCRM documents the move from version 7 to 8 as a migration into a new SuiteCRM 8 environment, with the 7 instance first brought to the latest 7.14.x or later, so a version 7 instance follows a different plan. For a true 8.x instance, also note which authentication method is in use, LDAP or SAML, and how each stop is expected to affect that configuration. Review customizations as well. The migration documentation warns that the process may remove non-core files under the public/legacy folder, so any custom files in that location need a deliberate decision before the test plan is set.
The output of this work is a written record the approvers can review: the current versions, the target patch, each stop with its release notes and console steps, and the staging test results. SuiteCRM 8.10.2 was published on GitHub on July 31, 2026, so confirm whether that is the patch to target when the work is scheduled. Ask whoever performs the upgrade to show how each stop is backed up and how the instance would be returned to its last working state if a stop fails. Those answers determine whether the path is ready to schedule.
Backups, inventory and staging before the SuiteCRM upgrade
Four preparation areas come before the upgrade itself, and each protects a different part of the instance: recoverable data, customizations that may not survive, a place to rehearse the upgrade, and a stack the target release supports. The SuiteCRM migration documentation advises the same preparation steps. Confirm what the upgrade does to non-core files before you run it.
Full backup before any change
Take a complete backup of the application files and the database before any upgrade step runs, and record the exact SuiteCRM version it reflects. Copy the backup off the production host so a disk or host failure there cannot take both copies with it. Restore it to a separate host and confirm that login, a sample set of records and the scheduler work before you rely on it. A backup that has never been restored is untested. Ask your team which owner signs off on the restore test and how long the restore took, since that timing feeds the cutover plan.
Inventory of customizations
List every change made outside the core release: custom modules, extensions, themes, logic hooks, language files, scheduled jobs and integration scripts. Pay particular attention to anything under the public/legacy folder, because the migration documentation warns that the process may remove non-core files there. For each item, record its owner, the reason it exists and whether a vendor or your team maintains it. This list drives the test plan, because every customization needs a check after the upgrade. Items nobody can explain are the ones most likely to break in production.
Staging instance that matches production
Build a staging instance that matches production's PHP, database and web server versions, then load a recent copy of production data into it. Version drift between environments is a common cause of failures that appear only after go-live. Run the upgrade on staging first, time each step and record every error and warning. Keep staging isolated from live email, payment and integration endpoints so test actions do not reach customers. Agree with your platform team how staging will be refreshed if production changes during the project.
Compatibility check against the 8.10 matrix
Compare the current PHP, Apache, MariaDB or MySQL versions against the SuiteCRM 8 compatibility matrix for the 8.10 line. The matrix lists PHP 8.2, 8.3 and 8.4, Apache 2.4, MariaDB 10.6, 10.11, 11.4 and 11.8, and MySQL 8.0 and 8.4, on Linux, Unix or macOS. Where the stack falls outside that list, plan the platform change as separate work before the application upgrade. Also check operating system support, PHP extensions and authentication settings such as LDAP or SAML. Confirm which matrix version applies to the release you intend to install.
SuiteCRM upgrade steps with checks and rollback points
This sequence moves an existing SuiteCRM 8 instance to the 8.10 line in a fixed order, proving each stop on staging before production. Each stop has a verified backup, a defined check and a clear decision point for rolling back or fixing forward.
Freeze change and announce the window
The client's CRM owner and the upgrade lead agree a change freeze on customizations, workflow edits, LDAP or SAML configuration changes and bulk data imports. Users, support staff and integration owners receive written notice of the window and of the expected read-only or limited-access period. Confirm with your own change board how long the window must be and who approves it. The step is done when the freeze is logged, the window is approved, and every integration owner has confirmed they can pause scheduled exchanges.
Confirm current version and upgrade path
Record the installed SuiteCRM 8 version, PHP and web server versions, database engine and version, AUTH_TYPE setting, custom modules and any non-core files. Compare these against the target release notes to find out whether an older install must pass through an intermediate 8.x release such as the 8.2.x line before reaching 8.10. Confirm this path in the release notes for your exact starting version, not from memory. The step is done when a written upgrade path lists each stop, its target version and the release notes reviewed for it.
Bring runtime to the compatibility matrix on staging
On a staging copy of the server, align PHP, Apache 2.4, and the database with the SuiteCRM 8.10 compatibility matrix. The matrix lists PHP 8.2, 8.3 and 8.4, MariaDB 10.6, 10.11, 11.4 and 11.8, and MySQL 8.0 and 8.4. Change one component at a time and rerun the existing SuiteCRM health and login checks after each change, so any regression can be traced to a single cause. Confirm the matrix version against the release you are targeting. The step is done when staging runs the current application unchanged on a supported runtime and the checks pass.
Mark a verified rollback point before each stop
Before every stop, take a full backup of the files and the database and restore it to a separate test location to confirm it is usable. The SuiteCRM migration guidance advises backing up both files and database and reviewing customizations first. Record the backup identifier, the SuiteCRM version it represents and the time it was taken. The step is done when a restore has been tested and the rollback point is written into the change log with the exact commands needed to return to it.
Apply each upgrade stop on staging
Apply each required stop on staging using the console steps documented for that target release, in the order set in the upgrade path. Run each command exactly as written in the release notes for that version, and confirm every command before running it. Capture the console output and any warnings or errors in the change log. Do not start the next stop until the current one completes without unresolved errors and the rollback point for it is recorded. The step is done when staging reaches 8.10 through every required stop with a complete record of each.
Run finalize and wait for background migrations
Run the finalize step only where the target release notes require it. Then monitor the background data migration jobs until they report complete, and check the queue and job logs for failures or stalled tasks. Do not open the instance to users while migrations are still running, because records may be partly converted. Verify record counts for key modules against the pre-upgrade baseline. The step is done when all migrations report complete, no jobs are failing, and the counts match the baseline or any difference has an explained cause.
Verify login, modules, jobs and integrations
Test sign-in with a standard account and an administrator account. If AUTH_TYPE is set to ldap or saml, test that path too, using a test user in each directory or identity provider. For SAML at 8.7.0 or later, confirm that logging out at the identity provider does not end the SuiteCRM session, since that behavior is documented and not a fault. Check key modules, scheduled jobs, email, and each integration against its agreed test cases. The step is done when every test case in the signed-off checklist passes on staging.
Repeat on production with a decision point
Repeat the same stop-by-stop sequence on production, with the rollback point taken immediately before each stop. Choose rollback when a data migration fails or leaves records in doubt, when sign-in is broken with no quick fix, or when an integration writes incorrect data. Choose a forward fix for isolated defects in a module, configuration or template that does not affect the schema or migrated data. Record the decision, its reason and its owner in the change log. The step is done when production passes the same checklist and the change owner signs off the result.
How to test the SuiteCRM upgrade and roll it back safely
The staging test plan decides whether the team can go live, and it also decides how far back the team can safely go if something fails. Build the staging instance from a recent copy of production files and database, running the same PHP, Apache and database versions your target 8.10 release supports according to the SuiteCRM compatibility matrix. Carry over your customizations, authentication settings and integration credentials, but point every integration at a test endpoint so no staging run writes to a live system. Assign one owner for the test plan and one for each area, and record every result with the tester's name and date.
Start with smoke tests that confirm the core paths work after the upgrade. Test login through the method you actually use, LDAP or SAML. If you use SAML on 8.7.0 or later, confirm that signing out at the identity provider does not end the SuiteCRM session, and tell users how sign-out behaves. Then run create and edit for each core module, search, email sending and receiving, one workflow per trigger type, the standard reports, and API calls made by each integration account. For the API checks, use the same account and permissions that the integration uses in production, so a permission gap shows up in staging instead of on go-live day.
Regression tests cover each customization: custom modules, fields, layouts, workflows, validation logic and any code you have added. Ask the business owner of each customization to write the expected result before testing starts, so the tester does not decide what correct looks like. Confirm that background data migrations finished, and check the job queue for failed, stuck or pending jobs. Any failed job must be explained and resolved before sign-off. Finally, compare record counts per module before and after the upgrade, and sample key fields such as owner, status, dates and relationships. Every difference must have a documented reason.
Set rollback decision points before the upgrade window opens, not during it. Before go-live, a rollback is usually a restore from the backup taken immediately before the upgrade, so define the conditions that trigger it: a failed smoke test, an unexplained count difference, a failed migration job or a broken integration with no fix in hand. Name the person who can call the rollback and the latest time it can be called. A rollback restores application files, the database and any configuration captured in the backup. It does not restore data written after that backup, changes made in external systems such as email providers or identity providers, or files outside the backup scope.
A rollback after go-live costs more because users write new records while the upgraded system runs, and background migrations may transform existing data in ways the previous version cannot read. Restoring the old database then discards post-go-live work, and reconciling it by hand can take far longer than the restore itself. Confirm with SuiteCRM documentation and your own staging tests whether the earlier version can read migrated data at all. Rehearse the full rollback on staging, including the time it takes and the manual reconciliation steps, so the team knows the cost before it is asked to pay it.
What drives SuiteCRM upgrade effort
This table lists the factors that move the effort of a SuiteCRM 8.x to 8.10 upgrade and how each one can be reduced before work starts. Use it to check your own instance against each driver. The main takeaway: ask for a written scope that prices each driver separately, so path length, customizations and downtime limits are visible in the quote.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Path length | Minor releases arrive roughly every eight weeks, so an older install may need intermediate stops, such as the 8.2.x stepping stone, before 8.10. | Confirm the exact stop sequence in the release notes and plan one tested upgrade pass per stop. |
| Custom modules, workflows, logic hooks and themes | Each custom element must be retested against the new core, and core changes can break logic hooks or themes. | Inventory every customization before the first stop and retest workflows and themes at each stop. |
| Third-party integrations and API consumers | Every system that calls the SuiteCRM API or receives its data needs testing against each target version. | List consumers, their owners and test cases, and agree a change freeze for them during the upgrade. |
| Authentication setup and identity provider changes | SAML behavior changed at 8.7.0, including no IdP-initiated logout, so logout flows and IdP settings need review. | Record the AUTH_TYPE in use and test login and logout with the identity provider before cutover. |
| Database size and background data migrations | Larger databases take longer to migrate, and background migrations run for a period that depends on data volume. | Measure the database on a staging copy and time each migration step there before setting a window. |
| PHP, database and web server upgrades | 8.10 supports PHP 8.2 to 8.4, Apache 2.4, MariaDB 10.6 to 11.8 and MySQL 8.0 or 8.4, so older stacks need upgrading first. | Compare current versions against the compatibility matrix and schedule platform upgrades as separate changes. |
| Number of environments and staging availability | Without a staging copy that matches production, the team cannot rehearse migrations or measure timings. | Plan development, staging and production environments and refresh staging from a recent production backup before each run. |
| Users and acceptable downtime | More users and tighter business hours raise the cost of each stop, and multiple stops add to the total window. | Agree the maintenance window in writing and confirm whether each stop fits inside it. |
How the 8.7.0 SAML change affects logins after the SuiteCRM upgrade
If your instance signs users in with SAML (enabled with AUTH_TYPE=saml and built on the nbgrp onelogin-saml-bundle), check login and logout behavior before you sign off the upgrade to 8.7.0 or later. The 8.7.0+ SAML implementation does not support IdP-initiated logout or POST binding to the logout service. In practice, a user who signs out at the identity provider keeps a live SuiteCRM session until that session ends or the user signs out of SuiteCRM directly. Treat this as a known behavior to test and plan for, not as a fault that the upgrade introduced.
Start by confirming with your identity provider administrator which logout options are configured for the SuiteCRM application, including whether the identity provider sends any logout request to SuiteCRM at all. Then run the flows on a staging instance that matches production. Sign in through the identity provider, sign out in SuiteCRM, and confirm the login page returns. Sign in again, sign out at the identity provider, and check whether SuiteCRM still accepts the same browser session. Repeat with a second browser and with a session that has been idle. Record each result with the SuiteCRM version, the identity provider version and the exact steps, so the same tests can be repeated after any later change.
Support staff need the same behavior written in plain language. Draft a short note that says signing out of the identity provider does not end the SuiteCRM session, and that users on shared computers must also sign out of SuiteCRM. Include the questions the help desk should ask when a user reports that they were still signed in after signing out elsewhere, and where to escalate such reports. Ask your security owner to approve the wording and to decide whether the current session lifetime, device controls or shared-computer guidance are acceptable compensating measures for your risk profile. Do not publish session timing values in the note until your own configuration has been confirmed.
Review the SuiteCRM 8.7.0+ SAML configuration reference before the upgrade is finalized. Compare each SAML setting in your current configuration with the reference, paying particular attention to any settings whose behavior or expected values changed at 8.7.0. If you are stepping through 8.2.x on the way to 8.10, apply this review at the point where the instance reaches 8.7.0, and repeat the login and logout tests at that point. Record any identity provider changes the reference requires, and make sure they are applied in staging before production.
LDAP is configured differently. If your instance uses LDAP (enabled with AUTH_TYPE=ldap and built on the Symfony Security LDAP authenticators), the SAML limitation described here does not apply, and you should check that setup against the SuiteCRM 8 LDAP configuration reference instead. Test directory-based sign-in, account disablement and password changes as separate items, because they depend on the directory and not on the identity provider logout flow. Confirm with your directory administrator which controls apply to each instance before you sign off the upgrade.
Questions teams ask before a SuiteCRM upgrade
What does a SuiteCRM 8.10 upgrade cost and what changes the price?
The cost depends on the scope agreed in writing, and no price is stated here. Scope drives the work: the starting version (older installs may need the 8.2.x stepping stone first), the number of instances, custom modules, integrations and login settings to check, database size, and how many environments such as staging and production must be prepared. Expect one-time costs for assessment, staging, the upgrade itself, testing and cutover. Recurring costs appear only if you add a support retainer after go-live. Ask the quote to list each scope item, separate one-time from recurring costs, and state what is excluded, such as fixes for customizations that testing uncovers.
How long does a SuiteCRM 8.10 upgrade take to complete?
Duration depends on the factors that set the amount of work, and no timeline is given here. The main drivers are the starting version, the number of customizations and integrations to retest, database size and any background data migrations, how quickly your business owners complete testing and sign off, and how many change windows are available. Ask for the timeline in the written scope with milestones tied to your sign-offs. Confirm the release notes and upgrade steps for your starting version with SuiteCRM before you commit to a date, because those notes determine which steps are required.
What does an SuiteCRM upgrade need from our team before work starts?
The upgrade needs four things from your side. First, access: administrator access to the servers, database, SuiteCRM admin console and, if used, the identity provider for single sign-on. Second, a staging environment that is a recent copy of production, so the upgrade is rehearsed on real settings and data. Third, business owners who name the workflows to test, such as lead conversion, quoting and reporting, and who approve the results. Fourth, a change window with approved rollback criteria. Also provide current file and database backups and a list of customizations, so the work starts from an accurate baseline.
Can our internal team upgrade SuiteCRM to 8.10 without a partner?
Yes, an internal team can run the upgrade if it has three things: the release notes for each version step, a staging copy of production, and a rollback that has been tested on that copy. The team also needs Linux, web server, PHP and database skills to match the platform requirements. Check the SuiteCRM 8 compatibility matrix for the PHP, Apache, MariaDB and MySQL versions that 8.10 supports, and confirm your current stack against it. If your team lacks time or experience, the same work can be scoped and delivered by DeployOpen under a fixed-scope agreement.
Does SuiteCRM 7.15 or an 8 extended support release change upgrade timing?
SuiteCRM 7.15 is an extended support release that receives security fixes until January 2028, so it does not by itself set a deadline for moving to 8.10. Moving from SuiteCRM 7 to 8 is a migration, a separate project with its own planning. For SuiteCRM 8, no extended support release had been nominated when this was written, and SuiteCRM expects to name one by Q3 2027. Confirm the current lifecycle with SuiteCRM before you set your schedule. If you run SuiteCRM 8, plan to stay on a supported minor line, since minor releases arrive roughly every eight weeks.
What happens if a SuiteCRM 8.10 upgrade fails during the change window?
A well-planned upgrade defines the failure path before the change window opens. The plan should set go or no-go checkpoints, name the person who decides to roll back, and state the time limit for the decision. Rollback restores the file and database backups taken before the upgrade, and it must be rehearsed on staging so the team knows the steps work. After a rollback, find the cause on staging before any retry. Ask the partner or internal lead to show the rollback procedure, the backup restore test and the decision log as part of the written scope.
Does upgrading to 8.10 change how SAML single sign-on behaves?
Yes, check single sign-on after the upgrade because SAML handling changed at 8.7.0. The 8.7.0 and later SAML implementation does not support IdP-initiated logout or POST binding to the logout service. Logging out at the identity provider therefore does not end the SuiteCRM session. Tell users to log out in SuiteCRM, and tell your identity team about the change. Test sign-in and sign-out with each user group before go-live, and review the SAML configuration reference for your version to confirm which settings apply to your identity provider.
What support is available after a SuiteCRM 8.10 go-live?
Support after go-live can come from several sources. SuiteCRM Ltd sells the SuiteASSURED support package for the software. DeployOpen offers retainers for ongoing support, upgrades and continuous testing, and those can be scoped in writing. Patch releases contain only security and bug fixes with no new features or database changes, so they are usually lighter to apply, but each one still needs testing against your customizations. Minor releases arrive roughly every eight weeks, so set a recurring upgrade cadence. Ask any provider for response processes, which systems they cover and how they handle your change windows.
How DeployOpen scopes, delivers and supports the SuiteCRM upgrade
DeployOpen plans the SuiteCRM 8.x to 8.10 upgrade as a fixed-scope engagement, with the written scope fixing which instances, versions and customizations are covered. Each step is agreed in writing before work starts, and the work runs in infrastructure you control, from a staging copy through to documented production handover and optional retainer support.
How we scope
- The written scope names the current SuiteCRM 8 version, the target 8.10 line release, and PHP, Apache and database versions.
- Scope records whether an 8.2.x stepping stone is needed for older installs before reaching 8.10.
- Customizations, custom modules, integrations and SAML or LDAP login settings are inventoried and assigned to a fix or retest.
How we build
- Upgrade steps run first on a staging copy restored from a current file and database backup.
- Console upgrade and finalize commands run in the order the upgrade guide sets for each stepping stone.
- Background data migrations are monitored to completion, with row counts and error logs checked before cutover.
How we hand over
- Documented test results cover login paths, including any SAML changes that apply from 8.7.0 onward.
- The runbook records versions, the rollback point, configuration changes and the compatibility matrix entries reviewed.
- Operators are walked through post-upgrade checks, the patch release cadence and who approves each change.
How we support
- Post-upgrade monitoring is agreed in the written scope, including who responds to login and background job failures.
- Patch releases with security and bug fixes only are planned as separate, tested changes on your schedule.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
