Project management software RFP questions to ask before you choose a partner
A good RFP tests a partner on five things: edition fit, what is lost in migration, how identity is wired, how upgrades are handled, and what training is included. Buyers usually arrive with a Jira instance, one or more Redmine installations or a spreadsheet estate, a hosting or sovereignty rule that rules out most SaaS options, and a requirement for single sign-on. Those constraints decide the answers, so the questions below are written to force specific answers rather than general assurances. The questions are vendor-neutral and apply equally to OpenProject, Plane and Redmine, and they should be sent to every candidate partner in the same form.
Run the evaluation in three passes. First, collect written answers to every question before any meeting, and ask each partner to name the exact edition, version and license model behind each answer. Second, script a demo around your own data: import a sample Jira export or a Redmine project, sign in through your identity provider, and perform an upgrade in a test environment. Third, check two or three references that run the platform in a comparable hosting model. Ask the partner to show which features sit in each edition, because a feature that works in a demo may depend on a paid tier you have not priced. The edition question should be answered first, since it drives licensing cost, identity options and the importer you can use.
DeployOpen is a Chainscore Labs company. It plans, implements, integrates, hardens, backs up, upgrades and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. It also runs security testing and prepares systems and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Treat any partner, including DeployOpen, that claims otherwise as a warning sign. Scope, deliverables and timelines should be agreed in writing before work starts, and any quote should follow from that written scope. The OpenProject pricing page is a useful baseline for comparing published edition terms against what a partner proposes.
Which questions reveal whether a partner can deliver project management software?
Which platform should we choose: OpenProject, Plane or Redmine?
No single platform fits every team, so the right answer depends on the methods you run, the identity model you need and how much configuration your team wants to own. OpenProject covers project and portfolio management with Gantt charts, work packages and agile boards, and it is licensed under GPL-3.0. Plane is licensed under AGPL-3.0 and focuses on issue and cycle tracking for software teams. Redmine is a long-standing, GPL v2 issue tracker with flexible roles and a wiki, and it has no paid edition. A good partner answers with a short scoring exercise tied to your workflows, then explains the trade-offs for each candidate. Ask them to show a working demo of your three most common workflows on the shortlisted platforms.
Do we need an Enterprise edition, and what does it cost per user?
You need an Enterprise edition when a requirement sits behind a paid tier, such as SSO, directory sync or advanced audit logs. For OpenProject, single sign-on (SAML, OIDC, CAS, Kerberos, Okta), LDAP group synchronization and custom branding are Enterprise features, sold per named user per month. The OpenProject pricing page lists 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. For Plane, the Community Edition is free, but moving to a paid plan requires the Commercial Edition with a license key. Plane's pricing page shows Pro at 6 to 8 US dollars and Business at 13 to 15 US dollars per user per month. Confirm current prices with each vendor, since these figures change.
Can our Jira data be migrated, and what gets lost?
Migration depends on your Jira deployment type, so confirm which product you run before comparing tools. The OpenProject Jira Migrator imports from Jira Data Center 10.x and 11.x, not Jira Cloud, and it is in beta, with the documentation advising use only in test setups. Plane's Jira importer supports Jira Cloud as well as Jira Server and Data Center, and it is available on Plane Cloud and on all plans of the self-hosted Commercial Edition. Redmine has no supported Jira importer: its third-party migration scripts are described as neither tested nor supported. Ask the partner to produce a field-by-field mapping of workflows, custom fields, attachments, history and permissions, and to run a trial migration that lists every item that did not transfer.
How is single sign-on and LDAP wired, and which edition is required?
Single sign-on and LDAP are configured in the platform, but the protocol and the edition decide what is possible. In OpenProject, SAML, OIDC and LDAP group synchronization require the Enterprise edition, and the partner should configure the identity provider's redirect URIs, attribute mapping and group-to-role rules. On self-hosted Plane, SAML and OIDC are available from the Pro plan upward, while LDAP support is an Enterprise feature. Redmine supports multiple LDAP authentication sources natively, and single sign-on typically depends on plugins that the partner must select, test and maintain. A strong answer names the identity provider you use, the attributes you map, the test accounts and the rollback plan if the directory is unavailable.
What hosting and sizing do we need for our user count?
Hosting depends on user count, database choice, and how many services you run around the platform. 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, and it requires PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions. Plane's self-hosted stack uses PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible object storage, and it can run on Docker Compose or Kubernetes with Helm. Redmine supports PostgreSQL, MySQL 8.0 to 8.4 and SQL Server, but its installation guide says SQLite is not suited to multi-user production use. Ask for a written architecture with backup, high availability and monitoring choices, and confirm that the sizing reflects your real concurrency, not only named users.
How are upgrades handled, and who keeps versions supported?
Upgrades are a recurring cost and should be part of the contract, not an afterthought. Redmine's upgrade procedure requires backing up the database and uploaded files, copying configuration, uploads and third-party plugins to the new installation, running db:migrate and redmine:plugins:migrate, then clearing the cache and restarting. Redmine 7.0.x is fully supported, 6.1.x receives only bug fixes and security updates, 6.0.x receives only important security updates, and 5.1.x and older are unsupported. OpenProject ships frequent releases, such as 17.9.0 on September 30, 2026 and 17.9.2 on October 15, 2026, so ask how patch releases are tested against your plugins and configuration. Confirm the vendor's current support windows in writing before signing.
What training is included, and what can our team run alone?
Training should be written into the scope, with named audiences and deliverables, because the cost of a platform is mostly people's time. Ask the partner to list training by role: administrators who manage the instance, project managers who configure templates and reports, and general users who log work and track issues. A good answer includes recorded or live sessions, written runbooks for backups, upgrades and user provisioning, and a handover checklist that proves your staff can perform those tasks. Also ask what support remains after go-live, and whether that support is a fixed-scope engagement or an ongoing retainer. DeployOpen offers implementation and support as fixed-scope engagements and retainers, and the exact training content is set in the written scope.
How to compare OpenProject, Plane and Redmine in the RFP
OpenProject is licensed under GPL-3.0 and offers a free Community edition with work packages, Gantt charts, agile boards, time tracking and dashboards. Single sign-on through SAML, OIDC, CAS, Kerberos and Okta, LDAP group synchronization and custom branding sit in the Enterprise on-premises tiers, so an RFP should confirm the edition before it confirms the feature list. Ask the vendor which tier includes each identity capability, how the per-user pricing published on its pricing page applies to your headcount, and whether the Jira importer covers your Jira deployment.
- Edition boundary: Ask which SSO protocols, directory sync and branding are included in the tier you are quoting, and whether they are priced per named user per month.
- Jira source: Confirm whether your instance is Jira Cloud or Data Center 10.x or 11.x, because the OpenProject Jira Migrator documents Data Center only and is in beta.
- Database: Ask for PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions in the platform design.
- Sizing: Request the expected concurrent user count and the matching core and memory sizing from the system requirements.
- Deployment: Ask whether you need Docker, packaged installs on a supported Linux distribution, or Kubernetes with Helm for horizontal scaling.
A closer look is warranted if the vendor cannot name the edition that includes SSO, if the migration plan relies on the beta importer for production data, or if the proposed operating system is outside the packaged list.
Plane offers three self-hosted editions: Community, Commercial and Airgapped. Community is licensed under AGPL-3.0 and matches the feature set of the Plane Cloud Free tier, while the Commercial and Airgapped editions are proprietary and built on separate codebases with their own release cycles. Moving a self-hosted Community install to a paid plan means switching to the Commercial edition and applying a license key, so an RFP should treat edition migration as a planned step rather than a configuration change. Agile cycles are a core part of the product, so test how they behave in your delivery model.
- Edition path: Ask how a Community install moves to the Commercial edition, whether the switch requires a reinstall or data migration, and who performs it.
- Seat model: Confirm how seats are counted, including which roles are paid and how the Free plan's 12 seats are used if you start there.
- Identity tier: Ask which plan provides SAML and OIDC on self-hosted deployments, and whether LDAP and API-enabled audit logs are Enterprise only.
- Jira import: Confirm the importer covers Jira Cloud and Jira Server or Data Center on the Commercial edition plans you are buying.
- Dependencies: Ask for the PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage design, and whether each can point to a managed external service.
A closer look is warranted if the vendor treats the Commercial and Airgapped editions as interchangeable with Community, or if the air-gap requirement is not confirmed against the Airgapped edition.
Redmine is a Ruby on Rails application released under GPL v2, with multiple projects, role-based access control, issue tracking, Gantt charts, wikis, time tracking, custom fields and repository integration with Git, Subversion and other systems. It has no paid edition, so the cost of a deployment comes from hosting, implementation, plugins, upgrades and the staff who maintain it. Redmine 7.0.x is the fully supported line, while 6.1.x and 6.0.x receive more limited fixes, so the RFP should pin the version and the support window before the project starts.
- Support line: Ask which Redmine branch the vendor will deploy and how long security updates will be provided for that branch.
- Runtime: Confirm the Ruby version support for Redmine 7.0, which covers Ruby 3.2, 3.3, 3.4 and 4.0, and that JRuby is not in the design.
- Database: Ask which production database is proposed, since SQLite is not suited to multi-user production use and MySQL requires READ COMMITTED isolation.
- Identity and plugins: Ask how LDAP and single sign-on will be delivered, and which plugins are needed and who maintains them through upgrades.
- Migration: Confirm how Jira data will be moved, because the built-in importers for Trac and Mantis are not working and third-party Jira scripts are not tested or supported.
A closer look is warranted if the proposal assumes Redmine's zero license cost covers the whole project, if plugin upgrades are not in scope, or if the migration plan depends on an unsupported script.
Which partner answers should end the evaluation early
Partners who answer these questions loosely usually hide a cost, a licensing gap or an unplanned risk. Each of the six red flags below is easy to test in a written proposal, and each one tends to surface later as a budget overrun or a stalled rollout.
Enterprise prices without a named edition
A quote that says per-user Enterprise pricing without naming the product, edition or tier cannot be compared or audited. OpenProject Enterprise on-premises, for example, is priced by plan, with Basic, Professional, Premium and Corporate each carrying different user thresholds, and Plane's paid plans are a separate licensing path from its Community Edition. Ask the partner to name the edition, the plan, the seat count and the license type in the quote, then confirm the same details with the vendor.
Full Jira history without a named source
A promise to import all Jira history without stating Jira Cloud or Jira Data Center is a warning sign. The OpenProject Jira Migrator reads from Jira Data Center 10.x and 11.x, not Jira Cloud, and is documented as beta for test setups. Plane's importer covers Jira Cloud as well as Server and Data Center, but only on Plane Cloud and paid self-hosted Commercial plans. Ask which Jira product, which versions, and which objects (attachments, history, workflows) are in scope.
SSO promised on a tier without it
Single sign-on is often treated as a standard feature, but on several platforms it sits behind a paid tier. OpenProject lists SAML, OIDC, CAS, Kerberos and Okta under its Enterprise features. On self-hosted Plane, SAML and OIDC start at Pro, while LDAP and API-enabled audit logs are Enterprise features. Ask the partner to show which tier includes the protocol and directory sync you need, and to name the license file or plan that enables it.
Upgrades treated as a one-off
A partner who delivers an installation and considers the job finished has not planned for the release cadence. OpenProject shipped 17.7.0, 17.8.0, 17.9.0 and 17.9.2 within a few months of 2026, and Redmine supports only its 7.0.x line for new features. Ask how upgrades are scheduled, tested in staging, applied to plugins and billed, and whether a retainer or a fixed-scope upgrade is included.
No written rollback plan
A migration without a documented rollback path leaves the organization with no safe way back if an import corrupts project data or a permission model fails. A credible answer names the backups taken before cutover (database and uploaded files), the point at which the old instance is frozen, and the test that decides whether to roll back. Redmine's upgrade procedure, for example, begins with a database and file backup before any migration step runs. Ask for the rollback plan in writing, with owners and decision points.
Training included without a defined scope
"Training included" can mean a recorded video, a single admin session or a full role-based program, and the difference changes the rollout cost. A useful answer lists the audiences (administrators, project managers, team members), the format, the number of sessions, the language, and whether training material is handed over for the client's own use. Ask for the curriculum and the acceptance criteria before signing, so that training is measured against a defined outcome rather than attendance.
What is lost when moving Jira data to open source project management
The first check is the Jira deployment type, because it decides the migration route. The OpenProject Jira Migrator imports from Jira Data Center 10.x and 11.x, not Jira Cloud, and its documentation is in beta with a recommendation to use it only in test setups. If your projects live in Jira Cloud, ask the partner which route they will use and whether it has been tested against your exact version. Plane's Jira importer supports Jira Cloud as well as Jira Server and Data Center, but it runs on Plane Cloud and on the paid Commercial Edition, so the license choice affects the migration path. Redmine has no supported Jira importer, and its migration wiki describes third-party Jira scripts as neither tested nor supported. Confirm these points in writing before the platform is chosen.
Next, require a written loss inventory that maps each Jira object to a target object or marks it as dropped. Ask how workflows and statuses translate, since a Jira workflow with transition conditions and validators rarely maps one to one onto another tool's states. Ask which custom fields carry over with their types and options, which are converted to text, and which are discarded. Ask how attachments are moved, whether they keep their links to issues, and what happens to issue history and changelogs, including who made each change and when. Ask how Jira users, groups and watchers map to local accounts, and what happens to deactivated users whose names still appear in old history. Each answer should name the object, the outcome and the person who accepted the loss.
Do not accept cutover on a plan alone. Require a test migration of a representative project set, run against a copy of production data, followed by a reconciliation of issue counts, field values, attachment counts and sample histories against the inventory. Agree in advance which losses are acceptable and which block cutover, and assign an owner to sign off each one. Ask the partner to state whether the test uses the same importer version and database engine as production. Plan a rollback path and keep the Jira instance read-only for a defined period after cutover. Those steps cost time and need agreed scope, so include them in the written statement of work rather than treating them as optional extras.
How SSO should be wired and tested before go-live
This sequence confirms that the identity provider, protocol and edition agree before any configuration starts, then proves that sign-in, role mapping, logout and removal of leavers all behave correctly in a test tenant. The result is a documented configuration that the buyer, the partner and the identity team can all audit.
Confirm the identity provider and protocol
The buyer's identity team states which identity provider is the source of truth (for example, Entra ID, Okta, Keycloak or an on-premises Active Directory) and which protocol it will use for each candidate platform: SAML, OIDC, or LDAP for directory lookup and group sync. The partner checks that the chosen platform supports that exact protocol and version of the identity provider. Done means a one-page matrix exists that names the protocol, the identity provider and the platform for each application, signed off by the identity owner.
Confirm the edition that includes the protocol
Single sign-on and directory features are edition-dependent, so the partner checks the current edition tables before the order is placed. For OpenProject, the supplied pricing lists SSO (SAML, OIDC, CAS, Kerberos, Okta) and LDAP group synchronization among Enterprise features. For Plane, SAML and OIDC are listed from the Pro plan and above on self-hosted installs, while LDAP is an Enterprise feature. For Redmine, which has no paid edition, the partner confirms which LDAP and SSO options are native and which need a plugin, and records the plugin's maintenance status. Done means the edition, seat count and any license key are written into the scope, with the vendor's current documentation attached.
Configure a test tenant with production-like settings
The partner builds a non-production instance on the same version and hosting pattern planned for production, with a test realm or tenant in the identity provider and a small set of test accounts. Redirect URIs, certificates, metadata and clock settings are set to the test values, and the attribute mapping for name and email is documented. Done means a user can sign in through the identity provider to the test instance, and the configuration export is stored in the project's change record.
Map groups to roles and permissions
The identity team defines which directory groups correspond to platform roles such as administrator, project manager, contributor and viewer. The partner maps each group to the platform's role model and tests the result with one account per role, including accounts that belong to several groups. Redmine's role-based access control and OpenProject's group synchronization both need this check, because a mismatch grants access that nobody approved. Done means a role matrix has been tested for each account, and any unmapped group is reported and resolved before go-live.
Test sign-in, session expiry and logout
Testers sign in from the browser, from a second browser profile, and from an account that the identity provider has forced to re-authenticate, then check that sessions end when the identity provider session ends. They also check logout from the platform and from the identity provider, and confirm that API keys and personal access tokens are not left active after sign-out where the platform issues them. Done means the test script passes on each supported browser, and the results are recorded with the date and version under test.
Test account deprovisioning and access removal
The identity team disables a test account in the identity provider, and the partner verifies that the account can no longer sign in, that group sync removes it from project roles where that feature is in use, and that its open work is reassigned according to the agreed process. Where the platform keeps local accounts for break-glass use, the partner documents who holds those credentials and how they are rotated. Done means the removal test passes and the leaver procedure is written down with named owners.
Document the configuration and hand it over
The partner writes the final configuration into the runbook: protocol settings, certificate and metadata renewal dates, group-to-role mappings, the edition and seat count, and the test evidence from the earlier steps. The buyer's identity team reviews the document and the partner's engineers walk them through it. Done means the runbook is accepted in writing, the certificate and secret owners are named, and the same tests are scheduled to repeat after each platform upgrade.
How to score partner responses
This table lists the criteria to score each partner answer, the weight to give it, what a full-marks answer contains and which answers should disqualify a bidder. Use it as a scoring sheet during evaluation, and record a short reason next to every score so the decision can be defended later.
| Criterion | Weight | Full marks require | Disqualifying answers |
|---|---|---|---|
| Platform fit | High | A reasoned choice among OpenProject, Plane or Redmine tied to your methods, team size, hosting limits and integrations, with the trade-offs named | Recommends a platform without asking about methods, hosting or user counts, or cannot explain why alternatives were rejected |
| Edition clarity | High | A feature-by-feature list stating which edition each required feature sits in, the per-user cost basis and the license or activation steps | Says all features are free or leaves edition boundaries for later, or cannot name the edition that includes SSO or LDAP |
| Migration plan | High | A written inventory approach, a stated importer source version (for example Jira Cloud or Jira Data Center), a list of what does not carry over and a test cycle before cutover | Assumes a full history transfer without testing, or cannot say which Jira deployment type the importer supports |
| SSO wiring | High | Named protocols, identity provider setup steps, group or role mapping, test accounts and a fallback login plan for administrators | Describes SSO as a checkbox without naming protocols, or proposes an edition change without confirming license cost |
| Upgrade method | Medium | A versioned upgrade runbook covering backups, database migrations, plugin compatibility, rollback and a stated support line for each release | No backup or rollback step, or upgrades are described as a one-off task with no owner after go-live |
| Training scope | Medium | Named audiences (administrators, project managers, team members), format, materials handed over and what is included in the fixed scope | Training is undefined, offered only as a link to vendor documentation, or priced outside the written scope without explanation |
| References | Medium | Named, verifiable references in comparable regulated or hosting contexts that the buyer can contact, with permission confirmed | Anonymous or unverifiable references, or references that do not match the platform or hosting model being proposed |
How upgrades and training should be defined in the scope
Upgrades differ by platform, so the scope has to name the procedure for the platform you choose. Redmine has a documented upgrade path: back up the database and uploaded files, copy configuration, uploads and third-party plugins to the new installation, run db:migrate and redmine:plugins:migrate, then clear the cache and restart. Its supported lines are also explicit. Redmine 7.0.x receives new features, bug fixes and security updates, 6.1.x receives only bug fixes and security updates, and 6.0.x receives only important security updates, while 5.1.x and older are unsupported. OpenProject and Plane publish their own release cadences (OpenProject 17.9.0 on September 30, 2026 and 17.9.2 on October 15, 2026; Plane Community v1.4.2 in August 2026), but the scope should not assume a cadence you have not checked. Ask the partner to confirm the current support window for your exact version directly with the vendor before signing.
Ask the partner to state in writing who performs each upgrade, who takes the backup and who signs off the rollback plan. Plugins and custom fields are the usual break point in Redmine, so require a retest of every third-party plugin and every integration on a staging copy before production, with the results delivered as a short report. For OpenProject and Plane, ask how the partner handles the Enterprise or Commercial license key, SSO and any database extensions across a version change. Price upgrades as a recurring line, not a one-time cost, and ask whether they are inside a retainer or quoted per event.
Training should be written as deliverables with named audiences. Ask what covers administrators (installation, roles, workflows, backups, upgrades), project managers (work packages or issues, boards, time entries, reporting) and general users, and who delivers each session: the implementation team, the vendor, or a third party. Confirm the language, the format (recorded, live, or documented runbook), and whether sessions are repeated for new joiners. Training that is not in the written scope is usually sold later at an extra cost, so treat it as a line item to be quoted and accepted before work starts.
How DeployOpen scopes and delivers project management implementations
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For project management software RFP questions, we start from a written scope that answers each question your RFP raises, then build and hand over the platform with the evidence your review board needs.
How we scope
- We confirm which of OpenProject, Plane or Redmine fits your methods, hosting constraints and identity model before any build work starts.
- The written scope lists which features need an Enterprise or Commercial edition, so license costs are visible in the quote.
- We document the Jira importer path, including Jira Cloud or Data Center version and what history will not carry across.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We install the chosen platform in your environment using the supported method, such as Docker Compose, Helm or packages.
- We configure SSO and directory sync against your identity provider and test role mapping with real user groups.
- We run a test migration from a copy of your source data and record which fields, attachments and links arrive intact.
- We run security testing on the deployed platform and document the findings and fixes before cutover.
How we hand over
- You receive architecture diagrams, configuration records, runbooks and an upgrade procedure written for your environment.
- We deliver administrator and end-user training as set out in the written scope, with materials you can reuse.
- Backup and restore steps are tested and documented so your team can prove recovery works without us.
- Compliance evidence, such as access reviews and change records, is packaged for your auditors, who issue their own findings.
How we support
- Ongoing support, version upgrades and continuous testing are available as retainers after handover.
- We track vendor release notes and security advisories, then plan upgrades with you, including plugin and database compatibility checks.
- Scope changes, such as adding an importer run or a new SSO connection, are priced and agreed in writing before work starts.
- We keep the runbooks current so that your internal team or a future partner can operate the platform without guesswork.
