Skip to content
AgenticUltimate by QOON Request a live demo
Migration

SuiteCRM 7 to 8: pre-migration checklist

·approx. 16 min read
In short
  • SuiteCRM 8 is not an in-place, one-click upgrade from 7. The official route is a migration process with its own package logic and integration of legacy components.
  • Most delays arise from incomplete inventories (packages, hooks and integrations) and a lack of realistic staging tests.
  • Going live without a documented rollback and business acceptance criteria is an organisational risk, rather than solely an IT issue.
Interactive check

Make a rough assessment of migration complexity

Not an oracle for hours — a guide to whether standard work or a dedicated project is more likely.

Assessment: relatively manageable

Focus on inventory, staging and business acceptance. Structured tools can help, but do not replace tests.

1 · Backup & inventoryClarify data, packages, integrations and rollback conditions.
2 · Staging / dry-runMigration path on a copy, smoke tests and known pitfalls from the release notes.
3 · Permissions & opsCheck the web server user, cache and scheduler again after CLI steps.
4 · Cutover & hypercareGo/no-go, communication and a short period of intensive support after the move.

For many organisations, moving from SuiteCRM 7 to 8 becomes unavoidable when support, the PHP stack or product strategy requires it. At the same time, it is not a routine patch. Official documentation and migration packages make clear that this is a structured transition, not a case of overwriting installation files and hoping for the best.

This article is a preparation and decision checklist. It does not replace a project plan or provide a binding assessment of your particular codebase.

1. Architecture: why 7 and 8 feel different

SuiteCRM 8 introduces a modernised application architecture and UI layer; legacy components and migration paths are part of the official model. For decision-makers, this means:

  • Expectations of the interface, navigation and administration paths change.
  • Customisations from 7.x do not automatically work unchanged.
  • Operations (PHP version, Composer/console steps, cache and permissions) follow the release notes more closely for the target version.

Anyone who wants to “just compare features” underestimates the migration work involved.

2. Agree the framework before technical work starts

  • Record the target release (such as a specific 8.x release line) in writing — not simply “something current”.
  • Prioritise business drivers: security, PHP end of life, lack of 7.x maintenance and a strategic UI direction.
  • Agree a maintenance window and communication plan for business teams.
  • Define roles: who decides go/no-go, who tests business processes and who supplies hosting?
  • Define rollback conditions: which failures trigger rollback, and how long does the backup remain valid?

3. Inventory — the part teams most often underestimate

3.1 Packages and custom code

List installed packages with their version and last known state. Mark each as production / optional / obsolete. Add logic hooks, scheduler jobs, custom modules and code copied into custom/ that was never packaged.

3.2 Integrations

SSO, ERP, marketing, telephony, document management and BI exports: every interface needs an owner and a post-migration test case.

3.3 Data quality

Duplicates, broken relationships and orphaned attachments — migration rarely creates these existing data problems by itself, but exposes them and slows acceptance.

4. Staging: what “tested” should mean

An empty demo instance proves little. At minimum:

  1. Use a copy containing realistic sample data or a full copy — decide deliberately and document it.
  2. Follow the official migration path for the selected package line (rather than using forum rumours as a runbook).
  3. Test script: login, permissions, a core sales flow, inbound/outbound email, one report, a critical custom flow and opening an attachment.
  4. Sample performance in modules with large lists — subjective, but an early warning.

Documented known issues (permissions after CLI commands, CSRF/session issues after repeated migration at the same URL, or choosing the wrong package instead of the migration package) belong in the runbook, not among go-live weekend surprises.

5. Data, files and cutover

  • Estimate database and file volumes; measure backup duration rather than guessing.
  • Attachments: sample before and after — open them, rather than simply checking that a file exists.
  • Cutover sequence: maintenance page, final synchronisation strategy, DNS/URL, sessions/cookies and initial smoke tests.
  • Hypercare: a clearly identified contact for 3–5 days, known workarounds and an escalation path.

SuiteMigrate supports structured transfers and mapping scenarios within AgenticUltimate. It does not remove the need for business acceptance or responsibility for custom code, but can make the technical approach more disciplined than ad hoc scripts. Suitability depends on the source system and data scope.

SuiteMigrate ↗

6. Suggested go-live criteria

Define these beforehand, not afterwards:

  • All priority A processes pass on staging
  • No unresolved “unknown” priority A packages without a plan
  • Backup and test restore documented
  • Business sign-off from process owners

Time savings and “success rates” without reference to your codebase would be speculative, so they are deliberately absent here.

← Back to magazine