CRM RFP questions

A discovery workshop should record how deals move today, who touches each record, and which fields the business actually uses. Ask the partner to run sessions with sales leaders, sales operations, support and finance, because each group reads the same record differently. The output should be a written list of pipelines, stages, entry and exit criteria, reports people rely on, and the systems that send or receive data. Ask whether the partner will also interview people who stopped using the current CRM, since their workarounds often reveal missing fields. Confirm that the workshop output becomes the input to a signed design document before any build starts.

A good partner maps pipelines stage by stage, comparing each current stage with its target stage in SuiteCRM, EspoCRM or Twenty. For every stage, the mapping should name the entry rule, the exit rule, the probability or forecast category, and the records that will be affected. Watch for stages that mean different things to different teams, and for closed-lost reasons that need a consistent list. Ask for a side-by-side table that the sales leadership signs off. Red flag: a partner who maps pipelines by copying the old stage names without a stage-by-stage review, because historical reports will then break silently.

The design should separate standard objects, such as accounts, contacts and opportunities, from custom objects that the business needs, such as partner referrals or renewals. The partner should produce a field inventory listing each field, its type, whether it is required, its source system, its owner and whether it holds personal data. Confirm the platform's native support for custom objects and fields: Twenty documents custom objects and fields defined as code, and EspoCRM configures entities through its Entity Manager. Ask how the partner avoids field sprawl, such as retiring unused fields before migration rather than carrying them forward.

Role-based access should be designed from a matrix of roles, teams, territories and record visibility, agreed before any user is created. The matrix should state who can view, edit, export and delete each object, and whether users see only their own records, their team's records or all records. Ask the partner how it maps existing owners and permissions, and how it handles managers who need cross-team visibility. For regulated data, confirm that the design supports field-level restriction where needed. Confirm each platform's specific model during discovery, because EspoCRM's teams and roles, and Twenty's workspace permissions, differ in their details.

A good sign-off document contains a complete field inventory, a stage-by-stage pipeline map, an owner and permission map, and a list of fields retired or deferred. Each row should show the source field, target field, transformation rule, default value, owner and whether the field holds personal data. The sign-off should be dated and approved by named business owners, with open questions listed separately. Ask the partner to show a sample of the document from a past project, redacted. Red flag: a partner who cannot produce a mapping document before the build starts, or who treats sign-off as a formality after the configuration is finished.

The duration depends on the number of pipelines, the count of custom fields, the number of teams that must agree, and the quality of the existing data. No duration is given here because no researched figure applies to your environment. Ask the partner for a fixed-scope timeline in writing, with the workshops, review rounds and sign-off dates listed separately. Work often grows when stakeholders disagree on stages or when a legacy export contains many unused fields. Ask which mapping decisions the partner expects your team to make, and how many review rounds the quote includes.

Yes, if the partner documents the mapping in a form your team can maintain, and if the platform configuration is kept understandable to administrators. Ask for the design document, the field inventory, the permission matrix and a short handover session with the people who will administer the CRM. Confirm where configuration lives, for example in the admin interface or in version-controlled code, and who holds administrator credentials. DeployOpen plans, implements, documents and supports self-hosted open-source platforms in your own infrastructure, and ongoing support is available as a retainer, so you can choose between internal ownership and continued support.

Check whether the partner marks personal data fields during mapping and carries that marking into access rules, export controls and retention settings. The partner should list which fields hold contact details, identifiers or notes that may contain sensitive information, and state how each is restricted. Ask how the design supports later access and erasure requests, since the mapping determines where personal data sits. Ask whether the partner records this classification in the sign-off document. The mapping is the point where privacy rules become concrete, so a partner that defers this to a later phase creates rework.

The first integrations are usually the ones that move money, orders or customer identity: ERP for invoices and orders, billing for subscription status, telephony for call logging, marketing for consent and campaign data, and the identity provider for sign-in. Ask the partner to rank these against your processes and to name the system owner for each data flow. Cost rises with the number of systems, the number of field mappings and how often records change in both directions. Each connector usually needs its own testing, monitoring and change process after go-live, so ask for those hours to be listed separately in the written scope.

Yes, SuiteCRM 8 can sign users in with LDAP or SAML. LDAP is enabled with AUTH_TYPE=ldap and built on the Symfony Security LDAP authenticators, and SAML is enabled with AUTH_TYPE=saml and built on the nbgrp onelogin-saml-bundle. Ask the partner to show the exact configuration keys used in your environment and to test directory group membership, account disablement and fallback access before go-live. Confirm with your identity team which method matches your directory and federation setup.

From SuiteCRM 8.7.0 onward, the SAML implementation does not support IdP-initiated logout or POST binding to the logout service. In practice, signing out at your identity provider does not end the SuiteCRM session. Ask the partner how they will document this for users, whether they will set session lifetimes or add a compensating control, and how they will test that disabling a user in the directory blocks access. Confirm the current behavior in the SuiteCRM SAML configuration reference for the version you plan to run.

EspoCRM supports OpenID Connect sign-in since version 7.3, with optional user creation on first login, mapping of identity provider groups to EspoCRM teams, backchannel logout and a fallback login method. EspoCRM's own two-factor authentication is not compatible with OIDC, so MFA must be enforced at the identity provider. Ask the partner to show how group claims map to teams, how a removed user is deprovisioned, and which fallback login is kept for administrators. Confirm the claim names and group handling with your identity provider vendor.

EspoCRM documents LDAP authentication, including Active Directory and OpenLDAP. Ask the partner to confirm which directory attributes map to user records, how disabled accounts are handled at next login, and whether group membership can drive roles or teams. Plan a test with a service account that has the minimum read rights needed. Because directory setups vary, the partner should confirm the exact flow against your directory version before quoting the work.

The partner should describe each connection by direction, trigger, data fields and failure handling. Typical patterns use the CRM's REST or GraphQL APIs, webhooks, scheduled jobs or an integration layer, depending on the platform. EspoCRM's API supports API key, HMAC and basic authentication through dedicated API users with role-based permissions, and its documentation describes HMAC as the most secure method and basic authentication as not recommended. Ask which method they will use, how credentials are rotated, and how failed syncs are retried and reported to the business owner.

A written quote should list each integration, its direction and data objects, the identity method, the test environments, and the acceptance tests that show the work is complete. It should also state who manages the identity provider and directory changes, and who pays for ongoing connector maintenance after an upgrade. Cost depends on the number of connectors, the complexity of field mapping, the number of identity groups and the availability of test systems from each vendor. Ask for these items to be priced separately so you can see which parts are optional.

Each upgrade of the CRM, identity provider or connected system can change APIs, authentication settings or behavior, so integrations need regression testing after every change. SuiteCRM minor releases arrive roughly every eight weeks, and patch releases contain only security and bug fixes. Ask the partner whether support covers connector regression tests, how they track vendor release notes, and whether they keep a staging environment that mirrors production identity settings.

No. SuiteCRM documents the move from version 7 to version 8 as a migration, not an upgrade. A new SuiteCRM 8 environment is set up and the SuiteCRM 7 data is moved into it. Before that work starts, the 7 instance must first be brought to the latest 7.14.x release or later. Your implementation partner should confirm the exact starting version in writing, because the path depends on where your instance sits today. The official SuiteCRM migration documentation describes the steps and should be the baseline for the statement of work.

No public figure applies to your instance, so the quote should come from a written scope. The main cost components are discovery of your customizations, environment build for SuiteCRM 8, data mapping and transfer, testing with real users, cutover, and training. Costs rise with the number of custom modules, workflows, integrations, reports, and years of data to move. Ask for the work split into one-time items (migration, testing, cutover) and recurring items (hosting, patching, support). SuiteCRM Ltd also sells migration and support services, so ask whether the partner is comparing against that option.

SuiteCRM's migration guidance requires the source instance to reach the latest 7.14.x release or later before data moves into version 8. Starting from an older 7 release adds an extra step to the plan and increases the risk of data or customization mismatches. Your engineers should record the current version, apply the supported updates on a copy first, and confirm the instance runs cleanly before any migration tooling is touched. A version check at the start of discovery prevents rework late in the project.

Run the full migration on a staging instance that matches production as closely as possible, then test it before any cutover. SuiteCRM's migration guidance advises testing on staging, backing up files and the database, and reviewing customizations first. Test scenarios should include login, record access by role, email and calendar sync, reports, scheduled jobs, integrations, and a sample of records checked field by field. Keep the staging results in a signed test log so the cutover decision rests on evidence. Ask the partner how many test cycles are included in the fixed scope.

The migration may remove non-core files under the public/legacy folder, so any custom code, logic hooks, images, or scripts stored there can disappear during the move. SuiteCRM's guidance tells administrators to review customizations before migrating for this reason. Your partner should inventory every file outside the core distribution, classify each as kept, rewritten, or retired, and rebuild any required behavior in the SuiteCRM 8 environment. Keep a full file and database backup before the first migration run so any missing file can be restored and compared.

SuiteCRM 7.15 is an extended support release that receives security fixes until January 2028. For SuiteCRM 8, minor releases arrive roughly every eight weeks, and patch releases contain only security and bug fixes, with no new features or database changes. SuiteCRM has not yet nominated an extended support release for version 8, and it expects to name one by Q3 2027. Confirm the 7.15 end date and the 8 release plan on the SuiteCRM LTS page when you write the operations plan, and budget for regular patching as a recurring task.

Each platform has its own upgrade path, and none should be treated as a generic upgrade. EspoCRM ships an installation script that deploys a Docker-based stack with a command.sh utility for backups, restores and upgrades, and its major versions are published separately, so confirm which major version your partner targets. Twenty ships frequent releases and is self-hosted with Docker Compose, so the plan should cover how often your team applies them and how it tests each one. The same rules apply everywhere: staging first, a verified backup, a rollback plan, and a written change record.

Authentication is one of the first things to break after a migration or upgrade, so test it on staging before go-live. In SuiteCRM 8, LDAP is enabled with AUTH_TYPE=ldap and SAML with AUTH_TYPE=saml. SAML in SuiteCRM 8.7.0 and later does not support IdP-initiated logout or POST binding to the logout service, so logging out at the identity provider does not end the SuiteCRM session. Document that limitation for your security team, and confirm how your partner will handle session timeouts and account deprovisioning. The partner should also re-test role mapping after every upgrade.

Cost follows the written scope: how many pipelines, custom objects and fields you need, how many source systems must be imported, how many integrations are built, and how much training and cutover support is included. Hosting is paid to your cloud provider or data center, while implementation, configuration, integrations and support are paid to the partner. Licenses for the open-source cores are free in the case of SuiteCRM, EspoCRM and Twenty's open source core, but the paid plans of each vendor and any add-ons are separate costs. Ask for a quote that splits one-time work from recurring support, hosting and any vendor subscriptions, and confirm what happens when scope changes.

Duration depends on the number of records to migrate, how much the pipelines and fields differ from the standard setup, the number of integrations, and how many people must approve each stage. Email and calendar sync, identity integration and any SuiteCRM 7 to 8 migration add their own testing cycles. DeployOpen does not publish fixed timelines; a timeline is agreed in the written scope before work starts. Ask the partner to show the phases, the test and cutover gates, and which of your decisions the schedule depends on.

Plan to provide a named business owner who can decide on pipelines and stages, a list of the users and teams with their roles, sample exports from your current CRM or spreadsheets, and access to the identity provider if single sign-on is required. Your infrastructure team needs to confirm hosting, backups, DNS, certificates and network rules. Legal or privacy staff should define retention periods and how access and erasure requests are handled. Ask the partner to list these inputs in the written scope so gaps are found before the build, not during cutover.

Often yes, but it depends on your stack and skills. SuiteCRM and EspoCRM are PHP applications on MySQL or MariaDB, while Twenty is a TypeScript application on PostgreSQL and Redis, so an existing team's skills often decide the shortlist. Operations include patching, backups, restores, upgrades, monitoring and a scheduled job runner. EspoCRM's installation script includes a command utility for backups, restores and upgrades, and SuiteCRM publishes minor 8.x releases about every eight weeks, with patch releases containing only security and bug fixes. Confirm internally who will own each task, then decide whether to keep those tasks in-house, hand them to a partner, or split them.

Support is usually split into two parts: the work your team keeps, such as user requests and business-rule changes, and the work a partner covers, such as security patches, upgrades, monitoring and incident response. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing. Ask what response times are committed, whether they are written as SLAs, which environments are covered, and how upgrades are tested in staging before production. Vendors also offer their own support tiers, such as SuiteASSURED for SuiteCRM, so compare what each one covers with your plan.

SuiteCRM documents the move from version 7 to version 8 as a migration, not an in-place upgrade. A new SuiteCRM 8 environment is set up and the 7 data is moved into it, after the 7 instance is first brought to the latest 7.14.x or later release. The migration documentation recommends testing on a staging instance, backing up files and the database, and reviewing customizations, since the process may remove non-core files under the public/legacy folder. SuiteCRM 7.15 receives security fixes until January 2028, and no SuiteCRM 8 extended support release had been nominated when this was written, so confirm the planned timing in your scope.

Ask the partner to show how they map your current pipelines and custom fields, how they handle import modes and duplicate rules, how email sync is configured, and which integrations they have built on your chosen platform. Request their test plan, backup and restore procedure, and how they manage secrets and access. For compliance-driven work, ask how they prepare evidence for access logging, encryption and change management, while confirming that independent auditors issue any formal assessment. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms in your own infrastructure, and prepares evidence for assessments without issuing audit reports.

The answer depends on data location, customization needs, integration depth and how the per-seat cost grows with headcount. Hosted SaaS removes most server work but charges per user every month, while a self-hosted CRM shifts cost to hosting, configuration, support and the team that runs it. EspoCRM Cloud, for example, lists 15 US dollars per user per month on its Basic plan with a three-user minimum, according to the EspoCRM pricing page, so compare that figure with your projected headcount over the contract term. Ask for a side-by-side model that includes hosting, partner fees, training and migration.