EspoCRM vs Odoo CRM

EspoCRM is a focused, AGPL-3.0 CRM for teams that need sales and customer records without an ERP. Odoo CRM fits teams that already run, or plan to run, Odoo for accounting, inventory or other back-office work.

On this page

EspoCRM vs Odoo CRM: when CRM alone is the need and when ERP tips it

Choose EspoCRM when the CRM is the only system you are replacing and sales, service and marketing data can live in one standalone application. Choose the CRM app inside Odoo when you want opportunities, quotes and customers tied directly to invoicing, inventory or other Odoo apps. The deciding question is whether ERP integration is planned within the next few years, because that choice is far harder to reverse than the CRM itself. Three questions settle most of the decision. First, is ERP integration planned, and if so, which modules must share customer and order data with the CRM? Second, which Odoo edition do your required features need? The Odoo editions page lists the CRM app in both Community and Enterprise, but the pricing page states that multi-company, Odoo Studio, external API access and custom modules sit only in the Custom plan, which can be hosted on Odoo.sh or on-premise. Confirm each feature against your own requirements before assuming the free edition covers it. Third, do you need paid EspoCRM extensions? The Advanced Pack covers reports, business process management and workflows, and the Sales Pack covers quotes, invoices and inventory, so price those alongside the free core.

Your team's skills matter as much as the feature list. EspoCRM runs on PHP with MySQL, MariaDB or PostgreSQL and needs cron for background jobs, while Odoo is built on Python and PostgreSQL and carries a major-version upgrade cycle that you must plan for, since security updates apply only during standard support. Ask your platform team which stack it can operate and patch on schedule, then request a written scope from each vendor or implementation partner that lists the integrations, identity method and upgrade process you need before you commit.

Which scenario favors EspoCRM and which favors Odoo CRM

This table maps common buyer situations to the platform that fits each one better, with the condition that would flip the choice. Read each row against your own requirements, and treat any feature marked for vendor confirmation as an open question until the vendor answers it in writing.

ScenarioBetter fitWhy and when the other platform wins
CRM only, with no ERP plansEspoCRMEspoCRM is a standalone AGPL-3.0 CRM with a free self-hosted core, so you run only the sales tooling you need. Odoo CRM would win if ERP expansion becomes likely within a few years, since adding modules later is easier in the same suite.
CRM must feed invoicing and inventoryOdoo CRMOdoo is a suite covering accounting, inventory and sales in one PostgreSQL database. EspoCRM reaches quotes, invoices, inventory and payments only through the paid Sales Pack, so confirm that pack covers your exact invoicing flow before choosing it.
Multi-company groupsOdoo CRMMulti-company support is listed in Odoo's Custom plan, which is also the only plan that can run on Odoo.sh or on-premise. Confirm multi-company behavior for your entity structure with Odoo, and confirm whether EspoCRM's team and role model meets your separation needs.
Team already operating OdooOdoo CRMYour team already has Odoo skills, upgrade routines and support windows, so the CRM app adds little new operating load. EspoCRM would win only if the CRM needs to stay separate from the ERP for ownership or upgrade reasons.
PHP team with MySQL or MariaDB skillsEspoCRMEspoCRM runs on PHP with MySQL 8.0 or later or MariaDB 10.6 or later, so existing database and web server skills transfer directly. Odoo is built on Python and PostgreSQL, so it would win only if your team already runs PostgreSQL and Python services well.
Need to lock down Odoo upgrade costEspoCRMOdoo Online and Odoo.sh require major upgrades every two years, and Odoo 17.0 standard support ended in September 2026. Confirm your self-hosted upgrade path and the effort it needs for your version before committing to either platform.
Enterprise support and extended support neededOdoo CRMOdoo offers paid support, and its standard support covers three years after each major release, with extended support limited to Odoo.sh for select versions and on-premise. Confirm extended support terms and SLAs directly with Odoo, because EspoCRM support terms depend on your contract.
Reports, workflows and BPM as core needsEspoCRM with the Advanced PackThe Advanced Pack adds reports, business process management and workflows as a paid extension, and it is included in all EspoCRM Cloud plans. Confirm the license model for self-hosted use with EspoCRM, and compare against Odoo Enterprise features for the same needs.

How EspoCRM and Odoo are built and what that means for operations

EspoCRM is a standalone PHP application, while the Odoo CRM app runs inside a Python and PostgreSQL suite that carries its own release and upgrade rhythm. The differences in stack, installation and upgrade cadence decide how much patching, backup work and specialist skill your team carries after go-live.

Core stack and database choice

EspoCRM runs as PHP on MySQL 8.0 or later, MariaDB 10.6 or later, or PostgreSQL 15, and it needs cron or a scheduled task for background jobs. Odoo runs as Python on PostgreSQL. If your team already operates MySQL or MariaDB well, EspoCRM fits that skill set directly, while Odoo asks for PostgreSQL competence from the start. Confirm which database your backup and high availability tooling covers before choosing.

EspoCRM installation script

EspoCRM provides an installation script for Ubuntu, Debian and Linux Mint. It deploys a Docker-based stack with Nginx and MariaDB, optional Let's Encrypt certificates and a command.sh utility for backups, restores and upgrades. This lowers the initial build effort, but your team still owns the host, the Docker layer, certificate renewal and the restore tests. Ask whether your environment matches the supported distributions before planning.

Odoo packaged and source installs

Odoo documents packaged installers and installation from source for on-premise use. Enterprise databases are activated by entering the subscription code, and the Enterprise source code is not publicly available, so an on-premise Enterprise install depends on a subscription or partner access. Test copies can be created by database duplication with neutralization. Decide early whether your team will build from source, use packages, or let a partner manage the install.

Odoo major versions and support windows

Odoo provides standard support for three years after each major release, and security updates arrive only during that window. Odoo 20.0 has standard support planned until September 2029, while Odoo 17.0 standard support ended in September 2026. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years. Plan a recurring upgrade project, test the upgraded database before production, and budget the Enterprise subscription needed for on-premise upgrades.

Patching and EspoCRM release tracking

EspoCRM ships point releases within its major line, and the current line is 10.0. Patching is largely your responsibility: you apply updates with the upgrade tooling, keep PHP and the database within the supported ranges, and test extensions such as the Advanced Pack after each change. Ask EspoCRM and your partner how security fixes are announced and how long the 9.x line is maintained before you commit to a patch calendar.

Skills to hire or keep

EspoCRM demands PHP, web server and MySQL, MariaDB or PostgreSQL administration, plus cron and scheduled task management. Odoo demands Python and PostgreSQL work, and it adds an upgrade discipline that often needs a developer who understands custom modules. Odoo Studio and custom modules are gated to the Custom plan, so customization skills matter more for Odoo. List which of these skills exist in-house today and which you would need to buy through a partner.

How the two platforms compare on the capabilities that decide the shortlist

This table sets EspoCRM and the Odoo CRM app side by side on licensing, editions, reporting and automation, sign-in, API access, stack and support windows. Read each row against the edition you would actually buy, because several Odoo capabilities depend on the subscription tier. The main takeaway: EspoCRM is a focused CRM extended by paid packs, while Odoo CRM arrives inside an ERP suite whose editions decide what you get.

CapabilityEspoCRMOdoo CRM
LicenseAGPL-3.0 for the open-source coreLGPL-3.0 for Community. Enterprise source is not public and requires a subscription.
Core CRM scopeStandalone CRM. Quotes, invoices and inventory come from the paid Sales Pack.CRM app inside a suite that also covers accounting, inventory, HR and manufacturing.
Free self-hosted editionOpen-source edition can be downloaded and self-hosted for free.Community edition is fully open source and lists the CRM app.
Paid add-ons or editionsAdvanced Pack and Sales Pack are paid extensions. Cloud plans include the Advanced Pack.Enterprise adds features and support. Confirm which CRM features are Enterprise-only with the vendor.
Reports and workflowsReports, BPM and workflows sit in the Advanced Pack. Formula Script drives workflow logic.Confirm with the vendor which CRM reporting and automation ship in Community versus Enterprise.
Identity optionsOpenID Connect with group-to-team mapping, plus LDAP for Active Directory and OpenLDAP. EspoCRM 2FA is not compatible with OIDC.LDAP authentication is documented. Confirm OIDC or SSO availability by edition with the vendor.
API access and authenticationAPI key, HMAC (most secure) and basic authentication through dedicated API users with role permissions.External API access is on the Custom plan. Confirm supported authentication methods with the vendor.
Database and stackPHP 8.3 to 8.5 on Apache, Nginx or IIS with MySQL 8.0+, MariaDB 10.6+ or PostgreSQL 15. Cron runs background jobs.Python application on PostgreSQL. Hosting on Odoo.sh or on-premise requires the Custom plan.
Supported version windowsCurrent line is 10.0, with 10.0.10 released October 14, 2026. Confirm per-version support with the vendor.Standard support runs three years per major release with security updates. Version 20.0 is supported until September 2029.

What each platform gives away free and what it charges for

EspoCRM's core is licensed under AGPL-3.0, and the open-source edition can be downloaded and self-hosted for free. Paid functionality sits on top as official extensions, and two of them matter most for a CRM buyer: the Advanced Pack and the Sales Pack. The other way to pay is EspoCRM Cloud, which is billed per user, per the EspoCRM pricing page.

  • Core license: The espocrm/espocrm repository is AGPL-3.0, so the self-hosted core carries no license fee under that license. You still pay for the server, administration and upgrades.
  • Advanced Pack: Adds reports, Business Process Management and workflows. It is included in all EspoCRM Cloud plans, so confirm the license terms that apply to a self-hosted instance before you assume it is free.
  • Sales Pack: Adds products, quotes, invoices, purchases, subscriptions, inventory and payments. Buy it only if your sales process runs those objects inside the CRM.
  • Other official extensions: VoIP, Google, Outlook, MailChimp, Zoom and Stripe integrations. Each is a separate decision that adds configuration and testing work.
  • EspoCRM Cloud: The Basic plan costs 15 US dollars per user per month (minimum 3 users), Enterprise costs 25 dollars (minimum 5 users), and the highest plan costs 69 dollars (minimum 10 users). The Advanced Pack is included in all cloud plans.

Before you budget, confirm how a self-hosted instance is licensed for each paid extension and whether the cloud minimums match your user count.

How each platform is extended and how users sign in

Both platforms let a team change the CRM without forking the core, but they do it in different places and under different licenses. EspoCRM customizes through its Entity Manager and Formula Script, and signs users in through OIDC, LDAP or its own login. Odoo extends through modules and Studio on the Custom plan, and signs users in through its LDAP authentication. The checks below focus on what your identity provider needs and which tier you must buy.

EspoCRM Entity Manager and Formula Script

The Entity Manager lets administrators add fields, change entities and configure behavior without editing core code. Formula Script runs in before-save scripts configured there, in API before-save scripts, and in workflows and BPM. This matters when the CRM must enforce rules such as required fields or derived values on every write, including writes made through the API. Confirm which of your rules belong in before-save scripts and which need the Advanced Pack's workflows and BPM, since those are paid extensions on EspoCRM and not part of the free core. Have a developer review scripts before they reach production, because they run on every matching save.

EspoCRM OpenID Connect sign-in

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, and backchannel logout. This matters when your identity provider already controls joiners, movers and leavers, because team membership and account removal can follow the directory. Confirm that your provider can send the group claims EspoCRM needs and that backchannel logout reaches your session model. A fallback login method is available, so decide and document who may use it. EspoCRM's own two-factor authentication does not work with OIDC, so enforce MFA at the identity provider.

EspoCRM two-factor and OIDC conflict

EspoCRM's own two-factor authentication is not compatible with OIDC sign-in. If you plan to use OIDC as the main login path, MFA must come from your identity provider, and you should test that policy against the fallback login method, which may bypass it. This matters for regulated teams that must show MFA on every access path. Confirm which MFA methods your provider supports, how it applies to users created on first login, and whether the fallback login is restricted to a small administrative group. Document the decision before go-live so auditors see one clear control rather than two conflicting ones.

EspoCRM LDAP for directory users

EspoCRM documents LDAP authentication, including Active Directory and OpenLDAP. This suits organizations that keep user accounts in a directory and want logins to follow it without OIDC. The choice matters most where the directory is the system of record and your team already runs it. Confirm the bind account, the user search base, and how disabled directory accounts are handled in EspoCRM, since a disabled user should lose CRM access. Also confirm whether group membership maps to teams, because that mapping drives record visibility.

Odoo Studio and custom modules

Odoo extends through custom modules, and Studio for visual changes, but only the Custom plan includes Studio, multi-company, external API access and custom modules according to Odoo's pricing page. Odoo's Community edition is LGPL-3.0 and can be extended by developers, but Studio and the paid plan features are not available there. This matters when your CRM changes must sit inside a broader ERP data model. Confirm with Odoo which features your planned customizations need, whether Studio changes survive upgrades, and who will maintain custom modules through each major version.

Odoo LDAP and API authentication

Odoo documents LDAP authentication for user logins, which suits teams with directory-managed accounts. Its external API access is available on the Custom plan, so integrations need an API credential plan of their own. This matters when a CRM sits beside other systems that authenticate against the same directory. Confirm how LDAP users are provisioned in Odoo, how removed directory accounts lose access, and which API credentials your integrations will use. Ask Odoo to confirm which authentication methods are included in your chosen plan before you design the integration.

What drives the running cost of each platform

The software license is the smallest and most predictable cost in both platforms, and it is not where the running budget goes. EspoCRM's AGPL-3.0 core can be downloaded and self-hosted for free, so the license line is zero unless you add paid extensions. If you need reports, workflows or business process management, the Advanced Pack is the extension the scope will name, and it is included in every EspoCRM Cloud plan: Basic at 15 US dollars, Enterprise at 25 and Ultimate at 69 per user per month, with minimums of 3, 5 and 10 users. Odoo's Community edition is LGPL-3.0 and free to run, but multi-company, Odoo Studio, external API access and custom modules sit only in the Custom plan, and on-premise hosting also requires a Enterprise subscription. Ask each vendor for the current per-user prices, the yearly discount terms and whether the quote covers Odoo Enterprise or only Community.

The recurring costs are hosting, administrator and developer time, patching and upgrades, and support. On the EspoCRM side, the server configuration documentation requires PHP 8.3 to 8.5, a supported MySQL, MariaDB or PostgreSQL database, and cron or a scheduled task for background jobs, so the admin effort is mostly a standard LAMP-style stack. On the Odoo side, the standard support window drives upgrade cost: standard support covers three years after each major release, security patches stop when it ends, and on Odoo Online and Odoo.sh major upgrades are mandatory every two years. Odoo 17.0 standard support ended in September 2026, so a database on that line already needs a planned move. Upgrades that touch custom modules and integrations cost more than the platform update itself, and the Odoo upgrade service requires Enterprise on-premise.

For the written quote, one-time costs are implementation, customization, data migration and test environment setup, and recurring costs are licenses, hosting, retained support and upgrade work. Request the number of users by role, the hosting model, the Odoo edition and any Odoo modules beyond CRM that the scope touches, the EspoCRM extensions required, the retainer or fixed-scope split, the upgrade and test plan for each major release, and who pays for custom module maintenance after handover. Confirm the exact Odoo support dates and pricing with Odoo and EspoCRM's current terms with the vendor before you sign, since these are the figures that change most often.

How to move CRM data between EspoCRM and Odoo in a planned order

This sequence turns a move between EspoCRM and Odoo CRM into a checked, reversible project, so the team knows what moved, what was rebuilt and what was retired before production changes.

  1. Confirm target edition and extensions

    Decide which edition and paid add-ons the target needs before any mapping starts, because the features in use decide the build. On the EspoCRM side, reports, workflows and BPM sit in the Advanced Pack and quotes, invoices and inventory sit in the Sales Pack. On the Odoo side, multi-company, Odoo Studio, external API access and custom modules are listed only for the Custom plan, and on-premise hosting requires an Enterprise subscription. Done when the team has a written list of required editions and a quote that matches it.

  2. Map entities, fields, users and teams

    The data owner and the platform engineer build a field-by-field map from source to target, covering accounts, contacts, leads, opportunities, activities and attachments. The map also covers users, teams and permissions, since the two products model roles and record visibility differently and those rules rarely carry across unchanged. Done when every source field has a target field, a transform rule or a documented reason to drop it, and the owners have signed off the permission model.

  3. Design identity and sign-in

    The identity team decides how users sign in on the target before accounts are created, using EspoCRM's OpenID Connect or LDAP options or Odoo's LDAP authentication, and confirms which fallback login stays in place. Note that EspoCRM's own two-factor authentication does not work with OIDC, so the second factor must come from the identity provider. Done when a test user can sign in through the chosen method and the admin account recovery path is tested.

  4. Export and import data with a test run

    The admin exports from the source, cleans duplicates and invalid records, and imports into the target on a test instance, using EspoCRM's import documentation for the EspoCRM side. Record counts, relationships and attachments are compared against the source export after each run. Done when a full test import reconciles on record counts and sample records, and every mismatch has an owner and a fix.

  5. Rebuild workflows and automations

    Workflows, approval rules, scheduled jobs and scripts are rebuilt on the target, because they do not transfer one to one between the two products. On EspoCRM this means Formula Script in the Entity Manager, workflows and BPM, and on Odoo it means the automation features of the chosen edition. This is usually where most of the build effort sits, so the team should inventory every automation before estimating it. Done when each source automation has a rebuilt equivalent or a documented decision to retire it.

  6. Validate on a test copy

    Validation runs on a separate copy of the target, and Odoo's database duplication with neutralization is useful for creating test copies from a production database without live outbound effects. Testers run real sales scenarios, check permissions by role and confirm integrations and email behavior. Done when the test copy passes signed-off scenarios and the rollback steps have been rehearsed.

  7. Cut over to the new system

    The team freezes writes on the source, runs a final delta export and import, and switches users and integrations to the target during an agreed window. The cutover runbook names who decides go or no-go and who can trigger rollback. Done when the final reconciliation matches the test run and users confirm they can work in the new system.

  8. Retire the old system with records kept

    The source is set to read-only and then decommissioned, but its final backup, audit logs and export archive are kept under the organization's retention policy. Keeping those records lets auditors and staff check historical activity after the switch. Done when the archive is verified as restorable and the retention owner has accepted it in writing.

Where EspoCRM and Odoo CRM implementation projects usually run long

Projects on EspoCRM tend to run long where custom entities, formula logic and identity testing meet in the same sprint. Entity Manager changes, before-save scripts written in Formula Script, and workflows or BPM rules are often scoped as small items, then grow once data owners review field types, relationships and permissions. Identity testing is the other common overrun. OIDC sign-in needs group-to-team mapping, the choice of whether to create users on first login, and a fallback login method all checked against real identity provider accounts, and EspoCRM's own 2FA is not compatible with OIDC, so that decision must be made early. Confirm in writing whether LDAP is in scope for Active Directory or OpenLDAP, and who tests it. Hosting setup also slips: background jobs require cron or a scheduled task, and a missed scheduler means workflows and reminders silently stop. Scope any paid extension, such as the Advanced Pack for reports and workflows or the Sales Pack for quotes and invoices, as a separate line item with its licensing confirmed in writing.

Projects on Odoo CRM run long for different reasons. The first is edition choice: the CRM app appears in both Community and Enterprise, but features such as multi-company, Odoo Studio, external API access and custom modules sit on the Custom plan, and on-premise hosting is limited to that plan too. Confirm the edition against the feature list before design starts, not after. The second is module scope. Adding sales, accounting or inventory apps turns a CRM rollout into an ERP project with its own data migration and approval chain, so decide which apps are in scope for the first release. The third is the upgrade test cycle. Upgrades run on a test database that must be validated before production, and on-premise use requires an Enterprise subscription. Plan a test window for every major version. The fourth is the support window: standard support for Odoo 20.0 runs until September 2029, and security patches stop outside standard support, so the version chosen sets the next upgrade date.

Before work starts, the team needs a data owner for each CRM object and pipeline, an identity administrator who can configure the provider and test group mapping, hosting access for the chosen server, database and scheduler, and a named sign-off authority for each phase. Put in writing the edition or plan, the list of paid extensions or Enterprise features, the in-scope ERP apps, the upgrade test window and the support end date for the chosen version. Ask DeployOpen to state which items are fixed scope and which are retainers, so the cost of later changes is visible in the quote.

What buyers ask before choosing between EspoCRM and Odoo CRM

Is the free EspoCRM core enough for a small sales team?

It can be, if you do not need reports, workflows or business process management in the product itself. The AGPL-3.0 core can be downloaded and self-hosted for free, according to the EspoCRM pricing page. The Advanced Pack adds reports, Business Process Management and workflows, and the Sales Pack adds products, quotes, invoices, purchases, subscriptions, inventory and payments. List the screens and automations your sales process needs, then check each against the free core and the paid extensions. Confirm extension licensing terms with EspoCRM before you budget, since the extensions are sold separately from the core.

Is Odoo CRM free to self-host?

The Community edition is free to use and is licensed under LGPL-3.0, and the editions page lists the CRM app in both Community and Enterprise. Running it still has costs: your own servers, PostgreSQL, backups, upgrades and admin time. The features that matter most for a self-hosted buyer sit behind paid tiers. According to Odoo's pricing page, only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. Confirm with Odoo which edition and plan your required features need before you assume the Community edition covers them.

Which Odoo features need Enterprise or the Custom plan?

Based on the supplied pricing facts, the Custom plan is the only plan that can run on Odoo.sh or on-premise, and it is the only plan that includes multi-company, Odoo Studio, external API access and custom modules. Enterprise is also required for on-premise use of the Enterprise edition, which is activated with a subscription code. List the features your sales team and integrations need, such as multi-company accounts, API access for your own middleware, or custom fields built in Studio. Then ask Odoo in writing which edition and plan includes each one, because feature placement can change between releases.

How long does a migration take, and what drives the effort?

No duration is supplied for either platform, so the answer depends on your data and process. The main drivers are the volume and quality of contacts, accounts and history, how many custom fields and workflows must be rebuilt, how many systems feed or read CRM data, and whether finance or inventory data must move with it. Odoo's upgrade documentation recommends testing an upgraded database before production, and EspoCRM's import documentation covers loading records. Ask any implementation partner for a fixed-scope written plan that lists the entities, integrations and test cycles included, so the timeline follows from the scope and not from a guess.

Can our team run either platform without outside help?

It depends on your database and web hosting skills and on how much change you plan to make. EspoCRM runs on PHP 8.3 to 8.5 with MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15, and it needs cron or a scheduled task for background jobs. An installation script for Ubuntu, Debian and Linux Mint deploys a Docker-based stack with Nginx and MariaDB. Odoo is built on Python and PostgreSQL, and its on-premise and source installation paths are documented. Odoo customization and upgrades usually need developers who know its framework. Assess your team's skills against these requirements, and treat an outside partner as one option, not a default.

How do Odoo's support windows affect upgrade planning?

Odoo provides standard support for three years after each major release, with security updates only during standard support. Odoo 20.0 was released in September 2026 with standard support planned until September 2029, and Odoo 17.0 standard support ended in September 2026. Odoo SaaS versions are released every two to three months and cannot use extended support. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years. Plan a recurring upgrade project, test each upgraded database before production, and confirm with Odoo which extended support options apply to the version you choose.

What does ERP integration add, and when is it worth the extra weight?

ERP integration matters when quotes, orders, invoices, inventory or accounting must share one customer record with the CRM. It adds weight: more modules, a larger database, more upgrade work and more people who must agree on master data. If your CRM is the only system that needs to be right, a standalone CRM is usually simpler to run. EspoCRM's Sales Pack covers quotes, invoices and inventory inside the CRM, which may be enough without a full ERP. Map which data each team owns and which system is the source of truth before you decide.

How DeployOpen helps choose, implement or migrate between these platforms

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For EspoCRM vs Odoo CRM, we start by checking whether CRM alone or the wider Odoo suite is the real requirement, then build the scope around that answer.

How we scope

  • We confirm which CRM workflows, integrations and identity requirements the platform must cover before any build starts.
  • We check which features need Odoo Enterprise or EspoCRM paid extensions, so licensing is settled in the written scope.
  • Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins, and ongoing support available as a retainer.

How we build

  • We install and configure the chosen platform in your cloud account, data center or air-gapped network.
  • We build entity customizations, workflows and integrations against your existing identity provider and data sources.
  • We run security testing and harden the deployment, including access control, backups and restore checks.

How we hand over

  • We document the architecture, configuration, customizations and upgrade steps so your team can operate the system.
  • We prepare the controls and evidence your compliance assessors may ask for, without issuing any audit report or certification.
  • We walk your administrators through backups, restores and upgrade testing before the scope closes.

How we support

  • Ongoing support, upgrades and continuous testing can be taken on as a retainer after handover.
  • Upgrades are tested in a non-production copy before any change reaches live users.
  • We can plan a migration between the two platforms, with the scope, data mapping and cutover agreed in writing first.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.