Migrate from Salesforce to SuiteCRM

Migrate from Salesforce to SuiteCRM: what the move involves and who does it

A Salesforce to SuiteCRM migration is an export, mapping, rebuild and parallel-run project, not a file copy. Teams usually arrive here at a renewal, after a seat count increase, when a data residency rule requires customer records on their own servers, or when Salesforce-specific automation has become hard to move anywhere else. The work starts by deciding which objects, fields, reports and automations the business still uses, because most Salesforce orgs carry years of unused custom fields and retired processes that should not be carried into a new system. Exported CSV files then have to be mapped onto SuiteCRM modules, relationships and custom fields, and each active Salesforce flow, approval or validation rule has to be rebuilt as a SuiteCRM workflow or accepted as a manual step.

In most projects an internal Salesforce or CRM administrator leads the work, with an implementation partner doing the hosting setup, data mapping scripts, testing and cutover planning. The reader should confirm who owns the SuiteCRM environment after go-live, who approves the data mapping, and who signs off the parallel run. SuiteCRM is published under the AGPLv3 license, so the software itself carries no per-user subscription. What recurs instead is the hosting, backups, patching and support, which the organization pays for in its own infrastructure or through a provider it chooses. The effort and risk depend mainly on how much custom Apex, managed package and integration logic sits behind the current org. Ask any partner for a written inventory of those components before agreeing a scope, and for a plan that runs the old and new systems side by side until users and integrations have been verified.

Which Salesforce capabilities map cleanly to SuiteCRM and which need rework

This table compares core Salesforce Sales Cloud capabilities with their closest SuiteCRM 8 modules, workflows and REST-based integrations. Each row is marked clean, needs rework or gap. Treat clean as a starting point to confirm against the SuiteCRM documentation and your own org, and plan migration effort for every rework and gap row.

Salesforce capability	SuiteCRM 8 equivalent	Fit
Accounts, contacts and opportunities	Accounts, Contacts and Opportunities modules with their relationships, confirm field types and sales stages against your data	Clean
Tasks, activities and notes	Tasks, Calls, Meetings and Notes modules, confirm how activity history links to records during import	Clean
Custom objects	Custom modules and custom fields, confirm each object's relationships and required fields in the Module Builder before importing	Needs rework
Page layouts and record types	Layout and field visibility settings per module, confirm whether every record type needs its own layout	Needs rework
Reports and dashboards	Built-in reporting and dashboard views, confirm that each Salesforce report can be rebuilt with the same filters, groupings and access rules	Needs rework
Flows, Process Builder and workflow rules	SuiteCRM workflows, confirm each trigger, condition and action; complex flow logic is rebuilt by hand	Needs rework
Approval processes	No direct equivalent to confirm in the SuiteCRM documentation; approvals usually need custom development or a manual process	Gap
REST APIs and AppExchange apps	SuiteCRM REST API for custom integrations; AppExchange packages have no direct equivalent and must be replaced, rebuilt or dropped	Gap

Which data to export from Salesforce and how to move it

Salesforce offers two documented export paths, and neither moves everything by default. The cards below cover what each path produces, what it leaves out, and what must be rebuilt in SuiteCRM once the records are extracted. Check each export against this list before you start cutover.

Data Export Service cadence

The Data Export Service produces a set of CSV files in a compressed archive. Salesforce runs it weekly in Enterprise, Performance and Unlimited editions, and every 29 days in Professional and Developer editions. Plan your extract window around that cadence, because a final cutover export cannot be produced on demand through this path. Confirm your edition and the export schedule in your own org before you set the parallel-run dates.

Data Loader for repeatable extracts

Data Loader is a separately installed client that runs through a graphical interface or from the command line. Because it can be scripted, it suits repeated delta extracts during parallel running, where the same objects are pulled again each cycle. Someone must install, license and maintain the client and its credentials. Store the scripts and configuration under version control so the extract is reproducible during audits.

Records, relationships and IDs

Export accounts, contacts, leads, opportunities, products and custom objects, and keep the Salesforce record IDs as an external key column in every file. Without those IDs, parent-child links such as contacts to accounts or line items to opportunities cannot be rebuilt in SuiteCRM. Check that each junction or lookup relationship is exported in a form you can map to a SuiteCRM relationship, and test the import on a staging instance first.

Attachments and file history

Neither export path should be assumed to carry every attachment or file version. Attachments and documents need a separate extraction step, with file names mapped to the parent record IDs so they can be attached again in SuiteCRM. Field history and activity history also need an explicit decision: keep them as archived read-only data or drop them. Ask your Salesforce admin which history objects are enabled before scoping the work.

Integrations and automation to rebuild

Exports carry data, not logic. Flows, approval processes, connected apps, middleware jobs and outbound integrations stay behind in Salesforce and must be rebuilt in SuiteCRM workflows or in your own integration layer. List every active automation and integration before the export, mark each as rebuild, retire or keep, and assign an owner. Email-to-case routes, calendar sync and marketing sync are common gaps that teams discover only after cutover.

Checking what each path leaves out

Before you rely on either export path, compare its output against your list of required objects, attachments and history. Because the path you choose determines what is missing, write a gap register that names each object, the export method that covers it, and the owner who will close each gap. Ask the implementation partner and your Salesforce admin to sign off the register before the first full extract.

The migration sequence from inventory to decommission

This sequence moves Salesforce Sales Cloud data and process into SuiteCRM in controlled stages, so each step produces evidence that the next one can rely on. Salesforce stays live until the team has reconciled records and confirmed users can work in SuiteCRM.

Inventory objects, fields, flows and integrations
The Salesforce administrator and a sales operations lead list every standard and custom object, field, validation rule, flow, approval process, report, dashboard and connected app in use, and note which are actually used by the sales team. Integrations such as email sync, marketing tools and ERP connectors get their own list with owner and data direction. Output: a signed-off inventory spreadsheet that marks each item as migrate, rebuild, retire or keep outside the CRM. You know it is done when every business process has a named owner and a decision.
Build a staging SuiteCRM 8 instance with the object mapping
Your platform team installs SuiteCRM 8 in a staging environment that matches your target production architecture, then maps each Salesforce object to a SuiteCRM module and each custom field to a SuiteCRM field. Check the compatibility matrix for supported PHP, Apache and database versions before installing, and confirm the release you deploy against the current SuiteCRM-Core releases. Before any staging test, take file and database backups and review customizations, because SuiteCRM's migration guidance warns that the migration may remove non-core files under the public/legacy folder. Output: a documented mapping table and a staging instance that loads a sample extract without errors.
Load and rebuild workflows in staging
Using the Data Export Service or Data Loader extracts, the implementation team imports accounts, contacts, leads, opportunities and notes into staging and rebuilds the flows from the inventory as SuiteCRM workflows, assignment rules and email templates. Each rebuilt automation is tested against the Salesforce behavior it replaces, including edge cases such as reassignment and closed-won transitions. Output: a test log showing each record count, each mapped field and each rebuilt process with a pass or fail result. You know it is done when the test log has no open critical defects.
Pilot with one team's data
A single sales team works in SuiteCRM with its own live pipeline for a defined period while Salesforce remains the system of record for everyone else. The pilot tests logins, permissions, reports, email capture and the daily tasks that team relies on. Users record what is missing or slower, and the team fixes mapping gaps before expanding. Output: a pilot sign-off from the team lead listing accepted gaps, open issues and the scope of the next wave.
Run in parallel and reconcile
For the agreed period, both systems stay live. Records created or changed in SuiteCRM are compared with Salesforce through scheduled exports, and reconciliation reports check record counts, owner assignments, pipeline totals and open activities by stage. Discrepancies are traced to a root cause, fixed in the mapping or the import, and retested. Output: a reconciliation report with zero unexplained differences in the agreed fields, approved by finance or sales leadership.
Cut over to SuiteCRM
The team freezes Salesforce writes, runs a final full extract and load into production SuiteCRM, repeats the reconciliation checks, and confirms that logins work through the identity provider you have configured, such as LDAP or SAML. Users are notified of the new access path and the support channel for the first days. Note that SAML logout behavior in SuiteCRM 8.7.0 and later does not end the SuiteCRM session when a user logs out at the identity provider, so brief users on this. Output: a cutover checklist signed by the project owner, with the Salesforce freeze time and the final reconciliation result recorded.
Decommission Salesforce after retention checks
Once the cutover is stable and the agreed observation period is complete, the team confirms that its retention obligations are met by a stored archive of Salesforce exports, removes integrations and connected apps, revokes user licenses, and asks Salesforce to close or downgrade the org according to the contract terms. Confirm the notice period and any data deletion terms with Salesforce in writing before you rely on them. Output: a decommissioning record that lists the archive location, access controls, revoked integrations and the date the subscription ended.

How Salesforce flows and automation are rebuilt as SuiteCRM workflows

Salesforce flows, validation rules, assignment rules and approval processes must be inventoried and then reimplemented in SuiteCRM as workflows, custom logic, or a documented decision to retire them. Converting each Apex trigger or flow one by one tends to reproduce behavior that nobody still wants, and it hides the rules that quietly protect data quality. Build a single register with one row per automation, listing the trigger, the object, the fields it reads and writes, the business owner and the reason it exists. Include lead assignment, opportunity stage changes, discount approvals and any rule that sends email or updates a related record. Then confirm, against the SuiteCRM version you install, which trigger types its workflow module supports (for example, record save, field change, scheduled runs or related-record events) and whether it can call external services. Do not assume parity from the Salesforce feature list.

Each rule needs test cases built from real exported records, not from the happy path. Useful edge cases include leads with missing country or owner fields, duplicate accounts, opportunities moved between stages in bulk, records owned by deactivated users, and approvals that are rejected, recalled or left waiting when an approver is unavailable. Confirm whether records loaded through the import tool fire workflows, because the answer changes the migration sequence and the cleanup plan. Run the test set in a staging copy of the migrated data first, then compare outcomes with what Salesforce produced for the same records during the parallel run. The SuiteCRM before you migrate guide is the right reference for preparing that staging environment and backups.

Ask the implementation partner for a written mapping that marks each automation as native workflow, custom code or retired, with the test evidence behind each mark. Custom code carries a recurring cost: it must be retested whenever SuiteCRM is upgraded, and SuiteCRM publishes minor 8.x releases on a regular cadence, so budget for that work in the support agreement rather than treating it as a one-off build. Keep the register under version control and assign an internal owner for each rule before cutover, so the people who approve sales processes can sign off on behavior changes.

Running Salesforce and SuiteCRM in parallel during cutover

In this approach, Salesforce is set to read-only for users once SuiteCRM holds the baseline data, and sales work moves to SuiteCRM during a defined window. Salesforce remains the reference copy until the final delta export is taken and loaded. The main risk is that records changed in Salesforce after the baseline export are missed, so the delta must be defined by a last-modified timestamp and checked against record counts per object.

Reconciliation: Compare record counts and key fields for accounts, contacts, opportunities and activities between the baseline, the delta and SuiteCRM, and keep a signed exception list for anything that does not match.
Sign-off: The sales operations lead signs off pipeline totals, and a named data owner signs off the reconciliation report before the freeze begins.
Integrations and email: Redirect inbound forms, mail-to-CRM capture and integration endpoints to SuiteCRM only after the delta load is verified, and disable Salesforce-side jobs so they cannot write new data.
Rollback: Keep Salesforce read-only but intact until the agreed review point, so the team can return to it if SuiteCRM fails verification. Changes made in SuiteCRM during the window must then be exported back manually.

Confirm with your Salesforce administrator how the org's export method and edition limit the delta, since the export cadence depends on the edition you hold.

Setting up login, hosting and the SuiteCRM platform for the migration

Start by fixing the target version and the stack before any data moves. SuiteCRM 8 pairs an Angular frontend with a Symfony backend, and the latest stable release listed in the SuiteCRM-Core repository is 8.10.2. Check the SuiteCRM 8 compatibility matrix for the PHP, Apache, database and operating system combinations that release supports, and build the production, staging and test hosts from that list only. Confirm the database engine and version with your DBA before provisioning, because a stack outside the matrix is the most common reason a migration rehearsal fails for reasons unrelated to the data. Keep at least one staging instance that mirrors production, since the migration documentation advises testing there first. If your current CRM is SuiteCRM 7 rather than Salesforce, the path is different. Moving from SuiteCRM 7 to 8 is documented as a migration, not an upgrade: you build a new SuiteCRM 8 environment and move the 7 data into it, after bringing the 7 instance to at least the 7.14.x line. Back up files and database, and review any customizations, because the migration may remove non-core files under the public/legacy folder. Most Salesforce exits do not need this step, but teams that already run an older SuiteCRM should not treat their existing instance as a simple upgrade target. Decide the sign-in model early, since it shapes user accounts and the cutover plan. SuiteCRM 8 supports LDAP, enabled with AUTH_TYPE=ldap, and SAML, enabled with AUTH_TYPE=saml. Confirm the exact configuration keys in the SuiteCRM 8 LDAP configuration reference and the SAML reference for your version. The SAML implementation in 8.7.0 and later does not support IdP-initiated logout or POST binding to the logout service, so ending a session at your identity provider does not end the SuiteCRM session. Plan for that with session lifetimes and user guidance, and test the behavior on your exact version before go-live.

What drives migration cost and duration

This table lists the main factors that raise or lower the effort of moving Salesforce Sales Cloud to SuiteCRM, with the reason each one matters and what to ask for in a written scope. Read it before requesting quotes, because most cost differences between two proposals come from these drivers rather than from the platform itself.

Driver	Why it moves cost or effort	How to keep it down and what to ask for
Number of custom objects and fields	Each Salesforce custom object needs a matching SuiteCRM module or relationship, and each custom field needs a definition, validation and report mapping. Field counts often grow over the years of an org's life.	Retire unused fields before extraction. Ask the quote to list every custom object and field with a mapping decision (map, merge, retire) and the count of modules it expects to build.
Volume and quality of data	Large record counts lengthen extraction, load and reconciliation. Duplicates, missing owners, invalid picklist values and broken lookups add cleansing work before any load succeeds.	Run a data profile on a sample export first. Ask for the record counts per object, the deduplication rules, and who signs off cleansed data before load.
Salesforce automations	Flows, Apex triggers, validation rules and approval processes must be read, re-specified and rebuilt as SuiteCRM workflows or custom code. Undocumented automation is the most common source of scope change.	Export a list of all active automations and their purpose. Ask the quote to state which are rebuilt, which are dropped by agreement, and which need custom development.
AppExchange packages and managed components	Each installed package may hold its own objects, triggers and integrations, and some have no SuiteCRM equivalent. Replacing one can mean a new integration or a manual process.	Inventory every installed package and its owner. Ask for a per-package decision and whether the quote covers replacement, custom build or retirement.
Integrations and interfaces	Connections to ERP, email, telephony, marketing tools and data warehouses each need new endpoints, credentials and monitoring. Salesforce-specific APIs and connectors must be rewritten against SuiteCRM interfaces.	List every system that reads from or writes to Salesforce, with direction and frequency. Ask the quote to price each integration separately so the team can defer some to a later phase.
User count, roles and training	Permissions, profiles and sharing rules must be rebuilt for each role. Training time grows with the number of users and the number of distinct processes they follow.	Group users into a small number of roles before design. Ask for the number of role templates, the training format and whether the client's own trainers deliver sessions.
Authentication and access setup	Single sign-on through LDAP or SAML requires identity provider configuration, testing and a decision on logout behavior. The SuiteCRM SAML reference notes that IdP-initiated logout does not end the SuiteCRM session, which may need a documented workaround.	Decide the sign-in model early. Ask the quote to state which identity provider integration is included and how logout behavior is tested and documented.
Parallel-run cycles	Running Salesforce and SuiteCRM side by side means repeated loads, reconciliation and user sign-off. Each extra cycle adds effort on both the data team and the business owners.	Agree the number of trial loads and reconciliation checks before work starts. Ask the quote to state how many parallel-run cycles are included and what happens if more are needed.
Staging, backup and customization review	Migration guidance calls for a staging instance, file and database backups, and a review of customizations, because the process may remove non-core files under the public/legacy folder. This adds setup and review work.	Ask for a staging environment in the client's infrastructure, a documented backup and restore test, and a written list of customizations kept or removed.

What usually goes wrong in a Salesforce to SuiteCRM move

Most failed CRM migrations fail on data and behavior, not on installation. The cards below cover the failure points that recur in Salesforce exits, from incomplete extracts to users who quietly keep working in the old system. Each card names the prevention step to build into the plan before cutover.

Incomplete exports from the wrong cadence

The Data Export Service runs weekly in Enterprise, Performance and Unlimited editions and every 29 days in Professional and Developer editions, so a export taken on the wrong day can miss weeks of activity. Records created after the last export never reach SuiteCRM unless you schedule a final delta extract. Confirm your edition, the export date, and whether the final cutover extract is captured with Data Loader or a manual run immediately before freeze.

Excluded content and missing attachments

Exports can leave out files, attachments and some object types depending on the method you choose, so history can disappear without an error. Email threads, documents and integration data are common gaps. Before cutover, compare record counts per object between Salesforce and SuiteCRM, and sample attachments on accounts and opportunities to confirm they were imported and linked correctly.

Duplicate and orphaned records

Re-running imports, merging accounts in two systems, or loading contacts without their parent accounts creates duplicates and orphans. Salesforce IDs are not meaningful in SuiteCRM, so keep the original ID in a dedicated external reference field for every object. Define the matching rule for accounts and contacts before the first load, and run a post-load report that flags contacts without an account and opportunities without a contact.

Customizations lost in a version migration

Moving from SuiteCRM 7 to 8 is a migration rather than an upgrade, and the migration docs warn that it may remove non-core files under the public/legacy folder. Custom fields, layouts and code in that folder can disappear silently. Inventory every customization, back up files and the database, and test the full migration on a staging instance before any production run.

Undocumented automation that stops working

Salesforce flows, validation rules, assignment logic and integrations often run without anyone listing them. When they stop, lead routing fails, stage changes stop triggering tasks and reports go stale. Build a register of every automation with its trigger, owner and business purpose, then rebuild each one as a SuiteCRM workflow or an external job and test it with real sample records.

Users reverting to old habits

If sales reps keep a spreadsheet or the old Salesforce login open, pipeline data splits across two systems and managers lose trust in both. Plan a fixed cutover date, a single freeze window for the old system, and role-based training on the screens each team uses daily. Track adoption by activity in SuiteCRM during the first weeks, and make the old system read-only once the cutover is signed off.

How the migration changes by size and starting point

A small sales team that uses standard objects such as accounts, contacts, leads, opportunities and tasks has the simplest move. Most of the data maps directly to SuiteCRM modules, and the main work is cleaning records, confirming picklist values and rebuilding a handful of list views and dashboards. Because few automations exist, the testing effort stays focused on data accuracy and daily user tasks.

Scope: Standard objects and a few custom fields, mapped one to one onto SuiteCRM modules and fields.
Testing: Import a sample into a staging instance, then compare record counts, owners and open pipeline totals against the Salesforce org.
Automation: Rebuild a small set of notifications and assignment rules as SuiteCRM workflows, and document each one before retiring the Salesforce version.
Cutover: A short parallel period in which users enter new records in one system only, with a final delta export to pick up late changes.
Admin skills: One internal administrator who can manage users, roles and the server, or a support agreement that covers those tasks.

Before committing, ask your implementation partner which of your objects and fields have no direct SuiteCRM equivalent, and confirm the export method against your Salesforce edition.

Questions buyers ask before a Salesforce to SuiteCRM migration

What drives the cost of moving from Salesforce to SuiteCRM?

The cost depends on the scope of the data and process you move, not on a list price for SuiteCRM, which is free to download under AGPLv3. Cost falls into a few components: hosting and the infrastructure that runs SuiteCRM, the implementation work to map objects and rebuild automation, data extraction and cleansing, testing, training, and ongoing support. Some of these are one-time, such as migration and build, while hosting, patching and support recur. The main drivers are the number of custom objects, the volume of Apex and flows to rebuild, the number of integrations, and whether you buy SuiteCRM support from SuiteCRM Ltd or from a services partner. Ask any provider for a written scope that separates one-time and recurring items, and compare it with your current Salesforce subscription and add-ons over the same period.

How long does a Salesforce to SuiteCRM migration take?

No single duration applies to every organization, so treat any fixed figure with caution. The timeline is set by the number of custom objects and fields to map, how much automation must be rebuilt as SuiteCRM workflows, the volume and quality of the data to clean, the number of integrations to replace, and how long parallel running and user acceptance testing take. Staging, backup and rehearsal runs add time before cutover. Confirm the duration with your implementation partner or internal team against a written plan with milestones, and ask which activities depend on decisions from your admins and data owners.

What does the migration need from our Salesforce admins and data owners?

The migration needs decisions more than keystrokes. Salesforce admins must document the objects, fields, record types, page layouts, validation rules, flows and Apex that define how the org works today, and confirm which of them still matter. Data owners must decide which records to keep, how to deduplicate accounts and contacts, which history to retain, and who signs off on field mappings and test results. Security and identity staff should confirm how users will sign in to SuiteCRM. Ask for a named owner for each area before work starts, because unresolved decisions are the most common cause of delay.

Can our internal team migrate from Salesforce to SuiteCRM alone?

A team with Salesforce admin experience, database skills and someone who can run SuiteCRM can often do a smaller migration in-house, especially with standard objects and modest automation. Larger orgs with heavy Apex, many integrations or regulated data usually need outside help for scoping, mapping, security configuration, testing and cutover. Whichever route you choose, check that someone owns patching, backups and upgrades after go-live. Ask any partner to state in writing which tasks they will do, which stay with your staff, and how knowledge transfers at the end. DeployOpen delivers fixed-scope implementation, and ongoing support is available as a retainer.

What happens to our Salesforce data and licenses when we exit?

Your Salesforce subscription is separate from your data, so you control the exit timing through your contract. Before you cancel, extract everything you need: Salesforce's Data Export Service produces CSV files in a compressed archive on a weekly cadence in Enterprise, Performance and Unlimited editions, and every 29 days in Professional and Developer editions, according to Salesforce Trailhead. Data Loader is the scripted option for repeatable exports. Check your contract for notice periods, data return terms and retention obligations, and confirm with Salesforce what happens to data after termination. Keep a verified archive of exports for records you must retain, and confirm how long your legal and compliance teams require it.

Can SuiteCRM replace our Salesforce integrations?

SuiteCRM can connect to other systems, but each Salesforce integration must be inventoried and checked individually. Start by listing every connected app, middleware flow, API consumer and AppExchange package, then confirm whether SuiteCRM 8 offers an existing connector, a documented API you can use, or whether custom development is needed. SuiteCRM 8 supports LDAP and SAML sign-in, which affects identity integrations, and SAML logout does not end the SuiteCRM session when you log out at the identity provider, so plan for that behavior. Ask for a written integration inventory with a replacement or retirement decision for each item before you commit to a cutover date.

How should we test SuiteCRM before we cut over from Salesforce?

Test on a staging instance that mirrors production, and run the migration more than once before go-live. SuiteCRM's migration guidance advises testing on staging, backing up files and the database, and reviewing customizations, because a migration may remove non-core files under the public/legacy folder. Test field mappings with real record samples, confirm permissions and sign-in with each role, check reports and dashboards, and reconcile record counts between Salesforce and SuiteCRM. Plan a parallel run where both systems are live for a defined period so users can verify data and process. Agree the exit criteria with business owners in writing.

Which SuiteCRM version and support model should we choose?

Choose a version based on the support you need, not just the newest release. SuiteCRM 8.10.2 is the latest stable version listed in the SuiteCRM-Core repository, and minor 8.x releases arrive roughly every eight weeks. Patch releases contain only security and bug fixes. Confirm the support model for the version you deploy, including whether you rely on community support or buy a package from SuiteCRM Ltd, such as SuiteASSURED. Check the compatibility matrix for your PHP, Apache and database versions before you provision hosts, and confirm the upgrade path you will follow after go-live.

How DeployOpen scopes, runs and supports a SuiteCRM migration

DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, including the SuiteCRM environment for a Salesforce exit. We agree the scope, deliverables and timeline in writing before work starts, so the extraction, mapping, workflow rebuild and parallel run are visible from the first week.

How we scope

Inventory of Sales Cloud objects, fields, reports, flows, Apex triggers and integrations that feed the migration
Decision on which Salesforce data and attachments move, and which history stays archived
Written scope listing environments, hosting location, identity sign-in method and cutover conditions

How we build

SuiteCRM 8 environment set up in your cloud account or data center, with the mapping of custom objects to modules documented
Test imports from Data Export Service or Data Loader extracts run on a staging instance before any production load
Backups of files and database taken before each run, with customizations reviewed for files the migration may remove

How we hand over

Parallel-run plan with reconciliation reports comparing record counts and key pipeline values between Salesforce and SuiteCRM
Runbooks for imports, backups, upgrades and user administration, written for your own admin team
Handover session covering workflow rebuilds, LDAP or SAML configuration and the known SAML logout limitation

How we support

Post-cutover support scoped in writing, covering issues found during the first business cycles
Ongoing upgrades and security patch reviews available as a retainer, aligned with SuiteCRM release timing
Continuous security testing of the SuiteCRM instance and its integrations available as a separate engagement

Migrate from Salesforce to SuiteCRM