SuiteCRM vs Dolibarr: when each one is the better choice
Choose SuiteCRM when the CRM process is the main work and you have people to run it; choose Dolibarr when you need invoicing, stock and projects in the same application and would rather run one system than two. Both are PHP applications on MySQL or MariaDB, so the hosting skills your team already has matter less here than the shape of the business. SuiteCRM is a dedicated CRM with a mature set of sales, case and campaign modules, which suits a sales organization with multi-stage pipelines, service queues and marketing campaigns that need their own owners. That advantage only matters if someone on your team will configure and maintain those processes. SuiteCRM 8 also carries built-in LDAP and SAML sign-in, which matters if your directory must control access.
Dolibarr is the stronger choice when the CRM is one part of a small business's administration. Its module set covers proposals, orders, contracts and help desk alongside invoicing, stock, projects and HR, and you enable only the modules you need. That keeps quotes, invoices and inventory in one database, which removes integration work between a CRM and a separate accounting or stock tool. The advantage weakens as sales complexity grows, because Dolibarr's CRM depth is narrower than a dedicated CRM's. Ask the Dolibarr Association or a partner to show how the sales and invoicing modules handle your real quote-to-cash path before committing.
The decision turns on three questions. First, how deep is your CRM process: if you run long pipelines, case management and campaign tracking, SuiteCRM fits better. Second, do you need ERP functions now or within the next few years: if invoicing and stock are needed from day one, Dolibarr removes a system. Third, which license terms your business can accept, since SuiteCRM is AGPL-3.0 and Dolibarr is GPL-3.0, and the obligations differ most for hosted modifications. Have counsel review the license against your planned customization and distribution before you build on either.
Which platform fits which scenario
This table maps common team scenarios to the platform that usually fits better, with the reason tied to supplied facts about module depth and release tracks. Read each row as a starting point: the answer shifts with your own sales process, service workflows and invoicing rules, so confirm module coverage against those workflows before deciding.
| Scenario | Better fit | Why |
|---|---|---|
| Sales team running long B2B pipelines with quotes and approvals | SuiteCRM | SuiteCRM is a dedicated CRM with a broad sales module set. Dolibarr also offers proposals and orders, so confirm whether its quote and approval steps cover your pipeline stages before choosing it. |
| Service team handling cases and customer queues | SuiteCRM | SuiteCRM's case handling is a core CRM function. Dolibarr lists a help desk module, so check its queue, SLA and escalation features against your service process. |
| Marketing team running multi-step email campaigns | SuiteCRM | Campaign management is a dedicated area in SuiteCRM. Dolibarr's published module list does not name a campaign module, so confirm whether it meets your needs. |
| Small business that needs invoices and stock with light CRM | Dolibarr | Dolibarr combines invoicing, stock and CRM in one application, and lets you enable only the modules you need. A dedicated CRM would require a separate accounting or stock system. |
| Project-based service business tracking time and delivery | Dolibarr | Dolibarr lists projects and timesheets alongside invoicing, so project work can link to billing in one system. Confirm how time-based billing and milestones match your contracts. |
| Team that wants one system for CRM and back office | Dolibarr | Dolibarr covers CRM, invoicing, stock, HR and projects in one PHP application. SuiteCRM is narrower, so back-office functions would need separate tools. Confirm depth in each module, since breadth can mean less depth in some areas. |
| Team already on SuiteCRM 7 and planning its next step | SuiteCRM | SuiteCRM 7.15 is an extended support release with security fixes until January 2028, and moving to 8 is a migration with its own guide. Dolibarr would be a different migration, so weigh the effort of either path. |
How SuiteCRM and Dolibarr are built and what that means for operations
SuiteCRM and Dolibarr are both PHP applications that most teams host themselves, but they differ in how many products sit inside one codebase, which database they expect and how identity and extensions are wired in. Each card below is a decision that changes patching, backup and staffing, so check them against your own environment before you commit.
PHP application and database
SuiteCRM 8.10 is documented on PHP 8.2, 8.3 and 8.4, Apache 2.4, and MariaDB or MySQL, so your existing LAMP or LEMP skills carry over. Dolibarr runs on MySQL, MariaDB or PostgreSQL and on any web server that runs PHP, which matters if your database standard is PostgreSQL. Confirm that your chosen PHP version sits in the vendor's current matrix before you build, and check the database versions in your change calendar. Staff who already patch PHP and the database will carry most of the run load.
Deployment options
Dolibarr can run on premises, on virtual or dedicated machines, in Docker, or as SaaS through cloud providers and partners. SuiteCRM is free to download and self-host, and SuiteCRM Ltd sells hosting as a separate service. In either case, the deployment choice sets who owns backups, host patching and recovery testing. Ask any partner which of those tasks they take on, in writing, and which stay with your team.
Module model
Dolibarr is one application with modules you switch on. Invoicing, stock, projects, HR and CRM share one database and one user model, so a sale can flow into an invoice and a stock movement without an integration. SuiteCRM is a dedicated CRM with sales, case and campaign depth. Choose Dolibarr when the business case depends on those back-office records, and SuiteCRM when the pipeline and service workflows are the core need. Enabling modules later adds testing and upgrade scope either way.
Identity options
SuiteCRM 8 supports sign-in through LDAP, configured with AUTH_TYPE=ldap, or SAML, configured with AUTH_TYPE=saml. The 8.7.0+ SAML implementation does not support IdP-initiated logout or POST binding to the logout service, so ending a session at the identity provider does not end the SuiteCRM session. Confirm how Dolibarr's authentication options fit your directory before you assume parity, and test logout and account disablement in staging.
Extension path
SuiteCRM customizations go through its module tooling, and every custom file needs review at each upgrade. Dolibarr extends through the DoliStore add-on marketplace and a low-code Module Builder. Third-party modules from either marketplace need the same review as your own code: check the author, the last release date and the license before installation. Budget for someone who can read the upgrade notes and retest the custom pieces after each release.
Resource footprint and staffing
Dolibarr's prerequisites page estimates about 150 MB for program files and 35 MB for an initial database, plus storage for uploaded and generated documents, and recommends at least a 1 GHz CPU for 30 or more users. Those figures are minimums for the application, not a sizing for your load. Ask your team to size the database, document storage and backup window for your real user count, and confirm the figures with the vendor before you commit to a host.
Side-by-side capabilities, licenses and requirements
This table compares SuiteCRM and Dolibarr on license, release lines, stack, CRM depth, back-office modules, identity options and vendor support. Read each row as a fit question: the condition column shows when a difference matters, and the confirm notes mark where the supplied facts stop.
| Capability | SuiteCRM | Dolibarr | Condition or note |
|---|---|---|---|
| License | AGPL-3.0 (SuiteCRM-Core and SuiteCRM repositories) | GPL-3.0 (Dolibarr GitHub repository) | AGPL-3.0 adds network-use obligations for modified versions. Have legal counsel confirm what this means for your deployment and any custom code. |
| Release lines and latest versions | SuiteCRM 8.10.2 and 7.15.2, both published July 31, 2026 | Dolibarr 24.0.0 (August 20, 2026) and 24.0.1 (September 7, 2026); 23.0 and 22.0 still get maintenance releases | SuiteCRM 7 is an extended support line with security fixes until January 2028. Dolibarr's line is a single current major with older maintenance lines. |
| Supported databases | MariaDB 10.6, 10.11, 11.4, 11.8; MySQL 8.0 and 8.4 (SuiteCRM 8.10.x) | MySQL 5.7.7 or newer, MariaDB 10.3 or newer, PostgreSQL 9.1.0 or newer; Microsoft SQL Server is experimental | Dolibarr supports PostgreSQL. SuiteCRM 8.10.x does not list it in the supplied matrix, so confirm before choosing it. |
| PHP and web server | PHP 8.2, 8.3 and 8.4; Apache 2.4 on Linux, Unix or macOS | Any web server that runs PHP, such as Apache, Nginx, Lighttpd or IIS | Dolibarr is more flexible on web server. Choose SuiteCRM if you need the supported Apache 2.4 path listed in its matrix. |
| CRM depth: sales, cases and campaigns | Sales pipeline, cases and campaign modules as a dedicated CRM. Confirm the exact campaign and case features in SuiteCRM documentation. | Proposals, orders, contracts and help desk modules | Choose SuiteCRM when pipeline, service and marketing depth are the main need. Choose Dolibarr when quotes, orders and contracts are enough. |
| Invoicing, stock and projects | Not a supplied SuiteCRM capability; confirm with the vendor if you need these in the same application. | Invoicing, stock, manufacturing (MRP), point of sale and projects modules | Dolibarr wins where invoicing, stock and projects must sit in one application with the CRM. Dedicated CRM teams may prefer a separate accounting system. |
| Identity options | LDAP (AUTH_TYPE=ldap) and SAML (AUTH_TYPE=saml) in SuiteCRM 8. From 8.7.0, SAML does not support IdP-initiated logout, so logging out at the identity provider does not end the SuiteCRM session. | Confirm supported SSO and directory options against Dolibarr documentation before planning integration. | Where single sign-out is a control requirement, test SuiteCRM SAML logout behavior in staging before go-live. |
| Extension model | SuiteCRM 8 modules and configuration within the open-source core; confirm packaging rules for custom modules with the vendor | Modular ERP and CRM with DoliStore add-on marketplace and a low-code Module Builder | Dolibarr's add-on marketplace and Module Builder suit teams that extend often. Review add-on licensing and maintenance before adopting them. |
| Vendor and commercial support | SuiteCRM Ltd sells SuiteASSURED support, SuiteCRM Hosted, implementation, training and migration services | Dolibarr Association (founded 2009) and DoliCloud, described as the official preferred partner, offers SaaS hosting | Ask each vendor for written support terms, response commitments and what the community or partner covers. Neither fact set includes SLAs. |
What the AGPL-3.0 and GPL-3.0 licenses mean for each platform
SuiteCRM is licensed under AGPL-3.0, as shown in the LICENSE files of the SuiteCRM-Core and SuiteCRM repositories maintained by SalesAgility. The software is free to download and run on your own servers. SuiteCRM Ltd earns revenue from paid services around the free software, and those services are separate from the license. Read the SuiteCRM home page for the current service list.
- Free download and self-hosting: You can install and run the core without a license fee. Your costs come from infrastructure, staff time and any services you buy.
- SuiteASSURED support: A paid support package from SuiteCRM Ltd. Ask in writing what response commitments and coverage it includes.
- SuiteCRM Hosted: A hosted option from the same company, so you pay for hosting instead of operating the servers yourself.
- Implementation, training and migration: Paid services that are priced by scope. Ask for a written quote that names each deliverable.
Confirm the terms of each service in its own contract, and confirm which license file applies to the exact release you deploy.
Dolibarr is free open source software under the GPL, licensed GPL-3.0 according to its GitHub repository. It is supported by the Dolibarr Association, which was founded in 2009 according to the Dolibarr website. Self-hosting the core has no license fee. The commercial option that most readers will see first is SaaS hosting, and that is offered by third parties rather than by the project itself.
- Free software under GPL-3.0: The core is available to download and run without a license fee. Your costs are infrastructure, administration and any services you buy.
- Dolibarr Association: Supports the project and was founded in 2009. Confirm directly with the association what membership or support options it offers.
- DoliCloud (third-party listing): DoliCloud describes itself as the official Dolibarr preferred partner and hosts Dolibarr as SaaS. Its listed Basic plan is 14 euros per user per month, and its Premium plan starts from 45 euros per month. Both plans have a 30-day free trial. These are the provider's published figures, and they may change.
- Other hosting paths: Dolibarr can also run on premises, on virtual or dedicated machines, with Docker, or through other cloud providers and partners.
Before you compare SaaS prices with self-hosting costs, ask any provider for current pricing, data location and contract terms in writing.
The license you must follow depends on what you do with the code. Running a modified copy for your own staff, offering the software to clients as a hosted service, and sharing copies with partners are different situations. AGPL-3.0 is widely described as extending copyleft obligations to software that users reach over a network, so hosting for others deserves particular attention with SuiteCRM. GPL-3.0 is primarily triggered by distribution of copies. Legal questions about hosting or redistribution should go to qualified counsel, and this page does not offer a legal conclusion.
- Internal use: Running a modified copy for your own employees is the simplest case. Ask counsel what, if anything, you must publish or offer in that setup.
- Hosting for clients: If you run either platform for other companies, ask counsel whether the AGPL-3.0 network terms or the GPL-3.0 distribution terms apply to your changes.
- Distributing modified copies: Sharing binaries or code with partners or customers can create source-availability duties under either license.
- Contractors and custom code: Agree in writing who owns custom code, under which license it will be released, and where it will live.
- Add-ons and modules: Extensions, custom modules and third-party packages may carry their own licenses, so check each one separately.
Bring the license files from your exact release, your hosting model and your partner contracts to counsel before you ship modified code or offer hosting to others.
What drives the running cost of SuiteCRM and Dolibarr
Running cost splits into one-time costs and recurring costs, and the two platforms weigh differently on each. One-time costs cover setup, data migration, customization and training. Recurring costs cover hosting, patching, support and the staff time spent on upgrades. Neither platform's license charges a fee, so the money goes to infrastructure, people and any paid services you choose. Dolibarr publishes modest resource figures on its prerequisites page: about 150 MB for program files, 35 MB for an initial database, plus space for documents, and at least a 1 GHz CPU for 30 or more users. SuiteCRM's compatibility matrix instead lists a stack of PHP 8.2 to 8.4, MariaDB or MySQL and Apache 2.4 that your team must keep patched. Ask your hosting or integration partner to size both against your user count and document volume, and confirm the final numbers in writing.
Staff skills and upgrade effort are usually the largest recurring items. Both platforms need PHP and database administration, but SuiteCRM also needs CRM process design: pipelines, case routing, campaign workflows and the roles that govern them. That design work is where most SuiteCRM hours go, and it recurs whenever sales or service processes change. On the upgrade side, SuiteCRM 8.x minor releases arrive roughly every eight weeks, and SuiteCRM 7.15 receives security fixes until January 2028, so a SuiteCRM 7 estate has a dated decision ahead of it. Dolibarr maintains several release lines at once, including 24.0, 23.0 and 22.0 in 2026, which gives you more choice of version but still requires a planned upgrade cycle with a staging test each time.
Support is the component most often left out of early estimates. SuiteCRM Ltd sells SuiteASSURED support, hosting, implementation, training and migration services, and independent partners also provide SuiteCRM work. Dolibarr is supported by the Dolibarr Association and by partners, and DoliCloud offers paid SaaS hosting with plans priced per user or per month, with a 30-day free trial. Those prices are published by the vendors and may change, so confirm them directly. For a quote, ask each provider for a written scope that states the users, modules, migration volume, environments, backup and patch responsibilities, support hours and what is excluded. Compare quotes on that basis, not on headline rates.
How to move data between SuiteCRM and Dolibarr
This sequence turns a move between SuiteCRM and Dolibarr into a scoped, tested and reversible project, so the target system holds the same business records with verified ownership and permissions before the old system is retired.
Confirm the reason and target scope
The sponsor, usually the head of sales operations or the CIO, writes down why the move is happening and which parts of the business it covers, such as sales only, or sales plus invoicing and stock. Someone from each affected team signs off the list. The step is done when the scope is agreed in writing and the reason is stated in one paragraph that the team can check later. If the move is in the other direction, repeat the same confirmation with the reverse goal in view.
Inventory every object that must transfer
A business analyst with the data owners lists each object type in the source system and marks it as move, archive or retire. Typical objects include accounts, contacts, opportunities, cases, campaigns, invoices, stock items and projects, plus attachments and notes linked to them. The output is an inventory with record counts per object and the owner of each set. Note that the two products cover these areas differently, so an object that is native in one may be a module or a custom build in the other.
Map fields and ownership between models
A solution architect maps each source field to a target field, with the data type, allowed values, required status and transformation rule. The map also records who owns each record, how users and teams translate across the two systems, and which relationships, such as an opportunity linked to an account and a quote, must be kept. The step closes with a signed mapping document and a list of gaps, such as fields with no equivalent, that the business must decide on. Confirm the mapping against each product's own data model rather than assuming parity.
Build the target on a staging instance
The implementation team installs the target product on a staging instance inside the client's own infrastructure, with the same database engine and PHP version planned for production. They configure users, roles, modules and any required customizations, and document each setting. Confirm supported versions against the vendor's compatibility documentation before installation. The step is complete when the staging instance starts cleanly and a configuration record exists that can be rebuilt from scratch.
Test imports and permissions
A tester runs the import on staging with a representative sample and then with a full copy, comparing record counts, totals, dates and relationships against the source. A second tester logs in as each role and checks that visibility and edit rights match the source access model, including records owned by other teams. Failed rows are logged with a cause and a fix. The step closes when the reconciliation report shows zero unexplained differences and each exception has a signed decision.
Run a parallel period with reconciliation
Users keep working in the old system while a named owner checks that the new system reflects the same activity, usually through a scheduled delta load or a daily reconciliation. Problems found here go back to the mapping or import scripts, and the tests are repeated. The period ends when the business owner agrees that the discrepancy log is empty for the agreed scope. Confirm the length of the parallel period with the business owner, since no supplied fact sets it.
Back up files and the database
Before cut over, the operations team takes a full backup of the source database and the file store, including uploaded documents and generated files, and tests a restore to a separate environment. The migration guidance for SuiteCRM 7 to 8 advises the same backup of files and database before any change. Record the backup time, location, checksum and restore test result. The step is done when a restore has been proven, not just a backup that completed.
Cut over and retire the old system
On an agreed date, the team freezes writes in the source system, runs the final delta load, reconciles totals, and reopens the target to users with communications and a rollback plan ready. After a stable period agreed with the business, the source is set read-only, archived and removed from the live network, while its backups are kept under the client's retention policy. The move is complete when the reconciliation is signed, the archive is verified, and access to the old system is closed.
Where SuiteCRM and Dolibarr implementations usually run long
The biggest schedule risk in a SuiteCRM project is usually process design, not installation. Before any build, agree who owns each pipeline stage, what a case must record before it can close, and how campaign lists are segmented and reported. Teams that skip this end up rebuilding modules after go-live. Identity setup is the second slip point. If you use SAML, confirm the logout behavior before sign-off: the SuiteCRM 8.7.0+ SAML implementation does not support IdP-initiated logout or POST binding to the logout service, so ending a session at the identity provider does not end the SuiteCRM session. Document that limit for your users and your security team, and ask any partner to state in writing how it will be handled. Staffing for module customization also needs a named owner, since changes to SuiteCRM 8 depend on developers who understand its Symfony-based code.
Dolibarr projects tend to slip on configuration decisions that touch money. Enable only the modules you need from the start: proposals, orders, invoicing, stock and projects interact, and turning on a module later can change forms, permissions and reports. Agree the chart of accounts and invoicing rules (numbering, tax treatment, payment terms and who approves credit notes) before any historical data is loaded, because corrections after posting are costly. Stock configuration, including warehouses, units of measure and valuation method, should be signed off by the people who count inventory, not only by the administrator. The module set you keep as the business grows is a decision to record now, with the criteria that would trigger adding or removing a module.
Across both platforms, the common causes of overruns are unclear process ownership, data cleanup that starts late, too many customizations, and one person holding administration, business configuration and support at once. Before work starts, ask any implementation partner to define in writing: who signs off each process and data model, how legacy data is mapped and cleaned and by whom, which customizations are in scope and how each is tested and documented for upgrades, which administrative roles the client keeps and which the partner holds, and how backups and staging are handled. The SuiteCRM migration documentation lists staging, backup and customization review steps that are a useful checklist for any SuiteCRM change. Ask for these items in the statement of work, not in a later change request.
Questions buyers ask before choosing SuiteCRM or Dolibarr
How much effort does a self-hosted SuiteCRM 8 setup need compared with Dolibarr?
SuiteCRM 8 usually needs more setup than Dolibarr because it is a dedicated CRM with a broad set of sales, case and campaign modules to configure. Its supported stack includes PHP 8.2, 8.3 or 8.4, Apache 2.4 and MariaDB or MySQL, and the SuiteCRM 8 compatibility matrix lists the exact versions for each release line. Dolibarr runs on MySQL, MariaDB or PostgreSQL behind any web server that runs PHP, and its effort rises mainly with the number of modules you enable, since each one needs setup, permissions and testing. Both products share the recurring work of patching, backups, PHP and database upgrades, and checking customizations after each release. Size the work against the modules you actually plan to use, not the full catalog.
Can our team run SuiteCRM or Dolibarr without outside help?
A team can run either product in-house if it has PHP and database administration skills, a staging environment, and someone who owns configuration and change control. SuiteCRM 8 adds identity work if you use LDAP or SAML sign-in, and that needs people who understand your directory or identity provider. Dolibarr's extension model, including the Module Builder, is approachable for developers who already work with PHP, but customizations still need testing before each upgrade. Many teams keep one internal owner and bring in outside help for the first deployment, the identity setup and periodic upgrades. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms in your own infrastructure, and ongoing support is available as a retainer.
How long does a SuiteCRM or Dolibarr implementation take?
No supplied fact gives a typical implementation duration, so the answer depends on scope. The main drivers are the number of modules, the volume and quality of data to migrate, the number of integrations with email, telephony or finance systems, how many customizations you need, and whether single sign-on is part of the work. Illustrative example: a team that moves contacts and a sales pipeline into a standard setup has a very different project from a team that migrates cases, campaigns and custom modules into a tightly integrated environment. Most DeployOpen engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts. Ask any implementer to tie the timeline to a named list of modules, data sets and integrations.
Should SuiteCRM 7 users move to SuiteCRM 8 now?
SuiteCRM 7.15 is an extended support release with security fixes until January 2028, so there is no immediate cliff for 7 users. No SuiteCRM 8 extended support release had been nominated at the time of the supplied research, and SuiteCRM expects to name one by Q3 2027, so check the SuiteCRM LTS and release lifecycle page before you plan. Moving from 7 to 8 is a migration, not an in-place upgrade: you set up a new SuiteCRM 8 environment, bring the 7 instance to the latest 7.14.x or later first, and move the data across. The migration may remove non-core files under the public/legacy folder, so review every customization before you start. Plan the move on a staging instance with full file and database backups, and set a target date well ahead of January 2028.
Is Dolibarr's free core enough for invoicing and stock?
Dolibarr's website lists invoicing and stock among its modules, alongside proposals, orders, contracts, manufacturing (MRP), point of sale and projects, so the core set can cover basic invoicing and inventory if you enable those modules. Whether it is enough depends on your tax rules, invoice numbering, multi-warehouse needs, approval flows and the reports your finance team expects. Check those requirements against the module documentation and a test instance before you commit. If you prefer not to host it, DoliCloud describes itself as the official Dolibarr preferred partner and lists a Basic plan at 14 euros per user per month and a Premium plan from 45 euros per month, each with a 30-day free trial. That is a third-party hosted listing, so confirm the current terms directly with the provider.
Do the AGPL-3.0 and GPL-3.0 licenses change anything if we host for clients?
The answer depends on whether you modify the software and how you deliver it, so have counsel confirm your position. SuiteCRM's AGPL-3.0 license includes a network provision: if you modify SuiteCRM and users interact with it over a network, you may need to offer those users the corresponding source of your modified version. Dolibarr's GPL-3.0 obligations are triggered mainly when you distribute copies of the software or modified versions, so running unmodified Dolibarr for clients generally carries different duties than hosting a changed build. Your client contracts should state who owns customizations and who receives source code. Ask counsel to review the license texts in the SuiteCRM-Core and Dolibarr repositories alongside your service model before you sign client terms.
What should we ask for in a fixed-scope quote?
Ask for a written scope that lists modules, user counts, data sets and volumes to migrate, integrations, identity setup such as LDAP or SAML, customizations, and the environments to be built, including staging. The quote should also name testing, backup and rollback steps, documentation, training, handover, and what happens after go-live. Separate one-time work from recurring work such as patching, upgrades and support, and ask what assumptions the price depends on and how change requests are priced. Both SuiteCRM and Dolibarr are free to download and self-host, so the costs are infrastructure, labor and any paid services you choose. DeployOpen does not publish a price list, and a quote follows from the written scope, so the better the scope, the more comparable the quotes will be.
How DeployOpen helps teams choose and implement a CRM
DeployOpen works on SuiteCRM and Dolibarr inside the client's own infrastructure, starting from the questions that decide this choice: which sales, service or ERP processes must run in one place, and who will own the platform after go-live. Engagements are fixed-scope, with the scope agreed in writing before work starts.
How we scope
- Map which sales, case and campaign processes need SuiteCRM depth, and which invoicing, stock or project work points to Dolibarr.
- Confirm the target PHP, MySQL, MariaDB or PostgreSQL versions against each vendor's published requirements before sizing hosts.
- Agree the written scope, deliverables and timeline up front, including which license obligations and customizations are in and out.
How we build
- Install and configure the chosen platform in your cloud account, data center or air-gapped network, with the identity method you select.
- Set up user roles, pipelines, modules or enabled Dolibarr modules, and document each customization so it can be reviewed at upgrade time.
- Test the build on a staging instance, including authentication, data import and the security testing agreed in the scope.
How we hand over
- Deliver runbooks for backups, upgrades, staging and rollback, along with configuration and customization documentation.
- Walk your administrators through daily operations, module changes and the steps for moving between SuiteCRM release lines when needed.
- Provide evidence of configuration and controls that your internal or external auditors can review, without issuing any audit opinion ourselves.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after go-live, with terms agreed in writing.
- Plan upgrades against each platform's release cadence and support windows, and test them on staging before production.
- Re-run security testing and review customizations whenever a major release or a change in scope affects your deployment.
