What does OpenProject cost to own on-premises?
OpenProject's software license is free in the Community edition and is charged per named user per month in Enterprise on-premises, but for most teams the larger share of total cost sits in hosting, implementation and administrator time. A team choosing OpenProject for portfolio, project and agile planning needs a multi-year budget that covers every one of these lines, so the license decision is only the first step in the model. The Community edition includes work packages, Gantt charts, agile boards, time tracking and dashboards, with community support. Enterprise adds features such as single sign-on, LDAP group synchronization and custom branding, which many regulated organizations need before they go live.
Enterprise on-premises is priced per named user per month. OpenProject lists Basic at 5.95 euros and Professional at 10.95 euros, both with a 25-user minimum, Premium at 15.95 euros with a 100-user minimum, and Corporate on request for 250 or more users (OpenProject pricing page). To build a first estimate, multiply the tier price by the number of named users you plan to license, then by 12 months and by the number of years in your model. Confirm with OpenProject GmbH whether these figures are current, whether billing is monthly or annual, and whether taxes or reseller fees apply in your country. Also confirm how named users are counted for contractors, read-only stakeholders and service accounts, since those choices can move the total more than the tier itself.
Costs fall into one-time and recurring groups. One-time items include planning, installation, identity and branding configuration, data import, and user training. Recurring items include the Enterprise subscription, application and database hosting, attachment storage, backups, PostgreSQL administration, patching within each release cycle, and the staff time needed to run them. Hosting cost depends heavily on user count. OpenProject's 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 (OpenProject system requirements). Those figures cover the application tier only, so size and price the database, attachment storage and backup capacity as separate lines in your model.
Teams usually keep the work in-house when they already run Linux, PostgreSQL and container platforms, have an identity team able to connect SAML or OIDC, and can name a platform administrator who owns patching and restore tests. They bring in a partner when the rollout has a fixed deadline, when a Jira import or identity integration needs specialist work, or when the internal team cannot cover upgrades and backup testing alongside its other duties. DeployOpen, a Chainscore Labs company, is one such provider. It plans, implements and supports self-hosted OpenProject inside the client's own infrastructure, but it is not an official partner, reseller or certified provider of OpenProject GmbH, so confirm subscription terms directly with the vendor.
Build a model with one row per cost component, and ask every provider for a fixed-scope quote that names deliverables, exclusions and the administrator hours the client keeps. Include recurring time for upgrades. OpenProject 17.7.0 was released on August 5, 2026, 17.8.0 on September 2, 2026, 17.9.0 on September 30, 2026, and 17.9.2 on October 15, 2026 (OpenProject release notes), so a platform that follows the release cycle will need regular upgrade effort rather than a single project. Ask the vendor how long each minor version remains supported, and ask your partner how upgrade work is scoped and priced.
What a cost of ownership study covers and what it delivers
A DeployOpen cost of ownership study turns OpenProject's public edition terms, your user count and your chosen install method into a multi-year cost model. Each part below feeds the same written model, so the numbers can be checked against your own assumptions before anyone signs a quote.
Edition comparison against named users
Community is free and Enterprise on-premises is priced per named user per month, with Basic, Professional and Premium tiers that carry user minimums. The study compares the tiers at your actual named-user count, including where the 25-user and 100-user minimums change the cost. It also checks which features you need, such as SAML or OIDC single sign-on, LDAP group synchronization and custom branding, because those determine whether Enterprise is required at all.
Sizing by user count
OpenProject's sizing guide gives core and memory tiers for roughly 200, 500 and 1,500 users. The study maps your expected concurrent load to one of these tiers and notes where your usage pattern, attachment volume or number of projects could move you out of it. Sizing sets the server, database and storage baseline that every later cost line depends on.
Infrastructure estimate for the install method
Docker is the recommended install, while packages for Ubuntu 22.04, Debian 12, RHEL 9.x and SUSE Linux Enterprise Server 15 and Helm on Kubernetes change the infrastructure bill. The study prices compute, PostgreSQL 16 or later with its required extensions, backup storage and, for Kubernetes, the cluster overhead you would otherwise not pay for. Each line is tied to your cloud account, data center or air-gapped environment, so you confirm the rates with your own providers.
Implementation and administration effort
Installation is only part of the labor. The study estimates the effort for setup, identity integration, project templates, data import, testing and the recurring administration that follows, such as user provisioning and release upgrades. Effort is split by role so you can see which tasks your own staff would cover and which you would pay a partner to carry, and each estimate states the assumptions behind it.
Multi-year cost model
The model separates one-time costs, such as implementation and data migration, from recurring costs, such as licenses, infrastructure, backups, support and upkeep. It spreads both across the number of years you choose and shows how growth in named users changes the license tier and the sizing band. Each recurring line is marked so you can see what grows with headcount and what stays flat.
Written model, scope list and open questions
The deliverables are a written model that lists every assumption, a quote-ready scope list that a provider can price against, and a set of open questions for items you still need to confirm, such as vendor rate cards, Enterprise support terms or migration source versions. No figure is presented as final until those questions are answered. Use the open questions to compare quotes on the same basis.
Community or Enterprise: what the per-user prices actually buy
The Community edition is free and covers core planning work: work packages, Gantt charts, agile boards, time tracking, dashboards and community support. For many teams that is enough to start. The decision to pay for Enterprise on-premises usually rests on three features: single sign-on through SAML, OIDC, CAS, Kerberos or Okta, LDAP group synchronization, and custom branding. If your identity provider or directory controls who can log in and which groups they belong to, those features belong on the requirements list before you compare editions. Without them, access management stays manual inside OpenProject.
Enterprise on-premises is licensed per named user per month. The published prices are 5.95 euros per user per month for Basic and 10.95 euros for Professional, both with a 25-user minimum. Premium is 15.95 euros per user per month with a 100-user minimum. Corporate is quoted on request for 250 or more users. Confirm current prices, currency, tax treatment and billing terms on the OpenProject pricing page before you budget, because list prices can change. Also ask whether invoices are monthly or annual and whether the subscription includes vendor support.
Illustrative calculation, not a quote: a team of 10 people that buys Basic pays for the 25-user minimum, so the bill is 25 multiplied by 5.95 euros, or 148.75 euros per month. That works out to about 14.88 euros for each person who actually uses the system. The same team on Professional would pay 25 multiplied by 10.95 euros, or 273.75 euros per month. The minimum matters most for small teams, because the gap between 10 real users and 25 billed seats is a recurring cost. If you expect to grow toward 25 within the contract term, the seats may be used. If not, ask whether the minimum can be adjusted at renewal.
The Nextcloud integration is part of the Community edition. It links Nextcloud files and folders to work packages and can manage project folders automatically. Single sign-on through an OpenID Connect provider for that integration is an Enterprise add-on. A team using Nextcloud can therefore start on Community and add the SSO add-on only if its identity policy requires it. Confirm with the vendor which account types count toward the per-user seat total, such as guests, read-only users or service accounts, because that changes the monthly figure more than the list price does.
What drives OpenProject cost and duration, and how to keep each one down
This table lists the main drivers of OpenProject cost and duration, why each one moves the total, and the lever that reduces it. Use it as a checklist for a quote, and confirm that each driver appears as a line item or a stated assumption in the written scope. The main takeaway is that user tiers and first-release scope usually shape the total more than hardware does.
| Driver | Why it moves cost | How to keep it down |
|---|---|---|
| Named users and edition tier | Per named user per month: Basic 5.95 euros, Professional 10.95, Premium 15.95, with 25 and 100 user minimums (OpenProject pricing). | Assign each group the lowest tier that covers its features, and confirm whether Community meets early needs. |
| User count against sizing bands | The sizing guide steps hardware up at about 200, 500 and 1,500 users, from 4 cores to 16 cores. | Size from measured load in a pilot, and confirm the band with OpenProject before buying servers. |
| Data volume and attachments | Attachments and retained history drive storage, backup size and restore time. | Set a retention rule and import only active projects in the first release. |
| Jira history | The Jira Migrator is beta and reads Jira Data Center 10.x and 11.x only. | Budget test runs and manual rebuilding of relations, sprints and workflows. |
| Identity integration | SAML, OIDC, CAS, Kerberos, Okta and LDAP group sync are Enterprise features. | Choose the identity provider early and confirm the plan includes each protocol you need. |
| Customization | Custom fields, work package types, workflows and branding add design and test effort for each change. | Limit the first release to core project templates, and add further changes after sign-off. |
| Number of environments | Each extra environment repeats install, data refresh, testing and patching work. | Run one test environment and use the same install method for production. |
| Compliance evidence needs | Access logs, change records and backup restore tests add evidence work for assessors. | Agree the evidence list up front. DeployOpen prepares evidence, and independent auditors assess it. |
| PostgreSQL version and extensions | PostgreSQL 16 or later is supported, with pg_trgm, btree_gist and unaccent required. | Reuse an existing PostgreSQL 16 or later server if the three extensions can be installed. |
How an OpenProject cost of ownership project runs, phase by phase
The sequence turns user counts, feature needs and hosting choices into a multi-year cost model that finance and IT owners have reviewed and can refresh. Each phase produces a document that the next phase depends on.
Inventory users, features and current tools
The partner and your team list every group that will use OpenProject, how many named users each group has, which features they need (work packages, Gantt charts, agile boards, time tracking and dashboards) and which tools they use today, such as Jira, file shares or Nextcloud. Identity requirements are recorded here as well, because single sign-on and LDAP group synchronization appear in Enterprise plans. The output is a user count by group and a feature list tagged as Community or Enterprise, confirmed by the project sponsor. Ask OpenProject to confirm feature availability for your target release before the list is final.
Choose the edition and shortlist the plan tier
Compare the feature list against the Community edition and the Enterprise on-premises tiers (Basic, Professional, Premium and Corporate), using the per-user prices and minimums on the pricing page. Paid tiers bill per named user per month, so a group that sits below a tier minimum changes the arithmetic. Record which users fall under each tier and whether the Nextcloud OpenID Connect add-on is needed. The output is a one-page edition decision showing the tier, the billed user count and the features that justify each Enterprise line. Confirm current prices and currency terms with OpenProject before the model is final, since prices can change.
Size the hosting and select the install method
Using the user counts from discovery and the sizing guide in the system requirements, map the rollout to a size class: roughly 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. Choose Docker (the recommended method), a .deb or .rpm package on a supported Linux distribution, or Kubernetes with Helm for horizontal scaling, and confirm the operating system is on the supported list. Note the PostgreSQL 16 or later requirement and the pg_trgm, btree_gist and unaccent extensions, since they shape the database line. The output is a sizing sheet with the install method, node sizes and database plan that the cost lines are built on.
Build the cost model across four lines
Build a multi-year model with four lines. Edition covers subscription fees for the chosen tier and billed users, which recur. Infrastructure covers compute, storage, backups, load balancing and the PostgreSQL service, whether hosted in your cloud accounts, data centers or air-gapped network. Implementation covers the one-time work to install, configure, connect identity and import data, and it is either quoted by a partner or estimated internally. Admin time covers recurring upgrades, patching, backup restore tests and user support. Give each line a unit, a quantity and an owner. The output is a workbook where every figure traces to a stated assumption, with one-time and recurring costs shown separately.
Review the model with finance and IT owners
Walk finance and IT owners through the model line by line. Finance checks the billing basis, currency, tax treatment, payment timing and the multi-year horizon. IT owners check the infrastructure sizing, database plan, backup approach and admin hours against their team's actual capacity. Record each change, who requested it and who approved it. Ask any partner quote to be written against the same line items so the totals can be compared directly. The output is a signed-off version of the model and an issue log showing which assumptions were challenged and how each was resolved.
Hand over assumptions and the refresh schedule
Deliver the model with a one-page assumptions register that lists the source of each price and sizing input, the edition terms in force on the review date and the owner of each line. Set a refresh schedule tied to events that change the numbers: user growth past a size class, new Enterprise features, price changes and new minor releases. The release notes list 17.7.0 on August 5, 2026, 17.8.0 on September 2, 2026 and 17.9.0 on September 30, 2026, so the refresh cadence should follow the upgrade cycle your team plans to adopt. The output is a model your team can update without rebuilding it, with a named owner and a next review date.
Recurring costs after go-live: hosting, licenses, upgrades and internal skills
This table lists the recurring cost lines of a self-hosted OpenProject installation, who is paid for each, and what drives it up or down. Read it alongside the one-time rows of your quote to separate what you pay once from what you pay every month or year.
| Cost line | Recurring or one-time | What drives it | What to request in a quote |
|---|---|---|---|
| Enterprise subscription | Recurring, per named user per month | Edition tier, named user count, and the 25-user minimum on Professional and 100-user minimum on Premium (OpenProject pricing) | Written per-user price in euros for each tier, minimums applied, Corporate pricing if 250 or more users, and whether support is bundled |
| Community edition | No license fee | Only infrastructure, staff time and any partner support you add; SSO and LDAP group sync are Enterprise features | Confirm which required features (SSO, LDAP sync, branding) you need, since they determine whether Community is enough |
| Infrastructure for the install method | Recurring, cloud or data center | Docker, package or Kubernetes with Helm; user count drives sizing, such as 4 cores and 4 GB RAM for up to 200 users per the OpenProject sizing guide | Hosting estimate by install method and user tier, storage growth for attachments, and who pays for monitoring and load balancing |
| PostgreSQL 16 or later | Recurring, database host or managed service | Required extensions pg_trgm, btree_gist and unaccent must be permitted by the host; managed or self-run choice changes labor | Confirm the managed service supports the three extensions, and who maintains PostgreSQL minor patches |
| Backups and restore testing | Recurring storage plus periodic test effort | Backup retention, database size, attachment volume, and how often restores are tested | Backup frequency, retention period, restore test schedule, and who owns the restore runbook |
| Upgrades across frequent minor releases | Recurring internal or partner staff time | Release cadence, such as 17.7.0 on August 5, 2026, 17.8.0 on September 2, and 17.9.0 on September 30, 2026, plus later 17.9.x patches; plus PostgreSQL version moves | Upgrade effort per cycle, whether a retainer covers each release, test environment provision, and rollback procedure |
| Internal skills and admin time | Recurring staff time | Number of admins, custom fields and workflows maintained, identity integration changes, and turnover of trained staff | Named owner roles, training scope, and whether documentation and runbooks are delivered at handover |
| Partner retainers | Recurring, optional | Scope of upgrades, monitoring, security patching and on-call response agreed in writing | Exactly what the retainer covers, response expectations stated in writing, and what is billed separately as extra work |
Which parts of the cost model teams keep in-house and which they outsource
The split between in-house work and outsourced work depends less on OpenProject itself than on the skills your team already has. A platform or IT team that runs Linux servers, operates PostgreSQL and administers identities can usually own most of the recurring work. A team without those skills will carry more cost in admin time, slower incidents and longer upgrades, and should price an external partner for the parts it cannot cover well. Decide the split by listing the skills you have, not by the tool's label. Tasks that most internal teams can own include license decisions, user administration, backup monitoring and routine minor upgrades. License decisions mean tracking which users need an Enterprise plan and whether the Community edition covers the rest, which requires someone who can read the published per-user prices and minimums and keep the named-user count current. User administration needs identity administration skills, plus a clear rule for who creates accounts and removes them when people leave. Backup monitoring requires checking that database and attachment backups complete and that a restore has been tested, which draws on PostgreSQL operations and Linux administration. Routine minor upgrades are repeatable when the team follows the release notes and tests in a non-production environment first. Tasks that teams often outsource are the ones where a mistake is expensive to reverse. Initial sizing needs an estimate of concurrent users and workload, mapped against the sizing guide's core and memory tiers. Identity integration design involves choosing between SAML, OIDC, LDAP group synchronization and Kerberos, and deciding which of these features need an Enterprise plan. The Jira migration cutover, if you move from Jira Data Center, is a one-time task that needs project management, data mapping and a rehearsed switch-over, and the Jira Migrator is in beta with documentation advising test use only. The first cost model itself benefits from an outside view, because it must combine license, infrastructure, implementation and admin time over several years. When you request quotes, ask each partner to separate one-time work (sizing, design, migration, first setup) from recurring work (support, upgrades, backups, user administration). Ask which named roles they would assign, such as a Linux administrator, a PostgreSQL specialist, an identity administrator and a project manager, and how many days each role is expected to spend. Then compare those roles with your own team's skills and identify the gaps you need to close, either by hiring, training or contracting. The result should be a written split that names who owns each task after go-live.
What usually skews the OpenProject budget and how to prevent it
Most OpenProject budget overruns come from licensing decisions, migration assumptions and operating work that were left out of the first estimate. Each card below names one common cost driver, explains how it changes the total, and gives a step to take before the quote is signed.
Buying Enterprise for every user
Enterprise on-premises is priced per named user per month, so every user added to a paid plan adds to the recurring cost. SSO, LDAP group synchronization and custom branding are Enterprise features, but many users need none of them. Before quoting, list which users need SSO or branding and which only need work packages, Gantt charts and boards, which the Community edition includes. Ask the vendor or partner to price a split deployment or a smaller paid group, and confirm in writing which features apply to which plan.
Missing the 25-user minimum
The Professional plan carries a 25-user minimum at 10.95 euros per named user per month, so a small team is billed as if it had 25 seats. For example, in an illustrative case, a team of 12 on Professional would still pay for 25 named users. Count the people who will hold a paid seat, including approvers and external collaborators, before choosing a plan. Ask whether the minimum applies to the whole instance or to a separate group, and confirm the rule in the quote.
Treating the Jira Migrator as finished
The Jira Migrator is in beta, its documentation advises use only in test setups, and it reads from Jira Data Center 10.x and 11.x only. It imports projects, issues, versions, custom fields, users, groups, statuses and types. Teams that plan a full cutover on the tool's output often find rework after go-live. Budget for test runs, manual checks of imported data and a source version check against the supported Data Center releases before the migration date is fixed.
Deferring relations, sprints, workflows and permissions
The Jira Migrator lists issue relations and sprint assignments as coming soon, and it leaves workflows and permissions for later. If these are pushed to a second phase without an estimate, the first phase looks cheaper than it is. Teams then rebuild Jira logic by hand during cutover. List every relation, sprint, workflow and permission scheme in use, mark each one as migrated, rebuilt or retired, and price the manual work as a separate line in the plan.
Skipping PostgreSQL version planning
OpenProject supports PostgreSQL 16 or later since version 16.0.0 and requires the pg_trgm, btree_gist and unaccent extensions. An existing database server that runs an older major version or lacks these extensions adds upgrade or provisioning work that is easy to leave out of the first estimate. Confirm the current PostgreSQL version and extension availability in the target environment, including managed database services, before the install is scoped and priced.
Omitting admin time for minor releases
OpenProject ships minor releases frequently. Examples in the release notes include 17.7.0 on August 5, 2026, 17.8.0 on September 2, 2026, 17.9.0 on September 30, 2026 and 17.9.2 on October 15, 2026. Each upgrade needs a backup, a test in a staging copy, a change window and a rollback plan. These are recurring internal or partner hours that a one-time implementation quote does not cover. Ask for the expected upgrade process in writing and add a yearly allowance for administrator time to the cost model.
What the client needs to provide before a cost model can be trusted
The inputs that move an OpenProject cost model most are named-user counts, the systems it must connect to, and the hosting limits it must respect. Ask for user counts split by group, not one total. Separate project managers, contributors, read-only executives, and external partners, because Enterprise on-premises is priced per named user per month, with Professional requiring a 25-user minimum, Premium a 100-user minimum, and Corporate offered on request for 250 or more users. A total of 180 can fall into different commercial positions depending on how many are external or view-only. Also ask for expected growth over the modeling period, with the month or quarter in which each step is expected to happen.
Next, list the existing tools that OpenProject will replace, sit beside, or connect to. For each, record the license type, the renewal date, the number of seats, and whether the tool is retired at cutover. Common examples include Jira Data Center, Confluence, Nextcloud, shared spreadsheets, and a separate time-tracking product. For any migration, supply data volumes: number of projects, issues, attachments with total size in gigabytes, custom fields, users, and groups. The OpenProject Jira Migrator reads from Jira Data Center 10.x and 11.x, not Jira Cloud, and is still in beta. If your source is Jira Cloud or another tool, say so early, because the import effort and the manual cleanup estimate change with the source.
Hosting constraints determine the infrastructure line and the operating burden. Confirm whether the system must run in a specific cloud region, a private data center, or an air-gapped network, and whether an existing PostgreSQL service, backup platform, and object or file storage can be reused. The OpenProject 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 those figures as a starting point and provide expected concurrent use, since peak activity matters more than headcount alone. For identity, record the provider type (SAML, OIDC, LDAP, Okta, Kerberos, or CAS), how groups are structured, and whether group synchronization is required. These identity features are Enterprise items, so the answer can change the edition decision.
Finally, name the people who can make decisions. Budget, platform, and business owners should each be identified with their authority and their sign-off points. Without them, assumptions stay open, and every open assumption becomes a scenario in the model, which widens the range between low and high cost. Also state which compliance frameworks or internal policies apply and what evidence an assessor is likely to request, such as access reviews, audit logs, backup test records, and change history. Evidence needs affect hardening, logging, and retention work, which recur over time. When you request quotes, ask each provider to state its assumptions line by line. A quote built on assumed user counts cannot be compared with one built on a verified count until both rest on the same inputs.
Common questions about OpenProject costs, effort and timing
Is the Community edition enough for our project management needs?
For many teams, Community covers core planning, but check the gaps before you decide. The Community edition is free and includes work packages, Gantt charts, agile boards, time tracking and dashboards, with community support. It also includes the Nextcloud integration that links files and folders to work packages. The main gaps are Enterprise features: single sign-on through SAML, OIDC, CAS, Kerberos or Okta, LDAP group synchronization and custom branding. If your policy requires central sign-in, group-based access control or a vendor support agreement, Community may fall short. Map each requirement against the current feature list on the OpenProject pricing page, because feature lists change between releases.
What do the Enterprise minimums add to our total cost?
Minimums can make a small team pay for more seats than it has. Enterprise on-premises is priced per named user per month. Basic and Professional carry a 25-user minimum, Premium carries a 100-user minimum, and Corporate is quoted on request for 250 or more users. If you have 10 named users, a Professional plan still bills for the 25-user minimum. Compare the per-user price multiplied by the minimum with your actual headcount for each tier, and compare that with your growth plan. Confirm the current euro prices and minimums on the OpenProject pricing page, since they can change. Ask how billing periods work and how added or removed users are prorated.
How does user count change our infrastructure costs?
User count mainly changes server size, and the sizing guide sets the steps. OpenProject's 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. Crossing one of those bands usually means a larger host. As concurrency grows, you may also need a separate database host and shared attachment storage. These are recurring costs billed by your cloud provider or data center. License cost rises with headcount as well, so model both lines together. Usage pattern matters too: heavy Gantt use or many simultaneous editors can need more capacity than the guide suggests. Load test in a staging environment before you commit to a size.
Can our own team install and run OpenProject without a partner?
Your own team can do it if it already runs Linux services, containers and PostgreSQL well. OpenProject supports Docker-based installation, which is the recommended method, plus .deb and .rpm packages for 64-bit Linux and Kubernetes with Helm charts. The work includes choosing the install method, setting up PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions, and configuring TLS, identity, backups and upgrades. The harder part is ongoing ownership: someone must apply each release within your maintenance window and test it first. A partner is useful when you need a fixed scope, a dated plan or migration help such as a Jira import. DeployOpen works on fixed-scope engagements with the scope agreed in writing before work starts.
How long does it take to build an OpenProject cost model?
The timeline depends on how much of your environment is defined. No single duration applies to every organization. A cost model usually needs the edition and user tiers, expected growth, hosting choice, identity requirements, data migration scope and the operating model for upgrades and backups. Each open question adds a discovery step, such as confirming SSO needs, sizing the database, deciding whether to import from Jira, or agreeing who approves changes. Requirements with clear owners move faster than requirements that span several departments. Ask for the timeline in the written scope, with assumptions, dependencies and exclusions listed. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the schedule is stated in the agreement.
What does our team need to provide for an OpenProject quote?
Bring your user list, your identity setup and a clear view of your data and integrations. For a useful quote, provide the expected named user count by tier, the hosting target (cloud account, data center or air-gapped network) and your identity provider with its group structure. If you plan to migrate from Jira, state the Data Center version. The beta Jira Migrator reads Jira Data Center 10.x and 11.x only, so Jira Cloud is outside its scope. Describe expected data and attachment volume, backup and recovery expectations, the other tools you want linked, and your approval and testing process. List compliance drivers too, so the scope covers evidence preparation. DeployOpen prepares evidence for assessments but does not issue audit reports or certifications. Ask for assumptions and exclusions in writing.
How do OpenProject upgrades affect our recurring costs?
Upgrades mostly add recurring admin time. OpenProject ships frequent minor releases, including 17.7.0 on August 5, 2026, 17.8.0 on September 2, 17.9.0 on September 30 and 17.9.2 on October 15. Each upgrade needs a staging test, a database backup and an update of the Docker image or packages. You must also keep PostgreSQL on a supported version, since OpenProject officially supports PostgreSQL 16 or later from version 16.0.0. These tasks recur for your admin team or for a support partner. Enterprise support and retainers vary, so confirm with OpenProject what each plan covers. Ask any partner for the recurring upgrade scope, the test cycle and the steps for a failed upgrade. DeployOpen offers ongoing support and upgrades as retainers.
How DeployOpen scopes, delivers and supports OpenProject cost work
DeployOpen scopes OpenProject cost of ownership work from a written statement that covers the edition, named user count, infrastructure and admin time your team will carry. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and testing are available as a retainer.
How we scope
- The written scope names the edition, the named user count and any Enterprise features you need.
- Sizing reviews hosting cores and memory against your user count, starting from OpenProject's sizing guide.
- The scope states which admin, identity and data import work is included and which costs stay with your team.
How we build
- Installation method is selected from Docker, packages or Helm against your Linux, Kubernetes and PostgreSQL standards.
- The cost model compares Community and Enterprise per-user pricing, then adds infrastructure and admin time over your chosen period.
- Testing covers Enterprise feature checks, backup and restore, and verification of required PostgreSQL extensions before go-live.
How we hand over
- Handover documents the edition decision, sizing assumptions and the recurring cost lines your finance team will carry.
- Runbooks describe installation, upgrade steps within the release cycle and PostgreSQL maintenance in your environment.
- Your team receives the cost worksheet with its formulas, so line items can be updated when user counts change.
How we support
- Ongoing support, upgrades and testing are available as a retainer, scoped separately from the fixed-scope build.
- Retainer work can cover release tracking, such as applying minor releases like 17.9.2 on your change schedule.
- Confirm with OpenProject which support terms come with each Enterprise plan, since vendor support differs from partner support.

