SuiteCRM customization: where configuration ends and code begins
Most teams with an administrator who knows SuiteCRM can handle Studio and Module Builder changes in-house, and a partner is usually brought in when the work needs code that must survive upgrades. That split is the core of this page. Tailoring starts when stock screens no longer match how sales, service or marketing works: a new record type such as a contract or equipment record, extra fields for regulated data, different layouts for each role, or behavior that runs when a record is saved. Each need can be met at a different layer, and the layer you choose determines how much work each future upgrade will cost. This page covers customization only. The wider implementation plan, data migration from SuiteCRM 7 or another CRM, the upgrade calendar and single sign-on are covered in their own sections.
The first layer is configuration in Studio and Module Builder. Studio changes field labels, dropdown values and layouts on existing modules, and Module Builder creates custom modules and their fields without writing code. Changes made through these admin tools generally carry the lowest upgrade risk, but you should confirm for your version how each change is stored and whether it carries through an upgrade. The second layer is custom modules and fields that go beyond what Studio exposes, such as relationships between new objects and standard records. The third layer is layouts defined per module and view, which often break when a core field is renamed or removed. The fourth layer is logic hooks and packaged extensions, which run code on save or on view and sit closest to the core. Upgrade risk rises at each step down this list.
Code-level changes are where upgrade cost concentrates. Logic hooks and packaged extensions depend on the internal interfaces of the release they were written for, so each minor release can require a review. SuiteCRM 8 minor releases arrive roughly every eight weeks according to the project's LTS page, so a customization written today may need checking several times over its life. Patch releases contain only security and bug fixes and no database changes, which makes them easier to absorb, but a minor release can change what your code touches. Before writing any code, inventory every customization, note which layer it sits on and record the business owner. Ask the developer to name each interface the extension calls and to list the tests that show it still works after an upgrade.
Several situations usually trigger the work. A new process needs its own record type, a regulator asks for fields that stock modules do not hold, two teams need different layouts on the same data, or an integration must write back when a record is saved. For each trigger, decide the lowest layer that meets the need and write down who will maintain it after go-live. When requesting a quote, ask for a written scope that names each module, field, layout and hook, the test cases for each one, and handover of source code and configuration exports. Confirm with SuiteCRM Ltd or on your own test instance whether a given extension mechanism is supported on your release before committing to it. Test every item on a staging instance first, because a customization that works on a clean install can still fail against your data.
What a SuiteCRM customization engagement includes
A fixed-scope customization project moves from requirements to tested change, and each stage produces something the client keeps. The work streams below are typical starting points, and the written scope confirms which ones apply to your SuiteCRM 8 environment. The deliverables at the end are what your team needs to maintain and upgrade the system after the engagement closes.
Requirements and inventory
Before any build, the work starts with a field and module inventory of what exists today and what each team needs to record. This separates fields that are already configurable from those that need code, and it identifies which Studio, Module Builder and custom items feed reports, workflows or integrations. Ask for the inventory as a written list of accepted requirements, with owners and open questions named.
Configuration in Studio and Module Builder
Many requirements are met by Studio and Module Builder without custom code, such as new fields, picklists, layouts and relationships. Configuration changes are easier to review and reproduce on a staging instance than hand-edited files. Confirm which changes the vendor's tools can make in your version and which will be documented as configuration steps instead.
Custom modules, fields and layouts
Custom modules bring their own fields, relationships, list views, detail views and edit layouts, and each must be checked against the security groups and roles that govern access. Record the module definitions, field types and relationship types so the next administrator can rebuild them. Confirm how record access will be tested for each team.
Logic hooks and extension code
Where configuration cannot meet a requirement, the work uses logic hooks or extension code placed in supported extension points rather than edits to core files. This is the highest-risk part of a customization, because it must be re-tested after every upgrade. Ask the provider to list each custom code path, its trigger and the reason configuration could not handle it.
Automated and manual test cases
Test cases cover the business processes the customization affects, including record creation, field validation, permissions and any hook behavior. Automated tests catch regressions in code, and manual scripts cover screens and workflows that users complete by hand. Ask for the test cases as a document your team can rerun before each SuiteCRM upgrade.
Documented change inventory
The change inventory records every module, field, layout, relationship, hook and code file added or altered, with its purpose and location. It is the reference used to decide what to keep, retest or remove when SuiteCRM moves to a newer minor release. Ask that it be kept current at each delivery milestone rather than written once at the end.
What drives the cost and duration of SuiteCRM customization
This table lists the factors that change how much a SuiteCRM customization costs and how long it takes, with the reason each one matters and how to keep it under control. Read each driver as a source of build work and also of ongoing review, testing and upgrade-regression work that continues after go-live. Most of the cost comes from the number of moving parts, so scope the smallest set of custom objects, logic and integrations that meets the requirement.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Custom modules and relationships | Each module adds fields, layouts, permissions, relationships and test cases, and each relationship must be tested from both sides. | Reuse standard modules where they fit, and model new objects only when records have their own lifecycle and reporting needs. |
| Fields and layouts per record type | Every field must be defined, placed on each layout, mapped for import and checked in reports, and the count grows with each record type. | Agree a field dictionary before build, remove duplicates and avoid fields that duplicate standard ones. |
| Logic hooks or extension code | Behavior that cannot be set in Studio or Module Builder needs code that must be reviewed and retested after every upgrade. | Prefer configuration and workflows first, and document each code extension with its purpose and owner. |
| Integrations reading or writing custom data | Each integration depends on field names, types and API behavior, so a change to a custom field can break a sync in another system. | Define field mapping, sync direction and error handling up front, and limit the number of systems that write to each custom field. |
| Environments (development, staging, production) | Changes must be promoted and tested in each environment, and differences between them cause defects that are hard to trace. | Keep a single version-controlled change path and confirm the staging instance matches production before each release. |
| User roles and security groups | Every role that can see or edit custom data needs its own access test, and access rules multiply as roles increase. | Map roles to business functions first, then test a small set of representative users rather than every combination. |
| Compliance evidence such as change records | Assessors expect records showing who changed what, when it was tested and who approved it, which adds documentation work to each change. | Agree the evidence required before build, and record approvals and test results in the same workflow as the change. |
How a SuiteCRM customization project moves from requirements to handover
The sequence runs from requirement inventory to handover, with a check at each phase that produces a signed record. Every custom item is traced to a business requirement, tested on a copy of production-like data, and documented so your team can maintain it through later releases. The timeline is set in the written scope, which follows the agreed inventory.
Run discovery and inventory requirements
The DeployOpen consultant and your business owners walk through each sales, service and marketing process the customization must support, and record how users work in each one today. Each requirement is logged with its owner, the data it touches, and whether it can be met with configuration in Studio or needs a custom module or code. Output: a signed requirement inventory that sets the scope, which the written scope then prices and schedules.
Design modules, fields and relationships
The team maps the records, fields, layouts and relationships each requirement needs, and decides which items belong in Studio, which in Module Builder, and which need logic hooks or an extension. Security groups and role access are checked against the design so users see only the records they should. Output: an approved design document with a data model diagram and a list of items marked for custom code, reviewed by your business owners before any build starts.
Build in a development instance
Developers build the agreed modules, fields, layouts, logic hooks and extensions on a development instance that matches the target SuiteCRM 8 version and supported PHP and database versions. Changes stay within supported customization points and the core application is left untouched, which keeps later upgrades manageable. Output: a development build with version-controlled code and a change log that maps each change back to a requirement ID.
Review and test on staging with production-like data
The build is deployed to a staging instance loaded with a recent copy of production-like data, with personal data masked where your policy requires it. Business owners run scripted test cases for each requirement, and the team tests permissions for each security group, imports, workflows and scheduled jobs. Output: signed test results and a defect list that is closed or formally accepted before release. Confirm with your data protection lead how the copy is produced, stored and deleted.
Release to production under change control
The approved build is deployed to production in a window agreed with your change board, after a full backup of files and database is taken and verified. A rollback plan is written beforehand, and the team runs a short smoke test of key records, layouts and scheduled jobs once the release is live. Output: a release record showing what changed, who approved it, and the post-release check results.
Hand over runbooks and an upgrade checklist
The team delivers runbooks for routine administration, the customization inventory, the test cases, and an upgrade checklist listing every custom item to retest before each SuiteCRM minor or patch release. Administrators walk your staff through the runbooks, and open questions are logged with an owner. Output: an accepted handover pack and a named owner for each customization. Ongoing upgrade and support terms are set separately in the written scope.
How custom modules and extensions survive SuiteCRM 8 upgrades
Custom modules, fields, layouts, logic hooks and extensions are the part of a SuiteCRM 8 instance most likely to break during an upgrade, because they depend on core behavior that the vendor is free to change between releases. SuiteCRM minor 8.x releases arrive roughly every eight weeks. Patch releases contain only security and bug fixes, with no new features and no database changes, so they are the lower-risk step. Minor releases are different. They can add features, adjust internal behavior and change how core code calls the functions, events or metadata that custom code relies on. A customization that worked on one minor release can fail quietly on the next, even when the install completes without errors.
The first practical control is structural. Keep custom code outside core files so that an upgrade replaces only what the vendor ships. Custom modules and extensions should live in the locations the platform's extension mechanisms define, not in files edited in place. Edits made directly to core files are overwritten or lost during an update and make it difficult to see what the team changed. Ask your implementation partner to show, before build starts, where each type of customization will live, and which items are generated by Module Builder or Studio and must not be hand-edited. Also confirm with SuiteCRM's current extension guidance for your target release which directories and extension points it supports, since these details change between versions.
The second control is traceability. Track every customization in version control, including custom module definitions, field and layout changes made through Studio or Module Builder where they can be exported, logic hook files, custom PHP, templates, configuration and database scripts. Keep a registry that lists each logic hook, override and extension, the core class or event it attaches to, the owner, the business reason and the release on which it was last tested. When an upgrade is planned, this registry becomes the checklist. Without it, the team cannot tell which of dozens of hooks are still needed, and an upgrade review becomes a guess.
The third control is testing. Run a staging copy of the production instance, including a copy of the database and custom files, and test each target release before it reaches production. Cover the workflows the business depends on: lead and opportunity conversion, custom module records, record permissions and security group behavior, email templates, scheduler jobs and any API integrations that read or write custom fields. Check the PHP and database versions against the compatibility matrix for the release you are moving to, and record the matrix versions the build was tested on alongside the test results. That record shows auditors and future engineers what was verified, and it tells the team which combination to revisit when the matrix changes. Confirm with your partner what the staging test cycle includes and who signs off the result.
Be clear about what a partner can and cannot guarantee. A partner can design the customization layout, build and document the extensions, maintain the registry, run regression tests against the agreed workflows and report defects found on staging. A partner cannot guarantee that a future SuiteCRM release will keep every behavior unchanged, and no partner can promise that a third-party extension, which the vendor does not maintain, will work on every minor release. Agree in writing which extensions are in scope for ongoing testing, how often each target release is assessed, and what happens when a minor release breaks a hook. Confirm the extension guidance for your specific release with SuiteCRM before you commit to a design, because the supported extension points are the foundation for every decision in this section.
Which parts of SuiteCRM customization teams keep in-house and which they outsource
This table shows which SuiteCRM customization work teams usually handle themselves and which they hand to an implementation partner, along with the skills each area needs. Treat each row as a starting point, since team size and existing skills change the answer. The main takeaway is that configuration and day-to-day admin usually stay in-house, while code extensions and upgrade regression testing are where outside help is most often useful.
| Work area | Usually kept in-house | Usually outsourced | Skills required |
|---|---|---|---|
| Business requirements and data definitions | Sales operations and service leads define stages, statuses, required fields and reporting needs | Facilitated workshops that turn requirements into a written data model for sign-off | Business process knowledge. No coding needed, but the owner must make firm decisions on data rules |
| Studio and Module Builder administration | Admins create fields, layouts, dropdown lists and simple modules on a staging instance first | Initial build review or admin training, usually scoped as part of the implementation | Studio and Module Builder use. An internal admin can learn this with vendor training and practice |
| Custom module and field design | Admins build simple modules and agree naming conventions with business owners | Complex relationships, large data volumes or design reviews before a module goes live | Relational data modeling and an understanding of security groups. Learnable with design experience |
| Logic hook or extension development | Small, well-documented changes made by a developer who already knows the codebase | Custom PHP extensions and hooks built against the SuiteCRM 8 codebase, with handover notes | PHP and the SuiteCRM 8 codebase conventions. Not a skill an admin typically picks up quickly |
| Automated testing and staging review | Business users run scripted acceptance checks on staging and sign off results | Building automated test suites and reviewing staging builds against the customization register | Test design for business users. Automated tests need PHP and CI tooling skills |
| Upgrade regression testing | Business users confirm critical processes after each minor release or patch | Running regression suites before each upgrade, including checks on customizations and integrations | Reading release notes, planning test cases and managing staging. Internal admins can learn the checklist; automation needs developers |
| Ongoing admin changes after handover | Field, layout, list and user or role changes handled through normal admin requests | New modules, extensions or integration changes that need development and testing | Admin skills are learnable internally. Code changes need PHP and upgrade awareness |
What goes wrong in SuiteCRM customization projects and how to prevent it
Most SuiteCRM customization problems come from a few decisions: where code is placed, how it is tested against new releases, and who owns it after go-live. Each card below names one failure mode and the prevention step that addresses it. Use the list as a review checklist before the build starts and again before each upgrade or migration.
Changes made in core or legacy folders
Edits made directly to SuiteCRM core files, or to folders outside the supported extension points, are overwritten or lost during upgrades. The SuiteCRM migration docs warn that non-core files under public/legacy may be removed during a move to version 8. Before any migration, list every file outside core and review whether each one is still needed. Keep customizations in supported extension locations, and confirm the approach against the migration docs on a staging instance first.
Extensions that break on minor releases
SuiteCRM 8 minor releases arrive roughly every eight weeks, and an extension written for one minor version can fail on the next. Patch releases contain only security and bug fixes, but minor releases can change internals that custom code depends on. Test every custom module, logic hook and extension against the target version on staging before production. Keep a dated test script for each release so the results can be repeated.
Production changes without a record
Field additions, dropdown edits, role changes and scheduler settings made directly in production leave no trail. A later upgrade or migration rebuild cannot reproduce changes that were never written down. Record each change with its owner, reason and date, and make it on staging first. Document module, field and layout definitions after each change so the two environments can be compared.
Logic hooks that clash with workflows
A logic hook that sets a field on save can conflict with a workflow that changes the same field, or with an API sync that writes it back. The final value then depends on execution order, which is hard to diagnose after go-live. Before building a hook, list every workflow, scheduled job and integration that touches the same module and fields. Assign each field one system of record and document which mechanism is allowed to write it.
Fields exposed to the wrong groups
Adding a field to a layout does not restrict who can see it, so a field placed on a shared layout can reach users outside the intended security group. Review each new field against role and security group settings before release. Test with a non-admin account in each affected group, and check detail, edit, list and export views, since each can expose data separately. Record the expected visibility for each field alongside its definition.
No owner after go-live
Custom modules and hooks often outlive the developer who wrote them, and the next upgrade then stalls because no one knows what the code does. Name an internal owner for each custom component and keep a short register with its purpose, dependencies, the version tested and the test script. Confirm before go-live who reviews and approves changes at each minor release. Ask any partner to hand over this register as part of the engagement.
How SuiteCRM customization changes by starting point
A stock SuiteCRM 8 instance that needs first customizations has the simplest starting point, because the platform is still close to its released state. Discovery is mainly a review of what the business needs changed, checked against what Studio and Module Builder can deliver without custom code. Testing focuses on whether each new field, layout or module behaves correctly for each security group and role, and whether later core upgrades will still work with those changes.
In practice, the work usually changes in these ways:
- Discovery: confirm which requirements Studio and Module Builder can meet, and flag any that need logic hooks or extensions.
- Testing: verify layouts, field validation and role visibility with test users in each team.
- Handover: record each custom module, field and layout with its owner and purpose.
- Upgrade readiness: note which changes are declarative, since those are easier to retest after a minor release.
- Cost drivers: the number of modules, the depth of workflow logic and the number of roles affect effort more than the instance age does.
Confirm with your implementation partner which customizations will be built in the platform's own tools and which will need code, and ask for that split in writing before work starts.
A SuiteCRM 7 instance with legacy customizations is a migration, not an in-place upgrade. The 7 instance must first reach the latest 7.14.x release or later, a new SuiteCRM 8 environment is set up, and the 7 data is moved into it. Discovery therefore starts with an inventory of legacy customizations, including custom modules, vardefs, logic hooks and files under the public/legacy folder, because the migration documentation warns that non-core files there may be removed.
The main changes by phase are:
- Discovery: list every legacy customization and classify it as core-equivalent, rebuildable in 8, or no longer needed.
- Testing: run the migration on a staging instance first, with a full file and database backup taken beforehand.
- Testing: compare migrated records, relationships and layouts against the 7 instance using agreed test cases.
- Handover: rebuild customizations in the SuiteCRM 8 framework and keep the 7 code only as reference.
- Handover: document which legacy behavior was retired on purpose, so users are not surprised after cutover.
Before committing to a plan, ask for the inventory of legacy customizations and confirm the exact 7 version you will migrate from.
An existing SuiteCRM 8 instance with customizations made by a previous developer and no documentation starts with unknowns. Discovery is a code and configuration audit that establishes what was changed, where it was changed and whether those changes sit in supported extension points or in modified core files. Without this step, any upgrade or fix can break behavior that nobody has written down.
The work typically follows this pattern:
- Discovery: compare the installed code against the release it was built from, and map each deviation from core.
- Discovery: review scheduled jobs, workflows and integrations that the previous developer may have set up outside the interface.
- Testing: record current behavior as a baseline, because the documented expectation may not match what users rely on.
- Handover: write documentation for each customization, including its purpose, owner and dependencies.
- Handover: transfer source control access, credentials and deployment steps to your team, with the credentials stored outside the code.
Ask for the audit findings in a written list before any remediation is quoted, since the number of undocumented changes is the main driver of effort.
A multi-environment setup with separate development, staging and production means customization is developed in one place and promoted through others. The main risk is configuration drift, where the same customization behaves differently because the environments run different versions, settings or data. Discovery should therefore confirm that each environment runs the same SuiteCRM version and PHP and database stack, and document which settings legitimately differ, such as URLs, mail servers and SSO endpoints.
The changes by phase are:
- Discovery: compare configuration across environments and separate environment-specific values from shared customization.
- Testing: promote each change through development and staging before production, and retest on staging after each promotion.
- Testing: keep test data out of production and confirm that workflows and scheduled jobs do not send live email from non-production environments.
- Handover: write a promotion runbook that covers order of steps, rollback and who approves each release.
- Operations: plan for the minor release cycle so that staging receives each new version before production does.
Ask how environment-specific values will be stored and who will hold the promotion approvals before the work is scoped.
An air-gapped or restricted network changes how every package reaches the system. Software, dependencies and updates must be moved in by approved media, so discovery includes confirming which packages, PHP extensions and database versions the change depends on, and how each one will be transferred and verified. Testing has to happen on internal systems that have no route to public package sources, which means any dependency needed for a test must already be inside the boundary.
The main changes are:
- Discovery: list every package and version the customization requires, and confirm the media-transfer process your security team has approved.
- Testing: run tests on an internal staging system that mirrors production, using only artifacts already inside the network.
- Testing: verify checksums or signatures for each package before it is installed.
- Handover: document the offline update procedure, including how future SuiteCRM minor and patch releases will be requested, approved and moved in.
- Handover: record the chain of custody for transferred media and who is authorized to import it.
Confirm with your security and network teams which transfer method and approval steps apply, and ask the implementation partner to list every external dependency before work begins.
What your team needs to provide before customization starts
Customization scope is set by the decisions your organization makes before any module is built. Before work starts, name a business owner for each custom module and for each field decision that affects reporting, approvals or record ownership. Without a named owner, questions about picklist values, required fields, layout order and whether a field should appear on the Accounts or Opportunities detail view stall the build. Each unresolved decision tends to become a rework item later, because a field added to the wrong module or with the wrong type is harder to change once records and reports depend on it. Current configuration and customization inventory. Provide a copy of your current SuiteCRM configuration and a list of every customization already in place. For a SuiteCRM 8 instance, that means custom modules, fields created in Studio or Module Builder, layouts, dropdown lists, workflows, logic hooks, custom code in the custom directory, and any extensions. Ask your existing administrator or vendor to confirm what they changed and where. The inventory tells the partner which items can be reused, which must be rebuilt, and which conflict with the core behavior you plan to keep. Items missing from the inventory usually surface during testing, when they cost the most to fix.
Access to a development or staging instance is the most important input for managing risk. Customizations should be built and tested on a non-production copy of the application, ideally with data that resembles production in volume and shape. Before sharing any production records, confirm with your security or data protection team whether personal data, customer financial information or health-related notes may be copied, whether they must be masked or pseudonymized first, where the copy will be stored, who can access it, and how long it will be retained. If production data cannot be copied, agree on a synthetic dataset that covers the same field types, relationships and edge cases. A source control repository that the partner can use is needed to track every change to custom code, metadata and configuration. Confirm whether you have an existing Git hosting service, who owns the repository, how branches and access are managed, and whether your change process requires code review. Also provide a test user for each SuiteCRM role and security group your users hold, so that field visibility and record access can be verified against the same permissions your people will have. Finally, list every integration that reads or writes custom data, and decide who approves production releases. Each of these items affects scope, cost and the risk of breaking a live process, so settle them in writing before the first sprint.
Questions buyers ask before hiring help with SuiteCRM customization
How much does SuiteCRM customization cost?
SuiteCRM carries no license fee, so customization cost is the labor to design, build, test and hand over changes. The main drivers are the number of modules and fields, the complexity of layouts and validation, how many logic hooks or extensions are needed, the number of roles and security groups that must be tested, and the integrations that read or write custom data. Ask for a quote built from a written scope that lists each module, field group, hook and test case, and that separates one-time build work from any recurring retainer for upgrades and support. DeployOpen does not publish a price list, so the figure follows from that scope. Compare quotes line by line against the same list of items.
How long does a SuiteCRM customization project take?
Duration depends on scope, and the written scope is the only reliable basis for a timeline. Adding a few fields to existing modules moves quickly, while a new custom module with relationships, permissions, workflows and reports takes considerably more design and testing. Review cycles, data decisions and role-by-role testing also consume time, often more than the build itself. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for a schedule that ties each deliverable to a milestone and names the client sign-offs required at each step. Any change request should update the plan in writing.
Can an internal admin build custom modules with Studio and Module Builder?
Often yes for simple modules, provided the admin has time, a test environment and a named owner for the design. Studio and Module Builder cover fields, layouts and basic module structure, which suits many departmental records. The harder work sits around the screen: relationships to accounts and opportunities, role-based access, validation rules, reports and the data model that integrations depend on. Changes made through the user interface should be recorded, reviewed and tested on staging before they reach production. Confirm in your own environment which Studio and Module Builder features your SuiteCRM version provides, since these capabilities change between releases. DeployOpen can take over the design, build or review under a written scope.
When does a SuiteCRM change need logic hooks or extensions?
Use configuration first, and move to logic hooks or extensions when behavior must run on record events or cannot be expressed through the admin screens. Typical triggers include calculations across related records, side effects on save or delete, calls to external systems, and logic that needs automated tests in code. Code adds a maintenance obligation: it must be reviewed against each minor release and rebuilt if a core interface changes. Ask the implementer to document why each hook or extension exists, what it touches and how it is tested. Keep business rules that change often in configuration where possible, so administrators can maintain them directly.
Will custom code survive a SuiteCRM minor upgrade?
It can, if it was built on supported extension points and is tested before each upgrade, but no one can confirm survival in advance. SuiteCRM 8 minor releases arrive roughly every eight weeks, so custom code should be reviewed on that rhythm. Patch releases contain only security and bug fixes, with no new features or database changes, which makes routine patching lower in risk. Minor releases can change internal interfaces, so each extension needs scripted checks and a staging run before production. Ask for an inventory of every customization that lists the files and core touchpoints it uses, along with a regression test set that covers each role.
What does the client need to provide for a customization project?
Name a business owner who can sign off on requirements and a technical contact with access to the environment. Provide staging and production access, the current SuiteCRM version, PHP and database details, a recent backup, sample data and documented process steps for each module. Access to the identity provider or directory matters if roles depend on group membership. Supply the list of integrations that read or write custom fields. Gaps in these inputs tend to extend the schedule, so list each one in the written scope with an owner and a due date.
Does SuiteCRM customization need a staging environment before production?
Yes, for any change that touches data, roles or code. SuiteCRM's migration guidance advises testing on a staging instance and backing up files and the database first. It also warns that a migration may remove non-core files under the public/legacy folder, so customizations there need review. Build staging on the same PHP, Apache and MariaDB or MySQL versions as production, checking the SuiteCRM 8 compatibility matrix for the release in use. Restore a recent copy of production data where policy allows. Test each role, then promote changes with a documented rollback plan. Ask for the test scripts to be part of the written scope.
What happens after handover of a custom SuiteCRM build?
Ownership and support depend on what the written scope includes. A typical handover covers documentation of each module, field, layout, hook and extension, the test cases used, and the admin steps for routine changes. Ongoing support, upgrades and continuous testing are available as retainers from DeployOpen. SuiteCRM Ltd sells its own support package, SuiteASSURED, which is separate from implementation work. Plan for minor releases roughly every eight weeks, and agree in writing who reviews each customization before every upgrade. Confirm the support window for the release line your organization runs before committing to a plan.
How DeployOpen scopes, builds and hands over SuiteCRM customizations
DeployOpen plans SuiteCRM customization as a lifecycle from the first meeting, with each engagement starting from a written, fixed scope covering the modules, fields, layouts and logic hooks involved. The work is carried out inside your own infrastructure. The aim is customizations your team can upgrade later, backed by documentation and testing it can keep using.
How we scope
- The written scope lists each custom module, field, layout, relationship and logic hook in the change.
- We record which changes use Studio and Module Builder and which need custom code, with reasons.
- Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts.
How we build
- Customizations are built on a non-production SuiteCRM 8 instance and promoted only after testing.
- Custom code is kept out of core files, so changes can be reapplied or reviewed during upgrades.
- Each change is checked against the SuiteCRM 8 version and the PHP and database versions in use.
How we hand over
- Handover includes a change register listing every module, field, hook and extension, with its owner.
- Your administrators receive documentation of how each customization is built, tested and rolled back.
- Walkthroughs cover how to make routine admin changes without breaking the custom logic.
How we support
- Ongoing support is available as a retainer covering upgrades, fixes and testing of custom work.
- Before each minor 8.x upgrade, custom modules and logic hooks are retested on staging.
- Where you hold a SuiteASSURED package, we agree in writing how our work and that support divide responsibility.
