When one OpenProject project is no longer enough for portfolio and program management
OpenProject portfolio and program management groups several projects under a program or portfolio, so leadership can see aggregated progress toward one strategic goal without collecting separate status updates from every team. Before you design anything, confirm on the OpenProject pricing page that the Premium or Corporate Enterprise plan includes this capability, because it is not part of the free Community edition. If several teams run multiple projects that feed one goal and leadership keeps asking for a single view, you have reached the point where a single project plan stops being enough. Teams usually take this step when one project has turned into a container for several workstreams, each with its own owners, milestones and budget, and when the same people are asked for status in different formats. Implementation normally starts once the organization agrees which strategic goals exist and which projects contribute to each one. That is a governance decision, so the first working session should include sponsors and project managers alongside the administrators who will configure the instance.
Most of the effort in this work sits in three areas. The first is structure: deciding which projects roll up into which program, whether a project can sit under more than one parent, and how many levels the hierarchy needs before reports become hard to read. The second is permissions: an aggregated view can expose information from projects that some viewers cannot open directly, so role assignments in each underlying project must match what leadership is allowed to see. The third is data quality, because roll-up figures are only as accurate as the dates, statuses and progress values that teams keep up to date in their work packages. Software installation is the smallest part of the work. If your organization already runs OpenProject, the change is mostly configuration, role design and agreement on how status gets reported. If you are deploying the platform for the first time, the infrastructure track runs alongside this one and should be scoped separately.
Ask any implementation partner, and your own team, to show the planned structure before the build begins. A useful test is a sample of the report leadership will receive, populated with test data, so the people who own the goals can confirm that the numbers answer their questions. Also agree who may change the program structure and how changes are recorded, since a hierarchy that drifts over a year makes historical comparisons meaningless. Finally, confirm the plan tier and user count early. Enterprise on-premises plans are priced per named user per month, and the Premium tier carries a minimum number of users, so the number of people who will see or edit portfolio data should be counted before the scope is written. Ask for a quote that names the plan, the user count, the structure to be built, the permission model and the data cleanup the vendor expects you to do yourself.
What OpenProject portfolio and program management does according to the platform docs
OpenProject groups projects into programs and portfolios, and the aggregated views depend on how the underlying projects are built. The platform documentation is the reference for what each edition includes. The cards separate the capabilities already in the free Community edition from those behind the Enterprise plan, and list what to confirm before scoping.
Community base the roll-ups depend on
Work packages, Gantt charts, agile boards, time tracking and dashboards are included in the free Community edition, according to OpenProject's pricing page. Program and portfolio views summarize this data, so the accuracy of work package dates, statuses and hierarchy in each child project determines whether the aggregated picture is reliable. Check how your teams record progress before you rely on any roll-up.
Grouping projects into programs and portfolios
This is the core capability: collecting several projects under a program or portfolio so leaders can review them together. Confirm how the grouping is modeled in the current release, including whether a program can contain another program, whether a project can belong to more than one group, and who may create and change groupings. These answers shape your project structure before any data is migrated.
Aggregated progress and strategic views
The documented views summarize progress and status across the projects in a group. Confirm which views exist, which fields they aggregate, how overall status is derived from child projects, and how often they refresh. Test with a small illustrative group of projects that has deliberately mixed statuses and dates, so you can see how the calculation behaves before you commit to it.
Enterprise plan requirement
Portfolio and program management requires the Premium or Corporate Enterprise plan. According to OpenProject's pricing page, Premium is listed at 15.95 euros per named user per month with a 100-user minimum, and Corporate is quoted on request for 250 or more users. Confirm which plan includes the feature in your target release, and check how the user minimum affects your cost base.
Access rules for cross-project views
Aggregated views only help when each viewer sees what they are meant to see. Map roles and permissions to the portfolio structure before rollout, and test with accounts from each role, including people who belong to some child projects but not others. If you use SSO or LDAP group synchronization, both listed as Enterprise features, confirm how group membership flows into those roles.
Release notes before you scope
Feature names, menu locations and behavior change between releases. The release history includes 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. Read the release notes for the version you plan to deploy, record the exact feature names and plan tier for each capability, and confirm them in writing before the scope is agreed.
Which configuration decisions shape a portfolio and program setup
This table lists the configuration choices a team should settle before building programs and portfolios in OpenProject. Each row sets out the options, when each one fits and what it costs to change once projects and users are already in place. The main takeaway is that plan tier, identity and project folder decisions are the hardest to reverse, so confirm them with stakeholders before any structure is created.
| Decision | Options | Fits when | Cost to change later |
|---|---|---|---|
| Program and portfolio hierarchy | Flat program with projects as children, or a portfolio holding several programs | A flat program fits one initiative with few projects. A portfolio fits several business lines that report separately. | Moderate. Moving projects between parents is possible, but confirm how it affects existing reports and dashboards. |
| Plan tier | Premium (minimum 100 named users) or Corporate (250 or more users, on request) | Premium fits mid-sized organizations. Corporate fits organizations with 250 or more users. | Recurring per named user. Premium lists 15.95 euros per user per month (OpenProject pricing). Changing tiers needs a new quote. |
| Cross-project visibility | Limit aggregated views to a PMO or program manager role, or open them to all project members | Limited access fits sensitive portfolios. Open access fits teams that share progress widely. | Low to change roles, but dashboards already shared with a wider audience need review. |
| Single sign-on | Local accounts, or SSO through SAML, OIDC, CAS, Kerberos or Okta | SSO fits organizations with a central identity provider. Local accounts suit small, isolated deployments. | High once users exist. Switching identity sources means matching accounts and rechecking roles. |
| LDAP group synchronization | Manual group membership, or LDAP groups mapped to OpenProject roles | Mapping fits teams that already manage access through directory groups. Enterprise plan required. | Moderate. Group-to-role mappings must be rebuilt if the directory structure changes. |
| Nextcloud project folders | Out of scope, or the Community integration linking folders to work packages with automatic folder management | Folder management fits teams whose documents already live in Nextcloud. OIDC SSO for Nextcloud is an Enterprise add-on. | Moderate. Renaming folder structures after many projects exist can break links and require cleanup. |
How program and portfolio grouping changes the way project data is set up
Grouping projects into a program or portfolio changes the data model before it changes any dashboard. Each member project holds its own work packages, types, statuses and custom fields, so a grouped view only produces useful totals when those elements line up across projects. Decide early which of them are defined once for the whole instance and which may vary by project, and record that decision. Changing it after several projects have built up history is harder than settling it at the start, because existing work packages keep the values they were created with.
User roles need the same attention. A person may hold one role in a parent program and a different role in a member project, and what they see in aggregated views depends on their permissions in the underlying projects. Map who needs portfolio-level visibility, who manages a single project, and who maintains the shared types and statuses. Confirm in your release whether role assignments inherit from a parent to its subprojects or must be set on each project. Then test with a non-administrator account before rollout, so a summary does not quietly leave out work that the viewer cannot access.
Inconsistent status names are the most common reason aggregated reporting fails. If one project uses "In review" and another uses "Review", a status-based chart treats them as different states, and a summary built on open or closed statuses can miss work. The same problem appears with custom fields that share a label but differ in field type, option list or required setting. Reconcile names, option values and field types across member projects before building any view, and publish the agreed list as the reference that every team follows.
Before settling on a common data model, check how the release you plan to run rolls up dates, progress and status from child work to parent. Confirm whether a parent's start and finish dates derive from its children, how progress is calculated when children use different measures, and which status a parent shows when its children disagree. Test these behaviors with a small sample program that uses the same statuses, types and fields as production. The results determine how strict the shared model must be and whether some reporting needs a calculation outside the platform.
Program and portfolio features sit in the Premium or Corporate Enterprise plan. The OpenProject pricing page lists Premium at 15.95 euros per named user per month with a 100-user minimum, and Corporate on request for 250 or more users. Ask for a written quote that matches your user count, and confirm in writing which features each plan includes before you design the data model around them. Recurring license cost follows the number of named users, so the plan decision and the role design should be made together.
Rollout sequence for portfolio and program management, and what each step produces
The sequence moves from edition and hierarchy decisions to a documented data model, tested access controls and one pilot program before the remaining programs follow. Each step closes with a named deliverable that your team keeps, so the portfolio views can be checked against agreed reporting questions at every stage.
Confirm edition, user count and hosting
DeployOpen confirms with you which OpenProject Enterprise plan includes portfolio and program features, which is the Premium or Corporate plan, and counts named users. Premium has a 100-user minimum, and Corporate is quoted on request for 250 or more users. The team also confirms the hosting method (Docker is the recommended installation, with packaged installs available on supported Linux distributions), the PostgreSQL 16 or later database with its required extensions, and a sizing tier from the vendor's guide. Output: a signed scope with an edition and sizing record. Ask the vendor to confirm current plan contents before signing, because feature placement between plans can change.
Agree portfolio hierarchy and reporting questions
Working with your portfolio owners and program managers, the team maps which projects roll up into which programs and portfolios, and names the owner of each level. It also records the reporting questions the views must answer, such as which programs are behind plan or which strategic goals have no active work. Each question is tied to the data it needs, so gaps surface before anything is configured. Deliverables: a hierarchy map and a reporting question register, signed off by the sponsor. The step is done when every question has an owner and a source field.
Define the shared data model
The team defines the attributes every project and program must carry so that aggregated progress means the same thing across teams. This covers custom fields, statuses, work package types, naming conventions and which fields are required at each level of the hierarchy. If any data comes from Jira Data Center, the team checks the migrator's beta status and its listed gaps first, including issue relations and sprint assignments, and records each mapping decision at field level. Deliverable: a data dictionary with field definitions, allowed values and data owners. The step is done when a sample program can be fully described from the dictionary alone.
Configure permissions and single sign-on
Roles are set up to match the hierarchy, so program managers see their own programs and portfolio leads see the full portfolio, with no access beyond what their decisions require. Single sign-on through SAML, OIDC, CAS, Kerberos or Okta, and LDAP group synchronization, are configured against your identity provider. Both are Enterprise features, so confirm they are included in the plan chosen in step one. The team tests each role with named test accounts, including accounts that should be denied access. Deliverables: a permission matrix mapping roles to hierarchy levels and an SSO and group sync test record. The step closes when every test account produces the expected result.
Pilot with one program
One program is loaded with live project data under the agreed data model, and its portfolio views are checked against the reporting questions from the second step. Program managers and the sponsor use the views for an agreed period, and the team logs every gap. Configuration issues are fixed within the agreed data dictionary, and any change to that dictionary requires approval. Deliverable: a pilot sign-off document listing accepted views, open issues and approved changes. Remaining programs are not onboarded until the sign-off is recorded.
Roll out remaining programs and hand over
The remaining programs are onboarded in groups, and each is checked against the data dictionary and permission matrix before its owners receive access. DeployOpen writes an operations runbook covering backups, user and group administration, upgrade steps that follow the OpenProject release notes, and how to add a new program to the hierarchy. Your administrators are trained on the runbook and run one onboarding while the team observes. Deliverables: an onboarded program list, the operations runbook and a handover record. The step is done when your administrators complete an onboarding without DeployOpen running it.
Migrating existing Jira project data into a program structure
The first thing to confirm is where your Jira data lives. The OpenProject Jira Migrator imports from Jira Data Center 10.x and 11.x. It does not read Jira Cloud, so a team on Jira Cloud cannot use it as a source without a different route. The tool is also in beta, and the migration documentation advises using it only in test setups. For a program structure that will drive portfolio reporting, this means the migration is a rehearsal and a validation exercise first, and a production cut-over only after the results have been checked.
The Migrator imports projects, issues, versions, custom fields, users, groups, statuses and types. Those objects form the raw material for a program. Projects become the units you group into programs and portfolios, versions can map to release milestones that feed roadmap views, and statuses and types determine how work packages are counted and filtered when progress is rolled up. Custom fields matter for any aggregation you rely on, because a field that did not arrive in the expected form will silently remove a dimension from your reports. Users and groups determine who sees which program data once permissions are configured.
Several things are not imported yet. Issue relations and sprint assignments are listed as coming soon, and workflows and permissions are listed for a later release. Plan for this gap explicitly. If your program dashboards depend on dependencies between work packages or on sprint-level progress, those links will not exist after migration and will need to be recreated by hand or by a scripted step your team owns. Workflows and permissions will also need to be rebuilt in OpenProject, so the roles and status transitions that govern program-level reporting should be defined in the target instance rather than assumed to carry across.
Validate the migrated structure in a test instance before any production cut-over. Compare project counts, issue counts, version assignments and custom field values against the Jira source for a sample of programs. Confirm that each program and portfolio grouping shows the expected child projects and that the aggregated progress figures match a manual check on a few representative programs. Check that users and groups resolve correctly, since a missing user will leave work packages unassigned in program views. Record every gap, decide who rebuilds each missing element, and agree the sign-off criteria in writing before the production date is set.
Ask your implementation partner and OpenProject to confirm the current beta status, the supported Jira Data Center versions, and the release in which relations, sprint assignments, workflows and permissions are expected, because these items are listed as future work and may change. Your own environment also sets the effort: the number of projects, the custom field count, and whether your Jira instance has been upgraded to a supported Data Center version will drive how much rework the test cycle needs. Scope the migration work so that these items are visible in the quote rather than discovered during cut-over.
What drives the effort and cost of a portfolio and program implementation
This table lists the factors that change the effort and cost of setting up OpenProject portfolios and programs, and shows which costs are one-time and which recur. Use it to see which inputs your quote must state before the scope is agreed. The main takeaway is that user count and plan tier drive the recurring license cost, while data cleanup and reporting views drive most of the one-time effort.
| Driver | Why it changes effort or cost | One-time or recurring | What to request in a quote |
|---|---|---|---|
| Programs and projects | Each program adds a roll-up level to design, and each project adds data to aggregate and test. | One-time build, recurring as the structure grows | Counts of programs and projects, plus expected growth over the next year |
| Named users and plan tier | Portfolio grouping requires Premium or Corporate, both priced per named user per month (OpenProject pricing). | Recurring license fee | User counts by plan tier, the Premium minimum and a Corporate quote for 250 or more users |
| Data cleanup before migration | Duplicate projects, stale work packages and inconsistent custom fields slow mapping and validation. | One-time | Cleanup scope, who performs it and the data sources to be migrated |
| SSO and LDAP group mapping | Group-to-role mapping must match the program and portfolio structure. SSO and LDAP group sync are Enterprise features. | One-time mapping, recurring group changes | Identity provider, protocol, number of groups and the role model to map |
| Host sizing | Documented guide: 4 cores and 4 GB RAM up to 200 users, 8 and 8 for about 500, 16 and 16 for about 1,500. | One-time setup, recurring hosting | Named user count, expected concurrent use and the infrastructure where the host runs |
| PostgreSQL version and extensions | PostgreSQL 16 or later is required, with the pg_trgm, btree_gist and unaccent extensions installed. | One-time setup, recurring patching and upgrades | Confirmed PostgreSQL version, extension availability and who operates the database |
| Reporting views | Each portfolio or program view needs field definitions, permission checks and sign-off, and later changes add work. | One-time build, recurring change requests | List of views, data fields, intended audience and refresh expectations |
How portfolio and program views connect to the rest of the platform
A program or portfolio view is only as current as the data behind it. The integrations and sibling modules below change who sees which projects, which data is available to roll up, and how the instance is run. Confirm each behavior against the current vendor documentation for your release before you fix the design.
SSO and LDAP group synchronization
LDAP group synchronization and single sign-on are Enterprise features in OpenProject. For program reporting, the key question is whether the groups that grant access to a program's projects come from your directory or are maintained by hand in OpenProject. Map which directory groups own which portfolio or program roles, then test that a removed directory member loses access to the aggregated views. Confirm the sync options, group mapping and supported login protocols in the vendor docs for your edition.
Nextcloud files linked to work packages
The Nextcloud integration is available in the Community edition. It links Nextcloud files and folders to work packages and can manage project folders automatically. For program reviews, linked documents such as charters, risk registers and steering packs sit beside the work they support. Decide who owns the Nextcloud folder structure, and check that Nextcloud file permissions match the access OpenProject gives each project. Single sign-on for this integration through an OpenID Connect provider is an Enterprise add-on, so confirm that requirement before you plan identity.
PostgreSQL as the database
Portfolio and program views aggregate many projects, work packages and users, so database load and query performance grow with the size of the instance. OpenProject officially supports PostgreSQL 16 or later since version 16.0.0 and requires the pg_trgm, btree_gist and unaccent extensions. Ask your database team to confirm those extensions are available on your self-hosted or managed instance before installation. Plan backups and restore tests for the database that holds program history, since reporting depends on it.
Packaged, Docker and Kubernetes deployment
OpenProject supports Docker-based installation, which the vendor recommends, .deb and .rpm packages for 64-bit Linux, and Kubernetes with Helm charts for horizontal scaling. Packaged installs support Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15. The deployment path shapes how upgrades, backups and database migrations run, which matters once a portfolio is live for many teams. Choose the path with your platform team before modules are configured, and confirm the operating system support and sizing guidance for your user count in the current system requirements.
Time tracking, team planner and agile boards
Program views draw on sibling modules. Time tracking and budgets supply cost and effort figures, the team planner shows scheduling and reassignment across people, and agile boards and backlogs show Scrum or Kanban progress inside a project. Each one changes what a rollup can report. Decide which projects log time against budgets, whether planner data feeds program reviews, and how board columns map to work package status. Confirm which of these modules your plan includes and how each contributes to aggregated views in the vendor docs.
Questions buyers ask before bringing in an implementation partner
Does portfolio and program management need Premium or Corporate in OpenProject?
Yes. The portfolio and program features covered here sit in the Enterprise tiers, Premium or Corporate, and the free Community edition does not include them. Confirm this on the OpenProject pricing page feature comparison, then in writing with the vendor for your exact version and user count. For reference, the pricing page lists Premium at 15.95 euros per named user per month with a 100-user minimum, and Corporate on request for 250 or more users. Your licence is paid to OpenProject, not to the implementation partner, so request the licence quote and the implementation quote separately and ask how minimum billing applies to your headcount.
How do I confirm which OpenProject plan includes a feature?
Start with the feature list on the OpenProject pricing page, then check the release notes for the version you plan to run, because feature availability can change between releases. The pricing page lists Enterprise features including single sign-on through SAML, OIDC, CAS, Kerberos and Okta, LDAP group synchronization and custom branding, so list every feature your design depends on. Then ask the vendor to confirm each one in writing against your edition, version and user count. Carry that confirmation into the written scope so the team building the solution and the buyer share the same assumptions.
What does an OpenProject portfolio setup cost in effort?
No effort figure is published for this topic, so the answer depends on your scope. Cost has four parts: the OpenProject licence, paid to the vendor per named user; the infrastructure you run, which includes one-time setup and recurring hosting and backups; the implementation effort for program design, configuration, testing and training; and internal staff time for decisions and data review. Licences and hosting recur, while design and build are usually one-time, although changes and support recur as well. Effort rises with the number of programs, the depth of the hierarchy, the reporting views required, data cleanup and identity integration. Ask for a quote that splits effort by workstream and lists its assumptions.
What makes an OpenProject program setup take longer?
Duration depends on a few drivers, and no fixed timeline is published for this topic. The largest are how many programs and portfolios must share one structure, whether data must be moved in from another tool, and whether single sign-on and LDAP group synchronization are in scope, since both depend on identity teams outside the project. Decision speed matters as much as configuration. Agreeing what progress, budget and status mean across programs often takes longer than building the views. Ask the partner for a phased plan that starts with a pilot program, sets clear decision gates and lists the inputs each phase needs from your side.
How long does an OpenProject portfolio implementation usually take?
No duration is published here, so treat any figure you hear as a claim to test. In general terms, the work moves from scope agreement to a pilot program, then to the remaining programs once reporting definitions are accepted. Timing depends on the drivers covered above, the availability of your program owners and the number of environments, such as test and production, that must be built and kept in step. Ask for a written schedule with milestones, the named client inputs each milestone needs and the effect of a slipped dependency. Fixed-scope work is agreed in writing before it starts, so the schedule should appear in that document.
Which client roles are needed for an OpenProject rollout?
Name these people before work starts. Program owners define how programs and portfolios group projects and which progress measures leadership needs. Data owners confirm which project data is authoritative and approve any cleanup or mapping. An OpenProject administrator manages accounts, roles, server access and upgrades after handover. An SSO contact supplies identity provider settings, group claims and test accounts for single sign-on or LDAP group synchronization. Also name a sponsor who approves scope changes. Record each person, their expected time commitment and the deliverables they own in the written scope.
Can an internal team set this up without an implementation partner?
Often yes, if the team has the skills and time. Installation is documented: Docker is the recommended method, with .deb and .rpm packages for supported 64-bit Linux distributions and Kubernetes with Helm charts for horizontal scaling. The database must be PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions. The sizing guide suggests 4 cores and 4 GB RAM for up to 200 users. The harder work is program design, agreement on reporting, identity integration and training, which benefit from people who have done it before. Assess your team's Linux, database, identity and OpenProject configuration skills against that list before deciding.
Is migrating from Jira Data Center to OpenProject safe in production?
Not as a first production cutover. The OpenProject Jira Migrator is in beta, and its documentation advises using it only in test setups. It imports from Jira Data Center 10.x and 11.x, and Jira Cloud is outside its supported sources. It moves projects, issues, versions, custom fields, users, groups, statuses and types. Issue relations and sprint assignments are listed as coming soon, and workflows and permissions come later, so plan to rebuild or reconcile those by hand. Run repeated rehearsals in a test environment, compare record counts and sample issues, then agree the remaining gaps and the cutover plan in writing.
How DeployOpen works on this
DeployOpen plans and implements OpenProject portfolio and program management inside your own infrastructure, with the Enterprise plan that the topic requires confirmed before design starts. Each engagement follows a written, fixed scope so that programs, portfolios and their reporting views are agreed before any configuration begins.
How we scope
- Written scope lists the programs and portfolios to be modeled, the projects grouped under each, and the aggregated views that leaders need.
- We confirm which Enterprise plan tier the required functions sit in and record that decision in the scope before work starts.
- Scope also states hosting targets, identity integration, and which data sources, if any, feed the portfolio views.
How we build
- We install OpenProject from Docker, packages or Helm charts in your environment, sized against the user count in the agreed scope.
- We configure program and portfolio structures, project hierarchy, shared status fields and roll-up reporting, then test them with sample projects.
- We check user roles and visibility so that portfolio views show only what each stakeholder group is permitted to see.
How we hand over
- Handover includes documentation of the program and portfolio structure, the reporting views, and the decisions recorded during scoping.
- Administrators receive runbooks covering backups, upgrades, the PostgreSQL requirements and day-to-day structure changes.
- Your team walks through a test run of the portfolio views with project managers and sponsors before acceptance.
How we support
- Ongoing support, upgrades and maintenance are available as a retainer after handover, covering new OpenProject releases.
- Upgrade planning reviews release notes and database requirements before each version change in your environment.
- Support scope, response expectations and review cadence are agreed in writing, so your team knows what is covered.
