How to set up the OpenProject team planner for team scheduling
The OpenProject team planner answers a question that team leads and PMOs ask every week: who is scheduled on what, and where can work move when someone is overloaded or away. It shows scheduled work packages by assignee over time, so a lead can move an item from one person to another without rebuilding the plan in a spreadsheet. Teams usually set it up once several people share the same projects and the Gantt chart no longer shows who is carrying the load. This section explains the setup steps that make the planner useful from the first day it is used.
This section covers configuration, data, integrations, effort and handover. Configuration means deciding which projects feed the planner, who belongs to them, and which roles can change dates and assignees. Data covers the work package dates, assignees and estimates the planner reads, along with the clean-up needed before go-live. Integrations covers how user accounts arrive, through the directory or single sign-on setup your organization already runs. Before you plan around the planner, confirm which edition includes it by checking the current OpenProject pricing page, because plan contents can change between releases.
Start by deciding which projects feed the planner. Mixing unrelated projects produces a crowded view that hides overload, so many teams begin with one department or one programme. Next, review the project roles you have defined and confirm the default role names in your installed version. People who move work between colleagues need permission to edit assignees and dates, while most team members only need to view the schedule. Check that the team planner module is enabled in every project in scope, because a project without it leaves a gap in the view. Finally, agree working conventions: which statuses count as scheduled, whether a work package needs both start and due dates before it appears, and who owns reassignments so two leads do not move the same person's work in conflicting directions.
Planner accuracy depends on data quality. Work packages without dates or assignees will not appear in the schedule, so run a clean-up across the projects in scope before the first review. Estimates matter if you plan to compare scheduled effort with logged time, which the time tracking and budgets topic covers in more detail. For user accounts, decide whether people are created manually or synchronized from a directory. LDAP group synchronization and single sign-on are listed among the Enterprise features on the pricing page, so if your identity setup depends on them, the edition decision comes before the planner design. Ask the implementer to document which fields the planner reads, so that later imports or bulk edits do not silently change what people see.
Effort depends mainly on the number of projects in scope, the condition of existing data and the number of identity sources that feed the user list. Cost has a one-time part, covering configuration, data clean-up, pilot testing and training, and a recurring part, covering Enterprise licences where they are used, upgrades and support. Enterprise licences are priced per named user per month, so the user count is a direct cost driver. Ask any quote to state the projects in scope, the user count, the identity integration, and the training and documentation to be handed over. Before handover, run a pilot with one team: move an assignment between two people, confirm the other person's view updates, and check that a reader sees only what their role allows. Hand over a short runbook that names who maintains roles, dates and reassignment rules.
What the OpenProject team planner does for scheduling and reassignment
The team planner is the part of OpenProject where work is scheduled across a team and reassigned between people. It sits beside work packages, Gantt charts and dashboards, and the cards below cover how those pieces connect and what to confirm before your team relies on them.
Planner purpose in the docs
OpenProject's documentation describes the team planner as a way to schedule work across a team and reassign it. Read the current planner page before you write this into a requirement, and copy the exact wording it uses for scheduling and reassignment into your scope document. That way your team and any partner test the same behavior. Confirm the version your team will run, because documentation and screens can change between releases.
Position beside work packages
Work packages are the core planning records in OpenProject, and the planner is documented as working with them for scheduling and reassignment. Before go-live, confirm which work package fields a planner change updates, such as dates and assignee. Then check whether those fields are the ones your reporting depends on. Test a sample project to see how a change made in the planner appears on the work package itself.
Gantt charts and dashboards
The OpenProject pricing page lists work packages, Gantt charts, agile boards, time tracking and dashboards in the free Community edition. The planner is not named in that list, so confirm its edition on the pricing page before you assume it is included. Also check which Gantt views and dashboard widgets your edition provides, because these determine what planners and managers see alongside the schedule.
Reassignment and change history
Reassigning work changes who is accountable for a work package, so audit and handover expectations depend on how it is recorded. Ask your administrator or partner to test a reassignment on a sample project. Then check the work package activity history, any notifications, and any email sent to the new assignee. Confirm in the current documentation whether reassignment through the planner is logged the same way as edits made in the work package form.
Confirm capabilities in release notes
OpenProject publishes release notes for each version, and planner behavior can change between them. Recent releases in the record include 17.7.0 on August 5, 2026, 17.8.0 on September 2, 2026, 17.9.0 on September 30, 2026 and 17.9.2 on October 15, 2026. Read the notes for the exact version you plan to install, list the planner changes that apply, and build your acceptance tests around that release.
Configuration decisions before turning on the team planner
This table sets out the choices a team must settle before the planner shows the right items to the right people. Each row names a decision, the options OpenProject exposes, the situations where each option fits, and where edition or role setup changes the answer. Confirm the marked items against the release you install, because planner behavior can differ between versions.
| Decision | Options | When each fits | Edition or permission note |
|---|---|---|---|
| Projects that get the planner | All projects in one instance, or a pilot set of delivery projects | Start with a pilot when teams are new to scheduling in a shared view | Confirm whether the planner is enabled per project and whether it is in the Community edition |
| Who can reschedule and reassign | Project admins only, planners with edit rights, or team leads with scoped roles | Restrict to leads when dates feed client commitments; open to members for self-managed teams | Set through role permissions; confirm which planner actions each role grants in your release |
| Work package types | A small fixed set such as task, milestone and phase, or extra types per team | Keep the set small so planner rows stay readable; separate milestones if they need their own view | Types are configured by administrators; confirm which types appear in the planner |
| Statuses and closed states | One shared status set, or team-specific workflows per type | Share statuses when teams report together; use separate workflows when a team's steps differ | Workflows are set per type and role; confirm how closed statuses affect what the planner displays |
| Planning scope | Per project planning, or a cross-project view through programs or portfolios | Plan per project for team-level work; add portfolio views when leadership needs aggregated timing | Program and portfolio grouping is listed under the Premium or Corporate Enterprise plans; confirm on the pricing page |
| Resource and capacity view | Planner alone for task-level scheduling, or a separate resource management approach | Use the planner alone for reassigning tasks; confirm any capacity features before promising them | Confirm which capacity features exist in the edition you plan to buy |
| User and group management | Local accounts, or SSO and LDAP group synchronization | Group sync helps when planner roles must follow directory groups across many users | SSO and LDAP group synchronization are Enterprise features; confirm the plan that covers your user count |
How a team planner rollout runs, step by step
This sequence moves a team planner from a plan on paper to a tested pilot and then a wider rollout. Each step ends with a written output that the next step depends on, so decisions stay visible to the sponsors and the team leads who will live with them.
Confirm edition and planner access
Before any installation, the sponsor and the platform owner check the OpenProject pricing page to confirm which edition includes the team planner for the work you plan to do. The Community edition includes work packages, Gantt charts, agile boards, time tracking and dashboards, while Enterprise features such as single sign-on and LDAP group synchronization are listed separately. Confirm the user minimums for each Enterprise tier with the vendor before you size the instance. The output is a written edition decision with the feature list and the named users, signed off by the sponsor.
Size and install the instance
Your platform team installs OpenProject on infrastructure you control, using Docker, which the system requirements recommend. The sizing guide suggests 4 cores and 4 GB RAM for up to 200 users, with higher figures for larger groups, so use the expected named user count from step one. Provision PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions, and confirm the backup and restore path on a non-production copy. The output is a reachable test instance with a documented install, a verified database restore and a note of the sizing basis.
Configure projects, roles and work package types
The platform owner and a process lead create the project structure, the roles that carry permissions, and the work package types the teams will use, such as tasks, milestones or features. Map each role to what it may view, edit and reassign, and keep the matrix short enough that team leads can read it in one sitting. Review it with two or three future users to catch missing roles before any data is loaded. The output is a role matrix and type list signed off by the process owner, with changes recorded in the configuration notes.
Load the pilot team's work
The pilot team's open work is brought into one pilot project, either entered by hand or imported. OpenProject's Jira migrator imports from Jira Data Center 10.x and 11.x, not Jira Cloud, and its documentation is in beta and advises test setups only, so confirm that fit with the vendor before using it. Issue relations and sprint assignments are listed as coming soon in that documentation, so check which of your items will need manual rebuilding. The output is a pilot project holding the team's current work, with a reconciliation list of items that did not load cleanly.
Run the planner with the pilot team
The pilot team plans and reassigns its work in the planner for a fixed working period, with the team lead owning the schedule and the platform owner logging any friction. Track how often dates move, how reassignments are agreed and where people still keep their own spreadsheets, because those gaps show what the configuration missed. Hold a short review with the team at the end of the period. The output is a reviewed pilot schedule, a log of configuration changes and an explicit go or no-go decision from the sponsor.
Widen the rollout deliberately
Once the pilot decision is positive, add teams in groups, each with its own project, roles and onboarding session, and connect identity if your Enterprise plan includes it and your policy requires it. Assign a named administrator and a release owner, and schedule upgrades against the release notes, for example by testing the current patch release such as 17.9.2 in the test instance first. Keep the pilot project as the reference for the other teams. The output is a rollout plan showing each group, its owner and its go-live check, plus a documented upgrade routine.
What drives effort and cost in a team planner implementation
This table lists the main effort drivers for an OpenProject team planner rollout, how each one raises or lowers the work, and what to request in a written quote. Read each row as a question to answer before you compare offers. The main takeaway is that scope, identity and data decisions usually shape the final effort more than the planner itself.
| Driver | How it changes effort | What to ask a partner for in a quote |
|---|---|---|
| Teams and projects in scope | Each project that uses the team planner needs its own module setup, roles and planning data, so more projects add configuration and testing. | A named list of teams and projects, module activation per project, and the planning views to configure. |
| Existing data volume | Work packages, dates and assignees moved from older tools need mapping and cleanup. The beta Jira Migrator does not yet cover issue relations or sprint assignments. | A data inventory, who cleans the data, and whether assignments and dependencies carry over or are rebuilt by hand. |
| Role and permission complexity | Planner visibility depends on project roles. Many roles, cross-project members and team-level restrictions require more test accounts and review rounds. | A role matrix review, test accounts for each role, and a named approver for access decisions. |
| Identity integration | SSO (SAML, OIDC, CAS, Kerberos, Okta) and LDAP group sync are listed as Enterprise features, so plan tier and identity provider work both affect scope. | Confirmed plan tier for SSO and LDAP group sync, the identity provider in use, and how directory groups map to project roles. |
| Hosting and database preparation | Docker, package or Kubernetes installs and PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions add platform work before go-live. | The hosting target, database version and extension setup, backup approach, and the sizing assumptions behind them. |
| Named user count | The sizing guide suggests 4 cores and 4 GB RAM up to 200 users, 8 cores and 8 GB near 500, and 16 cores and 16 GB near 1,500. Enterprise pricing is per named user. | The sizing assumption for your user count, expected peak concurrent use, and the license tier that matches the count. |
| Number of pilot cycles | Each pilot round adds feedback, schedule corrections and retesting of reassignment and capacity views with a selected team. | The number of pilot rounds, exit criteria for each round, and who runs the feedback loop. |
How existing schedules and resource data move into OpenProject
Most teams bring existing schedules into OpenProject through one of three routes: a spreadsheet they maintain by hand, a planning tool they are leaving, or a Jira Data Center instance. The route decides how much planning data arrives intact. The Jira Migrator documentation covers only Jira Data Center, so for spreadsheets and other tools, ask OpenProject or your implementation partner which import options apply to your source. Until that is confirmed, treat those routes as a manual rebuild of the plan in the team planner, with the old file kept as a reference for the people who own the dates.
If the source is Jira, the OpenProject Jira Migrator imports projects, issues, versions, custom fields, users, groups, statuses and types. Issue relations and sprint assignments are listed as coming soon, and workflows and permissions are planned for later. The migrator reads from Jira Data Center 10.x and 11.x only, not Jira Cloud. It is in beta, and the documentation advises using it only in test setups. For a team planner, missing relations and sprint assignments matter because they often show how a team sequences its work and who carries which items.
Before you commit to a migration path, run a test import of a copy of your Jira Data Center data into a test instance. Check whether start and due dates, and the assignee on each imported issue, match the source. Confirm how versions and statuses appear in the planner views your team uses. Record every field that does not survive, including relations and sprint membership, and assign someone to rebuild those by hand with a date for completion. Ask OpenProject to confirm the current behavior for each field, because beta tooling can change between releases.
Base the migration path on the test results together with the field list. Confirm how imported users and groups map to accounts in your target instance, since planned work can only be assigned to people who exist there. If the test shows that planning dates or assignments are lost or altered, decide whether the team will rebuild them before go-live or run the old and new plans side by side for a defined period. Put that decision, and the owner of each rebuild task, into the written scope before the production import is scheduled.
How the team planner connects to the rest of the stack
OpenProject's team planner works on work packages, so its connections run through the same identity, file and reporting layers as the rest of the project. The integrations below decide who can sign in, where planning documents live and how planned effort reaches portfolio and cost views. Confirm each requirement against the official docs for your target version before you commit to a design.
Single sign-on protocols
OpenProject lists SSO through SAML, OIDC, CAS, Kerberos and Okta as Enterprise features, so a team planner used by people across several systems inherits whichever sign-in model you choose. Decide early whether planners sign in through your workforce identity provider or through local accounts, and whether session lifetimes match your policy. Check which protocol your identity provider supports and which OpenProject version your deployment targets before you configure anything.
LDAP group synchronization
LDAP group synchronization is also an Enterprise feature. Directory groups can drive membership in projects, which determines who appears in the planner and who can be assigned work. Map directory groups to project roles on paper first, then confirm with the vendor how removed users and nested groups are handled in the version you run. Unclear mappings show up as people who can see work they should not see, or as people who cannot be assigned tasks at all.
Nextcloud file linking
The Nextcloud integration is available in the Community edition. It links Nextcloud files and folders to work packages and can manage project folders automatically, so estimates, specifications and schedules stay attached to the tasks they describe. Confirm which Nextcloud versions the integration supports for your release. If your team needs single sign-on through OpenID Connect for this integration, note that it is an Enterprise add-on and price it separately.
Portfolio rollups across teams
Portfolio and program management groups projects so that planned work from several teams can be viewed together. Team planner dates and assignments feed the aggregated progress that these views show. Portfolio grouping requires the Premium or Corporate Enterprise plan, so confirm that tier before you design cross-team views. Ask the vendor how planner scheduling data appears in portfolio reports for your target version, and test it with a sample program before rollout.
Time tracking and cost baselines
Time logging, unit costs and budgets determine whether planned effort can be compared with booked effort. Planner assignments give the baseline, and time entries show what was spent against it. Ask who maintains rates and budgets, and whether finance needs exports for billing or controlling. Confirm which of these features are included in the edition you plan to run, since some cost reporting depends on the plan tier.
Questions teams ask before hiring help with the team planner
Is the team planner included in the free OpenProject Community edition?
The team planner is not named among the Community edition features on the OpenProject pricing page, which lists work packages, Gantt charts, agile boards, time tracking and dashboards with community support. Confirm on that page, for the plan you intend to run, whether the team planner is included before you scope the work. If it requires Enterprise, the plan you need depends on your user count and on the Enterprise features your teams use. Ask the partner to state the plan requirement in the written scope, so the licence cost is visible before the build starts. Community is free software under GPL-3.0, but free licensing does not cover implementation, hosting, migration or support labor.
What drives the cost and timeline of an OpenProject team planner project?
Scope is the largest driver: the number of projects, the planner views you need, the number of teams, and whether roles and workflows change. Migration adds effort when planner data comes from another tool. The OpenProject Jira Migrator, for example, imports from Jira Data Center 10.x and 11.x only, not Jira Cloud, and is in beta with documentation advising test setups only. Identity and pilot size also matter, because single sign-on and LDAP group sync are Enterprise features. For licences, the pricing page lists Enterprise on-premises per named user per month: 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. Implementation is typically one-time, while licences recur. Ask each quote for phased deliverables, the user count, and what is excluded.
What does the planner project need from our own team?
The work depends on named owners. You need a product owner who makes role and permission decisions, a platform owner for hosting and upgrades, an identity contact for single sign-on or directory groups, and a sponsor who signs off the pilot. Provide test data that reflects how your teams schedule and reassign work, such as sample or anonymized projects, work packages, users and planning scenarios. Give the partner access to the target hosting environment, the database server and the identity provider settings, within your change process. Make role decisions early, because planner visibility depends on them. The written scope should list each dependency and the person responsible for it, so delays show up in the plan.
Can our internal team set up the OpenProject team planner alone?
Yes, if your team has the skills and time and the scope is small. Installation is documented: Docker is the recommended method, and packages exist for 64-bit Linux, with Kubernetes and Helm charts for horizontal scaling. The requirements are specific, including PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions. The harder parts are usually role design, identity integration, migration from another tool, backup restore testing and upgrade testing. Check whether the same people can cover Linux, database, identity and project management work during the same period. A partner is useful when a skill is missing or the deadline is fixed. Running a short internal pilot first will show you how much effort the full rollout needs before you decide.
How do OpenProject upgrades affect the team planner setup?
Upgrades can change planner behavior, so read the OpenProject release notes for every release between your current version and the target before you schedule one. Check each note for database migrations, changed requirements and changes to planning views. Test the upgrade on a copy of production data first, including planner views, custom fields and the roles teams depend on. Keep current backups of the database and file storage, and confirm that your PostgreSQL version still meets the supported minimum for the target release. Agree in the written scope who signs off a production upgrade and whether upgrades are covered after go-live. DeployOpen offers ongoing support, upgrades and continuous testing as retainers.
Do we need single sign-on or LDAP before the planner goes live?
Not always, but decide before the pilot, because the choice changes the build. The OpenProject pricing page lists single sign-on through SAML, OIDC, CAS, Kerberos and Okta, along with LDAP group synchronization, as Enterprise features. If your teams already sign in through a corporate directory, group membership can control who sees and plans which work, which reduces manual role upkeep. Confirm on the pricing page which features your chosen plan includes. Provide the identity provider details, the group naming scheme and a set of test accounts for each role. Limit local administrator accounts to break-glass use, and record that decision in the scope so reviewers can check it.
What hosting does an OpenProject team planner need to run reliably?
Settle the platform before you configure the planner. The system requirements name Docker as the recommended installation, with .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 vendor'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. Treat these as starting points and check them against your own usage. Plan for backups, a PostgreSQL server with the required extensions, TLS termination and monitoring. DeployOpen deploys in your own cloud accounts, data centers or air-gapped networks.
How DeployOpen scopes and delivers an OpenProject team planner rollout
DeployOpen plans, implements and supports OpenProject inside your own cloud accounts, data centers or air-gapped networks. For the team planner, we start by confirming which edition and plan your users need, then agree the scope in writing before work begins. Engagements are fixed-scope, so deliverables and timelines are set out in advance.
How we scope
- Confirm which OpenProject edition and Enterprise plan the team planner requires for your user count before quoting
- Map which projects, teams and resource views will use the planner, and which will stay on Gantt or boards
- Agree the written scope, deliverables and timeline before work starts, with ongoing support available as a retainer
How we build
- Deploy OpenProject in your infrastructure with the install method, database and sizing confirmed during scoping
- Configure project roles and permissions so planner access follows your team structure and existing access model
- Test scheduling and reassignment with sample teams and work packages, then record results in the test report
How we hand over
- Document configured roles, planner settings, backup routines and the upgrade steps your administrators will follow
- Hand over a runbook covering user administration, planner troubleshooting and recovery from backup
- Walk administrators and team leads through planner use, reassignment rules and where to raise issues
How we support
- Plan OpenProject upgrades in your environment, with database checks run against the release notes before each change
- Keep backups and restore tests current, so planner data can be recovered if an upgrade or host fails
- Offer retainer support for patching, monitoring and changes to planner configuration as your teams evolve
