Which self-hosted project tool fits your team: OpenProject or Plane
OpenProject fits classic, schedule-driven and mixed teams, and Plane fits engineering teams already working in Jira or Linear style issue flows. If you are leaving a spreadsheet plan or Jira and your stakeholders need Gantt charts, baselines and a login path through LDAP or SAML, OpenProject matches that shape of work. If your developers want backlogs, cycles and issue states first, and the planning layer is secondary, Plane is the closer fit. Many teams are mixed, so decide which group sets the daily workflow and which group only needs visibility.
Three decision drivers matter most. First, identity: on OpenProject, SAML, OpenID Connect, CAS, Kerberos and LDAP group synchronization sit in the Enterprise plans on the OpenProject pricing page, while on self-hosted Plane, SAML and OIDC start at Pro and LDAP is an Enterprise feature on Plane pricing. Confirm which login method your directory needs and which tier includes it before you build a plan around it. Second, the Jira import path: OpenProject's Jira Migrator reads only Jira Data Center 10.x and 11.x and is in beta, so Jira Cloud teams should plan a test import. Plane's Jira importer supports Jira Cloud as well as Server and Data Center on its Commercial Edition, but moving to a paid plan requires switching from Community to Commercial with a license key.
Third, the deployment stack. OpenProject runs on Docker or packaged installs with PostgreSQL 16 or later and the pg_trgm, btree_gist and unaccent extensions. Self-hosted Plane needs PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage such as MinIO, so the operational footprint is wider. Ask your platform team which of these services they already run, which they can host as managed services, and whether the air-gapped Plane edition is required. Those answers will usually settle the choice before feature comparisons do.
Which platform fits which team scenario
This table maps common team situations to the platform that fits better and the condition that makes the choice hold. Read each row against your own sprint model, reporting needs and Jira deployment type, because the importer and paid-feature facts decide several of the answers.
| Scenario | Better fit | Condition that makes it hold |
|---|---|---|
| Engineering-only sprint work with issues, backlog and boards | Plane | Your team works in issue-first flows, wants a Jira or Linear style interface, and does not need Gantt charts as the planning view |
| Mixed business and delivery teams sharing one plan | OpenProject | Non-engineering stakeholders need Gantt timelines, work packages, dashboards and time tracking alongside agile boards in one tool |
| Teams that need Gantt charts and baseline comparison | OpenProject | Baseline comparison is listed as an Enterprise feature on OpenProject's pricing page, so budget for a paid tier if you need it |
| Teams needing SSO with LDAP group sync on self-hosted installs | OpenProject | Your directory sync requirement is covered by Enterprise plan features, and you accept per-user monthly licensing to get them |
| Teams needing SAML or OIDC without LDAP | Plane | SAML and OIDC are available on Plane's Pro tier and above, so a lower-tier paid plan may meet the need; confirm the seat counts with Plane |
| Migrating from Jira Cloud | Plane | Plane's Jira importer supports Jira Cloud on Plane Cloud and on all plans of the self-hosted Commercial Edition, while OpenProject's Jira Migrator covers Data Center only |
| Migrating from Jira Data Center 10.x or 11.x | Either, with a test first | Both can import from Data Center; OpenProject's Jira Migrator is in beta and documented for test setups, so run a trial import before committing |
| Teams planning to move from Community to a paid tier later | OpenProject | OpenProject's Enterprise plans are added to the same install path, while Plane's paid features require switching from Community to the Commercial Edition with a license key |
How OpenProject and Plane are built and deployed
Both platforms can run on your own servers, but the install paths and the number of services you operate differ. The cards below cover what each stack asks of an operations team on day one and across upgrades and backups.
OpenProject install options
OpenProject supports Docker-based installation, which the project recommends, plus .deb and .rpm packages for 64-bit Linux and Kubernetes with Helm charts for horizontal scaling. Packaged installs are limited to Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15. Confirm your distribution is on that list before choosing packages over containers, since the choice drives how you patch and roll back.
PostgreSQL 16 and required extensions
OpenProject officially supports PostgreSQL 16 or later from version 16.0.0 and requires the pg_trgm, btree_gist and unaccent extensions. Check that your managed or in-house database service allows these extensions before you commit to a host layout. Most of your backup and restore planning will centre on this database, so agree on the owner of the PostgreSQL instance early.
OpenProject sizing guide
The sizing guide suggests 4 cores and 4 GB RAM for up to 200 users, 8 cores and 8 GB for about 500 users, and 16 cores and 16 GB for about 1,500 users. Treat these as starting points and load-test with your own project and attachment volumes. Ask the vendor how sizing changes with Enterprise add-ons such as portfolio views, since heavier reporting can shift the load profile.
Plane's service stack
A self-hosted Plane deployment runs PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible object storage such as MinIO. Each of these is a separate service to back up, monitor and upgrade, so the operating footprint is wider than a single application database. The Helm chart can point each component at an external managed service, which reduces in-cluster state but moves responsibility to your cloud or data team.
Plane deployment methods
Plane documents Docker Compose for small and mid-size teams, Kubernetes with Helm for high availability, and other methods including Podman and air-gapped installs. Air-gapped use depends on the Airgapped edition, which is proprietary, so confirm with Plane which edition and update channel your network can receive. Ask how the Compose and Helm paths are upgraded, and whether the Community and Commercial images follow the same version numbers.
Upgrades, backups and operating load
OpenProject ships roughly monthly minor releases, so plan a recurring upgrade window and test each one against your PostgreSQL and extension setup. Plane's release cadence and per-edition cycles mean you should map which edition each environment runs before scheduling upgrades. For both, define backup scope across the database, file storage and configuration, and rehearse a restore that includes every service in the stack.
How SSO, LDAP and Jira import differ in practice
On OpenProject, single sign-on with SAML, OpenID Connect, CAS, Kerberos and Okta and LDAP group synchronization sit in the Enterprise feature set listed on the pricing page, beyond the free Community edition. On Plane, self-hosted SAML and OIDC are available from the Pro plan upward, while LDAP support is listed as an Enterprise feature. The practical difference is that a team wanting directory-driven group membership will pay for an Enterprise tier on either platform, but the paid tier at which SSO first appears differs, and LDAP sits at the top of Plane's ladder.
- OpenProject SSO: Enterprise adds SAML, OIDC, CAS, Kerberos and Okta options, which matters if your identity provider is one of these protocols.
- OpenProject LDAP group sync: Directory groups can drive project membership only on Enterprise, so plan who manages groups in the directory.
- Plane SSO: SAML and OIDC start at Pro, so a team that needs single sign-on but not directory group sync may pay less on Plane.
- Plane LDAP: LDAP support is an Enterprise feature, so a directory-based login requirement pushes Plane to its highest self-hosted tier.
- Edition coupling: Plane's self-hosted paid features require moving from Community to the Commercial edition with a license key.
Before sign-off, confirm with each vendor which identity protocols and directory features are included in the exact edition and plan you will buy, and test a login with your own identity provider in a non-production instance.
The OpenProject Jira Migrator imports from Jira Data Center 10.x and 11.x and does not support Jira Cloud. It is in beta, and the documentation advises using it only in test setups. Plane's Jira importer is available on Plane Cloud and on all plans of the self-hosted Commercial edition, and it supports Jira Cloud as well as Jira Server and Data Center. For a team whose Jira instance is in the cloud, that difference alone can decide the shortlist.
- OpenProject source scope: Only Jira Data Center 10.x and 11.x are in scope, so Jira Cloud and older Data Center versions need a different path.
- OpenProject maturity: The migrator is in beta, so a production cutover should rest on a rehearsal in a test setup.
- Plane source scope: Jira Cloud, Jira Server and Data Center are all listed, which widens the set of teams it fits.
- Plane edition requirement: The self-hosted importer depends on the Commercial edition, so the importer is tied to the paid path.
- Data mapping: Ask each vendor how issues, custom fields, workflows, attachments and sprints map, because the list of supported objects is not part of the researched facts.
Confirm your exact Jira deployment type and version, run a trial import of a representative project, and compare the imported item counts and fields against the source before agreeing a migration plan.
Some facts that affect a migration plan are not settled by the public material alone, so they belong on a written question list for each vendor. The questions below are the ones a platform team should close before committing budget or a cutover date. Each answer should be recorded against the edition and version you intend to run.
- Edition boundary: Ask which features apply to the exact edition and plan you buy, including whether directory group sync and SSO are bundled or priced separately.
- Importer support window: Ask OpenProject whether the Jira Migrator will leave beta and when Jira Cloud support is planned, if at all.
- Importer scope: Ask Plane which Jira objects, attachments and workflow states the importer carries across, and which need manual rework.
- Upgrade path: Ask both vendors how identity configuration and imported data survive upgrades between releases.
- Support responsibility: Ask who handles SSO and LDAP issues in your environment, your team, DeployOpen or the vendor's paid support.
Record each answer in writing with the version it refers to, since release cadences on both sides move quickly.
Capability comparison: OpenProject and Plane
This table compares OpenProject and Plane on license, paid tiers, SSO and LDAP placement, Jira import, deployment and database requirements. Read the rows where both platforms show a check or a clear statement as points that need a side-by-side test, and treat the cells marked to confirm as open questions for your vendor call.
| Capability | OpenProject | Plane |
|---|---|---|
| License and community edition | GPL-3.0 Community edition, free, with work packages, Gantt charts, agile boards, time tracking and dashboards | Community Edition under AGPL-3.0, matching the feature set of the Plane Cloud Free tier |
| Paid tier entry point | Enterprise on-premises priced per named user per month, with Basic at 5.95 euros and a 25-user minimum at Professional | Self-hosted paid plans need the proprietary Commercial Edition and a license key; Pro and Business are listed per user per month in US dollars |
| SSO and LDAP placement | SAML, OIDC, CAS, Kerberos, Okta and LDAP group synchronization are Enterprise features | SAML and OIDC start at Pro on self-hosted; LDAP support is an Enterprise feature |
| Gantt and agile boards | Gantt charts and agile boards are included in the Community edition | Confirm Gantt and board views for your plan and edition with Plane before committing |
| Portfolio and resource management | Portfolio and resource management are Enterprise features | Confirm portfolio and resource capabilities against the Business and Enterprise Grid tiers |
| Jira import | Jira Migrator supports Jira Data Center 10.x and 11.x only, not Jira Cloud, and is in beta | Jira importer supports Jira Cloud and Jira Server or Data Center on the self-hosted Commercial Edition |
| Deployment methods | Docker-based install (recommended), .deb and .rpm packages, and Kubernetes with Helm for horizontal scaling | Docker Compose for small and mid-size teams, Kubernetes with Helm, Podman and air-gapped installs |
| Database and storage | PostgreSQL 16 or later with pg_trgm, btree_gist and unaccent extensions | PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible object storage such as MinIO |
| Linux and package support | Packaged installs support Ubuntu 22.04, Debian 12, RHEL 9.x and SUSE Linux Enterprise Server 15 | Confirm supported host operating systems and package formats with Plane for your target environment |
What is free and what is paid on each platform
OpenProject is licensed under GPL-3.0 and developed by OpenProject GmbH. The Community edition is free and includes work packages, Gantt charts, agile boards, time tracking and dashboards, with community support. Paid capability arrives through the Enterprise plans for on-premises installs, which are priced per named user per month.
- Basic at 5.95 euros: per named user per month on the OpenProject pricing page, with no stated user minimum in the supplied facts.
- Professional at 10.95 euros: per named user per month, with a 25-user minimum.
- Premium at 15.95 euros: per named user per month, with a 100-user minimum.
- Corporate on request: intended for 250 or more users, so the reader should ask for a written quote tied to the scope.
- Enterprise features: SAML, OpenID Connect, CAS, Kerberos and Okta single sign-on, LDAP group synchronization and custom branding are listed as Enterprise features.
Recurring fees scale with the named user count, so the reader should confirm how the seat count is measured and whether minimums apply to the whole tenant. Ask for the quote to state which tier includes SSO and LDAP group sync, since those features drive the tier choice for regulated teams.
Plane Community Edition is licensed under AGPL-3.0 and matches the feature set of the Plane Cloud Free tier. Plane self-hosting also offers two other editions: Commercial and Airgapped. Both are proprietary and each is built on a distinct codebase with its own release cycle, so the free install and the paid install are not the same software.
- Community edition: AGPL-3.0 with the Cloud Free feature set and no license key required.
- Commercial edition: proprietary, unlocked with a license key, and the edition used by the Kubernetes guide.
- Airgapped edition: proprietary, aimed at installs without outbound network access.
- Free plan limit: the Kubernetes docs list a Free plan with 12 seats and the Free feature set.
- Pro and Business pricing: Pro is shown at 6 to 8 US dollars and Business at 13 to 15 US dollars per user per month, with Enterprise Grid priced on request.
The switch is the step most teams miss. A self-hosted Community install must first move to the Commercial Edition before any paid plan applies, and paid seats are counted by users with paid roles. Confirm with Plane how a migration from Community to Commercial is performed and whether data moves in place.
On self-hosted Plane, SAML and OIDC sit on Pro and above, while LDAP support and API-enabled audit logs are listed as Enterprise features. The cost question therefore depends less on the base seat price and more on which identity and audit controls the organization needs on day one.
- SAML and OIDC: available from Pro upward on self-hosted deployments.
- LDAP support: listed as an Enterprise feature, so directory-based sign-in for on-premises teams may require the Enterprise Grid quote.
- API-enabled audit logs: also an Enterprise feature, which matters for teams with audit evidence requirements.
- Seat counting: paid seats follow users with paid roles, so guest and viewer role assignments should be reviewed before a quote.
- Recurring cost: per-user subscriptions recur monthly, while the Community install carries no license fee but still needs hosting and staff time.
Ask Plane for a written quote that lists the tier, the seat count, the role mix and whether LDAP and audit logs are included. Confirm which fees are charged on the Commercial edition when the deployment is air-gapped.
License fees are only one line in the cost of either platform. The vendor is paid for subscriptions, the implementation partner is paid for the install, integration and migration work, and the client's own staff run the hosting, backups and upgrades. Each of these costs behaves differently over time.
- One-time costs: installation, SSO and LDAP wiring, data migration from Jira or another tracker, and acceptance testing.
- Recurring costs: subscription seats, hosting infrastructure, backup storage, upgrades and staff time for administration.
- OpenProject sizing: the sizing guide suggests 4 cores and 4 GB RAM for up to 200 users, 8 cores and 8 GB for about 500 users and 16 cores and 16 GB for about 1,500 users.
- Plane infrastructure: PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage each add operating load unless they are provided as managed services.
- Quote scope: DeployOpen agrees scope, deliverables and timelines in writing before work starts, and the quote follows from that scope.
Before comparing totals, ask both vendors for their seat counting rules, minimums and tier boundaries, then model the same user count and role mix on each side.
Moving work from one platform to the other
This sequence moves work between OpenProject and Plane without losing the project history your teams depend on, and it ends with a documented rollback path. Because the two products use different data models, the move is a re-platform rather than a configuration change.
Confirm the Jira source and version
Identify whether your source is Jira Cloud or Jira Data Center or Server, and record the exact version. OpenProject's Jira Migrator reads from Jira Data Center 10.x and 11.x, not Jira Cloud, and its documentation advises beta use only in test setups. Plane's Jira importer supports Jira Cloud as well as Jira Server and Data Center, so the source type can decide which tool fits. Done when the source type, version and the owner of the export are written down.
Run a test import into a sandbox
Stand up a non-production instance of the target platform and import one representative project, including its issue types, links, attachments and sprints. Run this as the platform team with a sample of project managers, using the target's own importer documentation. Done when the test project's issue counts and key fields match the source, and any gaps are logged with a clear owner.
Decide what is rebuilt, not migrated
List every project, custom field, workflow, status and permission scheme in Jira, then mark each as transfers, is recreated by hand, or is retired. Expect custom workflows, field types and dashboard views to need manual rebuilding, because the two products model these differently. Done when a signed-off inventory exists, with each item assigned to a builder and a decision on whether it moves at all.
Map users, roles and groups to identity
Map each Jira user and role to a target role, and decide how sign-in works before cutover. On OpenProject, SAML, OIDC, CAS, Kerberos and LDAP group synchronization sit in the Enterprise feature set, so confirm your edition covers the method you need. On self-hosted Plane, SAML and OIDC start at the Pro plan and LDAP is listed as Enterprise. Done when a test user from each role signs in through the chosen method and gets the expected access.
Validate content and permissions in the test environment
Compare a sample of imported items against the source for attachments, comments, history, assignees and permissions, and check that users see only what they should. Confirm the licensing position too: Plane's self-hosted Community install must move to the Commercial Edition before any paid plan, and seat counts follow paid roles. Done when the validation checklist is signed by the project owners and the licensing path is confirmed in writing with the vendor.
Cut over with a frozen source
Schedule a window in which Jira is set to read-only for the migrated projects, run the final import, and repeat the spot checks against production data. Notify users which platform is authoritative and where new work goes. Done when the source is locked, the final import log is archived, and the spot checks pass.
Plan and test the rollback
Before cutover, document how to restore the Jira projects to writable status and how to handle any work created in the new platform during a failed window. Keep backups of both the source export and the target database, and test the restore in the sandbox. Done when the rollback runbook has been rehearsed once and a named owner can execute it without outside help.
What drives the running cost of each platform
The running cost of OpenProject or Plane is mostly people and infrastructure, and the license line is often the smallest part of it. Start by sizing both platforms against your real user count. OpenProject's system requirements give a clear example of how load scales: 4 cores and 4 GB RAM for up to 200 users, 8 cores and 8 GB for about 500 users, and 16 cores and 16 GB for about 1,500 users. Plane's documentation describes Docker Compose for small and mid-size teams and Kubernetes with Helm for high availability, so its footprint depends heavily on which of those you choose. Ask your vendor or partner for the sizing they assume for each platform at your peak concurrency, not only at the headcount on the org chart. Licensing is the recurring cost that is easiest to model. OpenProject Enterprise on-premises is priced per named user per month, with Basic, Professional, Premium and Corporate tiers and minimums at 25 and 100 users, so the bill changes sharply as you cross those thresholds. Plane's self-hosted paid path requires switching from Community to the Commercial Edition, and paid seats are counted by users with paid roles, so the number of guests, viewers and admins in your workspace affects cost. Ask each vendor to confirm in writing how it counts seats, whether SSO and LDAP sit in the tier you need, and whether support is priced separately.
The database and object storage bill is separate from the application license and recurs with your data. OpenProject officially supports PostgreSQL 16 or later and requires the pg_trgm, btree_gist and unaccent extensions, so confirm that your managed or self-run database can enable them. Plane needs PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible object storage such as MinIO, and its Helm chart can point each one at an external managed service. Each added component is another backup target, patch stream and on-call dependency. Price each one in your own environment, including backup retention and restore testing. Upgrade effort is the cost most often missed in the first quote. OpenProject ships roughly monthly minor releases, and Plane publishes its Community releases on its own cycle, so staff time for patching, testing and rollback recurs in both cases. Budget that time explicitly, and ask for the upgrade and support model in writing: who applies updates, who tests them, what the response windows are and whether a retainer covers ongoing upgrades. A written quote should list the scope of each item, the one-time setup, the recurring license and support, and the assumptions behind sizing.
Questions buyers ask before choosing OpenProject or Plane
Which costs more to run, OpenProject or Plane?
Neither license fee is the main cost, so the answer depends on which paid tier you need and how many people you will pay for. OpenProject Enterprise on-premises is priced per named user per month, with Basic at 5.95 euros, Professional at 10.95 euros (25-user minimum), Premium at 15.95 euros (100-user minimum), and Corporate on request for 250 or more users. Plane's pricing page lists Pro at 6 to 8 US dollars and Business at 13 to 15 US dollars per user per month, with Enterprise Grid on request. Plane seats count users with paid roles on the Commercial Edition, so role mix matters. Infrastructure is a recurring cost for both: Plane's self-hosted stack includes PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage, while OpenProject sizing starts at 4 cores and 4 GB RAM for up to 200 users. Ask each vendor for a written quote based on your user count and roles.
Is LDAP included in the free edition of OpenProject or Plane?
No, LDAP is not in the free edition of either platform. OpenProject lists LDAP group synchronization among its Enterprise features, alongside SSO with SAML, OIDC, CAS, Kerberos and Okta. On self-hosted Plane, SAML and OIDC are available from the Pro tier upward, while LDAP support is listed as an Enterprise feature. Because the tiers and feature names can change, confirm LDAP placement on each vendor's current pricing page before you budget for it. Also confirm whether your directory needs group sync, plain bind authentication or something else, since those needs can change which tier you require.
Can Jira Cloud projects be imported into OpenProject or Plane?
For Plane, yes: its Jira importer supports Jira Cloud as well as Jira Server and Data Center, and it is available on Plane Cloud and on all plans of the self-hosted Commercial Edition. OpenProject's Jira Migrator is different. It imports from Jira Data Center 10.x and 11.x, not Jira Cloud, and it is in beta, with documentation advising use only in test setups. If your source is Jira Cloud and you prefer OpenProject, plan for a manual or scripted export path and test it in a non-production environment. Confirm the current importer scope with each vendor before you commit to a timeline.
Can an internal team run OpenProject or Plane without a partner?
A small internal team can run either one, but the workload depends on the deployment method and the amount of integration you need. Plane documents Docker Compose for small and mid-size teams and Kubernetes with Helm for high availability, and its Kubernetes guide installs the Commercial Edition. OpenProject recommends Docker-based installation and also supports packages on specific Linux distributions and Helm charts for horizontal scaling. Staff needs to cover upgrades, backups, PostgreSQL maintenance and identity configuration. OpenProject requires PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions. If nobody on the team owns those tasks, a fixed-scope implementation and handover from DeployOpen can cover planning, hardening, backup design and documentation, and ongoing support can run as a retainer.
How long does a migration to OpenProject or Plane take?
The duration depends on data volume, the source system, how many integrations you need, and how much history you keep. No migration timeline is supplied for either platform, so ask for one based on your own export. Importer maturity is the first driver: OpenProject's Jira Migrator is beta and limited to Jira Data Center, while Plane's importer covers Jira Cloud as well as Data Center and Server. Other drivers include custom fields, workflow mapping, attachments, user matching against your directory, and a test cycle with real project data. Agree on a scope and deliverables in writing before work starts, since most DeployOpen engagements are fixed-scope.
What does the migration need from our team?
Your team needs to supply access, decisions and time from people who know the data. Expect to provide export access from the source tracker, a list of projects and custom fields that must survive, a user mapping from your directory, and a named owner who signs off on test results. Data owners should decide which closed projects to archive instead of import. Security staff should review how SSO or LDAP connects to the new platform and where backups are stored. Keep the source system readable until acceptance is complete. Ask any partner to list these inputs in the written scope so that dependencies are visible before work starts.
Which platform should an engineering team with Jira habits choose?
Plane is closer to the Jira and Linear issue-tracker model, so engineering teams that work in backlogs, cycles and issue flows often find it familiar. OpenProject fits teams that need classic project management with Gantt charts, baselines, portfolio views and resource planning, and those features sit partly in the Enterprise tier. If your mix includes non-engineers who expect Gantt planning, OpenProject may suit them better. Test each tool with a real project before deciding, and confirm SSO, LDAP and importer needs against the current vendor documentation.
How DeployOpen helps you choose and implement either platform
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For OpenProject vs Plane, that means turning the licensing, identity and deployment questions in this comparison into a written scope that your team can review before any work starts.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We confirm which edition fits your user roles, so seat counts and paid features are settled up front.
- We check your identity setup, including SSO and LDAP placement, against the edition you choose.
How we build
- We install the chosen platform in your infrastructure, using the deployment method your team already runs.
- We configure SSO and directory sync, and test sign-in with real user roles before go-live.
- We run a Jira import test in a non-production environment, since importer limits depend on your Jira deployment type.
How we hand over
- We document the installed stack, configuration, backup routine and upgrade steps for your own operators.
- We prepare the controls and evidence your compliance assessors may ask to see, without issuing any attestation.
- We walk your administrators through daily operations so the platform stays under your team's control.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrades are planned against each vendor's release cycle, so your team knows when a change is due.
- Security testing of the deployed platform can be scoped separately, with findings tracked to closure in writing.
