SuiteCRM implementation plan and cost

What a SuiteCRM implementation involves and who usually runs it

A SuiteCRM implementation covers configuration, data, security, integrations, hosting and handover, and the software itself is free while that work is not. SuiteCRM is open-source and free to download and self-host, but the cost sits in the people and infrastructure that turn a fresh install into a system your sales and service teams use every day. If you have already chosen SuiteCRM 8 as a self-hosted CRM, the planning question is which of those components you will build yourself and which you will buy from a partner. Most organizations start this work for one of three reasons. The first is replacing a per-user CRM subscription, where the goal is to stop paying seat fees for every user. The second is consolidating from an existing SuiteCRM 7 instance, which SuiteCRM documents as a migration into a new SuiteCRM 8 environment rather than an in-place upgrade. The third is bringing sales and service onto one platform so that accounts, cases and renewals share the same data. Each trigger changes the scope. A seat-cost replacement may mostly be configuration and data import, while a consolidation carries customizations and history that need mapping. Write down which trigger applies before you request any quote.

On delivery, the short answer is that a team with CRM administration skills, PHP experience and database administration experience can carry out much of the work in-house. The harder parts are usually the ones that need judgment across the whole system: deciding the module and field model, designing security groups and roles, and testing that permissions behave as intended for each team. Check whether your staff have done this before on any CRM, because role design errors are costly to find late. Migration steps, upgrade cadence and single sign-on setup each have their own detailed topics on this site, so this section only establishes where they fit in the plan.

Before deciding who does the work, ask three questions of your own team. Who will own the CRM after go-live, including the Studio changes, workflow updates and scheduled jobs? Who can test a PHP or database change on a staging copy before it reaches production? Who will answer for backups and restore tests? If the answers are unclear, a partner can cover the build while your team learns to run it. If they are clear and your staff have the skills, in-house delivery is a realistic option for a contained scope. Either way, confirm the supported PHP, Apache and MariaDB or MySQL versions for the SuiteCRM 8 release you choose before procurement, because the compatibility matrix changes between releases.

Whichever route you choose, put the scope in writing before work starts. A written scope should list the modules and fields in use, the security groups and roles, the workflows and integrations, the data sources for import, the hosting model and the training and handover deliverables. Ask any partner to separate one-time costs, such as design, configuration, data import and training, from recurring costs, such as hosting, support packages and the admin time you will keep spending after go-live. Ask what drives each cost up, such as the number of integrated systems or the volume of records to clean. A quote that cannot explain its components is hard to compare with an in-house estimate, so require the breakdown.

What a fixed-scope SuiteCRM implementation includes

A fixed-scope SuiteCRM 8 engagement is built from a set of work packages, each ending in a named deliverable the client keeps. The scope, deliverables and timeline are agreed in writing before work starts, and anything the document does not list is handled as a change request with its own agreed scope.

Solution design

The design document records which sales, service and marketing processes SuiteCRM will support, which modules and relationships are needed, and which standard features are kept as they are. It is the reference for every later decision. Check that it lists what is out of scope, because that list is what prevents disputes about extra work later.

Modules, fields and layouts

This package delivers a configured instance with standard modules adjusted through Studio, any custom modules built in Module Builder, and the fields and page layouts users will see. The client receives a field inventory that maps each field to its purpose and owner. Ask whether custom fields are listed one by one in the scope, since the count drives configuration effort.

Security groups and roles

Access rules are set through roles, security groups and record ownership, so each team sees only the data it needs. The deliverable is a role matrix signed off by the client, plus test accounts for each role. Confirm early who approves access decisions, because these rules are the most common source of rework after go-live.

Workflows and email templates

Automated steps such as assignment rules, status changes, reminders and outbound templates are built and documented. The client receives a workflow register listing each trigger, action and owner. Decide with the partner which logic belongs in workflows and which needs custom code, because custom code adds upgrade testing later.

Data import and mapping

Existing contacts, accounts and history are mapped to SuiteCRM fields, cleaned and loaded in controlled batches. The deliverable is a mapping specification, import logs and reconciliation reports showing record counts by source. Ask who supplies and cleans the source data, since slow data preparation is a frequent cause of schedule slip.

Named integrations

Each named system, such as an ERP, marketing platform, telephony system or web form, is connected through the SuiteCRM 8 API with agreed authentication, field mapping, sync direction and error handling. The client receives an integration specification and test results per connection. Only the systems named in the written scope are included, so list each one explicitly.

Login and identity setup

Sign-in is configured with LDAP or SAML, the two login methods the SuiteCRM 8 documentation describes, or with local accounts where that is the agreed choice. The deliverable is a configured login path and a note on limits, including that a SAML logout at the identity provider does not end the SuiteCRM session. Confirm which identity provider and directory are in scope.

Hosting build and handover

The hosting build covers the web server, PHP, database and file storage in the client's environment, sized against the supported versions in the SuiteCRM compatibility matrix. Testing, training and handover close the engagement with test records, user training material and a runbook for backup, restore and patching. Ask whether hosting is in your infrastructure, SuiteCRM Hosted or another provider, because that choice changes who maintains the server after handover.

What makes a SuiteCRM implementation cost more or take longer

This table lists the factors that most often move SuiteCRM effort up or down, with the reason each one matters and how to keep it contained. Read each row as a lever you control during scoping, since the same platform can cost very different amounts depending on these choices. Most of the savings come from deciding scope early, not from negotiating rates later.

Driver	Why it changes effort	How to keep it down
User roles and teams	Each role needs its own security groups, role permissions, field visibility and list views, and each one must be tested with real accounts before go-live.	Start from a short list of standard roles for sales, service and marketing, and add exceptions only when a team has a documented need.
Modules and custom fields	Every custom module or field adds a data model, layout, permissions and import mapping, and each one must survive future upgrades.	Use standard modules and existing fields first, and limit new fields to data that a report, workflow or integration needs.
Volume and quality of source data	Duplicate accounts, inconsistent picklist values and missing owners slow mapping and cleanup, and often push back the import date.	Clean and deduplicate data in the source system before extraction, and agree which records are in scope for migration.
Number and type of integrations	Each API connection needs authentication, field mapping, sync direction, error handling and monitoring, and two-way sync is the hardest case.	Limit the first release to the integrations that users need on day one and defer the rest to a later phase.
Custom workflows and code extensions	Workflows are cheaper to build and maintain than custom code, but complex logic written as code needs testing against every upgrade.	Build with standard workflows, scheduled jobs and email templates first, and write custom code only when those cannot meet a defined requirement.
Number of environments	Development, staging and production each need configuration, data refreshes and test cycles, and staging is needed for any migration test.	Keep to the environments the release process requires, and automate configuration deployment so each environment is built the same way.
Login requirements (LDAP or SAML)	Directory and SAML connections add identity provider setup, attribute mapping, group mapping and testing for login and logout, including the documented SAML logout limitation.	Confirm the identity provider, attributes and groups before build, and agree in writing how logout behavior will be explained to users.
Hosting model	Self-hosting in the client's infrastructure adds server build, web and database configuration, backup, monitoring and patching work, while a hosted offer moves some of that work to the provider.	Decide the hosting model in scoping and ask any hosted provider to confirm in writing which operational tasks it covers.
Compliance evidence needs	Auditors may expect documented access reviews, change records, backup restore tests and patch evidence, which adds design and collection work.	Define the evidence list at scoping and build the logging, review and change routines to produce it as part of normal operations.

How a SuiteCRM 8 implementation runs, phase by phase

Each phase ends with a named output the client keeps, so scope, design decisions and test evidence are visible before the next phase begins. The sequence below is the order DeployOpen works through on a fixed-scope engagement, and the timing of each phase is set in the written scope.

Run discovery and map processes
DeployOpen works with sales, service and marketing leads to map how leads, accounts, cases and campaigns move today, and which spreadsheets, mailboxes or legacy systems hold that work. The client provides process owners, current reports and a list of systems to connect. The output is a process map and a prioritized requirements list with named owners, which the client signs off before design starts.
Produce the solution design
The design fixes the modules in use, the roles and security groups that match the approved process map, the data model including custom fields and relationships, and an integration map listing each connected system, its data flow direction and its authentication method. Confirm the target version at this stage by checking the chosen SuiteCRM 8 release against the current compatibility matrix for PHP, Apache and database support, because minor releases arrive roughly every eight weeks. The output is a written design document the client approves.
Build the environment and hardening baseline
Engineers provision hosting in the client's cloud account or data center, install SuiteCRM 8 on the PHP, web server and database versions confirmed in the design, and apply a baseline covering TLS, web server settings, file permissions, secrets handling, backups and access logging. Development, test and production environments are built in this phase so changes move through them in order. The output is a documented environment, a successful backup and restore run, and a hardening checklist the client can audit.
Configure and build customizations
Configuration covers Studio layouts, fields, roles and security groups, followed by Module Builder work for custom modules, logic hooks and workflows that the design requires. Standard configuration is used wherever it meets the requirement, which keeps custom code small and easier to carry through later upgrades. The client receives a build in the development environment, a change log, and a list of customizations with the reason each one exists, so the upgrade team knows what to retest.
Map data and run a trial import
The team maps fields from the source system to SuiteCRM 8 records, agrees transformation rules for duplicates, picklist values, owners and dates, and loads a trial extract into the test environment. The client's data owners review sample records and reconciliation counts for each object. When the source is SuiteCRM 7, the migration documentation advises bringing that instance to 7.14.x or later first, testing on a staging instance and backing up files and database. The output is a mapping specification and a trial import report with counts and exceptions the client has signed off.
Build and test integrations
Each connection in the integration map is built against the agreed authentication method, field mapping, sync direction and error handling, then tested with test accounts in the test environment. Where SSO is in scope, LDAP or SAML login is tested together with logout behavior, since the SAML implementation in 8.7.0 and later does not end the SuiteCRM session when logout starts at the identity provider. The output is a test record for each connection covering success paths, failed calls and retries, plus an operations runbook.
Run user acceptance testing
Named business users run scripted scenarios drawn from the process map, such as lead to opportunity to quote, case escalation and campaign follow-up, in the test environment with migrated data. Each defect is logged, graded and fixed in agreed order before retest. The client keeps the signed test scripts and defect log, and acceptance is recorded in writing against the approved requirements. Changes found in this phase go through the same change control as the build.
Cut over, go live and hand over
The cutover plan sets the freeze on the legacy system, the final data load, the integration switch-over, the rollback point and the approver for each step. After go-live, DeployOpen supports the first live period and trains administrators and end users on the configured system using the client's own records and workflows. Handover includes admin documentation, the runbook, backup and restore evidence, and the support options set out in the written scope. The output is a closed cutover record and a handover pack the client's team can operate.

One-time and recurring SuiteCRM implementation costs

The SuiteCRM 8 core software carries no license fee. The core repository is licensed under the GNU Affero General Public License version 3, so you can download and self-host it without paying SuiteCRM Ltd for the software itself. The money goes elsewhere: infrastructure, implementation labor, data work, integration build, training and handover. Each of these is a cost line you will pay someone for, whether that is your own staff, a partner or a vendor. Before you build custom code, ask counsel what the AGPL obligations mean for modifications you run for internal users and for any users who interact with the system over a network. The answer affects how you structure custom modules and whether you keep them in a private repository.

One-time costs cluster around the build. Design covers modules, fields, security groups, roles, page layouts and workflow rules, and it is the phase where scope changes are cheapest. Build covers configuration in Studio and Module Builder plus any custom code. Data import covers field mapping, cleansing, deduplication and test loads into staging. Integration build covers the APIs, authentication, sync direction and error handling for each connected system. Testing and training follow, and handover adds the runbooks, configuration records and admin documentation your team needs after the partner leaves. Each phase can grow with the number of user groups, source systems and approval paths, so the number of those items is the first thing to pin down in any estimate.

Recurring costs continue after go-live and are easy to underbudget. Hosting is the largest, whether you run it in your own cloud account or buy SuiteCRM Hosted. Backups and periodic restore tests, operating system and PHP patching, and database maintenance all recur. Minor SuiteCRM 8 releases arrive roughly every eight weeks, and each upgrade needs regression testing of your customizations, because patch releases can change behavior your extensions rely on. A support package such as SuiteASSURED is optional but common. Internal admin time is the cost most often missed: someone must review security groups, manage user lifecycle and triage workflow failures every month, even when a partner handles the technical work.

SuiteCRM Ltd sells several paid services around the free software, including the SuiteASSURED support package, SuiteCRM Hosted, implementation, training and migration. These are optional alternatives to some of the work described above, not requirements. Choosing SuiteCRM Hosted replaces a hosting and patching line, but you still need internal admin time and a plan for customizations. Buying vendor implementation replaces some labor, but you still need a named owner for requirements and sign-off. When you request a quote from any provider, ask for labor itemized by phase, a written list of assumptions such as the number of source systems and data volume, explicit exclusions, the change request rate for out-of-scope work, the process for upgrade testing after go-live, and a clear statement of who owns and pays for hosting and third-party licenses.

Which SuiteCRM implementation work teams keep in-house and which they outsource

This table shows which parts of a SuiteCRM 8 implementation teams often keep internally and which they often hand to a partner, along with the skills each task needs. Use it to map your own staff against each row, since the split depends on your team's existing capacity and experience. Business ownership and user acceptance testing usually stay with the business, while build and integration work is where specialist skills matter most.

Work item	Typical owner	Skills required
Business process ownership	Usually in-house: sales, service and marketing leaders define how the process should work	CRM administration, business process analysis
Final data decisions	Usually in-house: data owners decide which records, fields and history are kept and how duplicates are resolved	CRM administration, knowledge of source system data
User acceptance testing	Usually in-house: named business users test workflows, layouts and reports before go-live	CRM administration, test planning, test automation for regression checks where used
Day-to-day admin	Usually in-house: users, roles, security groups, picklists and routine configuration changes after go-live	CRM administration
Solution design	Often outsourced or shared: architecture of modules, fields, roles, integrations and hosting is agreed before build	CRM administration, solution architecture, API and data engineering
PHP and database build and hardening	Often outsourced: server build, PHP and MariaDB or MySQL configuration, and hardening against the supported version matrix	Linux and web server, PHP and MariaDB or MySQL
LDAP or SAML setup	Often outsourced: login integration with the directory or identity provider, tested with real accounts and logout behavior	Identity provider administration, Linux and web server, PHP
Integration build	Often outsourced: API connections to ERP, marketing, telephony or web forms, including authentication and error handling	API and data engineering, PHP
Data mapping and trial imports	Often outsourced or shared: field mapping and repeated test loads from the source system, with the business approving results	API and data engineering, CRM administration, MariaDB or MySQL
Cutover support	Often outsourced or shared: go-live runbook, final import, DNS and certificate changes, and post-cutover checks	Linux and web server, MariaDB or MySQL, CRM administration, test automation

What goes wrong in SuiteCRM implementations and how to prevent it

Most SuiteCRM delays and rework come from a small set of decisions made early or skipped under time pressure: platform versions, customization choices, access design, data quality, login behavior, testing and ownership after go-live. Each card below names one of these failure points and the check that prevents it, so the plan and budget reflect the work that actually has to happen.

Platform versions outside the compatibility matrix

Teams sometimes pick a PHP, Apache, MariaDB or MySQL version because it is already installed on their servers. SuiteCRM 8.10 supports 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. Before scoping hosting, check the compatibility matrix for the exact release you plan to deploy, and budget a platform build step if your standard images do not match it.

Custom code built where configuration would do

Custom PHP is often written for a field, layout or approval step that Studio, Module Builder or a workflow could handle. Each custom component then needs testing and rework at every minor upgrade, which recurs on SuiteCRM's roughly eight-week minor cycle. During scoping, ask for each requirement whether configuration or workflow can meet it, and record custom code as a separate, costed line with an owner.

Role and security group design that exposes records

Roles and security groups are often copied from the previous CRM or set up around org charts that have since changed, which leaves some users able to see accounts, opportunities or service cases outside their territory. Map each team's data visibility needs before building roles, then test with a sample user from every role. Include the review of these groups in the ongoing admin plan, since staff changes will otherwise drift the access model.

Data imported without cleansing or mapping sign-off

Importing contacts, accounts and history from spreadsheets or a legacy CRM without field mapping approval produces duplicate records, mixed date formats and orphaned relationships that users notice within days. Require a signed field mapping document per module, a duplicate review and a sample import reviewed by the business owner before the full load. Data cleansing is usually the largest variable effort in migrations, so ask a partner to show how it is scoped.

Login configured without testing logout behavior

With SAML login in SuiteCRM 8.7.0 and later, signing out at the identity provider does not end the SuiteCRM session, because IdP-initiated logout and POST binding to the logout service are not supported. Users may stay signed in on shared machines after they are removed from the directory. Test sign-in and sign-out from both sides with a real test account, document the limitation for users and security staff, and confirm the compensating control, such as session timeouts or endpoint policy, before go-live.

Cutover without a staging rehearsal

Skipping a staging run is a common way to lose a go-live window. The SuiteCRM migration documentation advises testing on a staging instance, backing up files and the database, and reviewing customizations because the migration may remove non-core files under public/legacy. Schedule at least one full rehearsal with timed steps, a documented rollback and a sign-off checklist, and treat any unresolved staging defect as a reason to delay cutover.

No named owner for patching after go-live

Once the system is live, patch releases and minor upgrades continue on their own schedule, and no one is assigned to apply them. Security fixes then wait until a problem appears. Name an internal owner for platform patching, assign a partner or support package for upgrade testing, and agree how customizations are retested before each release. This recurring work belongs in the cost model from the start.

How a SuiteCRM implementation changes by starting point

A new deployment has no legacy records to map, so the work centers on design decisions made before anyone enters data. Scope is set by the modules, fields, security groups and roles, and process rules the teams will use from day one. Sales, service and marketing leads should own those decisions because they define what the system must record.

Module and field design: agree which modules, fields and layouts are needed at launch and which can wait.
Security groups and roles: define access by team and record ownership before user accounts are created.
Initial workflows and templates: decide which automations are needed at go-live, such as lead assignment or email templates.
Test data and training: prepare sample records for acceptance testing and plan user training on the agreed layouts.
Hosting model: choose between your own infrastructure and SuiteCRM Hosted, which determines who operates the platform after launch.

Check that the launch scope is signed off in writing, since changes to modules and roles after build usually need more rework than the original decisions. Custom module detail is covered in the customization topic, and workflow detail in the workflow automation topic.

What your team must provide before a SuiteCRM implementation starts

The most useful thing your team can do before a SuiteCRM implementation starts is name the people who will make decisions. Each of the sales, service and marketing processes needs a named business owner who can approve lead stages, case queues, quote handling and campaign rules without waiting for a committee. An executive sponsor should be named at the same time, with authority to settle scope trade-offs when two departments want different field lists or approval paths. Without these two roles, the design phase tends to stall on questions that only a business owner or sponsor can answer. Confirm the names, their time commitment and their backup before the kickoff date is set.

Technical access is the second group of inputs. The implementation team needs accounts on the target hosting environment, whether that is your cloud subscription, your data center or an air-gapped network, along with the ability to create servers, databases, DNS records and TLS certificates. Check the SuiteCRM 8 compatibility matrix against your standard server images, because supported PHP, Apache, MariaDB and MySQL versions are fixed points in the build. If login will use SSO, the identity provider administrator must be available to register the application and to confirm the attribute list for username, email, groups and roles. Ask that administrator now whether the identity provider can send logout requests, since SuiteCRM 8.7.0 and later SAML does not end the application session when a user signs out at the identity provider.

Data and integration inputs are often the longest lead items. For each object you plan to migrate, such as accounts, contacts, leads, opportunities and cases, provide an export and name a data owner who can answer questions about duplicates, required fields and retention rules. Provide a list of every system that must connect to SuiteCRM, with the direction of data flow, the API access available from each vendor and your credentials policy, including who issues service accounts, how secrets are stored and how often they rotate. Also provide written decisions on user roles, security groups, approval rules for discounts or refunds, and the standard reports that managers need on day one. These decisions drive the configuration more than any technical choice does.

Finally, name the people who will test and run the system. A user acceptance test team should be drawn from the business, not from the project, and each tester needs time booked in advance to run scripted scenarios. Name the administrators who will receive handover and carry the system after go-live, including who approves changes and who reviews patch releases. The drivers table later on this page shows that late delivery of these inputs is the most common cause of schedule slippage, so treat each item here as a dependency with an owner and a due date. Ask the implementation partner to confirm the list in writing before the plan is baselined.

How much does a SuiteCRM implementation cost and how long does it take?

Does SuiteCRM itself cost anything to use?

The SuiteCRM 8 software has no license fee. SuiteCRM is free to download and self-host, and its core repository is licensed under the GNU Affero General Public License version 3. You still pay for the things that run and change it: infrastructure to host it, implementation and customization work, data migration, training, and ongoing support. SuiteCRM Ltd sells its own paid services, including the SuiteASSURED support package, SuiteCRM Hosted, implementation, training and migration. Those are optional. Hosting and services can come from your own team, a partner, or a mix, so ask each vendor to state which costs they include and which they leave to you.

Typical paid components:

Hosting and backups in your cloud or data center
Implementation, configuration and customization
Data import and migration
Integrations, testing and training
Support and upgrades, either in-house or under a retainer

What factors make a SuiteCRM implementation cost more or less?

Cost follows scope. The main drivers are the number of modules and custom fields, the complexity of security groups and roles, the number and depth of workflows, how much historical data must be cleaned and mapped, how many external systems must connect, and how many users must be trained. Single sign-on, high availability and a staging environment for testing each add defined work. Migrations from SuiteCRM 7 or another CRM usually add mapping and cutover effort. Each driver should appear as a line item in a written scope so you can see what changes the price. Cost is one-time for design, build, migration and training, and recurring for hosting, support, upgrades and admin time. Ask partners for a quote that separates these two groups.

How long does a SuiteCRM implementation take?

No fixed duration applies to every SuiteCRM project. The timeline is set by the written scope and the drivers listed above, plus how quickly your team can make decisions, supply data and test. A small deployment with standard modules and a few users will run far shorter than a multi-team rollout with custom modules, SSO and several integrations. Ask the partner for a phased plan with milestones for discovery, build, data migration, testing, training and go-live, and for the assumptions behind each phase. Compare that plan against your own calendar, including freeze periods, budget cycles and the availability of your business owners.

Can our own team implement SuiteCRM without a partner?

Yes, if you have the skills and time. SuiteCRM 8 is self-hosted, so the team needs administration experience, Linux server skills, working knowledge of PHP and a supported database such as MariaDB or MySQL, and the ability to read release notes and test changes. Check the compatibility matrix for the PHP, Apache and database versions your chosen release supports. The harder parts are usually business process design, data mapping, security role design and integration testing, because they need people who know how the business works. Many teams split the work: they run the platform and a partner handles migration, custom modules or integrations. Make that split explicit in the plan.

What does the work need from our team?

Most of the effort falls on your people, so plan for it before signing. You will need a named business owner for each area (sales, service, marketing), a decision maker who can approve field and workflow designs, and access to the systems that hold current data. An administrator or platform owner must provide servers or cloud accounts, network paths, DNS, certificates and identity provider settings. Testers from each team must check records, permissions and workflows in a staging environment, and they need time to do it. Trainers or super users will need time to learn the system and train others. Name these people and their hours in the plan so the schedule reflects them.

How should we compare partner quotes for SuiteCRM?

Compare quotes on structure, not total alone. A useful quote itemizes each phase (discovery, design, build, data migration, integration, testing, training, go-live and support), lists the modules, fields, workflows and integrations in scope, and states the assumptions behind each estimate, such as data quality, number of review rounds and availability of your staff. It should name exclusions, such as hosting, third-party licenses, or post-go-live fixes. Ask for the change rate or how changes outside scope are priced and approved. Also confirm who owns the code, configuration and documentation at handover. A low total with broad exclusions can cost more than a higher quote with clear boundaries.

What should a SuiteCRM quote ask for in writing?

Ask for a written scope that lists deliverables, acceptance criteria and dates for each milestone. Request the list of assumptions and exclusions, the rate for out-of-scope changes, and the approval process for those changes. Confirm which environments the partner will build (development, staging and production) and who provides hosting and backups. Ask how testing and rollback will be handled and what documentation will be delivered. For recurring costs, ask what ongoing support, upgrades and monitoring include and how often they are scheduled. Finally, ask how the partner will keep the platform on supported PHP and database versions, since that affects both cost and risk over time.

How DeployOpen scopes, delivers and hands over SuiteCRM implementations

DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports SuiteCRM inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. Most engagements are fixed-scope, so modules, roles, workflows, data import, integrations, hosting and training are agreed in writing before work starts.

How we scope

The written scope lists modules, fields, security groups and roles, workflows and layouts before any build starts.
Data import, integrations and migration sources are named, with the systems, owners and cutover approach recorded.
Hosting, training and the support model are costed separately so you can see one-time and recurring items.

How we build

Customizations are built on standard SuiteCRM extension points so they can be retested at each upgrade.
Role and security group rules are tested with named test users for each sales, service and marketing persona.
Imports and integrations run first on a staging instance, with a backup of files and database taken beforehand.

How we hand over

Handover includes configuration records, custom code, the as-built documentation and a log of decisions made.
Administrators receive runbooks for backups, restores, scheduler jobs, user provisioning and access reviews.
Users receive training scoped to their roles, with materials that match the layouts you configured.

How we support

Ongoing support is available as a retainer covering upgrades, patch testing and fixes to your customizations.
Upgrades follow SuiteCRM's minor release cycle, with compatibility checks against PHP and database versions first.
Ask which SuiteCRM 8 extended support release, if any, applies before you fix a version.