Why a SuiteCRM 7 upgrade to 7.15 is the first step for older instances
An older SuiteCRM 7 instance that cannot move to SuiteCRM 8 yet should first be brought to 7.15, the extended support release, which receives security fixes until January 2028. The upgrade buys time before the SuiteCRM 8 migration, which SuiteCRM documents as a move of data into a newly built SuiteCRM 8 environment. Staying on an unpatched 7 release while the migration is planned exposes the CRM and its customer data for longer than most organizations intend.
The supported route to 7.15 runs through the SuiteCRM 7 release line, so the first decision is where your instance sits today. SuiteCRM's migration documentation asks for the 7 instance to be on the latest 7.14.x release or later before any move to SuiteCRM 8, which means an instance several releases behind will need its own step sequence. Confirm the starting version, the intermediate releases and the database and PHP requirements for each step in the SuiteCRM 7 release notes on GitHub. SuiteCRM 7.15.2 was published on July 31, 2026, the same day as SuiteCRM 8.10.2, so the 7.15 line is current for the patch level you should target.
The work runs entirely inside your infrastructure, on your servers, virtual machines or cloud accounts, under change control your team approves. DeployOpen does not take custody of your data or move it to a vendor-hosted service to perform the upgrade. Your team should decide who holds the backup copies, who signs off the staging results and which maintenance window fits the business. Before any production step, a staging copy should be restored from a current file and database backup, and every custom module, theme and script should be listed so its behavior can be checked against 7.15.
Plan the upgrade as the first phase of a longer program, not as a final state. SuiteCRM expects to name an extended support release on the 8 line by Q3 2027, according to its LTS page, so confirm that date and the 7.15 end-of-security-fix date directly on that page before you set internal deadlines. Ask any implementation partner for a written scope that lists the environments, the backup and rollback steps, the checks used to confirm the upgrade worked and the handover of runbooks to your team.
What changes in 7.15 and what each change asks of the team
This table lists what the 7.15 extended support release changes for an existing SuiteCRM 7 instance, what each change means for operations, and what your team needs to do. Read the support window and version rows first, because they set how long the instance stays supported and which build to target. Functional, breaking and deprecation details are not covered on this page, so confirm them in the 7.15 release notes before you schedule the upgrade.
| Change | Impact | Action needed |
|---|---|---|
| Release type | 7.15 is an extended support release, so it is maintained longer than a standard feature release. | Plan the instance on 7.15 as a stable base and set a review date well ahead of the support end. |
| Security fix window | Security fixes are provided until January 2028. | Record January 2028 as the support end date and schedule the next move before it. |
| Current release | 7.15.2 is the current release in the 7.15 line. | Target 7.15.2 in staging and confirm the version shown in the admin area after the upgrade. |
| Functional changes | Feature and behavior changes in 7.15 are not covered on this page and may affect modules and workflows. | Confirm functional changes in the 7.15 release notes on the SuiteCRM 7 GitHub releases page, then list the affected workflows. |
| Breaking changes | Breaking changes can stop custom code, logic hooks or integrations from working after the upgrade. | Check the release notes for breaking changes and test each custom component and integration in staging. |
| Deprecations | Deprecated features still run in 7.15 but may be removed in a later release. | Confirm deprecations in the release notes and record any custom code that depends on them for later work. |
Why 7.15 is a holding point and not the SuiteCRM 8 migration
Upgrading to SuiteCRM 7.15 keeps an older SuiteCRM 7 instance on a supported extended support release while the move to SuiteCRM 8 is planned. It does not move your data into SuiteCRM 8. SuiteCRM documents the move from 7 to 8 as a migration: a new SuiteCRM 8 environment is set up, the SuiteCRM 7 data is moved into it, and the 7 instance must first be brought to the latest 7.14.x or later. The 7.15 upgrade changes the existing 7 instance in place, so the two projects have different outputs, different risks and different owners.
The work in this upgrade is the command-line upgrade of the existing instance, followed by permission fixes and repairs. Those steps leave the instance on the 7.15 line, where SuiteCRM has published security fixes through January 2028. Because 7.15 is later than 7.14.x, completing this upgrade also satisfies the documented prerequisite for starting a migration, but you should confirm that against the current migration documentation before you plan the move. Nothing in this upgrade creates the SuiteCRM 8 environment, so the upgrade does not test the migration path.
Choose 7.15 as your holding point if the migration will not begin soon and the team needs a supported 7 instance in the meantime. Pay attention to the lifecycle: SuiteCRM has not yet nominated a SuiteCRM 8 extended support release, and it expects to name one by Q3 2027. If your plan depends on landing on an extended support release for 8, treat that date as a dependency to track. Also ask who in your organization decides when the migration starts, because the holding point only remains useful if someone reviews it before January 2028.
Plan the SuiteCRM 8 migration as separate work with its own staging instance, backups of files and database, and a review of customizations. SuiteCRM's migration guidance warns that the migration may remove non-core files under the public/legacy folder, so custom code in that location needs to be inventoried before any cutover. Test the migration on staging against the SuiteCRM 8 compatibility matrix for your chosen release, including PHP, web server, database and operating system versions. Do not treat the 7.15 upgrade in production as a rehearsal for that work.
Before you approve the 7.15 upgrade, record the current SuiteCRM version, the customizations in use and the integrations that depend on the 7 instance. Set a review date ahead of the January 2028 security cutoff. Then ask your implementation partner for a separate written scope for the SuiteCRM 8 migration, covering staging, testing, data verification, customization review and cutover, and ask which of those items are included in the upgrade quote and which are not.
What to prepare before the SuiteCRM 7 upgrade starts
Four preparation items come before the 7.15 command-line upgrade starts. Each one protects a different part of the work: recovery, scope, testing and platform fit. Together they show whether the upgrade can run safely and give your internal team or a partner a clear starting point.
Full file and database backups
Take a complete backup of the SuiteCRM 7 file tree and its database before any upgrade step runs. The command-line upgrade rewrites files and changes the database, so the backup is the only dependable way back if a step fails partway. SuiteCRM's migration guidance advises backing up both files and database. Store copies outside the server, record checksums, and run a test restore on a separate host so you know the backup can be read before you need it.
Inventory of customizations
List every change made to the instance, including custom modules, field definitions, layouts, logic hooks, custom themes and any files under the public/legacy folder. The migration guidance warns that non-core files under public/legacy may be removed, so each file you added there needs a decision: keep it, rebuild it or retire it. Record the owner, the reason for each change and whether it still works on the current version. This list sets the scope of testing and tells a partner what needs to be quoted.
Staging instance from a production copy
Build a staging instance from a recent copy of production, on the same PHP, Apache and database versions, with the same custom code and a copy of the data. Run the upgrade there first, then sign in with several user roles and test the modules your teams use every day, along with scheduled jobs and outbound email. Keep staging isolated from production mail and integrations so test runs do not send messages to customers or write to live systems. Staging is where the customization inventory gets proven.
Check 7.15 platform requirements
Compare the PHP, Apache and database versions on the current host with the requirements for SuiteCRM 7.15, the extended support release that receives security fixes until January 2028. The compatibility table for SuiteCRM 8 covers a different release line, so it cannot answer this question. Confirm the 7.15 requirements with SuiteCRM directly, then list any gaps, such as a PHP version that must change first, and plan those platform changes as separate work with their own rollback steps.
How the SuiteCRM 7 upgrade to 7.15 runs, step by step
This sequence moves an existing SuiteCRM 7 instance to the 7.15 extended support release, which receives security fixes until January 2028, in a controlled order. A verified backup and a tested staging run come before production, and each step names the check that proves it worked and the point to roll back to.
Confirm the current 7.x version and upgrade path
The SuiteCRM administrator and the platform owner record the exact installed 7.x version, the PHP, database and web server versions, any custom packages and any modified core files. They then read the 7.15 upgrade documentation for the supported starting versions and any intermediate releases it requires. The step is done when the upgrade path is written down and every instance in scope has a confirmed starting version. Rollback point: nothing has changed yet, so there is nothing to revert.
Take and verify full file and database backups
Back up the SuiteCRM file system, including custom code and upload directories, and the database, captured in a consistent state. Store the copies outside the application server. Restore the database dump into a scratch database to confirm it is usable, and compare the file listing with the source. The check is a successful test restore and a matching file inventory. Rollback point: this verified backup is the restore point for every later step, so keep it until the production upgrade is accepted.
Build a staging copy of the instance
Restore the verified backup onto a staging environment that matches production for PHP, database and web server versions. Point staging at its own database, and disable outbound email, scheduled jobs and integrations so test activity does not reach customers or external systems. The check is that staging loads, users can sign in and record counts are close enough to production to make the test meaningful. Rollback point: staging can be rebuilt from the same backup at any time.
Run the command-line upgrade on staging
Run the command-line upgrade process described in the 7.15 upgrade documentation. Take the exact commands and flags only from that document, and record the output of every stage along with any warnings. The step is complete when the process reports success and the application shows version 7.15. Rollback point: restore the staging copy from the verified backup, correct the cause of the failure and run the process again.
Apply permission fixes and run repairs
Before changing anything, record the current file ownership and permissions so the changes can be reviewed and reversed. Then set ownership and permissions for the web server user as the documentation specifies, and run the repair routines it lists for the database and file caches, in the order given. Log each result. The check is a clean repair report and no permission errors in the application log. Rollback point: restore the recorded permissions, or reset the instance from the backup taken in the second step.
Check logs and key workflows on staging
Review the application and web server logs for errors and deprecation notices introduced by the upgrade. Then test the workflows the teams depend on: sign-in, creating and editing leads, cases and accounts, email and calendar actions, reports, scheduled jobs, and every custom module or integration in use. Compare results with the behavior recorded in the first step. The step closes when the logs show no new errors and the business owners sign off the test list. Rollback point: a failed workflow returns the team to the upgrade run, or restores staging from backup.
Repeat the upgrade on production in a planned window
Agree a maintenance window with the business owners. Take a fresh production backup immediately before work starts, because it will be newer than the staging backup. Apply the same steps used on staging, including maintenance mode if the documentation requires it, and repeat the log and workflow checks. The step is done when production results match staging and the owners accept the outcome in writing. Rollback point: restore production from the backup taken just before the window, the last point at which the data changes can be discarded safely.
How to test the upgrade and roll back if it fails
Sign-off on the SuiteCRM 7 upgrade to 7.15 should rest on a written test plan with a named owner for each area, agreed before anything runs against the staging copy. Start with login: test the local account path and any LDAP or SAML sign-in the instance uses, with a user from each role group. Record access comes next, so a sales representative, a service agent and a manager each confirm they see the records their role allows and no others. Email and calendar functions need a send, receive and meeting invitation test from a mailbox the owner controls. Scheduled jobs, custom fields and layouts, integrations and reports complete the list. Assign each item to a person who knows the expected result, such as a sales operations lead for layouts and reports and an integration owner for each connector.
Set the rollback decision point before any production change begins, and write down the conditions that trigger a return to the pre-upgrade version. The application owner and the change approver should review the staging results, the list of failed checks and the time available for a rollback together. Decide in advance which failures stop the change, such as login failures for any user group, missing records, broken email delivery or failed scheduled jobs, and which can be accepted and fixed after go-live. A decision made under pressure during a maintenance window tends to favor pressing on, so the criteria should exist on paper before that window opens. Confirm also that the backup you would restore from has already been restored successfully on a separate environment.
A rollback restores two things together: the application files and the database. Both must come from the same verified backup point, taken after the last business activity you intend to keep and before the first upgrade step. Restoring files from one point in time and the database from another can leave the instance looking healthy while custom code or stored configuration fails. The SuiteCRM migration documentation advises backing up files and database, testing on staging and reviewing customizations, and it warns that some non-core files under the public/legacy folder may be removed. Store the backup where the upgrade process cannot overwrite it, and confirm that your team can reach it without depending on the person who ran the upgrade.
A rollback is complete only if you know every change the upgrade made. Keep a running change record during the work: each command run, each permission or ownership change, each repair step, each database or configuration edit, and each custom file that was modified, moved or removed. Before the upgrade, note the state of custom fields, layouts, scheduled jobs and integration settings so you can compare them afterward. Without this record, a restored file set can miss a permission fix applied outside the backup scope, or a scheduled job can stay in a changed state. Ask your implementation partner to hand over the record at the end of the work, and rehearse one restore on staging using it before the production window.
What makes a SuiteCRM 7 upgrade take longer
This table lists the factors that most often lengthen a SuiteCRM 7 upgrade to 7.15 and explains how each one changes the work. Read each row as a question to answer about your instance before you schedule the change window. The main takeaway is that the count of customizations, extensions and integrations usually shapes the effort more than the version jump itself, so inventory them before anything else.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Custom modules and customizations | Each custom module, field and layout must be checked against 7.15 and may need rework or retesting. | Build a written inventory from Module Builder, studio changes and custom code, and mark each item keep, rework or retire. |
| Edits to core or legacy files | Direct edits can be overwritten or conflict with the upgrade, and they are harder to review later. | List every changed core or legacy file, compare it with the shipped version, and move changes to supported extension points where possible. |
| Third-party extensions | Each extension has its own compatibility with 7.15, and vendor support for it may be unclear. | Confirm each extension's support statement for 7.15 in writing, and decide per extension whether to update, replace or remove it. |
| Database size and backup time | A large database lengthens the full backup, the restore test and the window available for rollback. | Measure database and file size, time a test restore on a copy, and confirm the rollback method before the change window opens. |
| Environments kept in sync | Production, staging and test instances drift apart, so a test passing on one may not represent production. | Freeze configuration changes during the work, and compare customization versions across environments before each run. |
| Integrations needing retest | Each connected system, such as email, calendar, LDAP or APIs, needs its own test scenario and owner sign-off. | List every integration with its owner and test cases, and agree sign-off criteria before the upgrade window opens. |
What the 7.15 upgrade should leave ready for the SuiteCRM 8 migration
A clean SuiteCRM 7.15 instance should give the migration four things: a backup set that has been restored and tested, a written inventory of customizations, a staging copy that matches production, and a reviewed list of files under the public/legacy folder that the migration may remove. SuiteCRM documents the move from 7 to 8 as a migration into a new SuiteCRM 8 environment, not an in-place upgrade, so the 7.15 work is what makes that move predictable. Treat each item as a deliverable with an owner and a sign-off date, not as a byproduct of the upgrade.
Start with the backups. The migration guidance advises backing up both files and the database before any change, and a backup that has never been restored is not evidence. Restore the 7.15 backup to a separate host, confirm that logins, records, attachments, email settings and scheduled jobs work, and record checksums or sizes for each archive. Keep the set until the SuiteCRM 8 environment has run in production for an agreed period. Ask your partner or internal team to state where the backups are stored, who can restore them, and how long they are kept.
Next, build a customization inventory. List custom modules, logic hooks, field and layout overrides, language files, themes, custom views, scheduled jobs, email templates, reports and every integration that reads or writes CRM data. For each item, record whether SuiteCRM 8 provides the same behavior, whether it must be rebuilt, or whether it can be retired. Then review public/legacy. The migration docs warn that non-core files in that folder may be removed, so every custom file there needs a documented owner and a decision to keep, move or drop it. Confirm the exact handling with the SuiteCRM migration documentation for your version.
Finally, create a staging copy that matches production. It should share the production database snapshot taken at a stated time, the same customizations, the same PHP and database versions in use on 7.15, and the same integrations pointed at test endpoints. Use it to run the 7.15 upgrade, the migration rehearsal and user acceptance tests. Record every difference you cannot remove. Staging that is older or cleaner than production will hide the problems the migration would otherwise surface.
Identity needs its own plan because login is not carried over from 7.15. LDAP and SAML for SuiteCRM 8 are configured in the 8 environment, using the AUTH_TYPE settings and the documented configuration references, so they should be designed as part of the migration rather than inherited from 7.15. Decide how users are matched, which attributes are mapped, and how accounts are disabled. Note that the 8.7.0+ SAML implementation does not support IdP-initiated logout, so an identity provider sign-out will not end the SuiteCRM session. Confirm each of these requirements with the current SuiteCRM LDAP and SAML references before scheduling cutover.
Questions buyers ask before a SuiteCRM 7 upgrade to 7.15
How much does a SuiteCRM 7 upgrade to 7.15 cost?
The cost depends on how much work your team already covers and how much customization the instance carries. SuiteCRM is free to download and self-host, so the fees pay for services: planning, environment preparation, the command-line upgrade, permission fixes and repairs, testing and handover. Ask for a written scope that separates one-time work from recurring items, such as support. SuiteCRM Ltd sells a SuiteASSURED support package, which is a separate decision from the upgrade itself. The main cost drivers are the number of customizations to review, the number of environments (staging, test and production), the PHP and database versions in use, and how much data cleanup is needed. Confirm all figures with DeployOpen or in your own environment before you budget.
How long does a SuiteCRM 7 to 7.15 upgrade take?
Duration depends on the size of the instance, the amount of customization, and how quickly your team can test and approve each stage. A fixed-scope quote states the timeline in writing, so ask for it there rather than relying on a general estimate. The longest stages are usually the customization review and staging tests, not the upgrade command itself. Plan time for a full backup, a rehearsal on a copy of production, user acceptance testing and a rollback window if something fails. Ask for the planned stages, the dependencies on your team's availability, and which tasks depend on confirmation from SuiteCRM or from your own environment. Agreed change windows and freeze dates keep the work away from busy periods for your users.
What does our team need to provide for the upgrade?
Your team provides access, decisions and knowledge. Typical needs include administrator access to the SuiteCRM 7 application, its web server and its database, a staging environment that matches production, and a recent full backup of files and database. Someone must own business sign-off on which data and workflows matter, and someone must know which customizations exist and why they were built. The SuiteCRM migration documentation advises reviewing customizations before a move, and it warns that the migration path may remove some non-core files under the public/legacy folder. Name contacts who have time in the schedule for testing, not only for kickoff meetings. Confirm the exact access model in writing before work starts.
Can our internal team upgrade SuiteCRM 7 to 7.15 alone?
Yes, an internal team can perform the upgrade alone if it has the skills and time. The technical work needs command-line experience on the server, working knowledge of PHP, the web server and the database, and the ability to read logs and run repairs and permission fixes safely. The team also needs a tested backup and restore method and a staging environment. The harder question is whether the team can review customizations and test business workflows without disrupting daily work. Many organizations split the work: internal staff own business testing and sign-off, while an outside team handles the technical steps. Check who would be on call during the change window and whether that person has completed a production upgrade before. A partner can carry the technical load under a written scope.
What must be settled before a fixed-scope upgrade quote?
Several items should be settled before a fixed-scope quote can be written. Start with the current SuiteCRM 7 version and the hosting details: operating system, PHP version, web server, database and where backups are stored. Next, inventory the customizations, modules, custom code and integrations, and mark which ones are business critical. Agree the environments, who approves test results, the acceptance criteria, the change window and the rollback plan. Confirm the version path to 7.15 in SuiteCRM's release information for your current build, and state whether a support package is already in place. Finally, name the decision owner and the person who signs off go-live. Each open item can become a change request later, so settle as many as you can in writing first.
When should we start the SuiteCRM 8 migration after 7.15?
Start planning the SuiteCRM 8 migration now, while 7.15 still receives security fixes. SuiteCRM's LTS information says 7.15 is an extended support release with security fixes until January 2028. No SuiteCRM 8 extended support release had been nominated at the time of the source, and SuiteCRM expects to name one by Q3 2027, so that nomination should shape your target release. Minor SuiteCRM 8.x releases arrive roughly every eight weeks, and each patch carries only security and bug fixes. Migration from SuiteCRM 7 to 8 is a new environment plus a data move, so it needs its own schedule with testing, backups and sign-off. Work backward from January 2028 and confirm all dates with SuiteCRM before you commit a timeline.
What should engineers check after the 7.15 upgrade finishes?
Engineers should verify the application, its background work and its dependencies, not only the version number. Check that users can log in, that records and attachments open, and that file permissions allow the application to write to its upload and cache directories. Confirm that scheduled jobs and cron entries still run, that outbound email sends, and that every integration endpoint responds with the expected data. Review the upgrade and repair logs for failed steps, warnings and skipped files, and rerun repairs where the log shows they are needed. Test each custom module and workflow against a list of expected results written before the change window. Keep the backup and the rollback procedure available until the business has accepted the instance in production.
Is upgrading to 7.15 wasted effort if we migrate later?
No. The SuiteCRM migration documentation says the SuiteCRM 7 instance should first be brought to the latest 7.14.x or later before the move to SuiteCRM 8, so 7.15 meets that step. The upgrade also gives you a supported security baseline while you plan the migration. Much of the work carries over: the backup routine, the customization inventory, the staging environment and the test scripts are needed for either path. The SuiteCRM 8 migration still requires a new environment and a move of your data, so budget for that separately. Ask any implementation partner to show how the upgrade work will feed the migration plan in the written scope.
How DeployOpen scopes, delivers and supports the SuiteCRM 7 upgrade
DeployOpen plans the move of an existing SuiteCRM 7 instance to the 7.15 extended support release as a fixed-scope engagement inside your own infrastructure. The work starts with a written scope, moves through a staging rehearsal with backups and a customization review, and ends with documented handover and optional retainer support.
How we scope
- The written scope names the source SuiteCRM 7 instance, the 7.15 target release and the environments involved.
- Scope covers a staging rehearsal, backups of files and database, and a review of custom code and extensions.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any upgrade work starts.
How we build
- Upgrade steps run from the command line, with permission fixes and repairs applied and recorded in order.
- The rehearsal runs on a staging copy, so production changes only after the steps are verified.
- Custom files are reviewed before the change, because SuiteCRM's migration guidance warns that non-core files under public/legacy may be removed.
How we hand over
- Handover includes a record of the versions, commands run, permission changes and repairs made on your instance.
- Rollback steps and the verified backup set are documented, so your team can restore the prior state if needed.
- Your team receives a runbook and notes on the period 7.15 security fixes cover, which runs until January 2028.
How we support
- Ongoing support, upgrades and testing are available as a retainer after handover.
- Before handover, ask us to confirm which 7.x release notes and security fixes your team should track.
- Patch review and planning for SuiteCRM 8 can be included in a retainer, scoped in writing.
