Why an OpenProject upgrade needs a plan, not just a version bump
An OpenProject upgrade is planned work that includes testing, a rollback path and a support decision, so it should not be handled as a routine version bump. Teams can run these upgrades in-house or bring in a partner, and the right choice depends on how many instances you operate, how far your current release sits from the target, and who will own the result if something breaks. This section is for teams running an older self-hosted release, a PostgreSQL version that now needs moving, or a deployment where updates have been deferred long enough that the next one feels risky.
Release pace is the reason delay gets expensive. The OpenProject release notes list 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. Those four releases arrived within about ten weeks, so an instance that skipped the August release would have four listed releases to catch up on by mid-October. These dates describe what has happened, not a fixed schedule, so do not plan around an expected next release date. Check the release notes at planning time and read every note between your current version and the target, not only the newest one, because configuration or database changes can appear in intermediate releases.
The database step often shapes the plan more than the application step. OpenProject has officially supported PostgreSQL 16 or later since version 16.0.0, and it requires the pg_trgm, btree_gist and unaccent extensions. Confirm that the target PostgreSQL version and these extensions are available on your database server before the change window, including whether your managed database service permits them. A PostgreSQL move is a separate change with its own backup, restore test and rollback, so schedule it apart from the application upgrade where you can. Also confirm your installation method: Docker is the recommended path, while .deb and .rpm packages cover the supported 64-bit Linux distributions, and each method has its own upgrade steps.
Before you choose a date, settle three decisions in writing. First, the target release and the path to it, including who approves each intermediate step. Second, rollback: a restore point that covers the database and attachment storage together, plus a tested way to return to the prior release. Third, the support decision. The Community edition is free and comes with community support. Enterprise on-premises is licensed per named user, but its support terms are a separate question. Ask OpenProject exactly which upgrade help, response channels and version coverage your plan includes, and ask any partner who will be on call, what they will test on a copy of your data, and how they will handle a failed upgrade. Those answers determine who owns the outcome, so get them before the work is scoped.
What an OpenProject upgrade and support engagement includes
An upgrade engagement moves one installed OpenProject instance from its current release to a target release through a tested path. Each card below is one stage or support option, and the exact covered items are fixed in the written scope before work starts. Every engagement ends with a runbook, a test record and an upgrade log.
Pre-upgrade assessment
The first step records the installed OpenProject version, the install method (Docker, .deb or .rpm package, or Helm on Kubernetes), the host operating system, the PostgreSQL version and the custom settings and plugins in use. These facts decide the upgrade path and which release notes apply. OpenProject ships minor releases often: 17.8.0 arrived on September 2 and 17.9.0 on September 30, 2026. Confirm which releases are skipped between the installed and target versions before planning the window.
Staging upgrade rehearsal
The upgrade runs first on a copy of production data in a staging environment built to match production. The rehearsal measures how long each step takes, surfaces configuration drift and shows whether custom attachments, storage paths and reverse proxy rules survive the change. Problems found here cost little to fix. Ask for the staging environment to be rebuilt from the same backup used for the production window, so the rehearsal reflects real data volumes.
PostgreSQL version and extension checks
OpenProject officially supports PostgreSQL 16 or later since version 16.0.0, and requires the pg_trgm, btree_gist and unaccent extensions. The check confirms the server version, that each extension is installed in the OpenProject database, and that the database role has the privileges the migrations need. If the server is older, a PostgreSQL upgrade becomes a separate change with its own backup and test steps, and it should be scheduled before the OpenProject upgrade.
Rollback plan and production window
The rollback plan names the backup that restores the database and file storage, the exact image or package versions to revert to, and the point after which rollback is no longer safe because migrations have run. The production window is agreed in advance with the business owners, and the team confirms the backup restores cleanly before the upgrade starts. Ask who has authority to call a rollback and how long that decision can wait during the window.
Post-upgrade checks of work packages and integrations
After the production upgrade, the checks confirm that work packages, their relations, versions and custom fields display and save correctly, and that a sample of attachments opens from storage. Integrations such as LDAP or SSO, the Nextcloud link and any API clients are tested with real accounts. Each check is logged against the test record so the business can sign off on a documented result rather than an informal confirmation.
Support options after handover
After handover, an organization can keep OpenProject supported through a partner retainer or through Enterprise support from OpenProject, which applies to Enterprise on-premises plans. The two cover different things, so compare them item by item: release monitoring, applying patch releases, the vendor's response commitments and who troubleshoots the database and host. The scope of any retainer, including covered items and response expectations, is set in writing before work begins.
What makes an OpenProject upgrade take longer or cost more
This table lists the factors that lengthen an OpenProject upgrade or raise its cost, with why each one matters and how to keep it under control. Read each row before you request a quote, because these answers determine how many upgrade steps, test rounds and environments the work needs. Version distance, install method and integrations can shape the effort as much as user count does.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Version distance | Each skipped release adds migrations and changes to review. Releases arrive often, such as 17.7.0 on August 5, 2026. | Upgrade through a current release line and read the release notes for each step. |
| Install method | Docker, package and Helm upgrades follow different commands, rollback paths and configuration files. | Standardize on one method and write the exact upgrade commands into a runbook. |
| PostgreSQL version | OpenProject officially supports PostgreSQL 16 or later since 16.0.0. Older database servers need an upgrade first. | Check the server version early and confirm pg_trgm, btree_gist and unaccent are installed. |
| Operating system (packaged installs) | Supported systems include Ubuntu 22.04, Debian 12, RHEL 9.x and SLES 15. An OS upgrade can become a second project. | Confirm the target OS is on the supported list before choosing the OpenProject release. |
| Users and data volume | The sizing guide scales cores and memory with user count. Larger databases and attachment stores lengthen migrations and backups. | Measure database and attachment size before testing, and time a restore on a copy. |
| Integrations | Nextcloud file links, SSO and LDAP group sync each need configuration checks and retesting after an upgrade. | Inventory every integration with its owner and test case before scoping the work. |
| Custom fields, types and plugins | Custom fields, work package types and plugins can behave differently after a release and need review. | List custom objects and plugins, and keep a regression checklist for each one. |
| Environments to test | Each environment, such as test, staging and production, repeats the upgrade and verification steps. | Agree how many environments need a rehearsal and reuse one scripted runbook across them. |
| Compliance evidence | Assessors may ask for change records, test results and proof of restore for each upgrade cycle. | Ask which evidence your assessor expects and capture it during every rehearsal. |
How an OpenProject upgrade runs from staging to a verified production release
This sequence moves an OpenProject instance from its current release to a newer one in a controlled way, with each phase ending in a record that the team can review before the next phase starts. The work covers discovery, compatibility, a rehearsal on restored production data, the production change and handover to a support cadence.
Inventory the current OpenProject estate
Record the installed OpenProject version, the install method (Docker, .deb or .rpm package, or Helm on Kubernetes), the host operating system, the PostgreSQL version, attachment storage location, reverse proxy and any plugins or integrations such as SSO, LDAP sync or the Nextcloud link. Note the user count and current sizing so the target can be checked against the sizing guide. The output is an inventory report that lists every component, its version and its owner. The step is complete when the client's platform owner has signed off that the report matches the running environment.
Check compatibility and PostgreSQL requirements
Compare the inventory against the target release's system requirements. Confirm the operating system is on the supported list for packaged installs, confirm PostgreSQL is version 16 or later, which OpenProject has required since release 16.0.0, and confirm the pg_trgm, btree_gist and unaccent extensions are present. If PostgreSQL needs a version move, plan that as a separate, tested change before the application upgrade. Review the release notes between the current and target versions for breaking changes, deprecated settings and migration steps. The output is a compatibility report with a list of required pre-work. The step closes when every gap has an owner and a resolution path.
Rehearse the upgrade in staging
Restore a recent production backup into a staging environment that matches production's install method, operating system and PostgreSQL version as closely as the client's infrastructure allows. Run the full upgrade procedure exactly as it will be run in production, including database migrations, configuration changes and service restarts. Record each command, its output, timings observed in staging and any error or manual intervention. Test the rollback path and confirm that a restore from backup works. The output is a rehearsal log. The step is complete when a clean run has been recorded and every deviation from the plan has been fixed and retested.
Agree the production change plan and go/no-go
Turn the rehearsal log into a production runbook with step-by-step commands, pre-checks, post-checks, rollback triggers and named responsibilities for each action. Confirm the backup for production is current and has been verified by restore. Agree the change window with the business owners and the people who need to be informed about downtime. Hold a go/no-go review in which the client's approver and the partner's engineer confirm readiness against a short checklist. The output is a signed go/no-go record that states the decision, the approvers and any conditions. Do not begin production work without it.
Upgrade production in the agreed change window
Take a fresh backup immediately before the change, then follow the production runbook step by step with the operator recording each action and its result in the change log. Apply the package or Docker image update, run the database migrations and restart services in the order the runbook specifies. If a post-check fails or the rollback trigger is reached, stop and follow the rollback path recorded in the plan. The output is a completed change log with timestamps, outcomes and any deviations. The step closes when all services report healthy and the change log has been reviewed by the operator and the approver.
Verify the release and run user acceptance
Confirm the running version matches the target, that background jobs and attachments work, and that SSO, LDAP synchronization and the Nextcloud integration behave as they did before the change, where those are in use. Check the key workflows with a small group of named users: creating and editing work packages, running Gantt and board views, logging time and reviewing dashboards. Review logs for new errors and confirm monitoring and backups are running on schedule. The output is a verification checklist and a user acceptance sign-off. The step is complete when the business owner accepts the release in writing and any open defects are logged with an agreed severity and owner.
Hand over the runbook and set the support cadence
Transfer the final runbook, the inventory report, the compatibility report, the rehearsal log and the change record to the client's operations team, and walk through them in a handover session. Agree how the team will track future minor releases, which patch releases will be applied and by whom, and how security advisories will be reviewed. Confirm the support route for the period after the change, whether that is internal staff, community support, an Enterprise support plan or a partner retainer, and what each covers. The output is a handover pack and a written support cadence. The step closes when the client's owner confirms they can repeat the upgrade without the partner. Ask the partner for a phase-by-phase timeline in the written scope before work starts.
Handling PostgreSQL moves to version 16 or later
The database step is often the riskiest part of an OpenProject upgrade because PostgreSQL holds the users, work packages, permissions and project settings that the application reads on every request. A failed database move can leave OpenProject unable to start against data that looks intact. OpenProject has officially supported PostgreSQL 16 or later since OpenProject 16.0.0, so any installation still on an older PostgreSQL major version needs a version change planned alongside the application upgrade. The platform also requires the pg_trgm, btree_gist and unaccent extensions, which must be present on the target server before cutover. Start by recording the current PostgreSQL version and the list of installed extensions in the OpenProject database, including on any standby, replica or managed instance. Confirm which extensions are already enabled and which are missing, and note the account that owns the database. Keep this output in the change record, because it is the baseline you will compare against after the move.
Next, take a backup and verify it before anything else changes. A backup that has never been restored is an assumption, not a recovery plan. Store a copy off the production host, check that the backup job completed without errors, and record file sizes or checksums where your tooling provides them. Then restore that backup to a separate host running the same PostgreSQL major version as production. Start OpenProject against the restored copy and check sign-in, a sample project, several work packages and a few attachments. Time the restore from start to finish. That measurement, not an estimate, should set the length of the maintenance window.
With a tested restore in hand, plan the major version move itself. Two common methods are a logical dump and restore with pg_dump and pg_restore, or pg_upgrade, which converts the existing data files to the new major version. The team should choose between them based on database size, the downtime it can accept, storage layout, whether the database is managed by a cloud provider, and the experience of the people who will run the work. Before choosing, confirm with OpenProject which PostgreSQL versions and upgrade paths are supported for the specific OpenProject release you are moving to. Do not assume that a path used for an earlier release still applies.
Before cutover, check extension availability on the target server. Install the target PostgreSQL major version, confirm that pg_trgm, btree_gist and unaccent can be created in the target database, and use an account with the rights to create them. Run the OpenProject upgrade against this staging target and review its logs for extension or collation errors. Keep the source database untouched until the upgraded instance has passed your acceptance checks, so that rollback means pointing OpenProject back at a known state. In a quote, ask the partner to name who runs each of these steps and who signs off on the result.
Which upgrade tasks teams keep in-house and which they hand to a partner
This table maps each OpenProject upgrade task to the team that usually performs it and the skills it needs, across Linux, database and application administration. Use it to see which tasks your staff already cover and which skills are missing. Teams with spare capacity often keep routine minor upgrades and hand off the PostgreSQL move and the first major upgrade.
| Task | Usually done by | Skills needed | Who typically keeps it |
|---|---|---|---|
| Release tracking and release notes | Application owner | Reading release notes, judging impact on custom fields, workflows and integrations | In-house |
| Staging rehearsal of a release | Platform engineer with a test lead | Docker or package administration, test data handling, scripted smoke checks | In-house if staff have capacity |
| OS and package updates | Linux administrator | Patching Ubuntu 22.04, Debian 12, RHEL 9 or SLES 15 hosts, service restarts | In-house |
| Docker or Kubernetes image changes | Platform engineer | Image tags, Helm values, rollout and rollback commands for the OpenProject containers | In-house if the team runs the cluster |
| PostgreSQL major version move | Database administrator | Dump and restore, checking pg_trgm, btree_gist and unaccent extensions, cutover timing | Often handed to a partner |
| First major OpenProject upgrade | Senior application administrator | Reviewing migration notes, checking custom fields and workflows, verifying backups | Often handed to a partner |
| Integration retests (SSO, Nextcloud, LDAP) | Identity engineer and application administrator | SAML, OIDC or LDAP testing, group synchronization checks, Nextcloud link tests | Shared, with scripted retests |
| Rollback drills | Database and Linux administrators | Restoring from backup, pinning previous image or package versions, timing restores | In-house ownership, partner can design the drill |
| Ongoing patch windows | Operations team | Change calendar, maintenance notices, on-call coverage, post-patch checks | In-house or under a support retainer |
How upgrades differ by install method, operating system and network
Docker is the installation method OpenProject recommends in its system requirements. An upgrade usually means changing the image tag and restarting the containers against the same data, so the procedure is short. The checks around it decide whether it is safe.
- Image tag change: Update the tag in your compose file or run configuration to the target release. Read the release notes for any migration that runs at startup.
- Volumes: Confirm that attachment and data volumes mount at the same paths in the new definition. Take a snapshot of them before pulling the new image.
- Environment variables: Compare your environment file with the sample file for the target version. Variable names and defaults can change between releases.
- PostgreSQL prerequisites: Confirm the database runs PostgreSQL 16 or later and has the pg_trgm, btree_gist and unaccent extensions before the new container starts.
Ask OpenProject which environment variables and startup migrations changed between your current and target version, and confirm that a rollback means restoring the database and the volumes together.
Packaged installs use .deb or .rpm packages for 64-bit Linux. OpenProject supports packaged installs on Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15. The upgrade runs through your operating system's package manager, so the operating system is part of the change, not only OpenProject.
- Repository configuration: Confirm that the OpenProject package repository for your distribution and the target release is enabled. Pin the package version so an unplanned update cannot run.
- OS dependencies: Check that the operating system packages OpenProject depends on are at the versions the target release expects, including the PostgreSQL client libraries.
- Operating system version: Confirm that your current OS release is on the supported list for the target OpenProject version. If the OS also needs an upgrade, schedule it as a separate change with its own rollback.
- Configuration step: Run the packaged configuration step after the package update, then review any configuration file changes the package manager reports.
- Database backup: Take a database dump and an attachment backup before the package update, and verify that the restore works on a separate host.
Ask OpenProject for the supported operating system list and the exact PostgreSQL and extension requirements for your target release, and confirm them against your own host builds.
OpenProject provides Helm charts for Kubernetes deployments that scale horizontally. A chart upgrade changes the chart version, the application version and the values file together, and the cluster performs a rolling update of the pods. The high availability topic covers node layout, database and storage design, so this tab covers only the upgrade sequence.
- Chart and application versions: Check which application release each chart version deploys. Upgrade the chart version deliberately and do not rely on an automatic image bump.
- Values diff: Compare your values file with the defaults for the target chart version. Review new or renamed keys before running the upgrade.
- Rolling update behavior: Confirm the readiness and liveness probe settings, and check how many pods can be unavailable during the update. Confirm that the migration job runs once before new pods serve traffic.
- Database readiness: Confirm the PostgreSQL version and extensions meet the target release requirements before the rollout starts.
- Rollback path: Confirm that Helm can return to the previous revision and that database migrations are either reversible or covered by a restore plan.
Ask OpenProject which chart versions pair with which application releases, and whether the target chart requires any migration step that runs outside the normal rolling update.
On air-gapped or restricted networks, the cluster or host cannot download packages, images or chart archives during the upgrade. Every artifact has to be staged inside the boundary before the change window opens. The procedure stays the same, but the preparation is longer, and it has to include the dependencies that the OpenProject artifacts pull in.
- Offline package staging: Download the OpenProject packages for your distribution, plus the operating system packages they depend on, and stage them in an internal repository. Record checksums for every file.
- Mirrored images: For Docker or Kubernetes installs, mirror the target OpenProject image and any supporting images into your internal registry. Reference them by digest where your tooling allows it.
- Helm charts: Stage the target chart archive and its values file inside the boundary, and confirm that the chart does not fetch dependencies from public repositories at install time.
- Transfer approval: Route the staged files through your media transfer process and keep a record of what crossed the boundary and when.
- Test in a matching environment: Run the full upgrade on a staging environment with the same restrictions before the production window.
Ask OpenProject which release artifacts are published for offline use, which images and chart dependencies they reference, and whether the release notes list any step that needs network access.
What usually goes wrong in OpenProject upgrades and how to prevent it
Most OpenProject upgrade problems do not come from the new release itself. They come from preparation gaps: backups that were never restored, database extensions missing on the target server, skipped versions, custom configuration nobody re-checked and integrations that report nothing when they break. Each card names one pattern and the step that prevents it.
Upgrading without a restore test
Teams often back up the database and attachments on schedule but never restore them into a separate environment. A backup that has never been restored is unverified. Before each upgrade, restore the latest PostgreSQL dump and the attachment directory into a staging host, confirm the instance starts and check that attachments open from work packages. Confirm the attachment path in the restored configuration matches the storage location in production, and record how long the restore took so the production window reflects it.
Missing PostgreSQL extensions on target
OpenProject officially supports PostgreSQL 16 or later from OpenProject 16.0.0 and requires the pg_trgm, btree_gist and unaccent extensions. A replacement or upgraded database server may not have these installed, and the migration then fails partway through. Check the extensions on the target server before the upgrade window, including any standby or new cluster. Confirm the database user has the privileges to create them, and treat any PostgreSQL major version move as a separate, rehearsed step.
Skipping release versions
OpenProject ships frequent minor releases, including 17.7.0 on August 5, 2026, 17.8.0 on September 2, 2026 and 17.9.0 on September 30, 2026. Jumping several of these at once runs the database migrations from every intermediate release in a single pass, and the upgrade notes for the skipped versions are easy to miss. Plan a version-by-version path from the current release to the target, read the notes for each step and test each step in staging before scheduling production.
Custom fields and plugins breaking
Custom fields, work package types, workflows, themes and third-party plugins are a frequent source of post-upgrade breakage. A field that renders correctly in one release can fail validation or disappear from forms in the next. Inventory every custom field, type, workflow and plugin before upgrading, then check each on the staging instance by creating and editing a work package of each type. Ask the plugin provider whether it supports the target release before the window is booked.
Integrations failing silently
SSO, LDAP group synchronization and the Nextcloud integration can appear to work after an upgrade while a certificate, token, group mapping or file link has stopped functioning. Users often notice only when a login fails or a folder link breaks days later. Write short test scripts for each integration: an SSO login with a test account, a sync check against a known LDAP group and a Nextcloud link that is created and opened. Run them on staging and again immediately after production cutover.
Upgrades in business hours without rollback
Running an upgrade during working hours leaves users editing work packages while migrations run, and a failed step then becomes an outage with no agreed exit. Schedule the window in advance, notify users, freeze edits for its duration and define go and no-go criteria before starting. Keep a rollback path that has been tested: the previous container or package version, the pre-upgrade database snapshot and the attachment copy. Agree in advance who can call a rollback and the time by which that call must be made.
What recurring upgrade and support work costs after go-live
Recurring upgrade and support cost has four parts: partner fees, internal administrator time, staging infrastructure and, if you choose it, an Enterprise subscription. The Community edition is free and comes with community support, so it carries no license fee but leaves the upgrade work with your team or your partner. Enterprise on-premises is priced per named user per month on the OpenProject pricing page: Basic at 5.95 euros and Professional at 10.95 euros with a 25-user minimum, Premium at 15.95 euros with a 100-user minimum, and Corporate on request for 250 or more users. Check these figures on the pricing page before you budget, because list prices can change between your evaluation and your renewal.
A partner cost is either a retainer or a per-engagement upgrade fee. Retainers suit a team that expects steady work across the frequent minor releases, such as the 17.7.0, 17.8.0 and 17.9.0 releases published between August and September 2026 in the OpenProject release notes. Per-engagement fees suit a team that upgrades once a year or less often. DeployOpen does not publish prices. Ask for a quote built from a written scope that lists the releases covered, whether PostgreSQL version moves and Docker or package steps are included, how many staging runs are included, the post-upgrade checks, and the rollback plan. A quote that leaves these items out is not comparable with one that states them.
Internal time is the cost that most often goes uncounted. Your administrators will read each release note, schedule patch windows, take and verify a backup, rebuild or pull the new Docker image or package, run the post-upgrade checks and watch the system afterward. Staging adds a recurring cost: an environment close in size to production so each upgrade is tested before it reaches users. The sizing guide in the system requirements 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. Staging is often smaller than production, but confirm that your test results still hold at production scale and that the staging database uses the same PostgreSQL version.
If you choose Enterprise, do not assume the subscription replaces partner work. Ask the vendor in writing what Enterprise support covers, including whether it includes upgrade assistance, PostgreSQL version changes, help with Docker or Helm deployments, and questions about your integrations or custom fields. Ask for the response times and the channels they apply to, and whether they differ by plan. DeployOpen can provide the implementation, upgrade and support work separately, and the two should be scoped so that no task falls between them. Confirm each answer in the contract before you choose a plan, because support terms are set by the vendor and can change.
Questions buyers ask before paying for OpenProject upgrade support
How much does an OpenProject upgrade cost and what drives the price?
The price follows from the written scope, and DeployOpen does not publish a price list. Four factors move it most: the number of environments (production, staging and any test copy), the version gap between your current release and the target, whether the upgrade includes a PostgreSQL move, and how many integrations must be retested, such as SSO, LDAP, Nextcloud or custom API connections. The install method also matters, since OpenProject recommends Docker-based installation and package or Helm-based installs follow different steps. Ask for the quote to separate one-time work (assessment, rehearsal, cutover, verification, documentation) from any recurring support retainer, and to state which environments and integrations are in scope. Your own staff time for testing and approvals is a cost even when you do not pay a partner.
How long does an OpenProject upgrade take to complete?
Duration depends on scope, the version gap, the PostgreSQL move, integration testing and the change window your organization can accept. OpenProject ships minor releases often: 17.7.0 arrived on August 5, 2026, 17.8.0 on September 2, 17.9.0 on September 30 and 17.9.2 on October 15, so a team that falls several releases behind has more steps to rehearse. A routine minor upgrade with a tested rollback plan is short to execute, but the rehearsal on a non-production copy often takes more effort than the cutover itself. Larger user bases and databases lengthen data verification and backup checks. Ask the partner for a timeline built from your environment inventory and rehearsal plan, and confirm the change window and approval steps with your owner before the schedule is fixed.
Can our own team upgrade OpenProject without a partner?
Yes, a capable internal team can apply a routine OpenProject minor release, provided it rehearses the upgrade first on a copy of production. Packaged and Docker-based installs follow documented steps, and the release notes describe each version change. The harder cases are a PostgreSQL version move, where OpenProject officially supports PostgreSQL 16 or later from version 16.0.0 and requires the pg_trgm, btree_gist and unaccent extensions, and any major change that alters database structure or integrations. Those moves call for someone who can verify extensions, backups, restore paths and rollback before touching production. Decide internally who owns the rehearsal, who approves the change and who validates SSO and integrations afterward. Many teams keep routine patching in-house and bring in a partner for the first major move.
What does OpenProject Enterprise support cover compared with a partner?
Enterprise on-premises plans are priced per named user per month. The published tiers are Basic at 5.95 euros, Professional at 10.95 euros and Premium at 15.95 euros per user per month, with a 25-user minimum for Professional and a 100-user minimum for Premium, and Corporate is available on request for 250 or more users. Enterprise features include single sign-on (SAML, OIDC, CAS, Kerberos, Okta), LDAP group synchronization and custom branding. The Community edition is free and comes with community support. Confirm with OpenProject in your order exactly which support terms your plan includes, since that is the vendor's commitment. A partner covers different work: planning the upgrade, rehearsing it, executing the change, testing your integrations and documenting the result for your team.
What must our team provide before an OpenProject upgrade starts?
Before work starts, your team should provide a recent, verified backup of the database and attachment storage, along with evidence that a restore has been tested. It should also grant administrative and server access for the environments in scope through your normal access controls, create test user accounts for each role and group (including SSO users), and agree a change window with operations and the business. Name one owner who can approve scope changes and sign off on verification. Share the current version, install method, operating system, PostgreSQL version and a list of integrations such as Nextcloud, LDAP, SSO or API clients. Gaps in this information tend to extend the assessment, so request a written intake list from the partner before the quote is finalized.
Can a partner upgrade an OpenProject instance it did not install?
Yes, a partner can take on an instance it did not install, but the first step is an assessment of what is actually running. The assessment should record the install method (Docker, package or Kubernetes with Helm), the operating system, the PostgreSQL version and extensions, the release in use, custom configuration, plugins and integrations, and the state of backups and restore tests. Packaged installs support Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15, so confirm your operating system appears on that list before scoping. Findings from the assessment go into the written scope, so the quote reflects the real starting point. Ask the partner which changes it will not make without your approval.
Does a PostgreSQL upgrade change how OpenProject upgrades are planned?
A PostgreSQL move is a separate change with its own risks, so it should be scoped and rehearsed on its own. OpenProject officially supports PostgreSQL 16 or later since version 16.0.0 and requires the pg_trgm, btree_gist and unaccent extensions. Before any move, confirm that the target server provides those extensions, that your backup restores into the new major version, and that connection settings, replicas and monitoring point to the right place afterward. Keep the old database intact until verification passes so a rollback path exists. Also check that capacity still fits: 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. Validate these figures against your own load before relying on them.
What you need to provide before an OpenProject upgrade window
Start by sending three things: the OpenProject version you run today, the way it is installed, and the PostgreSQL version behind it. The install method determines every later step. A Docker deployment, a .deb or .rpm package on a supported Linux distribution, and a Kubernetes deployment with Helm charts each follow a different upgrade procedure, so the assessment cannot begin until we know which one applies. Confirm the PostgreSQL major version as well. OpenProject officially supports PostgreSQL 16 or later since version 16.0.0, and the pg_trgm, btree_gist and unaccent extensions must be present. If the database is older, the upgrade plan gains a database step that needs its own window. Read-only access to the application server and database lets us verify these values directly instead of relying on a summary.
A recent backup only counts if it has been restored successfully. Provide the date of the last backup, the scope it covers (database, attachments, configuration files and any container volumes), and evidence that a restore was tested on separate hardware. Attachments are often stored apart from the database, so a database dump alone leaves uploaded files unprotected. Next, provide a staging environment built with the same install method and sized close to production. A staging copy lets the upgrade run and be checked before it reaches users. If you cannot provide one, give written permission to build a temporary copy inside your infrastructure. Without staging, the first real test of the new release happens in production, and rolling back becomes the only recovery path.
Next, list every integration and customization. Include single sign-on through SAML, OIDC, CAS, Kerberos or Okta, LDAP group synchronization, the Nextcloud integration, API clients, scripts, reporting tools, custom fields, work package types and workflows. Each one needs a test case after the upgrade, and some depend on Enterprise features whose configuration may change between releases. Name an approver who signs off the change and a user acceptance owner who represents the teams using boards, Gantt charts and time tracking every day. Agree a change window with those business users in advance. OpenProject publishes minor releases frequently, for example 17.7.0 on August 5, 2026, 17.8.0 on September 2, 2026 and 17.9.0 on September 30, 2026, so decide which target release this upgrade will move to before the window is booked.
Finally, decide who will run the system after the upgrade. The Community edition is free and comes with community support. Enterprise on-premises licenses are priced per named user per month, with minimums that depend on the plan, and they include features such as SSO and LDAP group synchronization. Confirm which edition you run and whether your license is current before scheduling, and ask OpenProject how license status affects feature access. Then choose the support model: your own team, Enterprise vendor support, a partner retainer, or a combination. Write down who receives release notes, who monitors security advisories, and who has authority to roll back. Those answers define the scope of any quote and the cadence of future upgrade windows.
How DeployOpen scopes, delivers and supports OpenProject upgrades
DeployOpen plans each OpenProject upgrade from a written scope, then builds and tests it inside your own infrastructure before cutover. Work covers the release you run today, the PostgreSQL version, and the Docker, package or Helm steps your install uses. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- The written scope names the current and target OpenProject versions and the installation method in use.
- It records the PostgreSQL version, required extensions, and whether Enterprise features such as SSO are in use.
- We review release notes for every version on the upgrade path and flag steps that need manual action.
How we build
- Upgrades are rehearsed on a copy of your production data in a staging environment inside your infrastructure.
- Work covers PostgreSQL moves to version 16 or later, with pg_trgm, btree_gist and unaccent present.
- Docker, .deb, .rpm or Helm upgrade steps are scripted and tested against the same configuration you run.
How we hand over
- Handover includes a tested runbook with pre-upgrade checks, rollback steps and post-upgrade verification.
- Backup and restore points are documented, and restore is verified before the production upgrade begins.
- Your team receives the upgrade record, configuration changes and a list of open follow-up items.
How we support
- Ongoing support can be added as a retainer covering planned upgrades as new OpenProject releases ship.
- Confirm with OpenProject which support terms your Enterprise plan includes and which work DeployOpen will cover.
- Retainer work can include staging tests of new releases, patch application and post-upgrade checks.
