OpenProject meetings management: keeping decisions linked to work packages
OpenProject meetings management lets a team run recurring meetings with agendas tied to work packages, record minutes, and share meeting calendars through subscriptions, so each decision stays attached to the work it affects. Teams usually implement it when steering, planning or review meetings keep producing decisions that live in email threads and slide decks, where the people doing the work cannot easily find them. If your team cannot trace a decision from the meeting to the work package it changed, this module addresses that gap.
This page covers what the meetings module does according to the OpenProject documentation, the configuration choices you make, the data you need to prepare, the integrations that touch meeting content, the factors that drive effort, and how rollout and handover work. Before you scope anything, confirm in the current OpenProject documentation which edition includes meetings management. The Community edition is free and documents work packages, Gantt charts, agile boards, time tracking and dashboards, but the meetings feature is not listed in that set, so check its availability on the current feature pages. If it sits in an Enterprise plan, that plan's per-user pricing becomes part of the cost picture, and the pricing page should be checked at the time of quoting.
The first decisions are organizational rather than technical. Choose which recurring meetings move into OpenProject, name an owner for each agenda, and agree on a minutes template that records decisions, owners and due dates in a consistent form. Decide who can see meeting content, because minutes often hold commercial or personnel information that a project's broader membership should not read. Confirm how the documented permissions model handles meeting visibility, editing rights and guest participants, since these settings determine whether the record can be trusted later. Write these choices down before configuring anything, so the administrator and the meeting owners work from the same rules.
Effort depends mainly on the number of recurring series, the amount of historical material you want to bring in, and how many meeting documents live outside OpenProject. Past decisions in email or slides are usually the largest unknown, so ask any partner to state whether historical import is in scope and how it will be done. If meeting documents are stored in Nextcloud, OpenProject's documented Nextcloud integration links files and folders to work packages, and you should test that link with real meeting attachments before rollout. For the rollout, pilot one recurring meeting with its owner, check that each decision creates a visible work package link, and expand only after the pilot shows the minutes are being kept.
Handover should leave the team able to run the process without the implementer. Ask for written documentation of the configuration, the minutes template, the permission rules and the integration settings, along with a short session for meeting owners and project administrators. Plan for the main risks: agendas that go stale, decisions recorded without a linked work package, and minutes that stop being updated after the first few meetings. Each risk needs a named owner and a periodic check. When requesting a quote, ask which edition and plan the work requires, which items are one-time setup, which items recur, such as upgrades and support, and how historical data import is priced and scoped.
What OpenProject meetings management does
The meeting capabilities OpenProject documents center on three things: agendas linked to work packages, minutes recorded for each meeting, and calendar subscriptions for participants. The cards below set out what each one does, the decisions it forces on your team, and what to confirm in the release notes and module documentation for the version you run.
Agendas linked to work packages
Agenda items can reference the work packages a meeting discusses, so each topic points to a task with its own owner, status and history. For recurring meetings, this keeps the agenda tied to the work it reviews. Check whether your version supports linking agenda items to work packages directly, and confirm how those links display to participants who lack permission to view the project.
Minutes kept with each meeting
Minutes belong with the agenda they record, so outcomes can be read beside the topics they answer. Decide who writes the minutes, who can edit them after the meeting, and how long they are retained in your backups. Confirm in the module documentation which minutes features your version provides, including versioning and export, before you write a procedure around them.
Calendar subscriptions for participants
Participants can subscribe to meeting schedules in their own calendar client, so recurring sessions appear alongside their other commitments. Before rollout, confirm which calendar formats your version exposes, whether subscribers see schedule changes, and what each subscriber can see when a meeting is restricted. Test with an external guest and with a user from a different group.
Action items as work packages
Decisions that create follow-up tasks should become work packages, so ownership, due dates and progress are tracked in the same place as the rest of the project. Agree the convention before the first meeting: who creates the item, which type and status it starts with, and whether the work package refers back to the meeting. Verify how that reference behaves in your version's documentation.
Version check before rollout
Meeting features may depend on the modules enabled and the plan in use, and their behavior can change between releases. Read the release notes for every version between your current and target release, then check the meetings module documentation. Confirm each capability in a test instance built on the same version you plan to run in production, rather than relying on a product overview.
Which meeting configuration choices fit which teams
This table compares the main meeting configuration decisions in OpenProject, with the team setup each option suits and what it means for permissions and visibility. Read each row as a question to settle before rollout, then confirm the stated behavior in your own OpenProject version and role setup before you rely on it.
| Decision and option | When it fits | Permissions and visibility | Confirm in your version |
|---|---|---|---|
| Recurring series per project | One team with its own standing meetings and a single set of work packages | Visibility generally follows project membership, so non-members usually do not see the series | Which project roles can create and edit series, and whether non-members see them |
| Recurring series per program | Steering or program boards that need one agenda across several projects | Attendees need access to each linked project, and access follows the program setup | Whether program-level members see the series without membership in each project |
| Agenda edited by the organizer only | Chair-led meetings where one person controls the order of items | Only users with edit rights on the meeting change the agenda | Whether attendees can view the agenda before the meeting and who can edit it during the meeting |
| Agenda open to attendee contributions | Reviews and retrospectives where participants bring their own topics | Contributors may need more than read access, which widens who can change the meeting record | Whether attendees can add items without full edit rights and how added items are attributed |
| Minutes kept per occurrence | Decisions tied to a specific date and reviewed as a dated record | Each occurrence keeps its own record, so readers need access to that occurrence | Whether people who only see the series can also open past occurrences and their minutes |
| Minutes kept per series | Ongoing logs where one running record suits the team | Access to the series usually covers the whole log, so sensitive entries need a separate place | How earlier entries are versioned and who can read or restore them |
| Minutes editable by attendees after the meeting | Teams that correct and complete records together | More editors means more people can change decisions, so the change history matters | Whether edit rights lock after a set point and whether the history shows editor names and times |
| Minutes editable by the author or organizer only | Formal or regulated records where one accountable owner signs off | Fewer editors reduce accidental changes but add a dependency on one person | How locking works, whether an audit trail exists, and how corrections are recorded |
| Calendar subscription for project members only | Internal teams that want meetings in their own calendar client | The subscription should reflect the subscriber's project permissions, so confirm how it is scoped | Whether each subscriber sees only meetings they could open in the web interface |
| Calendar subscription shared with outside people | Clients, suppliers or partners who attend meetings but do not hold accounts | An outside subscriber may see titles, times or details that the link exposes, so limit what the link carries | What an external subscriber can see, how to revoke a shared link, and whether it can be limited to titles and times |
How agendas and minutes stay linked to work packages
The working pattern has three linked records. An agenda item points to an existing work package, the minutes record the decision taken on that item, and a follow-up work package carries the resulting action into delivery. When this holds, anyone who opens the work package can see which meeting raised it and what was decided, and anyone reading the minutes can click through to the work. The meetings module is meant to support this chain, but the exact behavior depends on your OpenProject release and edition. Before relying on it, confirm in the release documentation whether the agenda reference is stored on the work package side, the meeting side, or both, because that determines where people will look for history.
Three habits make the chain hold up over months. First, agree a naming convention for follow-ups, such as a meeting identifier, a decision number and a short action phrase (illustrative: "MTG-07 D3 confirm vendor SLA draft"). Choose a scheme your team can type and search. Second, decide who creates follow-ups. A single note taker is usually the simplest option: they create the work packages during or immediately after the meeting and link each one to the decision it implements. Third, assign each follow-up to one named person who is accountable for it, so the next meeting has a specific person to ask about status. Settle these three rules before the first pilot meeting, and write them into the meeting guidance your attendees receive.
Open actions need a review point, or the links become an archive nobody reads. Start each meeting by listing the open follow-ups linked to the previous meeting's decisions. Filter by owning project and status, then mark each item as closed, re-planned with a new date, or escalated. Re-planned items should keep their original link so the history of the decision stays intact. Also check that every attendee can see the work packages they are expected to discuss. If a follow-up sits in a project an attendee cannot access, the link will not help that person in the room, so agree access with the project administrator before the meeting begins.
The behavior to test in a pilot is what happens to the link after the work changes. Move a linked work package to another project, rename it, change its type, and close it. After each change, open the meeting and the minutes to see whether the agenda reference, the decision text and the follow-up link still resolve. Also confirm that assignees receive notifications for follow-ups created from minutes, and that calendar subscribers can see the meeting without seeing restricted work packages. Record the results in a short table with the test, the expected result and the observed result. If any link breaks after a move, adopt a team rule that work packages are moved only after their open actions are closed, and keep that rule in the meeting guidance.
Rollout sequence for meetings management
This sequence takes OpenProject meetings management from a confirmed edition and configuration to a rollout across your projects, with each step closing on a written output. Fixing the taxonomy, permissions and pilot results first means the wider rollout repeats a tested setup.
Confirm the module and edition
Before any configuration, confirm with OpenProject which release you will deploy and whether meetings management is included in the Community edition or requires an Enterprise plan for that version. Check the release notes for the target line and record the answer alongside your deployment version. Ask whether any related add-ons, such as single sign-on, are needed for your identity setup. The step is done when a signed note states the version, edition, licensed user count and any plan gaps, and the team has accepted it.
Define meeting types and series
Work with the project owners to list the recurring meetings that matter, such as steering reviews, sprint or delivery reviews and team stand-ups. For each type, record the purpose, owner, recurrence pattern, standard agenda items, the work package types expected in the agenda, and the minutes template. Agree naming rules so series are easy to find in calendars. The step closes with a signed-off meeting taxonomy that a project owner can apply without asking the platform team how to set up each series.
Set roles and permissions
Translate the taxonomy into roles. Decide who creates and edits meetings, who can add agenda items linked to work packages, who records minutes and outcomes, who can view meetings across projects, and who can administer templates. Build a permissions matrix that maps each role to each meeting action and to the project membership it depends on. Test the matrix with test accounts for each role, including a user outside the pilot project. The step is done when the matrix is signed off and every test account behaves as the matrix says.
Configure a pilot project
Choose one active project with a willing owner and enable the meetings module there only. Create the agreed series, apply the templates, and confirm that agenda items link to real work packages and that minutes can record decisions and follow-up actions. Check the calendar subscription for one member's calendar client, and confirm notification behavior with the pilot members. Keep a configuration record of every setting changed. The step is done when a checklist shows each series, role and integration point has been tested end to end.
Run two or three real meeting cycles
Run the pilot series through at least two or three actual meeting cycles. For each cycle, the owner prepares the agenda in OpenProject, the meeting takes place, minutes are captured in the platform, and resulting work packages are updated during or after the meeting. Log what took longer than expected, which fields were skipped, and any permission or calendar problems. The step is done when the cycle log is complete for every meeting and the open issues are listed with an owner and a status.
Hold a pilot retrospective and adjust
Gather the pilot owner, the attendees and the platform administrator for a retrospective built on the cycle log. Review the taxonomy, templates, permissions matrix and calendar behavior, and decide which changes to make before wider use. Record each decision with its reason and update the configuration record and matrix to match. The step closes with a signed pilot retrospective that lists the changes adopted, the changes deferred and the owner of each. Do not extend the rollout until that document exists.
Extend to other projects with a checklist
Extend meetings management to further projects in batches, using a rollout checklist that covers project enablement, series creation from the approved taxonomy, role assignment, calendar subscription guidance, a short user briefing and a named support contact. Confirm each batch against the checklist before its first meeting cycle. Keep the permissions matrix as the reference for any exception request. The step is done when every planned project has a completed checklist, a named owner and a recorded first meeting, and the rollout log is handed to the operations team.
Data setup and migrating existing meeting notes
Before go-live, settle the data that meetings depend on: users and groups, projects, work package types and statuses, and any action lists that already exist. Meeting records link to work packages, so the work package types, statuses and project structure must be final before you import or type in a single minute. Changing a status or type after meetings are recorded can leave older notes pointing at values that no longer match your process. Decide who owns each project, which groups can create meeting records, and whether recurring meetings belong to a program-level project or to each team project. Write these decisions down in the configuration record, because they determine how the meetings module behaves for every user. Users and groups deserve the same care. Confirm how accounts will be created and deactivated, whether group membership will come from a directory, and which roles may edit minutes or mark action items complete. Enterprise single sign-on and LDAP group synchronization are Enterprise features, so confirm with OpenProject that your plan includes them before you design group-based access. Ask your identity team to supply a clean list of active staff and contractors, since importing stale accounts into a meetings history creates confusion when people are later assigned follow-up actions. For existing work, the OpenProject Jira Migrator is the documented path for moving projects, issues, versions, custom fields, users, groups, statuses and types from Jira Data Center 10.x and 11.x. It does not support Jira Cloud. The migrator is in beta, and the documentation advises using it only in test setups, so run it against a copy of your data and validate the results before any production decision. Issue relations and sprint assignments are listed as coming soon, and workflows and permissions are planned for later. Any action items that depend on relations or sprints will need manual reconciliation after import. The migrator is not documented as moving meeting records. Existing minutes in other tools, whether wiki pages, documents, spreadsheets or a meeting product, therefore need a separate plan. For a small archive, manual transfer into agendas and minutes may be enough, with the most recent decisions carried over and older records kept in a read-only archive. For a larger history, a scripted import is possible, but confirm the target data model with OpenProject first, then test the script in a non-production environment that matches your production version and database. Check that meeting dates, attendees, links to work packages and attachments survive the transfer. Finally, ask for a written verification list before cut-over. It should include a sample of imported projects and work packages compared with the source, user and group counts reconciled against the identity source, a check that every action list item has an owner and a status, and a restore test of the database backup taken before the import. Treat any unresolved gap as a go-live blocker, and record which gaps were accepted, by whom and with what follow-up.
What drives meetings management effort and cost
This table lists the main effort and cost drivers for OpenProject meetings management, with whether each one is paid once or recurs and what reduces it. Use it to count your own inputs before asking for a written, fixed-scope quote, since the drivers interact and the largest ones are usually team count and user count.
| Driver | Why it changes effort or cost | One-time or recurring | What reduces it |
|---|---|---|---|
| Teams and recurring series | Each team with its own recurring series needs a meeting template, agenda structure and calendar subscription set up and checked. | Setup is one-time per series; new teams and series recur over time | Use one standard template per meeting type and onboard teams in batches. |
| Existing meeting records to move | Past agendas and minutes must be mapped to the right projects and work packages, and this mapping is usually checked by hand. | One-time | Move only active series and recent records, and agree in writing which older records stay in the source system. |
| Users and roles | Each role, such as organizer, attendee or administrator, needs permission design and testing before rollout. | Design is one-time; role changes recur with staff turnover | Keep the role count small and confirm which users need edit rights and which only read minutes. |
| Named-user licensing (Enterprise) | Enterprise on-premises is priced per named user per month: Basic at 5.95 euros, Professional at 10.95 euros (25-user minimum), Premium at 15.95 euros (100-user minimum), Corporate on request (OpenProject pricing). | Recurring monthly per named user | Confirm which Enterprise plan includes the meetings features you need, and count only the users who need them. |
| SSO and directory requirements | OpenProject lists SAML, OIDC, CAS, Kerberos and Okta single sign-on, plus LDAP group synchronization, as Enterprise features (OpenProject pricing). | Integration is one-time; group and certificate upkeep recurs | Map directory groups to project roles before go-live and confirm the chosen protocol with your identity provider. |
| Calendar subscriptions for external participants | Feeds that reach people outside your network need an access and exposure review, and each feed adds a point to check. | Review is one-time; new external series recur | Limit feeds to series that external parties need and agree the access model with your security team. |
| Hosting footprint | 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). | Infrastructure is recurring; sizing is one-time | Size to active users rather than total headcount and confirm the figure against your expected load. |
| Database prerequisites | OpenProject requires PostgreSQL 16 or later and the pg_trgm, btree_gist and unaccent extensions (OpenProject system requirements). | Setup is one-time; upgrades recur with each release | Use a database that already has the extensions and plan upgrades alongside OpenProject release cycles. |
| Quote basis | A quote is only comparable when it states the counts for each driver above, so the scope and deliverables are clear before work starts. | One-time for the engagement; support can recur as a retainer | Ask for a written, fixed-scope quote with these counts stated, not an estimate. |
How meetings connect to files, identity and calendars
A meetings rollout reaches beyond OpenProject itself. Agendas, minutes and attachments depend on where files live, who can sign in, which groups see a meeting, and how participants get sessions into their calendars. The cards below mark each connection, the edition that provides it, and what to confirm before you scope the work.
Nextcloud file links and project folders
The Nextcloud integration, available in the Community edition, links Nextcloud files and folders to work packages and can manage project folders automatically. For meetings, this is where agendas, minutes and attachments can sit beside the decisions they record. Before you build, decide who owns the folder structure, how folders map to projects, and what happens to links when a file is moved or renamed in Nextcloud. Confirm supported Nextcloud versions in the integration documentation for your OpenProject release.
OpenID Connect sign-in for Nextcloud
Single sign-on for Nextcloud through an OpenID Connect provider is an Enterprise add-on, so it needs an Enterprise plan in addition to the Nextcloud setup. Without it, people sign in to Nextcloud with a separate Nextcloud account, which means a second set of credentials to create, reset and remove when someone leaves a meeting group. Confirm the add-on and plan requirements with OpenProject before you design identity. Decide whether one identity provider will serve both OpenProject and Nextcloud.
OpenProject single sign-on protocols
OpenProject lists single sign-on with SAML, OIDC, CAS, Kerberos and Okta among its Enterprise features. Participants who sign in through your identity provider reach meeting pages without a local OpenProject password, and account removal follows the identity source. Choose the protocol your identity provider already supports, then test it with a pilot group that includes any external guests you invite. Confirm which options your plan includes on the current pricing page.
LDAP group synchronization for meeting access
LDAP group synchronization is also listed among OpenProject's Enterprise features. Meeting access usually follows project membership, so the groups in your directory determine who can see agendas, minutes and attendance. Map directory groups to OpenProject roles before rollout, and agree on who approves changes to those groups. Confirm how group changes propagate, how often synchronization runs, and how nested groups are handled in the documentation for your version.
Calendar subscriptions for participants
Participants can subscribe to meeting calendars so scheduled sessions appear in the calendar apps they already use. Calendar handling is where meetings most often drift from the plan, because clients differ in how they display updates, cancellations and time zones. Confirm which clients are supported, how changed or cancelled sessions sync, and how recurring series behave in the documentation for your OpenProject version. Test with the calendar apps your participants actually use.
Confirming the edition each meeting feature needs
Before you design recurring meetings, confirm which OpenProject edition each meeting feature requires. The answer decides whether the build can stay on the free Community edition or needs an Enterprise subscription, and it changes the cost of the whole project. OpenProject's pricing page describes the Community edition as free and lists work packages, Gantt charts, agile boards, time tracking and dashboards, with community support. Meeting functions such as agendas linked to work packages, minutes, recurring meeting series and calendar subscriptions are not named in that list, so do not assume they are included. Build a short register with one row per feature in your design, and record the edition that the module documentation states for each one.
The Enterprise on-premises plans are priced per named user per month. OpenProject's pricing page lists Basic at 5.95 euros and Professional at 10.95 euros per user per month, each with a 25-user minimum. Premium is listed at 15.95 euros per user per month with a 100-user minimum, and Corporate is available on request for 250 or more users. These are list prices that OpenProject publishes, and they change over time, so treat them as a starting point and confirm the current figures before budgeting. Ask whether a minimum applies to the whole subscription or to each tier, and whether the meeting features in your register sit in the tier you are pricing.
Turn the register into three actions. First, test each feature in a non-production OpenProject instance on the exact version you plan to deploy, and note the result beside the documented edition. Second, check the release notes for that version, because a feature can move between editions or change behavior between releases. Third, request a written quote that maps each required feature to a tier, the number of named users and the minimum that applies. Keep the licence line separate from configuration work, since the licence recurs each period while DeployOpen's configuration work is one-time and quoted from the written scope. Revisit the register at each planned upgrade.
Questions teams ask before hiring help with meetings management
What drives the cost of a meetings setup on OpenProject?
Cost comes from four places: the OpenProject licence, the labor to configure it, the infrastructure it runs on, and support after go-live. The Community edition is free, but Enterprise on-premises is priced per named user per month: Basic at 5.95 euros and Professional at 10.95 euros (Professional has a 25-user minimum), Premium at 15.95 euros with a 100-user minimum, and Corporate on request for 250 or more users, according to OpenProject's pricing page. Licences recur monthly for as long as the seats are kept. Configuration work such as agenda templates, meeting series, roles and calendar setup is mostly one-time, although later changes to the meeting taxonomy add effort. Infrastructure and maintenance recur. Cost rises with user count, the number of integrations such as SSO and LDAP group sync, and how much custom structure each meeting series needs. Ask any partner for an itemized written scope that separates one-time labor, licence tier, hosting assumptions and any recurring support.
How long does a pilot to rollout take for meetings management?
No single duration fits every organization, so the timeline should be agreed in the written scope rather than assumed from someone else's project. The main drivers are the number of teams and recurring meeting series in the pilot, how quickly named owners agree on a meeting taxonomy, whether identity and calendar access are approved on time, whether a test environment is available, and how many users join each rollout wave. A pilot should run long enough to cover a full meeting cycle, so you can see whether agendas linked to work packages, minutes and calendar subscriptions behave as expected. Rollout waves then follow what the pilot shows. Ask for named milestones and a decision gate at the end of the pilot, so each stage has a clear go or no-go point.
What does our team need to provide before meetings work starts?
Your team needs to provide four things before build work begins. First, named owners for the meeting process, the project sponsor and the people who approve changes to templates and roles. Second, a meeting taxonomy that lists meeting types, recurrence patterns, required attendees and the work package types each meeting should link to. Third, access to identity and calendar systems, including the directory or SSO provider you want OpenProject to use and the calendar service that subscriptions will read from, with approvals in place for test accounts. Fourth, a test environment that mirrors the production setup closely enough to try agendas, minutes and subscriptions with realistic but non-sensitive data. Missing any of these usually pushes work into later phases, so confirm availability in the scoping call and record it in the scope document.
Can our internal team set up meetings management without outside help?
A capable internal team can often do this alone, provided it confirms a few things first. The team should be comfortable administering Linux servers, PostgreSQL and either Docker-based or packaged installs. OpenProject's system requirements list Docker as the recommended installation method, 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. PostgreSQL 16 or later is required, along with the pg_trgm, btree_gist and unaccent extensions. Confirm the edition that includes the meetings features, the user count against the sizing guide, your SSO and LDAP needs, and whether you have an OpenProject administrator who has run an upgrade before. If any of these are unclear, a short assessment can answer them before you commit.
Can existing meeting minutes be migrated into OpenProject?
The documented migration path does not cover meeting minutes, so confirm this with the vendor before assuming it is possible. The Jira Migrator imports projects, issues, versions, custom fields, users, groups, statuses and types from Jira Data Center 10.x and 11.x, not Jira Cloud. It is in beta, and the documentation advises using it only in test setups. Issue relations and sprint assignments are listed as coming soon, and workflows and permissions come later. A practical workaround is to keep minutes as files in Nextcloud, which OpenProject's Nextcloud integration can link to work packages in the Community edition. Whatever route you choose, test it in a non-production environment first, check that links and attendee lists survive the move, and agree the approach in writing before any historical data is moved.
Which OpenProject edition features must we confirm before buying licenses?
Confirm the meetings features first, because the supplied facts do not state which edition includes them, and the answer decides your licence tier. Then check the Enterprise features your design depends on. OpenProject lists single sign-on through SAML, OIDC, CAS, Kerberos and Okta, LDAP group synchronization and custom branding as Enterprise features. The Nextcloud SSO through an OpenID Connect provider is an Enterprise add-on, while the Nextcloud file linking is available in the Community edition. Also confirm the per-user pricing structure, including the Professional 25-user minimum and the Premium 100-user minimum, and how the Corporate tier is quoted for 250 or more users. Get these answers from OpenProject in writing and attach them to the purchase order, so the licence count matches the features you actually need.
What should engineers check about calendar subscriptions and identity?
Engineers should check three areas before go-live. First, calendar subscriptions: confirm which users can subscribe, what each subscription exposes, how often clients refresh, and how removed or rescheduled meetings appear in the subscribing calendar. Second, identity: decide whether users sign in through SSO or local accounts, and if you want group-based access, confirm that LDAP group synchronization is included in your chosen edition. SSO and LDAP sync are listed as Enterprise features. Third, database and hosting: PostgreSQL 16 or later with the required extensions, and capacity sized to your user count using the sizing guide, which suggests 4 cores and 4 GB RAM for up to 200 users. Test each path in the test environment with a small set of accounts, and record the results so the operations team can repeat the checks after upgrades.
How DeployOpen works on this
DeployOpen plans OpenProject meetings management as part of a written, fixed-scope engagement, starting from how your teams run recurring meetings and which work packages those meetings should link to. The build runs inside your own infrastructure, whether cloud accounts, data centers or air-gapped networks. Ongoing support, upgrades and testing are available as a retainer.
How we scope
- The written scope names which teams, projects and recurring meetings move into OpenProject.
- It records how agendas link to work packages, and which meeting outputs become tasks or decisions.
- Plan requirements for meetings features are confirmed in writing before the scope is signed.
How we build
- Configure meeting settings, roles and project permissions in a staging instance before production rollout.
- Set up calendar subscription feeds and test them in the calendar clients your staff actually use.
- Test agenda-to-work-package links, minute capture and notification behavior with pilot teams.
How we hand over
- Documentation covers meeting setup, agenda conventions, and how minutes link to work packages.
- Administrators receive runbooks for installation, configuration changes, backups and access reviews.
- Knowledge transfer sessions walk your moderators and project managers through the recurring meeting workflow.
How we support
- Ongoing support, upgrades and testing are available as a retainer after handover.
- Upgrades are planned against OpenProject release notes, with a staging rehearsal before production.
- Confirm during scoping who on your side owns meeting content, permissions and calendar feed access.
