Migrate from SugarCRM Community Edition to SuiteCRM

The route runs through SuiteCRM 7 because SuiteCRM documents the move to SuiteCRM 8 as a migration into a new environment. A SuiteCRM 8 instance is set up first, and the data from the 7 instance is then moved into it. Before that move, the 7 instance must be brought to the latest 7.14.x or later. Your SugarCRM CE data therefore has to reach the SuiteCRM 7 line before SuiteCRM 8 is in scope. The current SuiteCRM 7 line is 7.15.2, published on GitHub on July 31, 2026. SuiteCRM describes 7.15 as an extended support release with security fixes until January 2028, which gives teams with a longer 7 runway a documented support window to plan against.

Each hop on this route is a separate project with its own backup, test and sign-off. The first hop moves the SugarCRM CE 6.5.x installation to SuiteCRM 7.6.6. Later hops move the instance forward through SuiteCRM 7 releases until it reaches 7.14.x or later, and only then does the SuiteCRM 8 migration begin. Treat each hop as a point where the system must be restorable. Before you set dates, confirm the exact 6.5.x to 7.6.6 steps and any intermediate versions in the SuiteCRM release notes for the versions you select. Those notes determine the number of hops, so do not assume a shorter path exists.

The first decision is where the SuiteCRM 7 stop should be. Landing on 7.15.2 keeps the instance on the extended support line through January 2028 while the SuiteCRM 8 cutover is still being scheduled. The SuiteCRM LTS page states that no SuiteCRM 8 extended support release had been nominated, and that SuiteCRM expects to name one by Q3 2027. Place those dates beside your own change calendar, approval cycles and the business window for cutover. If the SuiteCRM 8 cutover could slip past the 7 support window, plan how the 7 instance will be secured for that gap now, and record who owns that decision.

Customizations need the same attention at every hop. The SuiteCRM migration docs advise testing on a staging instance, backing up files and database, and reviewing customizations, because the migration may remove non-core files under the public/legacy folder. Build an inventory of custom code, vardefs, layouts, logic hooks and themes before the first hop, and mark which items live under public/legacy. Anything removed or altered must be restored, rebuilt or retired in the target before the next hop begins. Ask your implementation team to present this inventory as a deliverable at each sign-off.

Version targets also change the stack. The SuiteCRM 8.10 compatibility matrix lists support for 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. Confirm which of these the servers for each 7 hop can run, because an intermediate hop may need a PHP or database version different from the one in place at the start. For quoting, ask for each hop to appear as a separate line with its backup, staging test, customization review and sign-off listed, and ask how repeated test cycles are priced. Effort depends on the number of hops and customizations, so the quote should show both counts.

Before any hop, inventory every customization in the SugarCRM CE instance and sort each item into one of three groups: keep, rebuild or retire. The SuiteCRM migration guidance warns that the migration may remove non-core files under the public/legacy folder, so anything you have added or edited there is at risk and needs an explicit decision. Customizations to review include custom fields and their metadata, custom modules, logic hooks, workflow and process definitions, layout and view overrides, custom language files, and theme changes. Do not assume that anything will or will not survive the move. Test each item on a staging instance built from a fresh backup of files and database, and record what you actually observed.

Start the inventory from the file system and the database, not from memory. Walk through the custom directories, the extension and metadata folders, the logic hook definitions, and any scheduled jobs or scripts that call into the application. Compare them against the core files of the SugarCRM CE release you are running. Anything that is not part of the stock code is a candidate for review. Ask your administrators and power users which workflows, reports and dashboards the business relies on, because a customization that looks minor on disk can drive a critical sales or service process.

Use the three groups to make the decision explicit. Keep means the item works unchanged on the target SuiteCRM release in staging and does not depend on a removed file. Rebuild means the business need is valid but the implementation must be recreated in the target version, often as a configuration or module built with the tooling that version provides. Retire means the need no longer exists, or a standard feature now covers it. Customizations that touch the public/legacy folder deserve particular attention in the rebuild group, because they may need to move out of that location before the hop. Confirm the exact removal behavior with the SuiteCRM documentation for your target release and with a test run, not with assumptions.

Keep a decision record for each item. A simple register with the item name, its location, its owner, the business process it supports, the group assigned, the reason, the staging test performed, the result and the person who approved the decision is enough for most teams. Store the register with the migration plan so the same record can be reviewed at each hop. Repeat the review at every step, because the code base and the target release change between hops. Items marked keep at one hop may need rebuilding at the next. Sign-off from the business owner for every retire decision reduces the risk of losing a process nobody remembered.

Plan for the cost of this work. Inventory and testing consume analyst and administrator time that recurs at every hop, and rebuilds are a development effort that varies widely with the number and complexity of customizations. Ask any implementation partner to quote the review as a separate line item, with the number of hops, the staging environments needed and the testing scope stated in writing. Ask whether the quote includes the decision register and the re-test after the post-migration repairs described elsewhere on this page.

Sign-in is one of the first places a SugarCRM Community Edition migration changes how people work, because SuiteCRM 8 does not reuse the login model of the old instance. Before the data moves, decide whether SuiteCRM 8 will authenticate users against a directory or against a SAML identity provider, since that choice determines where accounts, roles and passwords live after cutover. SuiteCRM 8 supports LDAP, enabled with AUTH_TYPE=ldap and built on the Symfony Security LDAP authenticators, and SAML, enabled with AUTH_TYPE=saml and built on the nbgrp onelogin-saml-bundle. Confirm the exact settings for your chosen method against the LDAP and SAML configuration references for the SuiteCRM version you will run, not against the SuiteCRM 7 login behavior you know.

The login method also sets the migration plan for users. If sign-in moves to LDAP or SAML, the password hashes and local accounts carried over from SugarCRM CE may not be the credentials people use day to day, so the plan should state which user records are matched to directory identities, how usernames map to the identity source, and which roles are assigned from group membership versus configured in SuiteCRM. Map each active SugarCRM CE role to a named owner before the pilot. Plan a documented fallback for administrator accounts so that a broken identity connection does not lock out the people who need to repair it.

Sign-out is the part most teams under-test. The SuiteCRM 8.7.0 and later SAML implementation does not support IdP-initiated logout or POST binding to the logout service. In practice, a user who signs out at the identity provider, or whose identity provider session ends, does not automatically end the SuiteCRM session. Ask your identity team which logout flows the identity provider will initiate, and decide how you will communicate this to users and how sessions will expire on shared workstations. Treat this as a documented limitation to accept, mitigate or work around, and record the decision.

Test sign-in and sign-out during the pilot on a staging instance that uses the same identity provider configuration as production. Cover first sign-in for a migrated user, sign-in for an administrator, a user whose role changed during migration, a disabled account, a password reset in the identity source, sign-out from SuiteCRM, and sign-out at the identity provider followed by a return to SuiteCRM in the same browser. Record the results against each login method you support. Ask your SuiteCRM partner and your identity provider administrator to confirm each step in writing before the production cutover is scheduled.

Effort depends mainly on how many identity sources are involved and how much directory or SAML configuration already exists for the organization. A single LDAP directory with clean group membership is usually simpler than a SAML setup that must be coordinated with several applications and an identity team. Ask any quote to separate the identity configuration work, the user and role mapping work, and the pilot testing, and to state who owns the identity provider changes after handover.