BPM RFP questions for implementation partners

How to run a BPM RFP with the right questions

Use one written question set for every bidder, and make each answer comparable. If you need a BPM partner to implement an open-source engine in your own infrastructure, the fairest way to compare proposals is to send the same questions in the same order, ask for written responses against a fixed sample, and then verify the claims in a live walkthrough. Start by asking every bidder to name the engine and the license they propose. Flowable is licensed under Apache-2.0, while Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license. Camunda 7 is a separate case: its Community Edition receives no further releases or security patches after 7.24. A proposal that does not state engine, version and license for production use is not yet comparable with the others.

Work in three stages. First, shortlist on written answers to the questions in this set, scoring each response against the same criteria. Second, require a written response to one sample BPMN process that you supply, covering how the partner would model it, test it, version it and integrate its human tasks. Third, hold a reference walkthrough in which the partner runs that same sample on a test environment, shows a version change with running instances, and demonstrates what happens when a cluster node fails. Ask the partner to show, not describe, each behavior. Record which answers came from the bidder's own experience and which were general statements about the product.

Treat vendor-neutral wording as a requirement for the RFP itself. Describe the needs (processes, human tasks, integrations, audit history, clustering, production licensing) and let each bidder map them to a platform, rather than writing the RFP around one product. Confirm current release status, support windows and license terms directly with the engine vendor during evaluation, because these change between releases. Ask every bidder to state in writing which vendor terms apply to the production environment you plan to run.

Which questions to ask a BPM partner about modeling, migration and operations

How do we know a partner can model and test BPMN processes properly?

A credible partner names the engine and version they will model against, such as Flowable 8.0.0, released on February 27, 2026, or Camunda 8.10.4, released on October 13, 2026, and explains how the models are checked. Ask how BPMN diagrams are reviewed against business rules, how unit tests run against the engine, and how process paths such as timers, error boundaries and compensation are exercised. Look for evidence: a sample test suite, a CI pipeline that runs process tests on every change, and a description of a past delivery in general terms. You should provide the process owners, the policy documents, and access to a test environment where the models can run with realistic data.

How are running process instances migrated when we deploy a new process version?

The answer should describe how running instances stay on the version they started with, and how any move to a new version is planned. Ask whether the partner will use versioned deployments, define a migration rule for each changed activity, and test the mapping on a copy of production data before cutover. Ask which engine feature they rely on, and which process variables and task assignments change shape between versions. Good answers include a rollback plan and a list of instances that cannot be migrated automatically. You should supply the current process inventory, the number of instances in flight, and the change calendar.

Can Camunda 7 or Activiti processes move to Flowable without restarting running work?

Flowable states that Camunda 7 and Activiti data can be migrated in place, including active process instances and history, according to its 2022 engineering post on escaping legacy engines. The partner should confirm that claim against your own schema and version, and say whether they will use the free Flowable LEAP tool to report the migration scope before work starts. Ask how Camunda 7 Java delegates, listeners and forms are ported, since the Camunda 7 Tasklist and Cockpit are not part of Flowable 7 or 8. Also ask which Flowable line they recommend: Flowable 7 moved to Java 17, Spring Boot 3 and Jakarta EE, while Flowable 8 moved to Spring Framework 7 and Spring Boot 4 without backward compatibility for Spring Boot 3. You should provide the Camunda version in use, the database, and the list of custom Java code.

Which UI will the partner build for human tasks, and who maintains it?

Flowable's open source engines provide Java and REST APIs but do not include a task UI in the open source distribution, so the partner must name the front end they will build or configure. Ask whether the work list, task forms and case views are built with a framework your teams already use, how forms bind to process variables, and how access is limited to the right users and groups. Ask who owns the UI code after handover and how it is versioned with the process models. Compare this with Flowable's commercial products, which add low-code modeling and monitoring, and note that Camunda 7 Tasklist and Cockpit are Camunda 7 applications. You should provide the task list of user roles, the form inventory, and your identity provider.

How is the engine clustered, and how are timers and async jobs kept from running twice?

The partner should describe the cluster topology, the database, and how nodes share state. Flowable's async executor coordinates nodes through lock owners and lock expiration times stored in the database, so expired locks are recovered and jobs are picked up by another node. Ask how they set the thread pool size, lock duration and the database type, since Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Ask for a failover test: stop one node during a timer and confirm it fires once. For Camunda 8 or Temporal, the clustering model differs, so the partner should name the component they will operate. You should provide the expected load, the availability target, and the database platform your operations team supports.

How will the partner secure the engine, identities and access to process data?

A strong answer covers three layers: who can deploy and change processes, who can see and act on tasks, and how the engine is protected at the network level. Flowable's docs say identity management can be replaced by implementing the IdmIdentityService interface, with an LDAP reference implementation, so ask how your directory will be connected. For Temporal, the self-hosted default authorizer allows every request unless one is configured, so ask for the Authorizer, ClaimMapper and mTLS settings they will apply. Ask how payload data is encrypted and what goes into logs, since process variables often contain personal data. You should provide your directory, role model and network zones.

What happens to our Camunda 7 processes now that end of life is approaching?

Camunda's final Camunda 7 feature release, 7.24, was scheduled for October 14, 2025, after which Camunda makes no further Community Edition releases or security patches, according to its February 2025 announcement. Camunda 7 Enterprise end of life was extended to April 9, 2030, with 7.24 receiving updates twice a year, and paid extended support available from April 2030 through April 2032. The partner should explain the options: stay on 7.24 under an enterprise agreement with a documented patch plan, migrate to Flowable, or migrate to Camunda 8. For Camunda 8, ask about the Camunda License 1.0, which limits use to non-production environments without a commercial license. Ask for a dated migration plan, the cost of each option, and who holds the licenses.

What does a BPM engagement cost, and what drives the price up?

Cost has four parts: modeling and testing of processes, integration with existing systems, the task UI, and infrastructure plus migration if an engine is being replaced. The partner is paid for the design, build, testing and handover work, while the engine license is zero for Flowable open source and a commercial license for Camunda 8 production use. Costs rise with the number of process variants, the number of integrations, the amount of custom UI, and the number of running instances to migrate. Costs fall when process owners prepare clear policies and when the scope is agreed as fixed deliverables in writing. Ask for a quote that separates one-time work from recurring support, upgrades and testing retainers, and ask which licenses are included. DeployOpen does not publish a price list, and a quote follows from the written scope.

Which engine and license fit production use

Flowable's open source engines for BPMN, CMMN and DMN are licensed under Apache-2.0, which places no production-use restriction on the engine itself. The commercial products, including Flowable Work, Engage, Orchestrate and Design, are separate offerings built on the same engines, and they add low-code modeling, visual debugging, security controls, monitoring and governance. Open source users get a community forum, while professional services and partners are offered separately. Flowable 8.0.0 was released on February 27, 2026, and it moved the engine to Spring Framework 7 and Spring Boot 4 without backward compatibility for Spring Boot 3, so upgrade effort depends on your current stack.

Production license: The Apache-2.0 engines can run in production without a per-environment or per-user license from Flowable. Confirm that no feature your design needs sits only in a commercial product.
Commercial boundary: Ask which capabilities you need from Flowable Work, Engage, Orchestrate or Design, and whether your partner's build relies on any of them.
Support model: Ask who provides L3 support for the engine, what the partner covers, and what the community forum does not cover.
Version path: Ask which major version the partner will standardize on and how Spring Boot 3 or Java upgrades are scheduled.

Confirm the license terms of each Flowable module you plan to use in writing with Flowable, because the commercial products sit alongside the open source engines and are not covered by the same terms.

Answers that should worry you in a BPM proposal

A BPM proposal reveals its quality in what it leaves out. The items below are the answers that signal gaps in licensing, migration, testing, user interface and operations. Each one is a question you can put to a partner before you sign.

Camunda 8 production without a license

Camunda 8 source files are under the Camunda License 1.0, which limits use to non-production environments such as development, testing and evaluation. A proposal that puts Camunda 8 into production without naming a commercial license from Camunda is leaving a compliance and cost decision unaddressed. Ask the partner to show the license position for every component in the production architecture, including Zeebe, Operate and Tasklist.

In-place migration without a dry run

Flowable has described in-place migration of Camunda 7 and Activiti data, including active process instances and history, but every engine and process model differs. A partner who promises that running instances will move cleanly without a rehearsal on a copy of production data is offering a guess. Ask for a migration report, a dry run plan and the rollback path for each process version.

No test strategy for BPMN

Process models carry routing, timers, decision calls and human task assignments, and each of these can fail silently. A proposal that describes only the modeling tool and not how models are tested, reviewed and promoted through environments gives you no evidence that changes will behave as intended. Ask how unit tests, process-level tests, decision table tests and change approval are handled in the delivery pipeline.

Task UI left undefined

Human tasks need a screen, forms, worklists, and permissions, and the open-source engines do not supply a complete production interface for every need. Flowable 7.0.0 removed the UI applications and the form engine, and Camunda 7 ships Tasklist and Cockpit, so the answer depends on the version chosen. A proposal that does not say who builds the task UI, with which framework, and how it is secured leaves a major share of the work unpriced.

Clustering claimed without lock handling

A clustered engine runs timers and asynchronous jobs across several nodes, so the way it coordinates them determines whether jobs run twice or never. Flowable's async executor uses lock owners and lock expiration times stored in the database to recover expired locks. A partner who says the engine is clustered but cannot explain lock ownership, expiry, database setup and node failure testing has not designed the cluster.

Camunda 7 support without end-of-life dates

Camunda's final Camunda 7 feature release was 7.24, scheduled for October 14, 2025, after which Community Edition receives no further releases or security patches. Enterprise Edition end of life was extended to April 9, 2030, with paid extended support from April 2030 through April 2032. A proposal that describes Camunda 7 support without naming these dates, and which edition it covers, cannot tell you how long the platform stays safe to run.

How Camunda 7 and Activiti processes move to Flowable

A credible migration plan starts with an inventory, not with the engine. Before any vendor is judged on migration, list every BPMN, DMN and form file across Camunda 7 or Activiti, note which process definition versions are deployed, and count the active instances and history records per definition. Ask the partner to produce the same inventory from your environment, including custom Java delegates, listeners, scripts and external task workers, because those are where migrations usually stall. Also confirm which Camunda 7 or Activiti version runs in production, since the upgrade path depends on it.

Flowable's published position is that Camunda 7 and Activiti data can be migrated in place, including active process instances and history, as described in its September 7, 2022 engineering post, Flowable's escape from legacy article. That post also describes the free Flowable LEAP tool, which reports ahead of time what a migration involves. Treat both as vendor claims. Run LEAP or an equivalent assessment against a copy of your production database, and require the partner to show the report before it is accepted as a plan. Ask which Flowable version the target is, because the Flowable 8.0.0 release notes describe a move to Spring Framework 7 and Spring Boot 4 that will affect any custom code embedded in your applications.

Verify the claim with a rehearsal, not a document. Ask for a test migration of your largest and longest-running process definitions, a comparison of instance counts and history before and after, and a written list of BPMN constructs that changed behavior or were converted by hand. Ask who owns the rollback plan, how long old and new engines will run side by side, and what happens to instances that span the cutover. These answers, not the 2022 post, should determine the migration scope and the partner's fixed-price proposal.

How to score partner responses

This table lists six scoring criteria for BPM partner answers and describes what a full, partial and missing answer looks like for each. Set your own weights before reading responses, so that scores reflect your risk, not the vendor's pitch. A partner that answers every criterion in writing with evidence will score well; vague answers on migration and end-of-life handling are the most common gaps.

Criterion	Full answer	Partial answer	Missing answer
Modeling and testing	Names the BPMN modeling tool, the review step before deployment, and automated test approach for process paths, timers and decision tables, with an example from a comparable process (illustrative)	Describes modeling in general terms but does not explain how paths, timers or DMN changes are tested before production	No description of how models are reviewed, versioned or tested
Running instance migration	Explains how active instances move between process versions, which cases need manual handling, and how the plan is rehearsed in a non-production copy	Covers new deployments only and leaves active instances for later discussion	Silent on running instances or assumes all instances can be stopped
Camunda 7 or Activiti to Flowable	Provides a migration assessment step, names the data and history covered (process instances, history, forms, custom code), and states how the Camunda 7 BPMN and DMN files are handled	Offers a general migration method but does not list the custom Java delegates, listeners, forms or history that need rework	Proposes a rewrite without assessing the existing estate or treats migration as a copy job
Task UI for human tasks	Specifies the UI approach (custom front end, low-code tool or existing portal), how task assignment and forms are built, and who maintains the UI after handover	Names a UI option but does not address task inbox behavior, form versioning or access control	No UI approach, or the UI is left to the buyer without a proposal
Clustering and operations	Describes how multiple engine nodes share the database, how job locking and recovery work, and which monitoring and backup steps are included	States that the engine is clustered but does not describe failover, timer handling or database sizing inputs	No answer on high availability, scaling or operational monitoring
License and end-of-life handling	States the engine and license for production use, confirms the Camunda 7 end-of-life dates in writing, and explains the plan and cost owner for moving off unsupported versions	Mentions the license or end-of-life risk but does not give a dated plan or name who decides	Recommends an engine without addressing whether the licence allows production use or the support status of the current version
Evidence and handover	Commits to named deliverables such as test records, runbooks, migration reports and architecture documentation, with dates agreed in the written scope	Lists deliverables in general terms without examples of what is retained or who signs them off	No evidence offered, or documentation is described as available on request only

What to confirm in your own environment before you sign

Before you sign, confirm the facts of your own environment, because a partner's answers to the questions above only mean something when they are tested against it. Start with the database engine. Flowable's configuration documentation lists H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types, and it notes that MySQL versions below 5.6.4 lack millisecond precision. Name the engine and version you run, state whether a DBA team owns it, and ask the partner to show the exact configuration they would deploy against it, including how the async executor's lock fields behave across nodes.

Next, document the identity source that task assignment will use. Flowable's documentation says identity management can be replaced by overriding the identity service or implementing its interface, with an LDAP reference implementation provided. Identify where candidate groups and users come from today (directory, HR system, or a custom store), who is authoritative for group membership, and how quickly removed staff must lose access to open tasks. Ask the partner to demonstrate a task being claimed, reassigned and completed by users from each group you list, so the answers are checked against your directory rather than an example.

Finally, inventory the processes and versions in scope, and confirm the production licensing position in writing. List every running Camunda 7 or Activiti process, its version, the number of active instances, and the timers that span months. Then confirm your organization's licensing status with the engine vendor. The Camunda License 1.0 permits use of Camunda 8 source only in non-production environments without a commercial license, so a production plan built on that code needs a decision from legal and procurement before the statement of work is signed. Treat the partner's migration estimate as provisional until it is checked against this inventory.

Running the BPM RFP in four stages

The sequence moves from written questions to a hands-on test of the engine, so the buyer compares partners on the same evidence. Each stage produces a document the buyer can file and reuse when scoring responses.

Issue the question set with a response template
The buyer, usually the process owner with the platform or architecture lead, sends one question set to every shortlisted partner. The set covers BPMN and CMMN modeling and testing, version migration of running instances, Camunda 7 or Activiti to Flowable moves, the task UI, clustering, and Camunda 7 end of life. A response template asks each partner to answer in the same order, state which engine and version they propose, and name the license that applies to production. The step is done when every partner has received an identical template and a return date agreed in writing.
Hold a written clarification round
The buyer collects follow-up questions from all partners and returns each answer to every partner, so no one gets information the others lack. Answers that name a tool, a migration step or a license term are checked against the vendor's own documentation. The buyer asks partners to confirm in writing which parts of their answer depend on the client's environment, such as database type, identity source or hosting. The step closes with a single clarification log that becomes part of the evaluation file.
Run a sample BPMN walkthrough with a version change
Each shortlisted partner models one agreed sample process in BPMN, deploys it to a test environment, and runs it to a human task. The buyer then asks for a new version of the same process, with a changed task or decision, and checks how the partner handles instances that started on the old version. The buyer observes whether running instances finish on their original version or move, and what the partner says will need testing before a production change. The step is done when the buyer holds a short written record of what was run, what was observed and what remains open.
Check a running instance and the task UI
During the same test, the buyer asks the partner to show a live instance in progress, including its variables, history, timers and the open human task. The buyer confirms that a user with a defined role can see and complete the task, and that the record of who did what is stored and can be exported. The partner should also show how the engine would run across more than one node, which the buyer records as a claim to verify rather than a finished result. The step closes with screenshots or exports attached to the evaluation file.
Compare written scope and deliverables
The buyer places each partner's written scope side by side, covering deliverables, the engine and version proposed, migration approach, test plan, clustering design, handover and support terms. Pricing and effort are compared only where each partner has broken them down by component, so the buyer can see which items are one-time and which recur. The buyer checks that each scope names who is responsible for production licensing and for Camunda 7 end of life planning. The step is done when a single comparison matrix is signed off by the evaluation group and the preferred partner is asked to confirm scope in writing.

How DeployOpen scopes and delivers BPM evaluations and implementations

DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. We answer BPM RFP questions with a written scope before any work starts, so vendors can be compared on the same evidence in the organization's own environment.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
The written scope names the BPMN, CMMN and DMN models, human task UIs and integrations in the evaluation
Scope confirms the target engine, the database and the cluster topology the vendor must answer for
A quote follows from the written scope, and no price list is published

How we build

Reference models are built so the team can test how each vendor models and tests BPMN processes
Version migration of running instances is demonstrated on a copy of client data inside the client's infrastructure
Camunda 7 or Activiti processes are assessed for a move to Flowable, including active instances and history
Clustering behavior, lock handling and failover are tested in a staging environment before any production decision

How we hand over

Deliverables include the written evaluation findings, the test results and the configuration used in each test
Documentation covers model versioning, deployment steps, operating procedures and the license terms that apply to production
Compliance evidence such as change records and access configuration is prepared for the client's own auditors
Knowledge transfer sessions prepare the client's engineers to run the engine and the task UI after handover

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial scope is delivered
Support can cover engine upgrades, patch tracking and planning for end-of-life dates such as those of Camunda 7
Backups, monitoring and security testing of the BPM platform can be added under the same written agreement
Each retainer scope is agreed in writing, including what the client or the vendor is responsible for operating

BPM RFP questions