Where Pega Platform cost vs self-hosted Flowable really differs
Flowable removes the license line from the Pega budget, but it adds re-implementation, UI development, infrastructure operations and an engineering team that Pega largely bundles into its platform and hosting model. If you are facing a renewal, a Pega Cloud or client-managed hosting decision, or a data residency or lock-in concern, the saving you can actually bank depends on how much of that bundled work your own staff or partners must now carry. No Pega license price or hosting price is supplied for this comparison, so you need to build the model from your own written quotes from Pega and from any Flowable partner you consider. Ask Pega to itemize subscription, hosting, support and upgrade effort separately, so each line can be compared with a matching Flowable cost.
The Flowable engines are Apache-2.0 licensed, so the engine software itself carries no license fee. Flowable's commercial editions, including Flowable Work, Engage, Orchestrate and Design, are separate products built on the same engines, and professional services and partner support are offered separately. Treat each of these as an optional line item that you add only if your requirements call for it, and record it on its own row in the model. Also confirm which Flowable release line you will build on, since the Flowable 8.0.0 release moved to Spring Boot 4 and dropped Spring Boot 3 compatibility, which affects the Java skills and build pipeline you must fund.
Most of the multi-year difference sits in one-time and recurring engineering effort. The one-time items are re-building case types, flows, decision rules and user interfaces, and migrating case data. The recurring items are patching the Java stack, operating the database and the async executor, maintaining identity integration, and staffing on-call support. Cost rises with the number of Pega rules that do not map directly to CMMN, BPMN or DMN models and with the amount of custom UI you must write. Ask any implementer for a fixed-scope estimate that lists each case type, the UI screens it needs and the support model after go-live, and compare that document line by line with Pega's quoted support and upgrade terms.
Cost components on each side of the comparison
This table lists each cost component of running Pega and of running Flowable, showing who is paid, whether the cost is one-time or recurring, and what the commercial side bundles that the self-hosted side must supply. Use it to build a like-for-like quote request, since most of the difference sits in rows the Pega subscription hides rather than in the license line itself.
| Cost component | Pega side | Flowable side (self-hosted) |
|---|---|---|
| Software license or subscription | Pega subscription, recurring; covers platform, updates and vendor support terms set in the contract | Flowable engines are Apache-2.0 licensed, so no license fee is due; commercial Flowable editions are optional and recurring if chosen |
| Hosting model | Pega Cloud (Pega-managed, recurring) or client-managed cloud, where Pega provides certification and 24/7 support while the client runs infrastructure | Client's own cloud, data center or air-gapped network; the client pays infrastructure directly and owns its operation |
| Infrastructure | Included in Pega Cloud fees; in client-managed mode, the client pays Kubernetes clusters, databases and storage on validated providers | Recurring compute, database, storage and backup for Flowable services, Kubernetes or VM hosts and monitoring, sized by process volume |
| Re-implementation of case types and decisions | Largely a one-time cost to rebuild Pega rules on Flowable CMMN, BPMN and DMN models, using the client's or a partner's developers | Same one-time effort, usually larger in year one because Flowable has no equivalent rule repository; ask for an inventory-based estimate |
| UI development | Pega's built-in low-code UI is part of the subscription; the client pays for licensed Pega developers | Flowable provides engines and REST APIs but not the case worker UI in open source, so the client funds custom front-end build and its upkeep |
| Data migration | Export effort from Pega, plus client-side migration planning; Pega exports move rules, not portable process models | One-time cost to move running case data into Flowable schemas, validate it and retire Pega instances in phases |
| Support and upgrades | Included in the vendor contract; Pega releases roughly every nine to twelve months with 36 months of support per version | Community forum at no charge; paid professional services, partner support or a retainer for upgrades, security patches and on-call coverage |
| Internal skills | Pega developer and administrator roles, often certified staff, recurring salary or contractor cost | Java, Spring Boot, BPMN and database skills to own the engine; recurring headcount or retainer. Confirm staffing needs in writing before comparing totals. |
What moves the comparison up or down
Six drivers decide whether a Pega estate or a self-hosted Flowable build costs more over several years. Most of them change both sides at once, so size them together before comparing totals. Ask your vendor and your implementation partner to price against the same counts.
Case types and decision rules
The number of case types, flows, decision tables and data pages you must rebuild is the largest one-time driver on the self-hosted side. Each case type maps to CMMN or BPMN models and each decision rule to DMN tables, so an inventory of rules by type and complexity sets the re-implementation effort. On the commercial side, the same inventory shows how much Pega rule work and licensed capacity your current estate depends on. Ask for a rule count broken down by type before anyone agrees on a figure.
Named and concurrent users
Pega commercial terms and most cloud hosting tiers are sized on user and workload counts, so ask the vendor to state how it counts named and concurrent users for your roles. Flowable has no per-user license, so user growth on the self-hosted side shows up as more application servers, database capacity and identity integration rather than a license line. Confirm which of your staff, customers or partners need task access and which only need reporting.
Case volume and retained data
Case throughput and how long closed cases stay online drive database size, history storage and backup cost. Flowable's async executor coordinates jobs across nodes through lock records in the database, so high timer and job volume also needs database capacity and tuning. Ask the commercial vendor how retention, archiving and storage are priced, and ask yourselves which history must remain queryable for audit and which can move to cold storage.
UI and portal scope
Pega includes a low-code user experience layer, while Flowable's open-source engines expose Java and REST APIs and do not ship the UI applications that Flowable 7.0.0 removed. Every portal, case worker screen and customer form you build on the self-hosted side is custom front-end work with its own developers, testing and release cycle. Count screens, roles and channels before estimating, and ask whether the commercial price assumes Pega's UI tooling for all of them.
Availability and disaster recovery targets
Higher availability targets raise the cost of both options, but the cost sits in different places. Pega Cloud and client-managed hosting spread that cost between the vendor's service terms and your own cluster operations, so ask which recovery objectives the vendor contracts for and which you must run yourselves. On the self-hosted side, you pay for redundant Kubernetes or VM capacity, database replication, tested backups and a regular restore exercise. Write the targets down before requesting quotes.
Skills already on staff
Existing Java, Spring and database skills lower the self-hosted run cost, while a team that knows Pega rule development lowers the commercial one. Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, so a team that has not yet upgraded will need that work included. Estimate the gap between current skills and the roles you need, then price training, hiring or partner support against it.
How to build the cost model with your own numbers
This sequence turns a Pega renewal into a like-for-like, multi-year comparison with a Flowable target, so each cost sits in a written quote or a contract line you can point to.
Collect the current Pega contract and hosting terms
Finance and procurement pull the current Pega subscription order, renewal terms, support tier, and the hosting model in use, either Pega Cloud or client-managed on Kubernetes. Note the term end date, the number of licensed users or application seats, and any clauses on price escalation or audit. Your infrastructure team lists what it runs today for a client-managed installation, including clusters, databases, storage, and monitoring. The step is done when you have one document that states what you pay each year, what it covers, and what you are obligated to renew. Ask Pega to confirm in writing which cost lines are included and which are extra.
Inventory case types, flows and decision rules
Architects and Pega application owners count the case types, flows, data pages, decision tables, and user interfaces in each production application, then tag each by business owner and by volume of active cases. Mark which rules are simple decision logic that maps to DMN tables, which are stage-based case lifecycles that map to CMMN, and which are sequential processes that map to BPMN. Record every integration point, report, and scheduled job. The output is a register that becomes the scope baseline for all later quotes. The step is done when each application has a complexity rating agreed by its owner, and the register is reviewed by the people who use the cases daily.
Size the Flowable target architecture
Platform engineers choose the deployment shape for Flowable: embedded in a Spring Boot or servlet application, or run as a standalone service through its REST APIs. Decide the database engine from the supported list in the Flowable configuration docs, and plan the async executor and multi-node setup that the Flowable advanced docs describe for timers and jobs. Identify where identity will come from, since Flowable identity management can be replaced through its identity service interface. Decide which UI layer, if any, you will build, because Flowable's open-source engines do not include the case and form applications that Pega provides. The step is done when you have a diagram and a list of components, each with an owner and a hosting location in your environment.
Price re-implementation and UI work from written scopes
Ask at least two implementation partners and your internal team to price the rebuild of each rated application from the inventory. Each quote must state the number of case types and processes in scope, the rules converted to BPMN, CMMN, or DMN, the user interface screens and their count, data migration effort for open cases, testing and UAT support, and the handover documentation. Ask for effort in named roles, such as Java developer, process designer, UI developer, and tester, with daily rates or fixed fees shown separately. Require a statement of what is excluded, such as third-party connectors or custom reports. The step is done when every application has a quote that a reviewer can compare line by line with the inventory.
Add infrastructure and ongoing operations
Infrastructure and operations staff price the recurring environment: Kubernetes or virtual machine capacity, databases with backup and restore, object storage for documents, monitoring, logging, certificates, and non-production environments for testing. Include the people who patch, upgrade the Flowable versions, and respond to incidents, and state whether the cost comes from internal staff time or from a support retainer. Add support for the Pega side as well, because client-managed Pega still requires your team to run the infrastructure, while Pega provides certification and 24/7 support. The step is done when each recurring line has a monthly or annual figure, a named owner, and a source, either a vendor invoice, a quote, or an internal rate card.
Separate one-time and recurring costs over a fixed horizon
Finance builds one model with a fixed number of years, the same length for both options, and places every cost in one of two columns: one-time (discovery, rebuild, data migration, training, cutover) or recurring (licenses or subscriptions, infrastructure, support, staff, upgrades). Show Pega's contract in its current form and at its renewal escalation, and show Flowable's engine as open source with any commercial subscription or support you choose shown separately. Run the model with a dependency on the case inventory so that a change in scope moves the rebuild cost. Also model a parallel-running period where both platforms operate. The step is done when the total cost for each option is visible by year and by category, and the assumptions are listed beside the totals.
Request quotes that state their assumptions
Before the model is final, ask each vendor and partner to put its assumptions in writing: the Pega renewal price basis and any change in support or hosting terms, the Flowable support option you select, the implementation scope, the hours or fixed fee, exclusions, change-request rates, and the acceptance criteria. Ask DeployOpen or any other provider for a fixed-scope proposal that names deliverables, timelines, and what is handed over, and ask for ongoing support or upgrade retainers as a separate line. Confirm the Flowable version you will target, since release history matters for upgrade planning, and confirm Spring and Java versions with your architects. The step is done when every number in the model traces to a document, and an internal reviewer can challenge each assumption without asking the author.
What the Flowable stack needs in place before it costs less
A self-hosted Flowable deployment starts with a platform decision, not a licence line. Flowable's engines for BPMN, CMMN and DMN can be embedded as a JAR in a Java SE application, a servlet container such as Tomcat or Jetty, a Spring application or a Java EE server, or run as a standalone service through the Flowable REST application. Choose the model first, because it sets who builds, tests and patches the runtime. Pick a supported database before anything else: Flowable's configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. If you run MySQL, confirm your version, since versions below 5.6.4 lack millisecond precision. For multi-node operation, the async executor coordinates timers and jobs through lock owners and lock expiration times stored in that database, so the database must be highly available and sized for lock traffic, not treated as a passive store.
Plan the Spring layer and identity deliberately. Flowable publishes Spring Boot starters for all engines, for REST, and for the individual process, CMMN and DMN engines, and exposes an actuator endpoint at /actuator/flowable for monitoring running processes. Wire it into your existing logging and alerting. Identity is the other integration point. Flowable lets you replace identity management by overriding IdmIdentityServiceImpl or by implementing the IdmIdentityService interface, and it ships an LDAP implementation as a reference. Your engineers must write and test that bridge against your directory, including group and role mapping, which is a recurring design item whenever the directory changes.
Two version items belong in the budget. Flowable 7.0.0 removed the UI applications and the form and content engines, so every form, task list and case screen that the Pega rules once supplied must be rebuilt in your own front end or in a commercial Flowable product, which is a development cost with no open-source default. Flowable 8.0.0, released February 27, 2026, moves to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, uses Jackson 3 by default and drops JUnit 3 and 4 support. Confirm which major version fits your plan, then schedule the upgrade of your application, tests and dependencies as a line item of its own. Ask your implementation partner to quote both the UI build and the framework upgrade separately.
Questions buyers ask about Pega and Flowable costs
How much more effort does Flowable need compared with Pega?
Flowable usually needs more build effort up front, because Pega ships a low-code application layer, case designer, decisioning rules and user interface tooling in one product, while Flowable provides the BPMN, CMMN and DMN engines with Java and REST APIs. Effort shifts to the parts Pega supplies by default: the user interface, identity integration, reporting, and the operational tooling around the engines. The gap depends on how much of your Pega application relies on built-in screens and rule types. Ask the vendor or partner to split the estimate into engine work, user interface work and integration work so the difference is visible line by line.
How long does a Pega to Flowable re-implementation take, and what drives it?
The duration depends on scope, not on the engine itself. The main drivers are the number of case types and flows in use, how many decision rules and data transformations must be rebuilt, how much user interface work is needed, how many integrations must be re-established, and whether case data must move while the old system stays live. Phasing case types off Pega in batches usually lengthens the calendar but reduces cutover risk. No duration in this section is a commitment. Request a written scope with phases, deliverables and acceptance criteria, and ask for the timeline to be tied to those phases.
Can an internal team do the migration alone?
It can, if it has engineers who know Java, the BPMN, CMMN and DMN standards, and the target database and deployment platform, and if it has time to learn the engine APIs. Teams without recent experience with case management often underestimate the user interface and data migration work. A useful test is whether the team can name every Pega rule type in use, who owns each one, and how each will be tested after cutover. Many organizations split the work: internal staff own the business rules and data, while an implementation partner handles the engine build, hardening and runbooks under a fixed-scope agreement.
What skills does the team need to run Flowable after go-live?
Plan for Java and Spring developers who can maintain engine embedding, process and case model authors who understand BPMN and CMMN, and operations staff who can run the chosen database, the Kubernetes or servlet hosting layer, backups and monitoring. Identity integration also needs someone who can implement or configure the identity service. Front-end developers are needed if the user interface is rebuilt in a custom application. Ask any partner to show which roles are covered in the handover and which will remain your responsibility.
What does the client need to provide for the engagement?
Expect to provide access to the current Pega environment and its exports, named business owners for each case type and decision, a test environment, cloud or data center accounts, identity and network details, and time from subject matter experts for acceptance testing. Missing access or unclear ownership is one of the most common causes of schedule slippage, so confirm these inputs before the scope is signed. Ask for a written list of client dependencies in the statement of work.
What should a quote include so the costs can be compared?
A comparable quote separates one-time costs from recurring costs. One-time items include discovery and inventory of Pega rules, engine build, user interface development, data migration, testing, hardening and documentation. Recurring items include infrastructure, database and backup operations, Flowable or other subscription fees if you choose a commercial edition, internal staffing, upgrades and support. Ask for the assumptions behind each line, the named deliverables, the acceptance criteria, and what is excluded. Compare this against the Pega licensing, Pega Cloud or client-managed hosting, and support terms that apply to your contract.
Does Flowable's open-source license remove ongoing support costs?
No. Flowable's open-source engines are licensed under Apache 2.0, so the software itself carries no license fee, but production operations still need people and time. Flowable also offers commercial editions and professional services separately, and the open-source community forum is not an enterprise support contract. Decide early whether you need a support agreement, a retained operations partner, or an internal on-call rota, and include that cost in the comparison with Pega's support terms.
Where a Pega versus Flowable comparison goes wrong
The most frequent error is comparing a Pega subscription with bare Flowable infrastructure. A Pega line item covers the platform, its rule engine, its case designer and vendor support, and in client-managed mode the vendor also provides certification and 24/7 support, while the client runs the underlying Kubernetes infrastructure. Flowable's engines are Apache-2.0 licensed, so the comparable Flowable line items are the servers or clusters, the database, the identity integration, monitoring, backups and the people who run them. Build the model with both sides listed component by component, then add the costs Pega covers that Flowable does not, such as the case designer and the UI tooling. Ask Pega for a written description of what the subscription includes in your deployment model, and confirm which Flowable support or commercial edition, if any, you intend to buy.
Two omissions distort the totals more than any license figure. The first is the user interface. Flowable's version 7 release notes say the UI applications were removed, so case workers, managers and reporting screens must be built with your own front-end stack or a commercial Flowable product. Estimate that UI work per case type, not as an afterthought. The second is the engineering team. A Flowable project needs Java developers who understand the BPMN, CMMN and DMN engines, operators for the database and the async executor, and product owners who can rewrite Pega rules as models. Do not assume the team that supports Pega today can absorb this work without training or hiring, and do not assume Flowable's commercial editions are required or excluded until you have compared the features you need against the open-source engines. The third omission is in-flight cases. Decide whether open cases finish on Pega, are migrated with their state, or are restarted, and cost each option separately.
Treat the migration of in-flight cases as a line item with its own owner. Running old and new case types in parallel adds licensing overlap, duplicate monitoring and reconciliation work, and the cost of that period is easy to underestimate. Inventory open case counts and their age by case type, and confirm with your own architects which of them can be migrated and which must run to completion. For Flowable, document how the async executor and its lock settings behave in a multi-node cluster, because jobs and timers left behind during cutover must be recovered by the new nodes. Ask every bidder to price the parallel-run period and the rollback path, and to state what assumptions they made about Pega rule export, which is covered in the export guide linked from this page.
How DeployOpen scopes a fixed-price Flowable implementation
DeployOpen approaches a Pega exit as a written, fixed-scope engagement, starting from what your Pega estate actually contains and what your infrastructure must support. The scope, deliverables and timelines are agreed in writing before any work begins, so cost comparisons rest on known inputs.
How we scope
- Inventory the Pega case types, flows, decision rules and integrations that the Flowable scope must cover.
- Agree in writing which BPMN, CMMN and DMN models, data stores and identity sources are in scope.
- Confirm your hosting target, whether your own Kubernetes, cloud accounts or data centers, before estimating infrastructure.
How we build
- Implement Flowable engines on your chosen database, such as PostgreSQL, Oracle or Microsoft SQL Server, with configuration documented.
- Build the user interfaces and identity integration your case workers need, since Flowable does not ship a full case UI.
- Test case flows, decision tables and async job behavior in a non-production environment before any cutover.
How we hand over
- Deliver architecture, runbooks, configuration records and test evidence as written deliverables at handover.
- Train your platform and developer team on operating the engines, the REST APIs and the async executor.
- Document which Pega features were retired, replaced or left out, so your cost model reflects the real result.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, if you want it.
- Plan upgrades around Flowable's release line, including the Spring Boot and Java requirements of each major version.
- Ask for a quote that separates one-time implementation fees from recurring hosting, support and staffing costs.
