SugarCRM on-site end of support: upgrade, SugarCloud or replace

Why a Sugar on-site support window forces a decision now

If you run Sugar on your own servers and your version is near or past end of support, you have three paths: take the vendor's releases on its cadence, move to SugarCloud, or replace Sugar with a self-hosted open-source CRM that you control. Options that keep customer records and attachments on your infrastructure are staying on-site with upgrades or moving to self-hosted SuiteCRM or EspoCRM. SugarCloud moves hosting to the vendor. Before you plan anything, get Sugar's current on-site support dates for your exact version in writing, along with what security fixes remain after that date.

The choice depends on three things: data residency (where records, attachments and backups must sit under your policies and contracts), change control (how quickly your change board can absorb major upgrades and test them on staging), and staffing (who patches the operating system, PHP and the database, runs backups and restores, and handles integrations). Open-source lifecycles differ, so compare them directly. SuiteCRM 8.x minor releases arrive roughly every eight weeks, and patch releases carry only security and bug fixes, so each cadence needs a planned test cycle. SuiteCRM 7.15 receives security fixes until January 2028, and no SuiteCRM 8 extended support release has been nominated yet. Ask every vendor for the same written lifecycle.

If control over data location is the constraint, keep the platform on-site: either upgrade inside the vendor's window if your team can staff the work, or move to a self-hosted open-source CRM where you set the release schedule. SugarCloud reduces infrastructure work, but your data then sits in vendor hosting, so verify residency terms in the contract. Whatever you pick, start with an inventory of your Sugar version, customizations, integrations and users. Note that moving from SuiteCRM 7 to 8 is a migration rather than an in-place upgrade, which takes longer to plan than a routine patch.

What staying on-site requires from you

Running Sugar on your own servers means you carry the version, platform and access decisions that SugarCloud otherwise makes for you. The cards below set out what each of those obligations involves, so you can judge whether your team can keep up with them.

A supported version on a fixed cadence

An on-site Sugar instance only receives fixes while its version is inside Sugar's support window, so the first question is which release you run and when its support ends. Ask Sugar for the written end-of-support date for your version and for the upgrade path it expects. If you move to SuiteCRM instead, the 8.x line ships minor releases roughly every eight weeks, and patch releases carry only security and bug fixes. Plan a standing staff slot to absorb that rhythm, not a one-off project.

A supported PHP, web server and database stack

Each upgrade can move the platform under the application. SuiteCRM 8.10 supports PHP 8.2, 8.3 and 8.4, Apache 2.4, MariaDB and MySQL on Linux, Unix or macOS. EspoCRM expects PHP 8.3 to 8.5 and MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15. Confirm Sugar's own compatibility list for your release, then check that your operating system packages still provide the versions you need before you commit to a target.

A tested staging path before every upgrade

Production should never be the first place a new version runs against your data and customizations. The SuiteCRM migration guidance recommends a staging instance, a full file and database backup, and a review of customizations, because a migration may remove non-core files under the public/legacy folder. Budget time for regression testing of workflows, reports and integrations on staging, and keep a tested rollback path for every change window.

Identity integration that must keep working

Most on-site Sugar instances authenticate against a directory or identity provider, and each upgrade can break that link. SuiteCRM 8 supports LDAP through AUTH_TYPE=ldap and SAML through AUTH_TYPE=saml, and its SAML implementation at 8.7.0 and later does not support IdP-initiated logout, so signing out at the identity provider leaves the CRM session open. Test sign-in, group mapping and logout on every release, and confirm the same behavior on whichever platform you choose.

Scheduled jobs and background processing

On-site CRMs depend on background work such as email sync, scheduled reports and workflow runs, and those jobs stop silently when a cron entry or scheduler is misconfigured after a move. EspoCRM requires cron or a scheduled task for background jobs, so the server design has to include that process from the start. Ask Sugar which jobs your instance runs, and verify each one after every change window.

Three paths when your Sugar version loses support

Your team, or a services firm working under a written scope, keeps the Sugar instance on your own servers and applies each supported release as it arrives. You keep the database, file store, configuration and the decision of when changes go live. The work recurs: every release needs a backup, a test on staging and a production change window, so the main cost is staff time plus the spare environment needed for testing.

Who runs it: your platform or application team, or a partner engaged for the upgrade cycle.
What stays with you: the database, attachments, network placement, change approvals and the timing of each release.
What recurs: applying each release, re-testing customizations and confirming that your operating system, PHP and database versions are still on the vendor's supported list.
What is one-time: building the staging environment, writing the upgrade runbook and documenting the custom code.
Main risk: falling behind the support window. Once a version drops out of support, security fixes stop, and a catch-up upgrade may cross several releases with more regression testing.

Before choosing this path, check the end-of-support notice for your exact version and the compatibility requirements listed for the release you would move to.

How SuiteCRM, EspoCRM and SugarCloud meet an on-site constraint

This table compares SuiteCRM 8, EspoCRM and SugarCloud on where data lives, what each option needs from your team, and where custom work starts. Read each row as a question to put to the vendor or your own engineers before choosing a path. The main takeaway is that the on-site constraint can be met by self-hosting open source, but the migration and login work is real and should be scoped in writing first.

Requirement	SuiteCRM 8	EspoCRM	SugarCloud
Licence and source access	AGPLv3 core, maintained by SalesAgility and sold support from SuiteCRM Ltd	AGPLv3, free self-hosted edition with official paid extensions	Proprietary subscription; confirm what source or export rights the contract grants
Where data lives	Your own servers or cloud account; you choose the location	Your own servers or cloud account; you choose the location	Sugar-hosted; confirm the data region and any sub-processors with Sugar in writing
Stack you must run	PHP 8.2 to 8.4, Apache 2.4, MariaDB or MySQL on Linux	PHP 8.3 to 8.5, MySQL 8.0+, MariaDB 10.6+ or PostgreSQL 15, plus cron	Nothing to host; your team manages users, configuration and integrations
Login options	LDAP and SAML built in, enabled by AUTH_TYPE	OpenID Connect and LDAP, including Active Directory and OpenLDAP	Confirm which SSO methods and provisioning options the contract includes
Known login gap	SAML does not support IdP-initiated logout, so an identity provider logout leaves the CRM session open	OIDC backchannel logout is supported; EspoCRM's own 2FA is not compatible with OIDC	Confirm session and logout behavior with Sugar before relying on it for access reviews
Migration from Sugar	Full rebuild of modules, fields and Sugar-only features on a new environment, tested on staging	CSV import with duplicate matching, recreated entities and BPM replacing Sugar workflows	No migration if you stay; exit requires a full export you verify before the contract ends
Work that needs custom development	Sugar-specific features, reports and integrations usually need rebuilding or replacing	Workflows and reports need the Advanced Pack or Formula Script; Sugar-specific predictive features have no direct match	Nothing to build while you stay on Sugar; upgrades follow Sugar's release schedule
Paid support and cost driver	SuiteASSURED, hosting and migration services from SuiteCRM Ltd; in-house staff otherwise	Official Cloud plans per user per month, or self-hosted with your own administrators	Per-user subscription that sets the upgrade path; confirm what support tier is included

What a move from Sugar to a self-hosted CRM involves

Moving off an on-site Sugar instance is a migration, not an upgrade. You build a new environment, move the data into it, review every customization and test the result on staging before anyone works in it. The SuiteCRM migration guidance treats the move from SuiteCRM 7 to 8 the same way, and the sequence applies equally when the destination is a fresh SuiteCRM 8 or EspoCRM installation. Plan for the new platform to be a separate system with its own database, file store, mail settings and authentication, not a patched copy of the old one.

Start with a complete backup of files and database from the current server, taken before any other step. The SuiteCRM migration documentation advises backing up both, testing on a staging instance and reviewing customizations first, because the migration may remove non-core files under the public/legacy folder. Inventory any custom code, templates, logic hooks, extensions and modified files that sit in that folder, and decide for each whether it is rebuilt, replaced or dropped. Confirm the exact file list and migration steps against the version you run, since the documentation changes with each release.

Testing on staging should cover more than a successful data load. Check record counts and relationships for each module, user roles and team access, scheduled jobs, email sending and identity sign-in. For SuiteCRM 8, confirm whether LDAP or SAML will be used, since each is enabled through its own AUTH_TYPE setting and needs the identity provider configured before cutover. Record each check with its result so the sign-off has evidence behind it. Ask the implementation partner or your own team to define acceptance criteria in writing before the first test run.

How to deploy the chosen option on your own infrastructure

This sequence moves a team from an unsupported or aging on-site Sugar instance to a target platform it runs itself, with backups, staging tests and identity settings verified before cutover. The result is a live system with a documented routine for backups and upgrades.

Confirm the target version and its requirements
Choose the destination, then check its published compatibility before any build work starts. For SuiteCRM 8, the compatibility matrix for 8.10 lists PHP 8.2, 8.3 and 8.4, Apache 2.4, MariaDB 10.6, 10.11, 11.4 and 11.8, and MySQL 8.0 and 8.4 on Linux, Unix or macOS. For EspoCRM, the server configuration docs list PHP 8.3 to 8.5, MySQL 8.0 or newer, MariaDB 10.6 or newer or PostgreSQL 15. Your team, or DeployOpen under a written scope, records the chosen versions in a short design note. The step is done when every server component has a confirmed version and an owner.
Build a staging environment
Provision a non-production copy of the target stack in your own cloud account, data center or air-gapped network. Keep it on the same OS family and database engine you plan to run in production so results carry over. For SuiteCRM 8, the migration documentation recommends testing on a staging instance first. For EspoCRM, the installation script can deploy a Docker-based stack with Nginx and MariaDB on Ubuntu, Debian or Linux Mint. The step is done when the empty application loads over HTTPS and the admin login works.
Take full file and database backups
Before touching data, export a complete database dump and a copy of the entire application file system from the current Sugar instance. If the instance runs on your servers, the database and file store are yours to copy directly. If it runs on SugarCloud, request the backup through Sugar Support and verify the package before relying on it. Store the copies in a location separate from the source server. The step is done when a restore of both the database and files has been tested on a scratch host and the record counts match the source.
Migrate or rebuild the data and customizations
Move records into the target platform in the order the data depends on it: accounts and contacts first, then opportunities, activities and custom modules. For SuiteCRM 7 to 8, the documented route is a migration into a new SuiteCRM 8 environment, with the 7 instance first brought to the latest 7.14.x or later. Review customizations before the move, because the migration may remove non-core files under the public/legacy folder. For EspoCRM, use the import tool with duplicate matching, and recreate custom entities and relationships in the Entity Manager. The step is done when a sample of records per module matches the source, and each custom field has a documented equivalent.
Configure LDAP or SAML and test logout
Connect the identity provider your staff already use. SuiteCRM 8 supports LDAP when AUTH_TYPE is set to ldap, and SAML when AUTH_TYPE is set to saml. EspoCRM supports OpenID Connect since version 7.3, plus LDAP for Active Directory and OpenLDAP. Test each login path with real staff accounts, and confirm that users who leave the directory lose access. For SAML on SuiteCRM 8.7.0 and later, IdP-initiated logout is not supported, so signing out at the identity provider does not end the SuiteCRM session. Document this for users and for your security team. The step is done when logins, role mapping and the logout behavior are recorded in a test sheet.
Set scheduled jobs and background processing
Enable the scheduled tasks the platform depends on. EspoCRM requires cron or a scheduled task for background jobs, so add the cron entry for the web user and confirm that queued jobs run. SuiteCRM's scheduler and mail jobs should be checked the same way in its administration settings. Confirm that the jobs run on the schedule you set and that failures are logged where your operators will see them. The step is done when a test job completes and the job log shows the last successful run.
Run cutover and retire the old instance
Agree a cutover window in writing with the business owners, freeze edits in the source system, take a final delta backup, and repeat the data move. Point users to the new address and switch the identity provider configuration to production. Keep the source instance read-only and reachable for a period you set in your own retention policy, so you can answer questions about migrated records. The step is done when the business owner signs off, the final backup is stored, and the old instance is access-restricted rather than deleted.
Keep backup and upgrade routines running
Assign an owner for patching and backups, and write the routine down. For SuiteCRM 8, minor releases arrive roughly every eight weeks and patch releases contain only security and bug fixes, so plan a regular update cycle tested on staging first. For EspoCRM, the command.sh utility covers backups, restores and upgrades in the script-based install. Confirm your restore test on a schedule. The step is done when the routine is in your runbook, the first scheduled backup has been restored successfully, and the next upgrade is on the calendar.

Questions teams ask before they choose

What does it cost to move off on-site SugarCRM?

The total is made of several components, and the software licence is usually the smallest part. SuiteCRM and EspoCRM can be downloaded and self-hosted for free under AGPL licenses, so the costs come from the following:

Hosting: servers or a cloud account, the database, backups, monitoring and TLS certificates. These recur every month.
Migration work: mapping modules and custom fields, rebuilding Sugar-only features, and testing on staging. This is one-time.
Support: SuiteASSURED from SuiteCRM Ltd, a partner, or internal staff time. This recurs.
Internal time: administrators, a database owner, and business users who sign off on the data.

Costs rise with the number of customizations, integrations and users to train. Ask for a written scope that splits one-time and recurring lines, with the assumptions behind each.

How long does a SugarCRM to open-source migration take?

The duration depends on how heavily Sugar is customized, how much data and how many integrations must move, and how quickly your business owners can test. No fixed duration applies to every instance. SuiteCRM's own migration guidance from SuiteCRM 7 to 8 treats the move as a new environment with data moved into it, not an in-place upgrade, and it recommends a staging instance, full file and database backups, and a review of customizations, since the migration may remove non-core files under the public/legacy folder. Ask for a timeline in the written scope with named milestones: discovery, data mapping, staging tests, cutover and rollback. Also ask how many test cycles are included.

Can our in-house IT team run a self-hosted CRM alone?

Yes, if the team already runs web applications on a LAMP or LEMP-style stack and can handle backups, upgrades and security patches. SuiteCRM 8 pairs an Angular frontend with a Symfony backend and supports PHP 8.2, 8.3 and 8.4 with MariaDB or MySQL on Linux, Unix or macOS. EspoCRM needs cron or a scheduled task for background jobs. Minor SuiteCRM 8.x releases arrive roughly every eight weeks, and patch releases contain only security and bug fixes. Someone must plan and test those updates. Before you decide, list who will own the application, the database, the web server and the on-call rota. If any of those roles are empty, that gap should appear in the scope.

What does the work need from our staff?

The work needs input from four groups, and each should be named before the project starts. Business owners confirm which fields, pipelines and reports must survive the move and approve test results. Administrators decide roles, permissions and workflows. Database and infrastructure staff own hosting, backups and restores. Security or identity staff set up single sign-on. For SuiteCRM 8, LDAP is enabled with AUTH_TYPE=ldap and SAML with AUTH_TYPE=saml. The SAML implementation from 8.7.0 does not support IdP-initiated logout, so signing out at the identity provider does not end the CRM session. Plan a user-facing control for that gap and confirm it in testing.

Do we need SuiteASSURED or a partner to run SuiteCRM?

Not always. SuiteCRM is free to download and self-host, but SuiteCRM Ltd sells paid services around it, including the SuiteASSURED support package, SuiteCRM Hosted, implementation, training and migration. You need external support when your team lacks the skills, when you want a vendor contract for response times, or when you want an outside party to handle a move. DeployOpen plans, implements, customizes, hardens, backs up, upgrades and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing first, and ongoing support is available as a retainer. DeployOpen is not an official partner of SuiteCRM Ltd.

Does SugarCloud keep our data in a location we choose?

Confirm this in writing with SugarCRM before you sign, because the researched facts for this page do not state where SugarCloud stores data or backups. Ask for the hosting region for production, staging and backups, the list of sub-processors that can access the data, and whether a region can be fixed in the contract. Ask how a full export is delivered and in what format. Self-hosting changes the question: you choose the cloud account, region or data center, so the location is set by your own architecture and your own contracts. Your compliance team should check whichever option you pick against your data residency obligations.

What risk comes with staying on an on-site Sugar version past support?

A version that is no longer supported stops receiving security fixes, so each new vulnerability found in its code or its dependencies stays open until you patch it yourself or move. The risk grows with internet exposure, the number of integrations and the sensitivity of the customer data. It also affects audits, because assessors ask for evidence that systems are patched and supported. Do not assume a support window from memory. Ask SugarCRM to confirm in writing the end-of-support date for your exact version and the last date for security fixes. Then compare that date with the time your scope needs for upgrade, migration or replacement, and record the decision in your risk register.

Evidence an auditor or regulator will ask for

Moving off an unsupported on-site Sugar version is as much a records exercise as a technical one. The records below show what runs where, what changed, what was tested and where the data sits, and they should exist before any auditor asks for them. DeployOpen prepares this evidence with your team, while independent auditors and certification bodies issue any attestation.

Supported version inventory

Keep a current register of every Sugar instance, its exact version and build, the PHP, Apache and database versions beneath it, and the date each component leaves vendor support. Record which instances are production, staging and archive. Review the register on a fixed schedule, because a version that has dropped out of support is a finding in itself, even if nothing has gone wrong yet. Tie each entry to the owner who accepts the residual risk.

Change and upgrade logs

Record each upgrade, patch, configuration change and customization deployment with the date, the approver, the reason and the rollback point. Auditors look for a clear line from a change request to the production state it produced. Include vendor release notes reviewed before each change, so the log shows that security fixes were assessed and not just applied.

Staging test results

Document the staging runs that precede each production change, including the test scope, the custom modules and integrations exercised, defects found and how they were closed. The SuiteCRM migration guidance advises testing on a staging instance and reviewing customizations first, so these results show that the advice was followed. Keep the results with the change record they support.

Backup and restore test records

A backup only counts as evidence once a restore has been performed. Keep dated records of full file and database backups, the restore target, the time the restore took, and the checks run afterward against record counts, attachments and user access. Confirm how long backups are retained and where they are stored. Because the migration guidance warns that a move may remove non-core files under the public/legacy folder, keep a file-level backup alongside the database dump.

Access configuration for LDAP or SAML

Document how users sign in, whether through LDAP with AUTH_TYPE=ldap or SAML with AUTH_TYPE=saml, along with the directory groups, role mappings and the process for removing leavers. Note a known SAML limitation: the 8.7.0+ implementation does not support IdP-initiated logout, so ending a session at the identity provider does not end the SuiteCRM session. Record this as a compensating control, such as a session timeout or a logout procedure.

Data location documentation

State where each data store lives: the application servers, database hosts, file storage, backup targets and any copy held by a hosted provider such as SugarCloud or a vendor support team. Include the country or data center region, the people with administrative access and the encryption in place. For a move to SugarCloud, ask the provider to confirm where backups and support access reside. This record answers most residency questions before they are raised.

What to confirm with Sugar and your own environment

Before choosing between upgrading, moving to SugarCloud or replacing Sugar, get the on-site end-of-support dates for your exact Sugar version in writing from SugarCRM. The public facts available here do not give those dates for on-site releases, and support windows can differ by product line and edition. Ask which release is current, which one reaches end of support next, whether a security-only window applies after general support ends, and what the vendor will provide during any gap. Record the answers with the date you received them, because a renewal or a planned migration should rest on that document, not on a forum post or an assumption about the release cycle.

Next, confirm the data location terms of SugarCloud with Sugar's contract and data processing documentation, not with a sales summary. Ask where production, backup and log data are stored, which sub-processors touch it, how long backups are retained, and what happens to your data at termination. Then confirm the export options you would rely on: which backups Sugar Support will produce on request, which files and attachments are included, whether uploads must be requested, and whether the backups API or SugarCloud Insights can retrieve a full package. Check any deadline for requesting that package, since it may be shorter than your notice period.

On your own side, inventory the PHP and database versions your Sugar instance runs and compare them with the compatibility matrix of any target you are considering, including the current SuiteCRM 8 matrix and the EspoCRM server requirements. Record your web server, operating system, cron or scheduled job setup, and any custom PHP extensions, LDAP or SAML integrations and file-system customizations. Then test a copy of your database on a staging host. Whichever path you choose, that staging result will tell you more about your real effort than any general estimate.

How DeployOpen moves a Sugar instance to a self-hosted CRM

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Sugar instance nearing the end of on-site support, the work starts with a written scope that compares staying on Sugar, moving to SugarCloud and replacing the CRM with SuiteCRM or EspoCRM.

How we scope

Inventory the current Sugar version, modules, custom fields, integrations, authentication method and database engine before any decision.
Confirm with SugarCRM the support end date for your installed version and the upgrade path it allows.
Agree a fixed scope in writing that names the target platform, deliverables, testing and timelines before work begins.

How we build

Stand up the target SuiteCRM 8 or EspoCRM environment on your servers or cloud account, with the PHP and database versions the vendor documents.
Migrate data to a staging instance first, with full file and database backups and a review of customizations before any cutover.
Rebuild authentication through LDAP, SAML or OpenID Connect where your identity provider is already in use, and test logout behavior.

How we hand over

Document the architecture, configuration keys, backup and restore steps, and the upgrade procedure your team will follow.
Provide test evidence from staging, including data reconciliation results and a list of Sugar features that were rebuilt or retired.
Walk your administrators through daily operation, user permissions and the release cadence so the handover is complete.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after go-live, scoped in writing like the original project.
Plan upgrades around the vendor's patch and minor release cycle so security fixes reach production on a predictable schedule.
Prepare systems and evidence that your auditors may review, while noting that independent auditors and certification bodies issue any formal assessment.