What an OpenProject implementation involves
A self-hosted OpenProject rollout is a chain of six pieces, and each one can be owned by a different team: the environment, the installation, configuration, identity, data and the staged rollout to users. The environment decision comes first. You choose the infrastructure, the Linux distribution from the supported list, and a PostgreSQL server that meets the version and extension requirements. Installation follows the method you selected (covered in the Docker and Kubernetes installation topic). Configuration then covers projects, work package types, statuses, roles and permissions, and the modules each team needs. Identity, data and rollout are the parts that most often change the plan.
Most engagements start with one of three triggers: moving project tracking off spreadsheets, leaving a hosted tool whose terms, data residency or cost no longer fit, or consolidating several team tools into one project record. Each trigger changes the work. A spreadsheet move is mostly configuration and training. A hosted-tool exit or consolidation usually adds a data import with mapping, reconciliation and a cutover date. Before you scope anything, write down which of these applies, which teams and user groups are in scope, and which projects must stay read-only or be archived rather than moved.
For many organizations the answer is in-house for a small Community deployment, if an experienced administrator team can own upgrades, backups and PostgreSQL maintenance. Partner help becomes more likely when you need Enterprise identity features such as SAML, OIDC, LDAP group synchronization or custom branding, when user counts grow into the hundreds, when data must be migrated from another system, or when you need compliance evidence for an assessment. Ask each candidate partner to state in writing which of these items it will deliver, which it will hand over for your team to run, and which it will leave out of scope.
What the work includes and what you receive
A typical fixed-scope OpenProject rollout moves through six work packages. Custom fields, workflows and Jira migration mechanics are covered in their own topics.
Requirements and process mapping
Workshops map how portfolios, projects, work packages and agile boards are used today and what each team needs from OpenProject. The deliverable is a requirements register and a process map that sets project templates and work package types at a planning level. Confirm that each team lead signs off on the mapping before configuration starts.
Environment design and sizing
The deliverable is a sizing and architecture document covering development, test and production instances, user counts, network zones and backup targets. OpenProject's sizing guide gives starting points of 4 cores and 4 GB RAM for up to 200 users and 8 cores and 8 GB for about 500 users. Ask for sizing based on your concurrency and attachment volume, not user count alone.
Installation and PostgreSQL setup
Installation uses Docker, which OpenProject recommends, or 64-bit Linux packages on supported distributions such as Ubuntu 22.04, Debian 12 and RHEL 9. The database runs PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions enabled. The deliverable is configured instances per environment and a runbook covering install, upgrade and restore steps.
Identity configuration
Identity work connects OpenProject to your directory and defines how users, groups and roles are provisioned. Single sign-on through SAML, OIDC, CAS, Kerberos or Okta and LDAP group synchronization are Enterprise features, so the edition decision comes first. The deliverable is an identity configuration record and tested sign-in for each user group.
Data import scope
The agreed scope defines which projects, work packages, users and attachments move into OpenProject and which stay in the source system. Import runs go to a test instance first and produce an import report listing record counts, failures and manual corrections. Confirm the source system and version early, because import tooling depends on them.
Admin training and handover
Administrators learn to manage users, projects, backups, upgrades and configuration changes on the instances you own. The deliverables are admin training material and a handover package with runbooks, access records and a list of open items. Confirm who on your side will own patching and release updates after handover, since that work recurs.
What drives cost and duration
This table lists the scope factors that move OpenProject implementation effort and cost, why each one matters, and how to keep it in check during scoping.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| User count and sizing tier | 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). Higher tiers add capacity planning, load testing and more complex backup windows. | Confirm the actual active user count, not the licensed headcount. Start with the lowest tier that fits the first wave and plan a scale-up step. |
| Edition and per-user minimums | Enterprise on-premises is priced per named user per month, with Basic at 5.95 euros and 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 (OpenProject pricing). Enterprise features such as SSO and LDAP group sync add configuration and testing work. | Decide Community or Enterprise per team, not for the whole organization on day one. Ask the vendor to confirm current prices and minimums before the quote. |
| Identity sources and SSO or LDAP group sync | SSO (SAML, OIDC, CAS, Kerberos, Okta) and LDAP group synchronization are Enterprise features (OpenProject pricing). Each identity source adds mapping rules, test accounts, and provisioning decisions. | Limit the first wave to one identity source. Agree in writing whether group sync is needed at launch or can follow in a later phase. |
| Data import volume and source systems | Importing from Jira Data Center uses the beta Jira Migrator, which covers projects, issues, versions, custom fields, users, groups, statuses and types, while relations, sprints, workflows and permissions are listed as later or coming soon (OpenProject Jira migration docs). Other source tools need custom mapping. | Import only active projects and a defined history window. Agree which objects are migrated and which are rebuilt manually, and run at least one test import. |
| Project templates and work package types | Each template, custom field, status and work package type needs design, approval, and testing with real teams. Adding more types multiplies the number of workflow and form combinations to check. | Start with two or three templates for the pilot teams. Defer the rest to a later wave with a documented review step. |
| Integrations, including Nextcloud | The Nextcloud integration, available in Community, links files and folders to work packages and can manage project folders automatically. SSO for it through OpenID Connect is an Enterprise add-on (OpenProject Nextcloud integration docs). Each integration needs its own account mapping and permission testing. | Scope Nextcloud file linking first and treat automatic folder management as a separate, optional phase. |
| Number of environments | Separate development, test and production environments each need installation, configuration, data refresh and access control. Test environments are needed for migration rehearsals and upgrade checks. | Agree the minimum set in writing, typically production plus one test environment. Confirm who pays for hosting each environment. |
| High availability and backup requirements | Kubernetes with Helm supports horizontal scaling, but a highly available PostgreSQL, shared attachment storage and tested restore procedures add infrastructure and operations work (OpenProject system requirements). | Confirm the recovery objectives your organization requires before design starts. Use a single-node install for a pilot if the business accepts that risk. |
| Compliance evidence needs | Controls for access, logging, encryption, patching and change records must be configured and documented so that assessors can review them. Evidence collection adds effort even when the platform itself is stable. | Name the frameworks and control owners up front. Ask for only the evidence the assessor has requested, and agree a retention period in the written scope. |
| Installation target: packaged OS or Kubernetes | Packaged installs support Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15, and Docker is the recommended method (OpenProject system requirements). Each target OS adds packaging, patching and support paths, and Kubernetes adds cluster operations. | Standardize on one approved target that your platform team already runs. Confirm the exact OS versions your environment supports before the quote. |
Project phases and what each produces
The sequence moves an OpenProject rollout from agreed scope to a tested production system with a signed handover, with each phase closing on a written decision.
Confirm scope and discovery findings
The partner and your stakeholders review the teams, projects, work package types, identity sources and existing tools in scope. The output is a written scope document listing edition, user count, integrations and out-of-scope items. The phase closes when you sign the scope and the quote, which shows the agreed timeline; ask for phase dates in writing.
Decide architecture and sizing
The team chooses the install method (Docker, packages or Kubernetes with Helm), the operating system, the PostgreSQL version and the hosting target, then sizes compute against your user count using the vendor's sizing guide. The output is an architecture decision record covering edition and backup approach. Sign-off comes from your infrastructure and security owners before any build starts.
Build the non-production environment
The partner installs OpenProject in a staging environment inside your infrastructure, configures PostgreSQL with the required extensions and sets up TLS and base administration. The output is a running test instance with documented install steps. The phase closes when the installation is reproducible and a basic smoke test passes.
Configure identity, roles and templates
Your identity sources are connected for sign-in and group mapping, roles and permissions are defined, and project templates, work package types, statuses and custom fields are built to match agreed processes. The output is a configuration baseline with a list of which features need an Enterprise plan. Your process owners sign off on templates before data work begins.
Run data import trials and cleanup
Source data is extracted and imported into staging, typically more than once. Each run is compared against the source for counts, users, relations and attachments, and gaps are logged for manual work. The output is a reconciliation report and cleaned source data. The phase closes when your data owners accept the trial results and the remaining manual work is documented.
Complete user acceptance testing
Your pilot users run agreed scenarios covering daily planning, reporting, permissions and integrations on the staging instance. Defects are logged, fixed and retested. The output is a signed UAT log with open issues classified by severity. Sign-off is given by the business owner who accepts the remaining open items in writing.
Cut over to production and hand over
The team runs the agreed cutover plan: final data import, backup verification, DNS and access switch, and smoke tests. The output is a live production system plus a handover pack with runbooks, backup and restore evidence, and admin access records. Final acceptance is signed by your operations owner, after which any post-go-live support is handled under the agreed support terms.
Recurring costs after go-live
This table lists the costs that continue after the project closes, marks each as recurring or one-time, and shows what moves it up or down; for multi-year modeling, see the OpenProject cost of ownership and editions topic.
| Cost component | One-time or recurring | What drives it |
|---|---|---|
| Software licensing | Recurring on Enterprise only. Community has no license fee. | Basic 5.95 euros, Professional 10.95 euros (25-user minimum), Premium 15.95 euros (100-user minimum) per named user per month, per OpenProject pricing |
| Server and PostgreSQL infrastructure | Recurring | User count. The sizing guide suggests 4 cores and 4 GB RAM up to 200 users, 8 and 8 for about 500, and 16 and 16 for about 1,500. |
| Backups and storage | Recurring | Attachment volume, retention period and copies of PostgreSQL data and files. Restore tests add admin time. |
| Internal admin time | Recurring | Patching, user and group administration, monitoring and support. Grows with integrations, custom fields and user count. |
| Upgrades within the release cadence | Recurring | Minor releases such as 17.7.0 (August 5, 2026), 17.8.0 (September 2, 2026) and 17.9.0 (September 30, 2026). Each needs test and rollout time. |
| Partner support or retainers | Recurring and optional | Scope agreed in writing. Ask what each retainer covers, how upgrades and testing are handled and what response times apply. |
| Initial install and data import | One-time | Install method, identity setup, edition choice and migration scope. These set the baseline for recurring effort. |
What usually goes wrong and how to prevent it
Six failure points cause most of the rework in OpenProject rollouts. Each card names the early decision in this plan that prevents it and what to confirm before work starts.
Sizing for launch users only
Teams often size the server for day-one users and skip the growth plan. OpenProject's system requirements suggest 4 cores and 4 GB RAM for up to 200 users, 8 cores and 8 GB for about 500, and 16 cores and 16 GB for about 1,500. Ask for user counts at 12 and 24 months and size the first install to that figure.
Edition and identity decided too late
SSO through SAML, OIDC or Kerberos, LDAP group synchronization and custom branding are Enterprise features, so the edition limits the identity design. Decide the edition and map identity sources, groups and roles before build starts. Otherwise group and role design gets reworked after users and permissions are already loaded.
Missed PostgreSQL requirements
OpenProject supports PostgreSQL 16 or later from version 16.0.0 and requires the pg_trgm, btree_gist and unaccent extensions. Check the database version and extension availability in the target environment, including any managed database service, before choosing the install method. Confirm both with the vendor or your database team.
Importing dirty data without rules
Jira exports and spreadsheets often carry duplicate users, stale projects and inconsistent statuses. The beta Jira Migrator imports projects, issues, versions, custom fields, users, groups, statuses and types, and its documentation advises test setups only. Write a cleanup rule covering what is archived, merged or dropped before the first test import.
Too many templates before testing
Project templates and work package types built before users test them tend to multiply, and each new type adds fields, statuses and workflows to maintain. Start with a small set tied to the reporting needs in this plan. Test it with a pilot team, and add new types only after a named owner approves them.
No admin owner after handover
Minor releases arrive often, for example 17.7.0 on August 5, 2026, 17.8.0 on September 2, 2026 and 17.9.0 on September 30, 2026. Without a named owner for upgrades, PostgreSQL changes, backups and user provisioning, the install falls behind. Name that owner and the support route in the quote, including whether Enterprise support or a retainer covers it.
How the work changes by starting point
A new deployment has no data to move, so the work centers on install method, database, sizing, edition choice and project templates. Docker is the recommended install method, and packaged installs are available on supported 64-bit Linux distributions.
- Supported packages: Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15.
- Database: PostgreSQL 16 or later, with the pg_trgm, btree_gist and unaccent extensions.
- Sizing: the sizing guide suggests 4 cores and 4 GB RAM for up to 200 users, and larger hosts for bigger teams.
- Client supplies: the host or virtual machine, the PostgreSQL instance, DNS and TLS certificates, and a named list of users, groups and first projects.
Work tracked in spreadsheets or another work management tool needs a mapping exercise before any import. The supplied facts do not include a migrator for these sources, so the import method is a scoping question to settle before quoting.
- Data model first: decide how source columns map to work package types, statuses, custom fields and project structure.
- Cleanup: duplicate IDs, inconsistent owner names and mixed date formats usually need a pass before import.
- Import path: confirm with OpenProject which import options apply to your source tool and edition.
- Client supplies: representative exports, owner lists, and the people who will sign off on the mapping.
- Time drivers: the number of source formats and the effort to reconcile history and ownership.
A move from Jira Data Center changes the plan around a beta importer. The sibling topic covers what the Jira Migrator imports today, so this tab focuses on how that affects scheduling, testing and cutover.
- Source version: the migrator reads Jira Data Center 10.x and 11.x. Jira Cloud is not a source, so confirm your version early.
- Test first: the documentation advises using the beta only in test setups, so plan at least one full test run before any production cutover.
- Manual work: workflows and permissions are not in the current import scope, so plan a manual rebuild for them.
- Pending items: issue relations and sprint assignments are listed as coming soon, so decide how to carry them over.
- Client supplies: administrator access for export, the target OpenProject version, and a decision on how much history to keep.
A Kubernetes target moves responsibility for scaling, storage and recovery onto the platform team. OpenProject supports Kubernetes with Helm charts for horizontal scaling, and the work depends on a cluster that already meets your standards.
- Cluster readiness: confirm the distribution, identity integration and upgrade process before installing the chart.
- Database placement: decide whether PostgreSQL 16 or later runs inside the cluster or on separate infrastructure, and confirm the three required extensions.
- Shared storage: attachments need storage that all replicas can reach, so confirm the storage class with your platform team.
- Client supplies: a cluster you control, ingress and certificates, backup tooling, and named owners for on-call and upgrades.
- Time drivers: cluster and storage readiness, plus restore testing. Sizing still follows user count.
An air-gapped or restricted network adds staging and approval steps to every stage of the work. The supported operating systems, PostgreSQL version and sizing guidance still apply, but every artifact has to reach the network through an approved path.
- Artifact transfer: Docker images, Helm charts or packages must be mirrored internally. Confirm the transfer method and the update cadence with your security team.
- Licensing: confirm with OpenProject how Enterprise licenses are activated when outbound connections are blocked.
- Identity: plan SSO against identity providers reachable inside the network before go-live.
- Client supplies: an internal registry or package mirror, internal DNS, the PostgreSQL host, and a documented change process.
- Time drivers: approval cycles and transfer steps, which often outlast the technical build.
What you need to provide before work starts
The quote for an on-premises OpenProject rollout is built from the inputs you provide before work starts. Gaps in these inputs do not stop the project, but they move cost and timeline, because each missing answer becomes an assumption that the scope has to carry. Start by naming an executive sponsor who can settle disputes about scope, and a project owner who makes day-to-day decisions and signs off the written scope.
Next, supply a list of the teams that will use OpenProject and the workflows each one runs today, such as portfolio reporting, sprint planning or work package handoffs. Add user counts by group and by identity source, for example Active Directory, LDAP or an existing OpenID Connect provider. The count and identity source determine the sizing tier, the Enterprise edition needed for single sign-on or LDAP group synchronization, and how much provisioning work sits in scope.
Confirm access to the target environment: cloud accounts, data center hosts or an air-gapped network, plus change approval paths. Decide the PostgreSQL plan early. OpenProject officially supports PostgreSQL 16 or later and requires the pg_trgm, btree_gist and unaccent extensions, so ask your DBA whether a managed or self-run instance can enable them. Also decide on TLS certificates, the public DNS name and whether internal certificate authorities issue them. Provide export samples from your current tools so the team can check field mappings before any import.
Finally, record decisions on project naming conventions, the project templates and roles you want, and the people who will administer OpenProject after go-live, including backups, user administration and upgrades. Ask your implementation partner to show how each input maps to a line in the quote, and confirm which inputs are still open. Items marked open are where cost and timeline are most likely to change.
Frequently asked questions
How much does an OpenProject implementation cost and what drives it?
Cost comes from three places: the implementation service, the software licenses and the infrastructure you run it on. DeployOpen does not publish a price list, and a quote follows from a written scope. The service cost depends on the install method, user count, identity integration, data import, templates, customization and testing. The Community edition is free, while Enterprise on-premises is billed per named user per month. Infrastructure and internal admin time recur every year. Ask any partner to separate one-time work from recurring support and to list each assumption behind the total.
Is the OpenProject Community edition enough for our teams?
For many teams, yes. The Community edition is free and includes work packages, Gantt charts, agile boards, time tracking and dashboards, with community support. Enterprise adds features such as single sign-on through SAML, OIDC, CAS, Kerberos and Okta, LDAP group synchronization and custom branding. Community includes the Nextcloud integration, but OpenID Connect sign-in for that integration is an Enterprise add-on. Confirm the current feature list on OpenProject's pricing page before you decide, because editions can change between releases.
When does OpenProject Enterprise become necessary, and what are the minimums?
Enterprise on-premises becomes necessary when you need its identity features or support terms that Community does not provide. Pricing is per named user per month. Basic is 5.95 euros and Professional is 10.95 euros with a 25-user minimum. Premium is 15.95 euros with a 100-user minimum. Corporate is quoted on request for 250 or more users. These figures come from OpenProject's published pricing. Count the named users you will license, check whether your headcount meets each minimum, and confirm current prices, taxes and billing terms with OpenProject before you budget.
How long does an OpenProject implementation take to complete?
No duration is meaningful without a defined scope. Timing depends on the install method, the number of identity providers, how much history you import and from which source, how many templates and custom fields you need, the number of test cycles, and how quickly stakeholders sign off. A fixed-scope engagement sets out deliverables and a timeline in writing before work starts. Ask for a phased plan with named milestones, the client tasks each phase depends on, and the effect on the schedule if an identity or data dependency slips. Treat any duration given before scope is agreed as an estimate only.
Can our own IT team deploy and run OpenProject without a partner?
Possibly, if your team already runs Linux services and PostgreSQL. OpenProject supports Docker-based installation, which is recommended, along with .deb and .rpm packages for 64-bit Linux, including Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15. It requires PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions. Be realistic about the ongoing load: releases arrive frequently, upgrades involve database and package steps, and someone must own backups, patching and incident response. Assess those skills and hours before you decide.
What should a written OpenProject implementation quote include?
A useful quote lists the scope, deliverables, assumptions and the client inputs each item depends on. It should state the edition, the named user count, the install method, the PostgreSQL version and extensions, the identity and data sources, and the sizing basis. 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. Ask the quote to confirm those figures against your concurrency and attachment volume. Also ask for one-time versus recurring costs, change control terms, and who performs upgrades after go-live.
How DeployOpen scopes and delivers OpenProject
DeployOpen plans, installs, configures, documents and supports OpenProject inside your own infrastructure, starting from a written scope that sets the edition, sizing, templates and identity approach before any cost is quoted. Engagements are fixed-scope, so the deliverables and timelines are agreed in writing before work begins.
How we scope
- The written scope names the OpenProject edition, install method and the number of users it covers.
- Sizing follows OpenProject's published guidance for user count, with the hosting environment confirmed before quoting.
- Identity, data import, project templates and branding needs are listed as separate items so each can be priced and sequenced.
How we build
- Installation uses the method chosen in scope, such as Docker, packages or Kubernetes with Helm, in your cloud, data center or air-gapped network.
- PostgreSQL is set up with the extensions OpenProject requires, and the database version is confirmed against current system requirements.
- Project templates, work package types, statuses and roles are configured and tested with a pilot group before wider rollout.
How we hand over
- Deliverables include installation records, configuration notes, the access model and a backup and restore procedure your team can run.
- Your administrators receive a walkthrough of upgrade steps and where release notes are checked for each minor version.
- Any data import is tested in a non-production run first, with reconciliation results documented before cutover is approved.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Retainer scope, response expectations and upgrade cadence are written down so they can be compared with your own team's capacity.
- Enterprise support from OpenProject GmbH is a separate contract from DeployOpen services, and both should be confirmed in the quote.
