SuiteCRM 7 to 8 migration: a rebuild of the data move
The official route from SuiteCRM 7 to SuiteCRM 8 is to set up a new SuiteCRM 8 environment and move the SuiteCRM 7 data into it. Before that move can start, the 7 instance must first be brought to 7.14.x or later. Most teams arrive here with years of accumulated records, custom fields and modules, workflow logic, email templates, user roles and integrations with mail, telephony, ERP or web forms. Those items do not carry across as one block. Each one needs a decision about whether it moves as data, gets rebuilt in SuiteCRM 8, or is retired. That is why this project is planned as a rebuild of the data move, and why the sections that follow focus on mapping, testing and cutover.
Three triggers usually start the project. The first is the support horizon of the 7 line. SuiteCRM 7.15 is an extended support release with security fixes until January 2028, so the date to plan around is the one that applies to your own version and contract, and you should confirm it with SuiteCRM Ltd. The second is a move from Salesforce or SugarCRM, where the source uses a different data model and the main work is mapping objects, fields and history into SuiteCRM 8. The third is a need for new login or hosting, such as connecting authentication to LDAP or SAML, or moving the application and database to new infrastructure. A single trigger can justify the project. Two or three together usually call for a staged plan with clear checkpoints.
The short answer is that teams with strong SuiteCRM administration and database skills can do parts of this in-house. Exporting records, building a staging copy and running trial imports are within reach of an experienced internal administrator. Partners are most often engaged for three areas: rebuilding customizations written for SuiteCRM 7 that must be reviewed against the SuiteCRM 8 platform before anything is reused, mapping old fields, relationships and record ownership to their SuiteCRM 8 equivalents, and running cutover with a tested rollback plan. These three areas decide whether users trust the new system on the first day, so they deserve the closest scrutiny in any quote.
Before you request a quote, run a few checks on the existing instance. Confirm the exact 7 version and whether it has reached 7.14.x or later. Take a full backup of files and database. Inventory every custom module, extension, logic hook and integration, and note which ones depend on files outside the standard core. The SuiteCRM migration documentation warns that the migration may remove non-core files under the public/legacy folder, so any customization stored there must be found and recorded before the move. Ask the provider how they will reproduce this inventory on a staging instance and what evidence they will give you that staging results match production.
What a SuiteCRM 7 to 8 migration includes and what you receive
A SuiteCRM 7 to 8 migration is a planned move into a new environment, not an in-place upgrade, so the work runs as a chain of linked stages. Each stage ends in a named deliverable that the next stage depends on. Scope, deliverables and timelines are agreed in writing before work starts.
Assessment of the 7 instance
The assessment inventories the SuiteCRM 7 instance: installed version, custom modules, logic hooks, vardefs, extensions, scheduled jobs, integrations, and files under the public/legacy folder. The migration documentation warns that non-core files there may be removed, so every custom file must be identified before work begins. The deliverable is a written inventory that sets the scope for every later stage.
Bringing the 7 instance to 7.14.x
SuiteCRM's migration path starts by bringing the 7 instance to the latest 7.14.x release or later, so the data is in a state the migration tooling expects. This step is tested on a copy of the instance first, with a verified file and database backup taken beforehand. Ask which 7.x release is the target and confirm the upgrade path against the current migration documentation.
Building the SuiteCRM 8 target environment
The target is a fresh SuiteCRM 8 installation on the client's infrastructure, with a PHP, Apache and MariaDB or MySQL stack chosen from the compatibility matrix for the release in use. Decisions here include hosting model, database sizing, file storage, and whether login uses LDAP or SAML from day one. The deliverable is a documented staging environment that mirrors the intended production build.
Mapping modules and fields
Each 7 module, field, relationship and dropdown list is mapped to its SuiteCRM 8 equivalent, with a decision recorded for anything that has no direct counterpart. Mapping decisions cover data types, required fields, and whether legacy data is archived or migrated. The deliverable is a mapping workbook that the business owners sign off before any data moves.
Rebuilding customizations
Custom fields, layouts, logic hooks and custom modules from SuiteCRM 7 are rebuilt in SuiteCRM 8 using its supported extension methods rather than copied over. Each rebuilt item is traced back to its inventory entry, so nothing is dropped silently and nothing is carried forward without a reason. Ask how customizations will be tested before each upgrade after go-live.
Data import and reconciliation
Records are extracted, transformed to the mapped structure, and loaded in dependency order: accounts before contacts, contacts before opportunities, and so on. Reconciliation compares record counts, relationship links and sample field values between source and target, and each exception is logged with its disposition. The deliverable is a reconciliation report that the business signs before cutover.
Staging test cycles and cutover runbook
Staging test cycles run the full migration against a copy of production data, with test evidence recorded for each pass: user acceptance results, integration checks, and defects with their status. The cutover runbook sets out freeze times, final data delta, DNS or access changes, and the go or no-go checkpoints. A rollback plan defines how the 7 instance stays available if a cutover checkpoint fails.
What drives SuiteCRM migration cost and duration
This table lists the factors that change how much work a SuiteCRM 7 to 8 migration takes, why each one moves effort, and what to do early to keep it down. Use it to scope your own environment before asking for a quote. The main takeaway is that data volume, customization and integrations usually matter more than the number of users.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Record volume and attachment size | Every record and linked document must be exported, transformed, imported and checked. Large attachment stores add transfer, storage and validation time, and they lengthen each test import on staging. | Archive closed records older than your retention rule before migration. Confirm attachment totals and file types early, and move cold files separately where your policy allows. |
| Number of custom modules and fields | Each custom module or field needs a mapping decision, a target definition in SuiteCRM 8 and a test case. Fields with unclear purpose multiply review time. | Audit fields against actual use and retire unused ones. Rebuild only what is still needed, using Module Builder where it fits instead of carrying over legacy code. |
| Workflows and logic hooks | Legacy workflows and PHP logic hooks rarely port directly. Each one must be re-specified, rebuilt and tested against current business rules. | Inventory every workflow and hook with its owner and purpose. Retire duplicates and move simple rules into standard workflow features. |
| Integrations (ERP, marketing, telephony, web forms) | Each connected system needs its connection repointed, its field mapping revalidated and its sync direction and error handling confirmed. Telephony and web forms often depend on exact field names. | List every integration with its vendor, data flow and owner. Confirm which ones have supported SuiteCRM 8 connectors or APIs before design starts. |
| SSO requirements | Login must be rebuilt for the new environment, whether LDAP or SAML. SAML logout behavior and group mapping need separate testing with each identity provider. | Decide the login method and group mapping before cutover. Confirm the identity provider settings with your directory or SSO team and test logout explicitly. |
| Number of environments | Development, staging and production each need the 7 instance upgraded, the 8 build configured and data loaded. Keeping them in step adds repeated effort. | Keep the number of environments to what your change process needs. Script environment builds so each one is reproducible. |
| Users, roles and security groups | Role and security group rules must be re-created and checked for each team. Permission errors surface late, when real users test. | Document current roles and access by team before migration. Reduce overlapping roles and test with a sample of real user accounts. |
| Data quality in the source | Duplicates, missing required fields, inconsistent picklist values and broken relationships require cleansing or agreed rules before import. Poor data often drives the largest share of unplanned work. | Run duplicate and completeness reports on the 7 instance before design. Decide cleansing rules with data owners and set a clear cutoff for what is migrated. |
| Compliance evidence needs | If auditors need proof of access controls, change records, data handling or retention, the team must capture and retain test results, approvals and migration logs. | Agree the evidence list with your compliance lead before testing. Record approvals and test outcomes as the work happens. DeployOpen prepares evidence, but independent auditors issue any assessment result. |
How the migration runs from assessment to cutover
The sequence moves a SuiteCRM 7 instance into a new SuiteCRM 8 environment in eight ordered phases. Each phase closes with a written output that the next phase depends on, so the client can see what is settled before data moves into production. Timing is set in the written scope and is not stated here.
Assess the source and inventory it
DeployOpen reviews the SuiteCRM 7 instance, its database, file system and installed extensions, and lists every custom module, field, logic hook, workflow, integration and scheduled job. The team also records which users, security groups and login methods are in use, and flags files in the public/legacy folder, which the migration may remove. The output is a written inventory with each item marked keep, rebuild or retire, signed off by the client before build work starts. Done when the inventory covers every custom component found on the instance and each open question has a named owner.
Bring the 7 copy to 7.14.x
Before data can move, the SuiteCRM 7 instance must be on the latest 7.14.x release or a later 7 release, as the migration documentation requires. This work happens on a copy of production so the live instance stays available during the preparation. Files and the database are backed up first, and customizations are reviewed because the migration may remove non-core files under public/legacy. The output is a verified 7 copy that starts cleanly, with a backup set that can restore it. Done when the copy passes login, a sample record check and a scheduler run.
Build and configure the SuiteCRM 8 target
The team sets up a new SuiteCRM 8 environment on the infrastructure the client has chosen, checking the server against the SuiteCRM 8 compatibility matrix for PHP, Apache and MariaDB or MySQL versions. Core configuration, email, scheduler, roles and security groups, and the chosen login method, such as LDAP or SAML, are set up in this phase and tested with a test account. The output is an empty but working target instance with a documented configuration record. Done when a test user can log in through the agreed method. Confirm supported versions for the release you plan to deploy before ordering servers.
Map data and run trial imports
Each SuiteCRM 7 module and field is mapped to its SuiteCRM 8 counterpart, with decisions recorded for fields that change type, relationships that need restructuring, and records that will not move. The team then runs trial imports into a non-production target and checks row counts, relationships, ownership and attachments against the source. Every mapping decision is logged so the same rules apply at final migration. The output is a mapping specification and a trial import report listing defects found and how each was resolved. Done when repeated trial runs produce the same results and every exception has an agreed outcome.
Rebuild customizations on the new build
Custom modules, fields, layouts, workflows and integrations are rebuilt on SuiteCRM 8 using its supported extension approach. Old SuiteCRM 7 code is not copied across by default. The team reviews each item from the inventory, decides its design on the new platform, and builds it under version control with automated tests where practical. Integrations are checked against the current APIs of the systems they connect to, and credentials are held in configuration rather than in code. The output is a tested customization set, a change log and a written list of anything dropped and why.
Test in staging and reconcile data
The full migration runs against a staging instance built with the same steps that will run at cutover. Testers work through scripted scenarios for sales, service and marketing processes, plus security groups, login and integration flows, while the team reconciles record counts, totals and key fields against the source. Differences are logged, fixed in the mapping or build, and the run repeats until it is clean. The output is a signed reconciliation report and a defect log with every item closed or accepted by the client owner. Done when a complete staging run passes the agreed test scripts with no open high-severity findings.
Rehearse cutover and rollback
The team runs the cutover runbook end to end on a rehearsal environment and records who performs each step and how long it takes, including the final data delta, access or DNS changes, scheduler restart and user communication. The rollback path is rehearsed as well, restoring the SuiteCRM 7 instance from its backup set and confirming users can work on it again. Gaps found in rehearsal are fixed in the runbook before the next run. The output is an approved runbook with a go or no-go checklist and a proven rollback. Done when the rehearsal finishes within the window set in the written scope.
Cut over and support hypercare
On the agreed cutover date, the team freezes the SuiteCRM 7 instance, runs the final data import, checks reconciliation, and opens SuiteCRM 8 to users. Hypercare follows for the period set in the written scope, with the team watching logs, scheduler jobs, login and integration errors, and answering user questions as they arise. The SuiteCRM 7 instance is kept read-only and backed up until the client confirms it can be retired. The output is a signed cutover record, a hypercare issue log and a documented retirement decision. Done when the hypercare exit criteria in the written scope are met.
Why the 7 instance must reach 7.14.x and what the migration can remove
The official path requires the SuiteCRM 7 instance to be brought to the latest 7.14.x release, or a later 7.x release, before any data moves. SuiteCRM documents this move as a migration: a new SuiteCRM 8 environment is set up and the 7 data is moved into it. The 7.14.x step brings the source system into the state the migration documentation expects. On a copy of production, applying it means taking the instance through its patch releases, then checking that users can log in, scheduled jobs still run, and custom modules still load. Record every change to files and the database so the team can explain each difference later. Confirm the exact 7.14.x or later release, and the order of patches, against the SuiteCRM migration documentation before starting.
The warning that matters most for custom work is that the migration may remove non-core files under the public/legacy folder. Any file there that your team or an earlier partner added, including overrides, custom entry points, images, scripts or templates, must be found before the migration runs. Start with a full listing of public/legacy on the copy of production, compare it with the files shipped in the 7.14.x release, and mark every difference. Each custom file then needs a decision with a named owner: rebuild it as a SuiteCRM 8 extension or workflow, keep it deliberately with a documented reason, or retire it because a standard feature now covers the need. A file left in place without a decision is the one most likely to disappear unnoticed.
Before any step runs on a copy of production, take a backup of the application files and of the database, and store both where the migration team can reach them. The file backup should include configuration files, upload and document directories, custom code, and the cron and web server settings the instance depends on. Take the database backup at the same point in time as the file backup so the two match. A backup only counts once it has been restored successfully on a separate host, so schedule a restore test and confirm that logins, records and attachments come back. Keep the production backup set untouched until cutover is complete and the rollback window in the project plan has passed. Ask your hosting provider or internal team how backups are encrypted and who holds the keys.
Staging tests come before any production move because the migration changes data structures, custom code and integrations at the same time, and a fault found in production is far harder to reverse. The staging instance should match production in SuiteCRM version, PHP and database versions, web server configuration and the set of custom files. Run the complete sequence there: the 7.14.x step, the public/legacy review, the SuiteCRM 8 environment build and the data move. Then check record counts by module, sample records and attachments, security group visibility, login through the configured authentication method, scheduled jobs, email and each integration. Repeat the run until the checks are clean and the steps are written into a runbook. Confirm the exact target SuiteCRM 8 release and its PHP and MariaDB or MySQL versions in the SuiteCRM compatibility matrix, because supported versions change between releases.
Which migration work your team can keep in-house
This table lists each migration work package with a typical split between in-house and outsourced delivery, plus the skills each one needs. Use it to see where your team has the capacity and knowledge to own work, and where a partner is worth buying. Most migrations split across both columns, so a team can keep the business decisions and daily checks while buying the code rebuild, scripting and cutover work.
| Work package | Usually kept in-house or outsourced | Skills needed |
|---|---|---|
| Business owner decisions on data retention and field mapping | Usually in-house | Business process knowledge, data ownership, sign-off authority |
| Source data extraction | In-house, with partner help on complex schemas | SuiteCRM 7 database structure, SQL, export handling |
| Staging environment and infrastructure | Often outsourced for the first build, then in-house | Linux administration, web server setup, hosting and access control |
| PHP and MariaDB or MySQL administration on the target | In-house if your team already runs these servers | PHP version management, database tuning, supported version checks |
| Custom code rebuild | Usually outsourced | PHP, SuiteCRM 8 extension development, review of SuiteCRM 7 customizations |
| Data transformation scripts | Often outsourced, with in-house testing | PHP or SQL scripting, data profiling, handling of edge-case records |
| Reconciliation and sign-off | Business sign-off in-house, checks shared | Record count comparison, sample review, user acceptance testing |
| Cutover and rollback | Shared: partner drafts the plan, your team approves it | Change management, backup and restore, production access control |
| SSO integration | Often outsourced | LDAP or SAML configuration, identity provider administration |
| Post-cutover support | In-house for daily use, outsourced for fixes | Administration, incident triage, user support |
What usually goes wrong when SuiteCRM 7 data moves to SuiteCRM 8
A SuiteCRM 7 to 8 move is a migration into a new environment, not an in-place upgrade, so most failures come from assumptions carried over from the old system. The cards below cover the failure points we see most often and the check or control that prevents each one. Work through them in staging before any production cutover.
Customizations lost in public/legacy
The SuiteCRM migration documentation warns that the migration may remove non-core files under the public/legacy folder. Custom code, templates and scripts placed there in SuiteCRM 7 can disappear or stop working in SuiteCRM 8. Prevention: inventory every file that differs from the stock 7.x install, record its purpose, and decide whether it is rebuilt as a SuiteCRM 8 extension, moved to a supported location, or retired. Confirm each decision in a staging test before cutover.
Undocumented customizations found late
Vardefs, layouts, logic hooks and custom fields often exist with no written record of who built them or why. Teams find out they are missing only when a user reports a broken screen after go-live. Prevention: export the SuiteCRM 7 customization set and review it module by module with the business owners, then mark each item as rebuild, replace or drop. Treat an item with no owner as a blocker until someone accepts it.
Field mappings that silently drop data
A field that imports without an error can still lose its content if the target field type, length or picklist values do not match the source. Dropped values often surface weeks later in reports rather than during the import. Prevention: write a field-by-field mapping sheet covering source field, target field, type, length and value translations, then reconcile record counts and sampled values for every module in a staging import before approving the mapping.
Duplicate and orphaned records
Re-running an import, merging accounts or importing contacts from a second source can create duplicate records. Relationships pointing at records that were not migrated leave orphaned links that look fine in a list view but break related lists and reports. Prevention: define the matching key for each module before import, run duplicate checks and relationship checks on the staging result, and agree who resolves exceptions before the production run.
Attachments that do not follow their records
Document and note attachments are stored as files, so moving database rows does not move the files on their own. Records can arrive with links to files that were never copied, or with files attached to the wrong record after an ID change. Prevention: copy the upload directory with the database backup, confirm that a sample of attachments opens from each module in staging, and check file counts against the source by module.
Users and roles that do not match the new model
Users, teams, roles and security groups created under SuiteCRM 7 do not automatically map to the access rules in SuiteCRM 8. Users can end up with more access than intended, or lose visibility of records they own. Prevention: export the current role and team assignments, design the SuiteCRM 8 security groups first, map each user to a group, and test record visibility with a sample of users from each department in staging.
Workflows firing during trial imports
Workflows, email templates and scheduled jobs that are active during a trial import can send customer emails, change record statuses or create tasks for real records. This happens easily when staging is connected to live mail servers or to integrations. Prevention: disable outbound email and scheduler jobs in every non-production environment, deactivate workflows before each trial import, and re-enable them only after the reconciliation sign-off.
SSO not tested before cutover
Login through LDAP or SAML behaves differently from SuiteCRM 7 and must be configured and tested in SuiteCRM 8 before users depend on it. The SuiteCRM SAML reference for 8.7.0 and later states that IdP-initiated logout and POST binding to the logout service are not supported, so logging out at the identity provider does not end the SuiteCRM session. Prevention: test login, logout and account lockout with real pilot users, and document the logout behavior for the support team and the users.
Integrations still pointing at SuiteCRM 7
ERP connectors, web-to-lead forms, marketing sync and telephony integrations often hold the old instance URL, API credentials or field names. After cutover they can keep writing to the retired system, and the gap may not be noticed for days. Prevention: list every integration with its endpoint, credentials and direction, repoint each one in staging with test records, and confirm that the SuiteCRM 7 instance is set to read-only or taken offline at cutover.
How the migration changes by starting point
Customization is the largest variable when the source is SuiteCRM 7. The SuiteCRM migration documentation advises reviewing customizations before anything else, because the migration may remove non-core files under the public/legacy folder. Custom modules, logic hooks and edited core files do not carry over as they are, so each item needs a decision: rebuild it for SuiteCRM 8, replace it with configuration, or retire it.
- Inventory: list every custom module, field, layout, logic hook and changed file, including anything under public/legacy.
- Keep or retire: decide for each item whether the business still uses it and who signs off on that decision.
- Rebuild: most extensions need new code for SuiteCRM 8, so budget for rewriting rather than copying files.
- Test: run each rebuilt item against staging data that resembles production, including edge cases in workflows and permissions.
Before you agree a scope, confirm how many customizations exist, which ones are business-critical, and who owns each one on your side.
Moving from Salesforce or SugarCRM is a data migration and rebuild, not a version move. There is no in-place path from another vendor's CRM to SuiteCRM 8, so the work is export, field mapping, relationship rebuild and import into a new SuiteCRM 8 environment. The effort sits in the mapping decisions and in re-creating the access model, not in the platform installation.
- Export: extract accounts, contacts, leads, opportunities, notes, attachments and activity history, keeping stable record identifiers so links can be rebuilt.
- Field mapping: map each source field to a SuiteCRM 8 module field, including picklist values, currency formats and date and time handling.
- Relationships: rebuild links between accounts, contacts, cases and opportunities, because they must be recreated from the exported identifiers.
- Attachments and history: decide which activity and files must be kept, and how file storage will be organized on the new server.
- Access model: recreate ownership, teams and roles from the source sharing rules, since these do not transfer automatically.
Before mapping starts, ask for the complete field list from your source system and confirm which objects must move, including any records you plan to archive instead.
The SuiteCRM migration documentation states that a SuiteCRM 7 instance must first be brought to the latest 7.14.x or later before the move to SuiteCRM 8. If your instance runs an earlier 7 release, that step adds upgrade work on the 7 side, and the 7 system needs its own testing before any data is moved. The extra work depends on how far your installation is from that baseline and how much you have changed it.
- Confirm the version: identify the exact 7.x release from the installed files and the database, not from memory or a previous document.
- Upgrade on 7: move to the latest 7.14.x or later, and retest your customizations on the 7 system after each step.
- Rollback points: take a backup of files and database before each step so that any stage can be reversed.
- Extended support option: the 7.15 line is an extended support release with security fixes until January 2028, so ask whether moving to it suits your timeline.
- Second inventory: repeat the customization review after the 7 upgrade, because changes made during that step can affect what you planned to rebuild.
Confirm your current 7.x version and whether a 7.14.x or later upgrade has already been tested in a non-production copy of your instance.
Login is configured on the SuiteCRM 8 target, so directory or identity provider settings change the cutover work more than the data work. SuiteCRM 8 can use LDAP, built on the Symfony Security LDAP authenticators and enabled with AUTH_TYPE=ldap, or SAML, built on the nbgrp onelogin-saml-bundle and enabled with AUTH_TYPE=saml. Either option needs directory or identity provider configuration, along with a plan for matching existing user records.
- Choose the method: LDAP suits accounts held in a directory, while SAML suits a central identity provider that handles sign-in for several applications.
- User matching: confirm that usernames or directory attributes match the existing SuiteCRM user records, or plan a mapping before cutover.
- Test accounts: test sign-in with users from each group, including administrators, read-only users and disabled accounts.
- Logout behavior: from SuiteCRM 8.7.0, the 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.
- Recovery path: keep a documented administrator access method for the case where the directory or identity provider is unavailable.
Confirm which login method your directory or identity provider supports, and whether the logout behavior is acceptable for your users and security policy.
When the target must run on a set PHP, Apache or database version, the compatibility matrix determines which build is possible. The SuiteCRM 8.10 matrix 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. If your platform team must use a version outside that list, the environment decision comes before any migration design.
- Pick a supported pair: choose a PHP and database combination from the matrix that your platform team already operates and patches.
- Check the exact release: confirm the matrix for the SuiteCRM 8 release you plan to deploy, because supported versions change between releases.
- Database engine changes: moving data into a different database engine adds restore, character set and collation tests on staging.
- Operating system: the matrix covers Linux, Unix or macOS, so confirm that your hosting platform falls within those families.
- Patch ownership: agree who tracks PHP, Apache and database patch releases after go-live, since these affect the platform beyond SuiteCRM itself.
Confirm your target PHP, Apache and database versions against the matrix for the release you will deploy, and ask for the migration to be tested on that exact stack.
What you need to provide before a migration starts
Gaps in what the client supplies will extend staging cycles more than any technical step in a SuiteCRM 7 to 8 migration. SuiteCRM documents this as a migration, where a new SuiteCRM 8 environment is set up and the 7 data is moved into it, so the target, the data scope and the people who will test it must be settled before the first import runs. Request each input in writing at scoping, and confirm that every item has a named owner with time to answer. Missing answers usually surface during staging, when a late decision forces a rerun of the data load and the full test pass.
Start with people and access. Name one business owner for each module in use, such as Accounts, Contacts, Leads, Opportunities, Cases and any custom modules, because these owners approve field mapping and test results. Provide access to the SuiteCRM 7 instance and its server, including the public folder and custom code, along with database access for export. Confirm that the 7 instance has been brought to the latest 7.14.x or later, as the migration docs require before the move. Supply a list of integrations with a named owner for each, since every connected system needs a test contact and a decision to repoint, rebuild or retire it.
Next, settle identity and hosting. If SuiteCRM 8 will use single sign-on, provide identity provider access so testing can cover LDAP (AUTH_TYPE=ldap) or SAML (AUTH_TYPE=saml). Plan test accounts for logout behavior as well: the 8.7.0+ SAML implementation does not support IdP-initiated logout or POST binding to the logout service, so signing out at the identity provider leaves the SuiteCRM session open. The target hosting must match the SuiteCRM 8.10 compatibility matrix, which lists PHP 8.2, 8.3 and 8.4, Apache 2.4, supported MariaDB and MySQL versions, and Linux, Unix or macOS. Confirm this choice with your platform team before the build begins.
Finally, decide data retention and archiving rules. Specify which records, attachments and audit history move into SuiteCRM 8, which stay in an archive, and who approves that scope. The migration docs warn that the process may remove non-core files under the public/legacy folder, so ask the client's team to list any customizations stored there and name an owner for each before staging starts. Agree on a backup of files and database that the client can restore independently. Last, name the person with sign-off authority for cutover and the person who can approve a rollback, and confirm that both are available during the cutover window.
Questions buyers ask about SuiteCRM 7 to 8 migration
Can our own team run a SuiteCRM 7 to 8 migration, and what must we provide?
Yes, an experienced in-house team can run the migration if it has Linux, PHP, MariaDB or MySQL and SuiteCRM administration skills and enough time for staging work. SuiteCRM documents the move as a new SuiteCRM 8 environment with the 7 data moved into it, so the work covers the new server build, data mapping, customization review, testing and cutover. Your team will also need to provide access to the SuiteCRM 7 instance, database and file storage, a customization inventory, business owners who can decide field and data mapping questions, test users, a cutover window, and admin access to any identity provider you plan to connect. Confirm the skills and capacity honestly before deciding.
What drives the cost and timeline of a SuiteCRM migration?
The main drivers are the number of customizations, modules and fields to map, the volume and quality of existing data, the number of integrations, whether SSO is in scope, and how many staging test cycles the scope requires. Costs fall into one-time work (assessment, build, mapping, import scripts, testing, cutover and training) and recurring items (hosting, support and admin time afterwards). Ask any provider for a quote that lists each piece of work, who performs it, what the client supplies, and which items are one-time versus recurring. DeployOpen agrees fixed scope and deliverables in writing before work starts, and the quote follows from that scope. No price is given here because it depends on your environment.
Can SuiteCRM 7 be upgraded in place to SuiteCRM 8?
No. SuiteCRM documents moving from 7 to 8 as a migration, not an in-place upgrade. The documented path is to bring the SuiteCRM 7 instance first to the latest 7.14.x release or later, set up a new SuiteCRM 8 environment, and move the 7 data into it. Before you start, the SuiteCRM migration guidance advises testing on a staging instance and backing up both files and the database. Plan the target SuiteCRM 8 version and its PHP and database requirements against the SuiteCRM 8 compatibility matrix, and confirm the supported combinations for your server stack before the build begins.
How many staging test cycles does a SuiteCRM migration need?
There is no fixed number. The count depends on scope: how many customizations need rebuilding, how complex the data mapping is, how many integrations and user groups are involved, and how many issues the first loads reveal. A typical cycle loads data into staging, checks records, fields, security groups and integrations against the agreed mapping, fixes the mapping or scripts, and repeats. Ask the provider to define the test cycles in the written scope, with entry and exit criteria for each, and to state what the client must sign off at each stage. Keep at least one full rehearsal of cutover in the plan.
Can data from Salesforce or SugarCRM be moved into SuiteCRM 8?
It can be planned, but the approach depends on what you export, how it maps, and which import method is used, so confirm it during scoping. Key questions are which objects and fields must move, whether attachments, notes and activity history are needed, how users and ownership map to SuiteCRM users and security groups, and what export formats the source system provides for your license level. SuiteCRM Ltd sells its own migration services, which is a separate option you can compare. DeployOpen plans and implements migrations onto self-hosted open-source platforms in your infrastructure, and the source-specific mapping should be confirmed in the written scope against a sample export.
What happens to our SuiteCRM 7 customizations during migration?
Customizations need an inventory and a decision before any build starts. The SuiteCRM migration guidance warns that the migration may remove non-core files under the public/legacy folder, so custom files there must be found and reviewed rather than assumed to carry over. Each customization is typically either rebuilt on SuiteCRM 8 using its supported extension approach, or retired because the business no longer needs it. Custom code, custom modules, logic hooks, layouts and integrations all need a separate check. Ask for a customization register in the scope, with a planned outcome for each item and an owner who signs it off.
Can SSO with LDAP or SAML be set up during the migration?
Yes, SuiteCRM 8 login can use LDAP, enabled with AUTH_TYPE=ldap, or SAML, enabled with AUTH_TYPE=saml. The SAML implementation in 8.7.0 and later 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. Plan for that limitation with users and security reviewers. Confirm which identity provider you use, how users are matched to existing SuiteCRM accounts during the data move, and how legacy API authentication will be handled. Test SSO on staging with real user groups before cutover, and document the logout behavior for your users.
Does the SuiteCRM 7.15 security fix window affect migration planning?
Yes, it affects the timing and the risk you carry while you migrate. SuiteCRM 7.15 is an extended support release that receives security fixes until January 2028. No SuiteCRM 8 extended support release has been nominated yet, and SuiteCRM expects to name one by Q3 2027. Planning should set a target cutover date with time for staging and rollback, confirm which SuiteCRM 8 release line you will run and how its patch releases will be applied, and decide how long the 7 instance stays online after cutover and what it is exposed to in the meantime. Ask your provider to show these dates in the schedule.
How DeployOpen scopes, delivers and hands over a SuiteCRM migration
DeployOpen treats SuiteCRM 7 to 8 migration as a planned move of data and configuration into a new SuiteCRM 8 environment. The work is agreed as a fixed scope in writing before it starts, then delivered and handed over inside your own infrastructure. Ongoing support is available as a retainer.
How we scope
- The written scope lists the SuiteCRM 7 modules, fields, customizations and integrations that move.
- We confirm the SuiteCRM 7 instance can reach the latest 7.14.x release before migration begins.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We build a new SuiteCRM 8 environment and map each SuiteCRM 7 field to its target.
- Non-core files under the public/legacy folder are reviewed before anything is removed or carried over.
- Custom logic is rebuilt in SuiteCRM 8 and login is configured for LDAP or SAML where needed.
How we hand over
- Test runs on a staging instance cover data import, customizations, logins and reporting before cutover.
- Backups of files and database are taken and restore is tested before the cutover window.
- You receive documentation of the mapping, configuration, cutover steps and any open items.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after cutover.
- SuiteCRM 8 minor releases arrive roughly every eight weeks, so a set upgrade cadence helps.
- Confirm with SuiteCRM Ltd which support package covers your installation before go-live.
