SugarCRM end of support: 26.1 only buys a year

SugarCRM end of support for on-site Sugar 25.1.x lands on 30 April 2027, and the obvious fix, upgrading to 26.1, only moves the cliff to 30 April 2028. If you run a heavily customised Sugar Sell or Sugar Enterprise instance on your own servers, the real decision is not "upgrade or not". It is whether to keep buying one year at a time.

By the end of this post you will know exactly what the dates are, what the 26.1 upgrade actually demands of your stack and your custom code, and how to price staying on-site against SugarAI's cloud and against replacing the CRM layer with one you own. As of 10 November 2026, that is 171 days of runway on 25.1.

The SugarCRM end of support dates, as SugarAI publishes them

SugarCRM now trades as SugarAI, and its support site has moved with it: old support.sugarcrm.com links redirect to support.sugarai.com. The authoritative source is the Supported Versions page, which is undated and says to check it regularly. Here is what it lists today.

On-site version	End of support	Status on 10 November 2026
Sugar 14.0.x	30 April 2026	Already unsupported
Sugar 25.1.x	30 April 2027	171 days left
Sugar 26.1.x	30 April 2028	Current on-site release

Each row covers Sugar Sell Premier, Advanced, Standard and Essentials, Sugar Serve, Sugar Enterprise and Sugar Enterprise+. The plan also covers "All On-Site Sugar products and versions, SugarCRM mobile solutions, and the Sugar Plug-ins, connectors, and extensions", so your mobile app and connectors age out with the core. The page is blunt about the rest: "Versions earlier than 25.1 are no longer supported."

How long is a SugarCRM version supported?

A SugarCRM on-site version gets "18 months of full maintenance and security support followed by 6 months of security-only support", so 24 months in total, with the last six months as a security-only support period. The dates in the table are each exactly a year apart, which is what you would expect from one on-site release a year.

What happens when SugarCRM support ends

After 30 April 2027, SugarAI says it "will no longer provide customer support, maintenance patches, or issue fixes" for 25.1.x. Patches already published on that date stay downloadable, but no new packages are produced. The software keeps running. What stops is the flow of security fixes for a system that usually holds your entire customer and pipeline history.

That distinction matters for how you argue the budget. End of support does not switch the software off on 1 May 2027. The risk is the first vulnerability disclosed after that date, and the audit or customer security questionnaire that asks whether your CRM is on a vendor-supported version. If your compliance posture requires supported software, the deadline is hard. If it does not, you are choosing how long to carry unpatched exposure, and that should be a written decision, not a default.

Is SugarCRM on-premise being discontinued?

No. SugarAI still ships on-site releases: 26.1 is available on-site and supported to April 2028. But the cadence is lopsided. The 25.2 release was cloud-only, and the 25.2 developer migration guide states plainly that "On-premise customers must wait until Sugar 26.1". SugarCloud instances, per the Supported Versions page, are "Always on the latest release". On-site customers get one release a year and do the upgrade themselves.

Why 26.1 only buys twelve months

The upgrade to 26.1 extends your support window from 30 April 2027 to 30 April 2028: twelve months, in exchange for a full upgrade project. If the yearly pattern in the table holds, staying on-site means repeating that project every year, each time against a release that has absorbed a cloud-only release's worth of change you have not seen yet.

That last point is documented, not speculative. The 26.1 developer migration guide warns that anyone upgrading from 25.1 "will be catching up with additional content released in the 25.2 cloud-only Sugar release." Your developers are effectively doing two releases of review in one upgrade.

Upgrade SugarCRM 25.1 to 26.1: what the guide requires

The 26.1 Installation and Upgrade Guide sets out a narrow path:

1. Get to 25.1.3 first. "Only instances running 25.1.3 are eligible for upgrade to the latest version 26.1.0." If you are on 25.1.0, 25.1.1 or 25.1.2, there is a patch step before the real one.
2. Pass the health check. The scanner runs as part of the upgrade, and a failed check blocks it. A yellow result means customisations may keep some modules on the legacy user interface.
3. Prove your code is upgrade-safe. Code-level changes must live in the custom directory "or they may be removed during the upgrade."
4. Pick the right upgrader. With more than 10,000 records per table, SugarAI recommends the command-line Silent Upgrader rather than the Upgrade Wizard. Check your largest tables, usually emails and activity history, before you plan the weekend.
5. Back up and rehearse. The guide asks for a file and database backup and a test run on a copy of production first.

The platform shift underneath 26.1

The upgrade must run on "a PHP version that is supported by both the source and target Sugar releases." Compare the two supported-platform pages and the overlap is narrow:

Component	Sugar 25.1.x	Sugar 26.1.x
PHP	8.3, 8.4	8.4, 8.5
MySQL	8.0.31, 8.4	8.4
Oracle (Enterprise only)	19, 23	19, 26
OpenSearch	2.7, 2.19	2.19, 3.3
Elasticsearch	8.x	8.x, 9.x

Sources: 25.1.x Supported Platforms and 26.1.x Supported Platforms. If your 25.1 server runs PHP 8.3 or MySQL 8.0, you have an infrastructure upgrade to do before the application upgrade can start. That is the same PHP pressure we walked through in upgrading PHP to 8.4 or 8.5, now arriving through your CRM vendor's support matrix.

Functional changes your users will notice

SugarAI's What to Expect When Upgrading to 26.1 note lists changes that touch customised estates directly. The dropdown editor moves to the Sidecar interface. Sugar Self-Service Center is gone and "the 'kiosk' API platform has been removed." SMTP Auth is no longer supported for Exchange Online, so outbound email settings need changing. The Intelligence add-on is now built in, and admins must assign its licence to users after upgrading. Anything you built on the removed pieces needs a replacement, not a retest.

Point releases deserve the same caution. The 25.1.0 release notes told on-site Sugar Market customers not to install 25.1.0 at all and to go to 25.1.1 instead "to avoid data loss". An upgrade plan that does not read every release note between your version and the target is a plan to find out in production.

Should we upgrade SugarCRM or migrate? Three honest routes

Every route has a real cost. We are not going to put numbers on them, because the inputs are yours: seat count, licence tier, the size of your custom directory and how many integrations touch the CRM. What we can do is name the cost lines, so the comparison is like for like.

Route	What you pay for	What it does not fix
Stay on-site, upgrade to 26.1	Patch to 25.1.3, PHP/MySQL/search upgrades, health-check remediation, retest of custom code and integrations; repeated each year	The yearly cycle and the cloud-only releases you catch up on
Move to SugarAI cloud	Subscription change, data move, rework of customisations the hosted platform will not accept	Vendor dependency; Sugar Enterprise itself is on-site only
Rebuild the CRM layer	Discovery, build, CRM data migration, user retraining	Nothing for free: you own maintenance from day one

The case for upgrading, in its strongest form

For many teams, 26.1 is the right call, and it is worth stating why. Your users know Sugar. Your data model, workflows and reports already work. A one-year upgrade, done carefully, is a bounded project with a vendor guide, a health-check scanner and a support case portal behind it. Replatforming a CRM is a far bigger change, and the worst outcome, a half-migrated system with two sources of truth, is worse than an old-but-supported one.

If your customisations live cleanly in the custom directory, your infrastructure already runs PHP 8.4, and the health check comes back green, upgrade. The deadline is then an annual maintenance line, not a strategic question.

When the cloud is the cleaner answer

SugarCloud removes the yearly on-site project, because, per SugarAI's 26.1 upgrade note, "All instances hosted on Sugar's cloud service will be upgraded to 26.1." The catch for larger customers is in the release notes: "Sugar Enterprise is supported as an on-site deployment only." Our reading is that, for an Enterprise customer, a cloud move is a product change as well as a hosting change, and it should be scoped with SugarAI as such before anyone assumes it is a lift-and-shift.

When rebuilding the CRM layer wins

Replacing Sugar makes sense when the customisations are the product: when the Module Loader packages, Studio changes and custom code encode workflows that are specific to how you sell, quote or service, and every upgrade is mostly spent protecting them. In that case you are already paying to maintain custom software, just inside someone else's release cycle. We made the per-seat version of this argument in HubSpot vs custom CRM seat maths; the on-site Sugar version adds a fixed yearly upgrade cost to the same equation.

This is the wrong choice if your Sugar estate is mostly stock with a few fields added. A rebuild will not pay for itself against a clean annual upgrade, and you should not let a deadline talk you into one.

Customisation and data-migration risk, whichever route you pick

The same inventory decides all three routes, so do it before you choose:

• Every file outside the custom directory, because the 26.1 guide says those changes may be removed.
• Every installed package and connector, because the Supported Versions page says only the latest version of supplemental connectors and module-loadable packages is supported.
• Every integration that calls the REST API, which is at version 11_27 in 26.1 according to the migration guide.
• Every feature on the 26.1 removal list: Self-Service Center, the kiosk API, Exchange Online SMTP Auth.
• Row counts per table, which decide your upgrader and, in a migration, your cutover window.

If the inventory is short, upgrade. If it is long and most of it is business logic rather than configuration, you have a custom CRM already, and the question is only who maintains it. We dealt with the same version-by-version arithmetic for Microsoft's on-premise CRM in Dynamics 365 on-premise end of life, and the pattern holds: the date forces the decision, but the custom code determines the cost.

Before 30 April 2027: pick the route, then budget it

With 171 days left on 25.1 as of 10 November 2026, the sequence is fixed: run the customisation inventory, check your PHP and database versions against the 26.1 matrix, run the health check on a copy of production, and only then choose. If you are still on 25.1.0 to 25.1.2, schedule the 25.1.3 patch now, because nothing else can start until it is done.

We have built a CRM from the ground up, an AI-powered sales CRM and sales engagement platform with a market intelligence engine and 360° customer lifecycle coverage, so we know what owning that layer involves. We have not run a SugarCRM migration, and we will say so in any scoping conversation. If your inventory says the custom code is the product, our CRM development team can scope a rebuild of the CRM layer against the cost of another on-site Sugar upgrade cycle, so you choose between two priced options before the 30 April 2027 deadline rather than after it.