What upgrades and support involve for SuiteCRM
Keeping SuiteCRM 8 current means planning for two kinds of release. Minor 8.x releases arrive roughly every eight weeks, and each one can change PHP, Apache, MariaDB or MySQL requirements as well as the behavior your customizations depend on. Patch releases carry only security and bug fixes and make no database changes, so they are usually the simplest to apply. SuiteCRM 8.10.2 was published on July 31, 2026, so check the current compatibility matrix against your host before you schedule any change.
Four events should start an upgrade decision: a new minor release, a security patch, an end-of-life version, or a PHP or database change on the host. Any of them can require a fresh staging run. SuiteCRM 7.15 receives security fixes until January 2028, and SuiteCRM has said it expects to name a SuiteCRM 8 extended support release by Q3 2027. Confirm that date with SuiteCRM Ltd and build it into your roadmap, along with the operating system and database lifecycles on your own servers.
Many teams with a capable administrator apply patch releases in-house after a backup and a staging test. Scheduled minor upgrades and customization testing are where outside help is most often sought, because each minor release needs regression tests for custom modules, workflows, logic hooks and SSO settings. SuiteASSURED is a paid support package sold by SuiteCRM Ltd, and partner work sits alongside it. Confirm directly with SuiteCRM Ltd what SuiteASSURED covers before you decide which upgrade tasks to keep in-house and which to outsource.
What the upgrade and support work includes
Upgrades on SuiteCRM 8 are planned, tested and cut over as a series of checks, not a single installation step. The cards below set out the work we would agree in writing before any change reaches production.
Release tracking and upgrade planning
We follow SuiteCRM 8 minor releases, which arrive roughly every eight weeks, and patch releases, which contain only security and bug fixes. Each candidate release is assessed against your instance, so the plan states which version you move to, why, and when the window opens.
Compatibility checks against the matrix
Before any upgrade we compare your PHP, Apache, MariaDB or MySQL versions with the SuiteCRM 8 compatibility matrix for the target release. Where a runtime component must change first, that work is sequenced ahead of the application upgrade and listed in the runbook for you to confirm.
Staging upgrades with file and database backups
Each upgrade is rehearsed on a staging copy built from production. Files and the database are backed up before the rehearsal and again before cutover, and restore from those backups is tested, so the rollback path is known rather than assumed.
Regression testing of customizations
Custom modules, workflows, integrations and login settings, including LDAP or SAML configuration, are tested against each target release. The migration documentation warns that some non-core files under the public/legacy folder may be removed, so we check customized files explicitly before sign-off.
Production cutover with rollback steps
The cutover runbook lists each step, its owner, the go or no-go criteria and the rollback steps for each stage. Rollback is rehearsed on staging, and the decision point is agreed with your team before the window opens.
Recurring support for incidents and patches
Between upgrades we handle incidents and apply patch releases under the support terms in your written scope. Support can be delivered as a retainer, and it is separate from SuiteASSURED, which SuiteCRM Ltd sells directly, so confirm which responsibilities each covers.
Deliverables and support handover
The engagement produces a written upgrade runbook, a test record for each release, a customization register and a support handover. These deliverables are named and agreed in the fixed scope before work starts, so you know what you receive and who maintains each item afterward.
What drives upgrade and support effort
This table lists the factors that most change how much work each SuiteCRM upgrade and ongoing support load takes, why each one matters, and what your team can do to keep it manageable.
| Driver | Why it changes effort | What you can do to keep it down |
|---|---|---|
| Custom modules | Each custom module has its own fields, layouts and relationships that must be re-tested after each upgrade, so effort grows with module count. | Keep the module list short, document each module's purpose and owner, and remove modules nobody uses. |
| Logic hooks and workflows | Hooks and workflow rules run automatically on record events, so a change in core behavior can silently alter them and they need regression checks. | Keep logic inside supported extension points, name each rule, and maintain a written inventory with expected outcomes. |
| Integrations (ERP, marketing, telephony, web forms) | Each integration depends on API fields, authentication and sync rules, so a SuiteCRM or partner API change can break data flow on any upgrade. | Document field mappings, sync direction and credentials per integration, and test each one on staging before every upgrade. |
| Environments (dev, staging, production) | Upgrades are rehearsed on non-production copies, so every extra environment adds setup, data refresh and test cycles. | Agree which environments are required, keep staging close to production in version and configuration, and automate refreshes where possible. |
| Hosting model (VMs, containers or SuiteCRM Hosted) | Self-hosted stacks require the team to manage the web server, PHP, database and patching, while a hosted service shifts part of that work to the provider. | Confirm which layers are your responsibility in writing, and standardize images or build scripts so each upgrade follows the same steps. |
| Authentication setup (LDAP, SAML or local accounts) | LDAP and SAML settings, certificates and identity provider changes must be verified after each upgrade, and logout behavior has documented limits. | Record the authentication configuration, keep test accounts for each login path, and confirm the identity provider settings are included in upgrade checks. |
| Data volume | Larger databases and file stores lengthen backups, migrations and test runs, and make rollback slower if an upgrade fails. | Archive or purge old records under a retention policy, and test restore times as part of each upgrade rehearsal. |
| Number of users and roles | More users and security groups increase the number of permission combinations to verify and the volume of access questions raised by support. | Limit security groups to documented roles, review them on a set schedule, and check access as part of each release test. |
| Compatibility changes (PHP, database, web server) | Each SuiteCRM minor release may move the supported PHP, MariaDB, MySQL and Apache versions, so the platform underneath may also need upgrading. | Check the compatibility matrix for each target release before scheduling, and plan platform upgrades ahead of the SuiteCRM upgrade. |
How an upgrade and support engagement runs
The sequence moves a SuiteCRM 8 instance from its current version to a supported target release with tested customizations, a rollback path and a named owner for ongoing support.
Assess the current version and customizations
We record the installed SuiteCRM 8 version, the PHP, Apache and database versions in use, the hosting layout, and every custom module, field, logic hook, workflow and integration. The output is a written inventory with each item marked as core, configured or custom, and a list of owners who can confirm expected behavior.
Review compatibility and gaps against the target release
We compare the inventory with the compatibility matrix for the chosen 8.x target release, covering supported PHP, Apache and MariaDB or MySQL versions, and flag any customization that touches files or APIs likely to change. The output is a gap register with required server changes, the upgrade path, and items to confirm with SuiteCRM before work starts.
Upgrade a staging copy after taking backups
We take full file and database backups of production, restore them to a staging environment that matches production, and run the planned upgrade there first. The migration documentation also advises reviewing customizations because a move can remove non-core files under the public legacy folder, so we check those files before and after. The output is a staging instance and a log of every change made.
Run regression tests with named business owners
Business owners for sales, service and marketing run agreed test scripts on staging covering records, workflows, email templates, scheduled jobs, integrations and any SSO login path. Each defect is logged with severity and an owner, and fixes are retested. The step closes when every in-scope test has a recorded pass signed by the named owner, or an agreed exception.
Cut over to production with a rollback plan
We agree the cutover window and communications with your team, run the upgrade on production from the tested steps, and repeat the smoke tests. A rollback plan with restore points and decision criteria is written and held ready until the owners confirm the system. The output is a cutover record showing the final version, the checks passed, and the rollback point retained.
Hand over to ongoing support
We deliver the updated documentation, the revised inventory, the test scripts for the next cycle and a runbook covering patch and minor release handling. Support scope, response expectations and who approves each upgrade are confirmed in the written scope. The step is complete when your admins have walked through the runbook and the support arrangement is signed off.
What stays in-house and what goes to a partner
This table compares the upgrade and support work your team usually keeps with the work partners often take on, and lists the skills each side needs so you can judge where your own staff are strong and where gaps appear.
| Work area | Usually kept in-house | Often outsourced to a partner |
|---|---|---|
| Business sign-off | Business owners approve release scope, go-live dates and acceptance of changed workflows and fields | Partner prepares release notes, impact summaries and a sign-off checklist for owners to review |
| Data owner decisions | Data owners decide retention, field meaning, access rights and which legacy records to keep | Partner flags schema or field changes in each release that need an owner decision |
| Day-to-day user support | Internal admins answer user questions, reset access and handle routine record issues. Needs SuiteCRM module and workflow knowledge | Partner provides second-line help for complex defects and configuration questions under agreed support terms |
| Change approval | IT or change board approves each upgrade window and rollback decision | Partner submits change requests with test evidence, rollback steps and affected components |
| Release tracking | Assign one owner to watch SuiteCRM 8 minor and patch releases and schedule reviews. Needs an understanding of the eight-week minor cycle | Partner monitors releases and security notices, then summarizes changes that affect your instance |
| Compatibility review | Confirm PHP, Apache, MariaDB or MySQL versions against the official matrix. Needs Linux, PHP and database operations skills | Partner reviews the compatibility matrix against your current stack and drafts any required platform changes |
| Staging upgrades | Keep staging infrastructure and access available. Needs Linux and web server administration skills | Partner runs the upgrade on a staging copy of files and database, then records the results and issues found |
| Regression test scripts | Provide business test cases for key sales and service processes. Needs domain knowledge of your pipeline and cases | Partner writes and maintains automated regression scripts. Needs test automation and browser testing skills |
| Customization fixes after upgrades | Review fixes to business logic and approve behavior changes. Needs SuiteCRM module and workflow knowledge | Partner repairs custom modules, logic hooks and extensions broken by an upgrade. Needs PHP and SuiteCRM 8 development skills |
| On-call incident response | Internal staff receive user reports and decide business impact during an incident | Partner handles overnight or weekend outages, database recovery and rollback under the agreed support model |
What usually goes wrong in SuiteCRM upgrades
Most failed SuiteCRM upgrades trace back to a short list of preventable causes. Each card names one failure mode and the check that stops it.
Unsupported PHP or database versions
A minor release can require a PHP, MariaDB or MySQL version that the host does not run. SuiteCRM 8.10 lists supported PHP 8.2 to 8.4, MariaDB 10.6, 10.11, 11.4 and 11.8, and MySQL 8.0 and 8.4. Compare the target release's compatibility matrix with the host before scheduling the upgrade, and plan any runtime change as its own step.
Customizations that break unnoticed
Custom fields, logic hooks, workflows and layouts can fail silently after an upgrade, and the first people to find the fault are often sales or service users. Test each customization on a staging copy with realistic records and roles, and record the expected result for each one so the test has a clear pass condition.
Skipping the staging environment
Upgrading production directly removes the chance to find problems before users do. A staging instance built from a recent copy of production files and database lets the team run the upgrade, test key business paths and time the work. Treat a staging run that has not been repeated after the last change as unverified.
No tested rollback path
Without a pre-upgrade backup of both files and database, a failed upgrade can leave the CRM in a state nobody can reverse quickly. Before the change, confirm who decides to roll back, how the backup is restored, and how long users are affected. Test the restore on staging rather than assuming the backup is usable.
Customizations in folders upgrades remove
The SuiteCRM migration documentation warns that the migration may remove non-core files under the public/legacy folder. Custom code placed there can disappear during a version change. Keep customizations in supported extension locations, and review any file outside the core tree before each upgrade.
Patches applied late
Patch releases contain only security and bug fixes, with no new features or database changes, so they are usually the lowest-risk changes to apply. Teams that defer them accumulate exposure. Agree a patch cadence with the business in advance, including who approves emergency security patches and how quickly they apply.
No written customization register
When nobody keeps a list of custom fields, logic hooks, workflows, integrations and extensions, each upgrade becomes a search through the system. A register that names each item, its owner, its location and its test case lets the team plan the upgrade and confirm nothing was missed.
How the work changes by starting point
The instance already runs a supported minor release, so the upgrade is a planned step. The work centers on the next minor release and its compatibility changes.
- Testing: Run customizations and integrations against the next minor on a staging copy built from a current backup.
- Sequencing: Plan one step at a time on the roughly eight-week minor cycle, and check whether the target needs a newer PHP or database version first.
- Access: Keep the change window small and limit sign-off to the admin and integration owners who review the test results.
- Confirm: Read the release notes for database changes, and check the compatibility matrix against the PHP, web server and MariaDB or MySQL versions in use.
Falling several minor releases behind widens the gap the team must test. Each minor can carry compatibility changes, so the catch-up runs as an ordered sequence of minor steps.
- Testing: Expect custom code and integrations to be tested against every intervening minor unless the vendor confirms a shorter path.
- Sequencing: Build a step plan with a staging run for each minor, and fix any PHP or database prerequisites before the first step.
- Access: Plan a longer change calendar with a sign-off point and a rollback rehearsal at each step.
- Confirm: Ask the vendor whether a direct path from your version to the target is supported, and confirm which current minor receives security fixes.
A SuiteCRM 7 estate moves to SuiteCRM 8 through a migration, which the vendor documents as a new 8 environment with 7 data moved into it. This tab covers the support model after that work. The migration steps are covered in the separate migration topic.
- Sequencing: Treat the migration as its own project with its own cutover date. Routine upgrade planning begins after go-live.
- Access: Confirm who keeps access to the legacy 7 instance during parallel running and how long that access lasts.
- Lifecycle: SuiteCRM 7.15 is an extended support release with security fixes until January 2028, which sets how long a 7 instance can stay in service.
- Confirm: Ask the vendor which 7.x version the migration documentation currently expects, and when it plans to name a SuiteCRM 8 extended support release, which it expects to do by Q3 2027.
The application steps stay the same on containers and virtual machines. Where the code and dependencies come from, and how a rollback runs, depend on the platform.
- Testing: On containers, test the new image together with its configuration, scheduler jobs and any supporting services before promoting it.
- Sequencing: On virtual machines, take a snapshot before each step. On Kubernetes, plan rolling updates and confirm that session and file storage are shared across replicas.
- Access: Container changes usually pass through a pipeline and a registry, so confirm who may approve image promotion.
- Confirm: Ask the vendor whether it publishes container images for your release or whether your team builds them, and confirm that your runtime matches the compatibility matrix.
Where the network cannot reach public sources, release packages and their dependencies must be staged inside the network before any upgrade starts.
- Testing: Build the staging copy from the same staged packages used in production, so test results carry over to the live system.
- Sequencing: Add time for package transfer and review to each minor step, since every step needs its packages staged first.
- Access: Restrict who can move packages across the boundary, and log each transfer for the environment owner.
- Confirm: Ask the vendor which artifacts each minor requires, including dependencies that normally download at install, and whether an offline bundle or internal mirror is supported.
What you need to provide before an engagement starts
The first inputs are access and a matching staging environment. Give the engagement team read access to the current web servers, the database host and the file store, plus a staging instance that runs the same PHP, Apache, and MariaDB or MySQL versions as production. Before the engagement starts, check the running versions against the SuiteCRM 8 compatibility matrix, and confirm that staging can receive a recent copy of the production database and files, since every upgrade is tested there first.
Next, provide a backup you have restored at least once. That means a full file backup, including custom directories, and a database dump, with written restore steps your team has tested. Also provide a current inventory of custom modules, Studio and Module Builder changes, workflows, logic hooks, custom fields, and each integration, with its direction of data flow and the owner of its credentials. The SuiteCRM migration guidance warns that non-core files under the public/legacy folder may be removed during a version change, so list any files you have placed there.
Login configuration is the third input. If users sign in with LDAP or SAML, supply the directory or identity provider settings, a test service account, the certificate details, and a test user for each role that must be verified on staging. Name one business owner who can accept test results and sign off on each release, and name a deputy for absences. Agree a change window and any freeze periods with that owner before the first upgrade is scheduled.
Finally, decide your patch and upgrade cadence. Minor 8.x releases arrive roughly every eight weeks, while patch releases carry only security and bug fixes, so the decision is how quickly you accept each change and how minor releases are batched into planned windows. Also note that SuiteCRM 8 core is licensed under AGPLv3. If you modify the core and distribute those changes, or run a modified version for users over a network, ask your counsel how the license terms apply to your own modifications before work starts.
Common questions about SuiteCRM upgrades and support
How much effort does a SuiteCRM 8 upgrade take and what drives it?
Effort depends mostly on how much custom code and configuration sits on top of the core, not on the version number alone. A stock instance with few customizations is the simplest case. The main drivers are the number of custom modules, logic hooks, fields, workflows and integrations, whether those were built to survive upgrades, the PHP and database changes the target release requires, and how many staging test cycles the business wants before cutover. Ask any provider for a quote that lists each of these drivers separately and states which test cases are included in the scope.
How often do SuiteCRM 8 minor releases arrive and how should I plan for them?
SuiteCRM 8.x minor releases arrive roughly every eight weeks. Plan a recurring upgrade window for each minor release you intend to adopt, rather than treating upgrades as one-off projects. Between minor releases, patch releases contain only security and bug fixes. Decide in advance which patch cadence you will apply quickly, which minor releases you will skip, and how long a staging test cycle takes for your customizations, so the calendar reflects real capacity.
Do SuiteCRM patch releases include database changes?
No. According to the SuiteCRM LTS guidance, patch releases contain only security and bug fixes, with no new features and no database changes. Minor releases are a different matter and may carry changes that require a planned upgrade. Confirm this behavior for the specific release you are applying by reading its release notes before scheduling the work, and always take a database and file backup before any change.
Which PHP and database versions does SuiteCRM 8.10 support?
SuiteCRM 8.10 supports 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. Check the SuiteCRM 8 compatibility matrix before each upgrade, because supported combinations can change between releases. Your operating system, web server and database vendor's own lifecycle dates also matter for planning, so confirm those separately with each vendor.
What does SuiteASSURED cover compared with outsourced upgrade work?
SuiteASSURED is the paid support package sold by SuiteCRM Ltd around the free software. Outsourced upgrade work is a separate engagement scoped to your environment, customizations and integrations. Support packages typically address product questions and software issues, while an implementation partner plans, tests and executes an upgrade against your own systems. Ask SuiteCRM Ltd and any partner to put the exact coverage, response terms and exclusions in writing, and confirm whether customization testing is included.
What must my team provide for a SuiteCRM upgrade engagement?
Expect to provide access to staging and production environments, administrator accounts, a current backup, a list of customizations and integrations, and named business owners who can approve test results. Your team also needs a change window and a rollback decision maker. Without these, testing slows and cutover risk rises. Confirm the full list in the written scope, including who performs backups and who signs off on each stage.
Can an internal admin team upgrade SuiteCRM alone?
Often yes for a lightly customized instance, if the admin team has Linux, web server and database skills, can build a staging copy, and has time for test cycles. The risk rises with custom modules, integrations, SSO and high availability setups, and with infrequent upgrades that let the gap widen. Assess your team's skills against the compatibility matrix and your customization list, and decide which tasks you will keep in-house and which you will buy as a fixed-scope engagement.
How DeployOpen delivers SuiteCRM upgrades and support
DeployOpen plans and carries out SuiteCRM 8 upgrades and ongoing support inside your own infrastructure, with each piece of work agreed in writing before it starts. Ongoing support is available as a retainer for teams that want continuing help after the first upgrade.
How we scope
- The written scope lists which SuiteCRM 8 minor and patch releases are covered and the PHP, Apache and database versions in use.
- Customizations, custom modules, integrations and SSO connections are inventoried so each one has a named test and an owner.
- Engagements are fixed-scope, so deliverables, responsibilities and the support period are agreed before any work begins.
How we build
- Each upgrade is first run on a staging instance cloned from production, with files and database backed up before any change.
- Compatibility is checked against the SuiteCRM 8 compatibility matrix for PHP, Apache and MariaDB or MySQL versions.
- Customizations and integrations are retested against the new release, and any breaking changes are fixed and documented before cutover.
How we hand over
- Your team receives an upgrade record covering versions moved between, test results, backups taken and changes made to the environment.
- Customizations are documented with their location, purpose and test steps so later upgrades can be planned without rediscovery.
- Rollback steps and restore tests are written down and run so your administrators know how to recover if a release misbehaves.
How we support
- Ongoing support can be set up as a retainer covering patch releases, minor release reviews and agreed response channels.
- Security and bug-fix patch releases are reviewed on a schedule agreed in the scope, with testing before they reach production.
- Ask what the retainer covers, how requests are prioritized and how SuiteASSURED from SuiteCRM Ltd fits alongside DeployOpen's work.
