Should you stay on SuiteCRM 7 or move to SuiteCRM 8?
Stay on SuiteCRM 7.15 while its extended support lasts if your change capacity is limited, and move to SuiteCRM 8 if the platform's direction matters to you and your customizations can be rebuilt. SuiteCRM 7.15 is an extended support release with security fixes until January 2028, according to the SuiteCRM LTS page. That date gives a team with a heavily customized instance time to plan, but it does not settle the question. No SuiteCRM 8 extended support release has been nominated yet, and SuiteCRM expects to name one by Q3 2027, so confirm that date with SuiteCRM before you commit to a long-term 8 roadmap.
The decision turns on four things. The first is customization volume: count the custom modules, logic hooks, templates and integrations on the 7 instance, and ask which can be rebuilt on SuiteCRM 8 and which should be retired. The second is identity. SuiteCRM 8 offers LDAP through AUTH_TYPE=ldap and SAML through AUTH_TYPE=saml, and the 8.7.0+ SAML implementation does not support IdP-initiated logout, so test whether a logout at your identity provider ends the SuiteCRM session. The third is staff skills in PHP and the hosting stack, since the 8.10 compatibility matrix lists PHP 8.2 to 8.4 with MariaDB or MySQL. The fourth is funding: confirm with your business how much migration effort it will pay for before choosing a date.
Treat the move as a migration, not an upgrade. The SuiteCRM migration guide describes setting up a new SuiteCRM 8 environment and moving the 7 data into it, with the 7 instance first brought to 7.14.x or later. Build and test the target on a staging instance, back up files and the database, and review every customization before cutover, because the migration may remove non-core files under the public/legacy folder. A practical first step is an inventory of customizations, sorted into rebuild, replace or retire, followed by a written migration plan that your business has funded.
Which scenarios favor staying on 7 and which favor 8
This table maps common SuiteCRM situations to the release line that fits them better, and names the condition that drives each choice. Read each row against your own customization inventory, identity requirements and support needs, because the extended support answer for SuiteCRM 8 is not settled yet.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Lightly customized 7 instance with a stable team | Stay on 7 for now | Core-only or minimally modified 7.15 keeps the upgrade simple, and SuiteCRM 7.15 has security fixes until January 2028. Plan the migration into a dated window rather than waiting for the deadline. |
| Heavily customized 7 instance | Plan the move to 8, starting with an audit | Custom code in the public/legacy area may not survive the migration, so the rebuild effort rises with each customization. Confirm which changes must be re-implemented as 8 modules before committing a date. |
| Need for SAML or LDAP sign-in | Favors 8 if the identity setup is a hard requirement | SuiteCRM 8 supports LDAP (AUTH_TYPE=ldap) and SAML (AUTH_TYPE=saml). Confirm which sign-in options your 7 instance already uses, and test logout behavior, since the 8.7.0+ SAML implementation does not end the SuiteCRM session when logging out at the identity provider. |
| New deployment with no legacy data | Favors 8 | Without a 7 dataset, there is no migration to run, and the 8 line receives the current minor releases, including 8.10.2 released July 31, 2026. Confirm the PHP, MariaDB or MySQL versions your hosting platform supports against the 8.10 compatibility matrix. |
| Team that must have a long-term support answer | Stay on 7 until 8 has a named extended release | SuiteCRM 7.15 is an extended support release with security fixes until January 2028. No SuiteCRM 8 extended support release had been nominated yet, and SuiteCRM expects to name one by Q3 2027. Ask SuiteCRM for the current position in writing before you rely on it. |
| Team that needs a fixed migration plan with a staging test | Either line, with a migration project | Moving from 7 to 8 is a migration with a new environment and data move, not an in-place upgrade. Ask for a written scope covering staging tests, backups and customization review before work starts. |
How SuiteCRM 7 and 8 are built and what that means for operations
SuiteCRM 7 and SuiteCRM 8 share a name and a license, but they are separate products with their own runtimes, requirements and release rhythms. Each card below covers one operational difference you need to check before choosing a line or running both during a transition.
Separate runtime and PHP requirements
SuiteCRM 8.10.x supports PHP 8.2, 8.3 and 8.4 on Apache 2.4. SuiteCRM 7 is a different codebase with its own platform requirements, so a server built for 8 cannot be assumed to run 7. Check the 7.15.2 requirements separately against your current PHP build, extensions and web server before you plan any shared host or image.
Database versions to confirm
The 8.10.x matrix lists MariaDB 10.6, 10.11, 11.4 and 11.8, and MySQL 8.0 and 8.4. Your existing SuiteCRM 7 database may run on a version that appears in neither list or that your DBA has already moved past. Confirm the 7 requirements and the target 8 versions together, because a database upgrade made for one line can block the other.
Different release cadence
SuiteCRM 8 minor releases arrive roughly every eight weeks, so an 8 instance needs a standing plan for regular minor upgrades. SuiteCRM 7.15 is an extended support release with security fixes until January 2028, which lets a team stay on 7 with a fixed end date. Decide which cadence your team can staff before choosing a line.
Patch releases carry fixes only
SuiteCRM 8 patch releases contain only security and bug fixes, with no new features and no database changes. This makes patch windows easier to approve and test. Minor releases are different, so a plan that treats every update the same will either delay security fixes or run untested changes in production.
Two stacks during a transition
Moving from 7 to 8 is a migration: a new 8 environment is built and 7 data is moved into it. While both run, you maintain two PHP versions, two sets of patches and two sets of backups. Budget for dual operation and agree on a cutover date, because a parallel run that drags on doubles the on-call and testing work.
Hosting footprint and staging
Because 7 and 8 differ in runtime and database needs, a staging instance for the migration is usually a second full environment, not a copy of the production host. Ask whether your hosting platform can run both lines side by side, and confirm the staging hardware, backup storage and network access your team will need before the work starts.
How the two lines compare on support, identity and release rhythm
This table sets SuiteCRM 7 and SuiteCRM 8 against the factors that decide whether a team can stay put or must migrate, including license, current versions, support windows, release cadence, login options and the migration path. Read each row as a question to answer for your own environment, and treat the support row as the one that sets your deadline.
| Factor | SuiteCRM 7 | SuiteCRM 8 |
|---|---|---|
| License | AGPL-3.0 per the LICENSE file in the SuiteCRM repository | AGPL-3.0 per the LICENSE file in the SuiteCRM-Core repository |
| Latest version | 7.15.2, released July 31, 2026 | 8.10.2, released July 31, 2026 |
| Support status | 7.15 is an extended support release with security fixes until January 2028 | No extended support release nominated yet; SuiteCRM expects to name one by Q3 2027 |
| Release rhythm | Maintained as the extended support line for security fixes | Minor 8.x releases arrive roughly every eight weeks; patches contain only security and bug fixes |
| Login options | Confirm the LDAP and SAML options available in your 7.15 build with your own configuration | LDAP via AUTH_TYPE=ldap and SAML via AUTH_TYPE=saml, built on Symfony and onelogin-saml-bundle |
| SAML logout | Confirm against your 7.15 setup before relying on single logout | From 8.7.0, IdP-initiated logout is not supported, so IdP sign-out does not end the SuiteCRM session |
| Migration path | Bring the 7 instance to the latest 7.14.x or later before moving | Migration to 8 is a new environment with 7 data moved in, not an in-place upgrade |
| Runtime requirements | Confirm PHP and database versions for 7.15 in its own documentation | PHP 8.2, 8.3 or 8.4; MariaDB 10.6, 10.11, 11.4 or 11.8; MySQL 8.0 or 8.4; Apache 2.4 |
What is free, what is paid and what SuiteCRM Ltd sells
SuiteCRM 7 is free to download and self-host under AGPL-3.0, the same license that covers SuiteCRM 8. The current release is 7.15.2, published alongside SuiteCRM 8.10.2 on July 31, 2026. Cost comes from the people and infrastructure that run it, not from the software itself. The line is the one to weigh first when the support window matters more than new features.
- Extended support window: SuiteCRM 7.15 receives security fixes until January 2028, according to SuiteCRM's LTS page.
- No license fee: Using, modifying and self-hosting the code carries no license charge under AGPL-3.0.
- Your own operating cost: Hosting, PHP and database upkeep, backups and patching fall to your team or to a partner you hire.
- Migration still ahead: Moving off 7 means a migration to a new 8 environment, not an in-place upgrade.
Before you commit, confirm with SuiteCRM Ltd exactly which fixes the 7.15 window covers and what happens to the line after January 2028.
SuiteCRM 8 is also free under AGPL-3.0 and can be self-hosted on your own infrastructure. The current release is 8.10.2. SuiteCRM 8 minor releases arrive roughly every eight weeks, which means the line moves faster than 7 and asks more regular upkeep from the team that runs it. Patch releases contain only security and bug fixes with no new features or database changes.
- Frequent minor releases: Expect a minor release about every eight weeks, each requiring a test and rollout cycle.
- Patch-only maintenance: Patch releases carry security and bug fixes, with no new features or database changes.
- Supported stack: The 8.10 compatibility matrix lists PHP 8.2, 8.3 and 8.4, MariaDB 10.6, 10.11, 11.4 and 11.8, MySQL 8.0 and 8.4, and Apache 2.4.
- No extended support release yet: SuiteCRM has not nominated an 8 extended support release and expects to name one by Q3 2027.
Confirm that your hosts and database versions match the compatibility matrix before you plan a rollout.
SuiteCRM Ltd maintains the software and sells services around it. Those services are separate from the license, so you pay for them only when you want the vendor or a partner to take on a part of the work. The published list includes SuiteASSURED support, SuiteCRM Hosted, implementation, training and migration services. Each is a contract choice, and none changes the AGPL-3.0 terms of the code.
- SuiteASSURED support: A support package for organizations that want a contracted support route.
- SuiteCRM Hosted: A hosted option run by SuiteCRM Ltd instead of your own infrastructure.
- Implementation and training: Set-up, configuration and user training delivered as a service.
- Migration services: Help moving a 7 instance into a new 8 environment, which the documentation treats as a migration project.
Ask for a written scope, the deliverables, the support hours and the response commitments before signing. Price quotes should state what is one-time work and what recurs each year.
The license does not separate the two lines, so the difference lies in support timing, operating effort and the cost of moving between them. A team on 7 pays the lower near-term effort of staying put, but it accepts a fixed end to security fixes and a later migration. A team on 8 accepts faster releases and a more frequent patch rhythm, and gains a line that continues to evolve. Compare the two on the dates and effort, not on the license text.
- Support window: The 7 line has a published end of security fixes, while the 8 line has no extended release nominated yet.
- Release rhythm: The 8 line changes more often, which increases routine testing.
- Migration cost: Moving to 8 is a project with staging, backups and customization review.
- Vendor services: Support and migration help are optional purchases from SuiteCRM Ltd or other partners.
When you request quotes, ask how each option is priced and how long each service is committed to run.
How customizations are at risk during the move
The move from SuiteCRM 7 to SuiteCRM 8 is a migration, not an upgrade. SuiteCRM documents it as a new SuiteCRM 8 environment that is built from scratch, with the SuiteCRM 7 data moved into it, and the 7 instance must first be brought to the latest 7.14.x or later. That means your custom modules, logic, templates and file changes do not carry over by running an in-place upgrade. Each one has to be found, judged and either rebuilt on the SuiteCRM 8 architecture or retired. Treat the migration as a rebuild of everything you changed, not as a version bump.
The scope of that rework depends on how much the instance was customized, and only you can measure it. Before you plan any work, inventory every custom module, field, workflow, logic hook, theme change, integration script and any file you edited under the public/legacy folder. The SuiteCRM migration docs warn that the migration may remove non-core files in that folder, so any custom code stored there is at direct risk. Record who owns each item, which business process depends on it and whether an equivalent already exists in the SuiteCRM 8 core. Items with no owner or no current use are candidates to drop rather than port.
Test the migration on a staging instance before any production cutover, and take full backups of both files and the database first. The SuiteCRM migration guidance and the related pre-migration checklist are the natural next read. Use the staging run to compare record counts, custom fields, reports and integrations against the 7 instance, and to confirm that users can log in with the identity method you plan to keep. Ask your implementation partner or SuiteCRM Ltd to confirm in writing which of your customizations will be rebuilt, which will be dropped and how long validation will take, because those answers, not the version numbers, set the real cost of the move.
The order of work for a 7 to 8 migration
This sequence moves a SuiteCRM 7 instance into a new SuiteCRM 8 environment in a way that keeps the live system running until the copy has been tested. Each step closes with a check that tells you whether the next one can start.
Inventory customizations and integrations first
The administrator and a developer list every custom module, logic hook, theme change, scheduled job, report, and external integration on the SuiteCRM 7 instance, and note which files sit outside core. This list decides how much rebuild work the project carries, so it should be complete before any other step begins. Done means each item is marked as keep, rebuild, retire, or confirm with the vendor. Ask SuiteCRM which of your items map to SuiteCRM 8 features before you assume they carry over.
Bring the 7 instance to 7.14.x or later
Before any migration work, the SuiteCRM 7 instance is brought to the latest 7.14.x or later release, as the migration documentation requires. The team applies the in-version upgrade procedure on the existing environment and retests core workflows afterward. Done means the instance runs the required version and the team has recorded the version number. Confirm the exact minimum version in the migration guide before you start, since that document is the authority for this requirement.
Back up files and database
The operator takes a full backup of the SuiteCRM 7 file system and database, and stores it outside the production host. This includes the public/legacy folder, because the migration may remove non-core files from that location. Done means a restore has been tested on a separate machine and the team can open the restored instance and log in. Confirm backup and restore steps against the before-you-migrate guidance so nothing is missed.
Build a staging SuiteCRM 8 environment
The infrastructure or platform team sets up a new SuiteCRM 8 environment that is separate from production, using a supported PHP, MariaDB or MySQL, and Apache combination from the compatibility matrix for the release line you have chosen. This is a new installation, not an in-place change to the 7 instance. Done means the environment installs cleanly and the team has recorded the exact versions in use. Confirm the current compatibility matrix before you pick versions, because the supported list changes between releases.
Move and test the data
The team moves the SuiteCRM 7 data into the staging SuiteCRM 8 environment following the migration guide, then checks record counts, user accounts, permissions, and attachments against the source. Business owners test sample workflows for accounts, leads, opportunities, and cases. Done means the reconciliation report matches the source for each module and every sign-off owner has accepted the test results in writing. Any gaps go back to the list from the first step.
Rebuild customizations on the new platform
A developer rebuilds each item marked as rebuild using SuiteCRM 8 mechanisms, not by copying 7 code forward, and retires items that the business no longer needs. Integrations are re-pointed and tested against the staging instance. Done means every item on the inventory has a documented outcome and each rebuilt integration passes a test that the business owner has reviewed. Ask SuiteCRM for guidance on the supported extension points before you commit to an approach.
Configure identity and test logout behavior
The identity team configures sign-in on staging using LDAP through AUTH_TYPE=ldap or SAML through AUTH_TYPE=saml, depending on the directory in use. They then test login, password policy, role mapping, and logout from both SuiteCRM and the identity provider. Done means test accounts sign in and out as expected, and the team has documented that IdP-initiated logout does not end the SuiteCRM session in the SAML configuration. Confirm the current SAML and LDAP settings in the configuration references before go-live.
Cut over with a rollback plan
The team agrees a cutover window, freezes changes on the SuiteCRM 7 instance, runs a final data move, and repeats the reconciliation checks before users are switched. A rollback plan states who decides to revert, which backup restores the 7 instance, and how users are told. Done means the business signs off on the production checks, the 7 instance remains available in read-only form for a set period agreed by the owners, and the rollback steps have been rehearsed on staging.
Where SuiteCRM migration projects usually run long
Migration projects from SuiteCRM 7 to SuiteCRM 8 run long for two reasons: the customization inventory is incomplete when scoping starts, and the team has not yet worked with the 8 architecture. Because the SuiteCRM documentation treats the move as a migration with its own guide, the work is a rebuild on a new platform, not an in-place upgrade. Before you sign a fixed scope, ask the provider to list every custom module, vardef and logic hook, workflow, report, custom template, integration and LDAP or SAML dependency from the 7 instance, and to say which of them will be rebuilt, which retired and which kept. Ask them to check the 7 instance against the migration guide's advice on the public/legacy folder, since the migration may remove non-core files there. Items missing from that inventory are where change requests start.
Infrastructure is the second source of effort. You need a new SuiteCRM 8 environment on Linux, Unix or macOS with a PHP version from 8.2, 8.3 or 8.4, Apache 2.4, and a database from the 8.10 compatibility matrix, such as MariaDB 10.6, 10.11, 11.4 or 11.8, or MySQL 8.0 or 8.4. Confirm whether your existing PHP and database versions are on that list, because aligning them can touch other applications on the same servers. Identity integration is a separate workstream: if you use LDAP or SAML, the AUTH_TYPE settings, attribute mappings and logout behavior must be tested in the new environment, and the SAML limits on IdP-initiated logout should be reviewed with your security team. Plan user acceptance testing against real pipelines, reports and approval flows, and agree in writing who signs off each one and who fixes defects found afterward.
Ask providers to show the staffing they will use for the 8 architecture, and whether the people who rebuild your modules will also support them after go-live. Ask what staging test cycles are included, how many rounds of acceptance testing the fixed scope covers, and what data cleansing and migration validation are their responsibility versus yours. Your own team should record the business processes that depend on the 7 customizations now, because those records are the basis for acceptance criteria. Any timeline a provider gives should be tied to that inventory and the agreed test rounds, not to a generic estimate.
Questions buyers ask before choosing a SuiteCRM line
How long do SuiteCRM 7.15 security fixes last?
SuiteCRM 7.15 is an extended support release that receives security fixes until January 2028, according to the SuiteCRM LTS page. That date is the practical deadline for a 7 instance that cannot move yet. Plan the migration backward from it, allowing time for staging tests, customization review and user acceptance. Confirm the date against the SuiteCRM LTS page before you set internal deadlines, since release lifecycle pages can change.
Will SuiteCRM 8 get an extended support release?
No SuiteCRM 8 extended support release had been nominated when this was researched. SuiteCRM expects to name one by Q3 2027. Until then, 8.x minor releases arrive roughly every eight weeks, and patch releases carry only security and bug fixes. If you need a long support window on 8, ask SuiteCRM Ltd in writing which release it will designate and how long it will receive fixes, and compare that answer with your own change calendar.
Can I upgrade SuiteCRM 7 to SuiteCRM 8 in place?
No. SuiteCRM documents the move from 7 to 8 as a migration, not an in-version upgrade. You set up a new SuiteCRM 8 environment and move the SuiteCRM 7 data into it, after bringing the 7 instance to at least the latest 7.14.x release. Treat the project as a rebuild of the application layer with data transfer, not a version bump on existing servers.
What drives the cost and effort of a SuiteCRM 7 to 8 migration?
The largest drivers are the volume and type of customizations, the number of integrations, the identity setup and the testing scope. Custom modules, logic hooks and templates usually need to be rewritten or re-tested rather than copied. Each integration with email, telephony, ERP or a data warehouse needs its own check. Identity work depends on whether you use LDAP or SAML. Testing covers data accuracy, permissions and reports. Ask any provider to price each of these areas separately, and state which parts are one-time (migration, rebuild, testing) and which recur (hosting, patches, support).
Can our team run the SuiteCRM 8 migration without outside help?
It depends on two things: your team's PHP and database skills, and how large your customization set is. The documentation expects a staging environment, full file and database backups, and a review of customizations, since the migration may remove non-core files under the public/legacy folder. A team that already runs PHP applications on MySQL or MariaDB can handle a small instance with few customizations. A large instance with many custom modules, integrations and SSO requirements usually needs a scoped plan and someone accountable for testing. Ask yourself who will own the rollback if the cutover fails.
What should we ask a provider to include in a written migration scope?
Ask for an itemized scope that names the source 7 version, the target 8 release, the customizations in scope and the ones excluded, and each integration and identity method to be reconnected. Request the staging, backup and rollback approach, the test plan with acceptance criteria, the data that will be moved and what will be discarded, and the cutover and post-go-live support period. Confirm who performs each task, what the client must supply, and how changes after sign-off are priced. Fixed-scope engagements agree these items in writing before work starts.
Does SSO carry over when we move to SuiteCRM 8?
Not automatically. SuiteCRM 8 supports LDAP through the AUTH_TYPE=ldap setting and SAML through AUTH_TYPE=saml, so you must configure and test the method you choose on the 8 instance. Note that the 8.7.0 and later SAML implementation does not support IdP-initiated logout or POST binding to the logout service, so signing out at the identity provider does not end the SuiteCRM session. Include this limit in your security review and in user communications before go-live.
Where to confirm SuiteCRM support and migration details
Before you commit to staying on SuiteCRM 7 or moving to SuiteCRM 8, check the official SuiteCRM LTS and release lifecycle page. It confirms that the SuiteCRM 7.15 extended support release receives security fixes until January 2028. It also states that no SuiteCRM 8 extended support release has been nominated yet, and that SuiteCRM expects to name one by Q3 2027. Record that date in your plan. If your customizations will not be ready for SuiteCRM 8 by then, you are choosing between an unnominated line and a 7.15 window that ends, so ask for the current status in writing from SuiteCRM Ltd or your partner before you set a deadline.
The compatibility matrix in the SuiteCRM documentation is the authority for the platform you will run. Confirm that your PHP, MariaDB or MySQL, and Apache versions appear in the matrix for the SuiteCRM 8 release you plan to deploy, and that your operating system is Linux, Unix or macOS. Then check the GitHub release pages for SuiteCRM-Core and SuiteCRM, which show the latest versions and their publication dates. Both 8.10.2 and 7.15.2 were published on July 31, 2026, and minor 8.x releases arrive roughly every eight weeks. Confirm the current patch level on the day you build the staging environment, not the version in this page.
The migration guide, *Migrating from SuiteCRM 7*, in the SuiteDocs repository defines the work. SuiteCRM treats the move as a migration into a new SuiteCRM 8 environment, not an in-place upgrade, and the 7 instance must first reach the latest 7.14.x release or later. Confirm that minimum in the guide, then test on a staging instance with full file and database backups. Review every customization, because the migration may remove non-core files under the public/legacy folder. Ask your implementation partner to list those files for your instance before cutover, and confirm who signs off on the staging results.
How DeployOpen helps choose and migrate SuiteCRM
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For SuiteCRM 7 vs SuiteCRM 8, we start by mapping your customizations and integrations against the migration path before anyone commits to a move.
How we scope
- We inventory your SuiteCRM 7 instance, customizations, integrations and login setup before recommending a path.
- Scope, deliverables and timelines for the 7 to 8 decision or migration are agreed in writing before work starts.
- We confirm which extended support window applies to your 7.15 deployment and document the dates to plan around.
How we build
- We set up a new SuiteCRM 8 environment in your infrastructure and move the SuiteCRM 7 data into it.
- We review each customization that may sit under the public/legacy folder and rebuild or retire it deliberately.
- We test on a staging instance and configure LDAP or SAML sign-in, including how logout behaves in your identity provider.
How we hand over
- We back up files and the database before any migration step, and document the restore procedure.
- We deliver written runbooks covering the migration steps, configuration keys, customizations and open risks.
- We walk your administrators through the 8.x release cadence and what changes in each patch and minor release.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after go-live.
- We can plan future 8.x minor and patch upgrades against your staging environment and change window.
- Ask us to confirm the support path for any SuiteCRM 8 extended support release before you commit to a date.
