How to migrate from Pega to Flowable without a big-bang rewrite
Flowable can run BPMN, CMMN and DMN workloads on infrastructure you control, but Pega rules are not portable process models. A move from Pega is therefore a re-implementation, and the practical way to manage its risk is to phase it case type by case type, keeping Pega running for the workloads that have not yet moved. Renewal pressure, a licensing change, a residency requirement or lock-in concerns usually justify starting the work, but they do not shorten it. Most of the effort sits in understanding what the Pega application actually does, not in the engine itself. In most organizations an internal platform or BPM team leads the migration and brings in an implementation partner for the Flowable build, the user interface work and the integration layer. Start with an inventory of case types, flows, decision rules, data pages, connectors and the user interfaces built on them, then rank each case type by business value, rule complexity and number of live integrations. Confirm with your Pega team which rules are inherited from a framework and which are custom, because inherited rules often hide dependencies. Ask your implementation partner for a written scope that lists which case types move in each phase. Run old and new side by side during each phase. Route new cases of a chosen type to Flowable while open Pega cases finish in Pega, and decide in advance how in-flight work, reporting and audit history will be handled. Flowable's async executor coordinates timers and jobs across nodes through lock records in the database, so confirm that your clustered deployment and database choice support it before cutover. The main risks are unclear business rules, undocumented integrations and user interfaces that staff have depended on for years, so plan a pilot with a small user group and a rollback path for every phase.
Which Pega capabilities map to Flowable and which need rework
This table compares the main Pega capabilities in scope for a move against Flowable's CMMN, BPMN and DMN engines, REST APIs and identity service. Read each row as a judgment on how much re-implementation the capability needs: clean means a direct engine equivalent exists, needs rework means the logic carries over with redesign, and gap means Flowable open source does not provide it.
| Pega capability | Flowable open source | Migration status |
|---|---|---|
| Case types and case lifecycle | CMMN engine for case models with stages, milestones and discretionary tasks, run through Java and REST APIs | Needs rework: case structure maps, but Pega case types and stage rules must be redrawn as CMMN models |
| Process flows (Flow rules) | BPMN 2.0 engine for process execution, timers, subprocesses and service tasks | Needs rework: flow shapes translate to BPMN, but Pega-specific flow actions and connectors need custom service tasks |
| Declarative and decision rules | DMN engine for decision tables and decision logic, with the event registry for event-driven triggers | Needs rework: decision tables migrate, while declarative rules and expressions require manual translation and testing |
| Low-code user interface | No UI applications in version 7.0.0 onward. Forms and screens are built as separate web or mobile front ends | Gap: no open-source low-code UI builder. Plan a separate front-end build for each case type |
| Visual modeling and debugging | Low-code modeling and visual debugging are offered in Flowable's commercial products, not the open-source engines | Gap: open-source users model in BPMN and CMMN tools and debug through logs and APIs unless a commercial product is added |
| Integration connectors | Java service tasks, REST APIs and the Spring Boot starters for embedding in applications | Needs rework: each Pega connector becomes a coded integration with its own error handling and monitoring |
| Identity and access | Identity management can be replaced by implementing the IdmIdentityService interface, with an LDAP reference implementation | Needs rework: connect your existing directory and role model, and confirm how Pega access groups map to it |
| Reporting and case history | History is stored in the database, and the engine exposes query APIs; async history was removed in version 7.0.0 | Needs rework: rebuild dashboards and reports on your own database and BI tooling |
The migration sequence: inventory, pilot, parallel run and decommission
The sequence moves Pega case types one at a time, so each cutover is proven against real work before the next one starts. Each phase closes with a written output that gates the one after it.
Inventory rules and case types
Export a complete catalog of Pega case types, flows, data pages, decision rules, user interfaces and integrations, then classify each one. Map every flow to a BPMN process, every adaptive case to a CMMN case and every decision table or strategy to a DMN decision, and mark rules that have no direct equivalent, such as declarative rules and UI-driven logic that will need custom development. The output is a rule inventory with a target artifact, an owner and a complexity note for each item. Confirm the export scope with your Pega team, because the export tools move Pega rules rather than portable process models.
Select a low-risk pilot case type
Choose one case type with a bounded set of flows, modest data volume, few integrations and a business owner who will test it. Build it on Flowable with the REST APIs, a supported production database and the identity service connected to your directory. Confirm the database type and identity integration early, since both shape the rest of the build. The output is a pilot scope document that lists what is in and out of the pilot, the test cases and the owner who signs the result.
Run the pilot against acceptance criteria
Run the pilot case type with real users on agreed test data and compare its outcomes with Pega for the same inputs. Check routing, SLA timers, escalations, user task assignment, audit history and any decision outcomes against the expected results. Exercise failure paths, such as a node restart during a timer, to confirm that the async executor recovers jobs as documented. The output is a pilot acceptance record with each test, its result, the defects raised and the sign-off from the business owner and the platform team.
Run Pega and Flowable in parallel
Route new cases of the pilot type to Flowable while Pega keeps running the rest of the portfolio, and reconcile the two sides on a regular schedule. Compare case counts, status transitions, decision outputs and integration messages, and log every divergence with its root cause. Keep the existing Pega case types in service and do not move open cases mid-flight unless a documented data migration covers them. The output is a reconciliation log showing that divergences are closed and that the operations team can run Flowable without vendor help.
Cut over case types in phases
Move the remaining case types in waves, grouped by dependency and business risk, with a rollback path for each wave. For each case type, plan how open cases finish: either they complete in Pega, or they are migrated with their data and state in a tested run. Where you use a conversion tool, validate its output in a non-production environment first. The output is a cutover record per wave that lists the case types moved, the open-case treatment, the rollback test and the acceptance sign-off.
Retire Pega rulesets and archive records
After the last case type is live and open cases have closed, stop new work on Pega, take final exports for records retention, and remove the Pega environments in the order your contract and retention policy allow. Confirm the retention obligations for case history with your legal and compliance teams before deleting anything. Pega Cloud and client-managed deployments each have their own exit steps, so confirm them with Pega in writing. The output is a retirement plan for Pega rulesets and environments, a verified archive of the records you must keep and a signed decommission record.
What data and integrations move, and what you rebuild
A Pega move splits into two tracks. Rules and their archives can be exported with Pega's documented tools, but they do not become portable process models, so case data, history, users and integrations each need their own extraction and rebuild plan. Start by listing what must survive the cutover and who owns each item.
Rules archives are not process models
The Export wizard, Deployment Manager and prpcServiceUtils produce application, ruleset and product archives. These capture Pega rules, not BPMN or CMMN models that Flowable can execute. Treat the archives as a reference inventory of case types, flows and decision rules, then redesign each one on Flowable's engines. Ask your Pega team which archive formats your version produces and which rule types they cover.
In-flight case data and work history
Open cases hold status, attachments, assignments and audit entries that Pega stores in its own schema. Extract them with a documented export or database query, map each case to a Flowable case instance, and decide whether closed cases are archived rather than migrated. Confirm with your Pega administrator how many cases are open at cutover, because a case that cannot be mapped must finish in Pega.
Users, roles and identity
Flowable's identity management can be replaced by overriding IdmIdentityServiceImpl or by implementing the IdmIdentityService interface, and an LDAP identity service is provided as a reference. Pega operator IDs, access groups and role-based permissions must be mapped to directory groups before any task is reassigned. Confirm which directory is the source of truth so that users are not duplicated during parallel running.
Database platform choice
Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Your choice should follow your existing database standards, backup tooling and licensing, not the engine itself. Note that H2 is suited to development and test only in most deployments, and that MySQL versions below 5.6.4 lack millisecond precision, which affects timer accuracy. Confirm the chosen engine and version against Flowable's configuration documentation before schema design.
Integrations and connectors
Pega connectors, service calls and data pages do not transfer automatically. List every inbound and outbound integration, then rebuild each as a service task, REST call or event handler that Flowable can invoke. Verify that timers and asynchronous jobs behave correctly across nodes, since the async executor relies on lock owners and lock expiration stored in the database. Test failure and retry paths explicitly.
User interfaces and custom code
Pega's low-code user interfaces, section layouts and rule-based validation are not carried into Flowable. Flowable's open-source engines expose Java and REST APIs, and the project removed its UI applications in version 7.0.0, so every screen, form and validation must be built or sourced separately. Budget this as its own workstream, and ask whether your Pega case types contain custom Java that also needs rewriting.
How the migration changes by estate size and starting point
A single case type with a small rule set is the most contained starting point. The inventory is short enough that one analyst can read every flow, data page and decision rule in a few working sessions, and the case lifecycle can be mapped directly onto a CMMN case model with its stages, milestones and sentries. Because the case types are few, the decision logic usually fits into a small number of DMN tables, and the user interface is a limited set of screens that a team can rebuild in one front-end project.
- Inventory depth: A full read of the rules is practical, so every flow, activity and when condition can be listed and traced to a business owner.
- UI rebuild: The screens are few, so a single front-end build covers the work, and the team can compare old and new screens side by side.
- Integration count: Usually a handful of connectors, such as one database or one document store, which keeps the reconnection effort bounded.
- Data migration: Open case instances can often be closed or completed before cutover, which removes most of the state transfer work.
- Team shape: One engineer with Flowable and Java experience can often carry the work with business sign-off from the case owner.
Confirm with the case owner which open cases must finish on Pega and which can move, and ask your implementation partner for a fixed-scope written plan that lists each rule against its Flowable equivalent.
A multi-application Pega estate with heavy custom Java usually spans several applications, shared rulesets and a layer of Java classes that Pega rules call through Java steps or connectors. The migration is less a rule-by-rule translation than a decomposition exercise: shared rules must be assigned to a new home, custom Java must be separated from Pega-specific APIs, and the order in which applications move becomes a planning decision. The Java code is an asset in this case, since Flowable is a Java engine and much of that logic can be kept, but the coupling to Pega classes has to be removed first.
- Inventory depth: The inventory has to cover applications, rulesets, dependencies between them and every Java class referenced from a rule, which is a significant analysis effort.
- UI rebuild: Several portals and case views are usually involved, so the team needs a shared component library and a rebuild order that follows business priority.
- Integration count: Each application tends to bring its own connectors, service calls and message queues, so the integration list is the longest of the three cases.
- Phasing: Case types are moved in waves, with coexistence routing so that old and new cases can run side by side during each wave.
- Team shape: A dedicated team with Java, process modeling and front-end skills is usually needed for the duration of the program.
Ask for a dependency map of rulesets and Java classes before any scope is agreed, since it determines the number of waves and the cost of each one.
A client-managed Pega Infinity deployment on Kubernetes, where the organization already runs the cluster, changes the migration in a different way. Pega's client-managed model places the infrastructure operations with the client, so the team that runs Kubernetes, databases and backups is already in place. That helps the target side: a Flowable deployment can reuse the same cluster, observability stack, secrets handling and backup routines. The migration then focuses on application logic, data and user experience rather than on platform operations.
- Inventory depth: Infrastructure inventory is smaller because the platform team already documents the cluster, but the rule inventory is unchanged and still has to be complete.
- UI rebuild: The UI work is the same as in other cases, though the deployment and release pipeline for the new front end can reuse existing tooling.
- Integration count: Integrations with in-house services are often already documented, and existing connectors to shared identity and logging can be reused in the new stack.
- Operations: Flowable runs as a Java service with a database, and the async executor uses lock owners and expiry times stored in the database to coordinate nodes, so the platform team needs to understand this model before cutover.
- Support: Pega's 24/7 support for the platform stops at cutover, so the in-house team takes on support for the new engines and needs an agreed support route.
Confirm which database types, Kubernetes distribution and identity service your team already operates, because these decide how much of the target stack can be reused.
What usually goes wrong in a Pega to Flowable move
Most failed or stalled Pega exits trace back to a handful of assumptions made early: that rules translate one to one, that screens are a small job, and that existing cases will simply finish where they are. Each card below names one of these risks and the check that prevents it, so the inventory, pilot and cutover plan address them before build work starts.
Treating Pega rules as portable
Pega rules are stored in a Pega-specific rule model, so a case type, flow or data transform does not export as a BPMN or CMMN model that Flowable can run. Flowable's engines execute standard BPMN, CMMN and DMN artifacts, which means each Pega flow must be redrawn and each case type re-modeled. Prevention: build a rule inventory that classifies each Pega artifact as re-model, re-implement in Java, or retire, and confirm the classification with the process owners before estimating build work.
Underestimating the UI rebuild
Pega case work is often delivered through Pega's low-code user interface layer. Flowable's open-source engines provide process and case execution with Java and REST APIs, but they do not supply the end-user screens, so each work queue, form and case view needs a front end built and tested. Prevention: count the screens and form fields per case type early, decide the front-end stack, and budget design and accessibility testing as a separate workstream.
Incomplete decision table migration to DMN
Pega decisioning rules such as decision tables and strategies do not map one to one onto DMN. Hit policies, input ordering, default outputs and data type handling can differ, and an unmigrated edge case changes a customer or case outcome without an obvious error. Prevention: export the decision logic, convert each table to DMN, and run both engines side by side on a recorded sample of historical inputs until the outputs match.
In-flight case data left behind
Open cases in Pega carry state, attachments, assignments and history that the Flowable engine does not inherit automatically. Moving only new cases leaves a long tail of work in the old system, which keeps Pega licensed and operated. Prevention: classify open cases by case type and age, decide per type whether to complete in Pega, migrate state, or restart, and keep the Pega environment readable until the last in-flight case closes.
Identity and role mapping gaps
Pega operator IDs, access groups and roles govern who sees and can act on each case. Flowable's identity management is replaceable: the docs describe overriding the identity service or implementing its interface, with an LDAP reference implementation. Prevention: map every Pega access group to a directory group, define how assignments and candidate groups resolve, and test segregation-of-duties rules with real users before go-live.
Spring Boot 4 and Java requirements on upgrade
Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 and dropped compatibility with Spring Boot 3, with Jackson 3 as the default JSON library. Teams that build on Spring Boot 3 or depend on JUnit 3 or 4 tests must plan the framework upgrade as part of the migration, not as a later patch. Prevention: pick the Flowable major version and matching Spring Boot line first, then check every custom listener, serializer and test suite against it.
What drives migration cost and duration
This table lists the main factors that move the cost and effort of moving Pega case types, flows and decision rules to Flowable, with the reason each one matters and how to keep it under control. Use it to build the list of questions for a written scope, since no single driver decides the outcome. Flowable's engine licence is Apache 2.0, so most recurring cost sits in infrastructure, development and support.
| Driver | Why it moves cost or effort | How to keep it down |
|---|---|---|
| Rule count and complexity | Each Pega rule type (flows, data transforms, decision tables, activities) maps to a different Flowable construct, and rules with custom Java or chained calls need manual redesign. | Classify rules by type and reuse, retire unused rules before scoping, and ask the partner for a rule-by-rule inventory. |
| Number of case types | Each case type needs its own CMMN or BPMN model, stages, data model and lifecycle tests, so effort scales with the count and their interdependencies. | Phase case types by business value and dependency, and move low-coupling case types first. |
| UI screens and portals | Pega's low-code user interface does not carry over to Flowable, which provides engines and REST APIs rather than a UI layer, so every screen must be rebuilt in a chosen front end. | Reuse a small set of screen patterns, agree a design system early, and confirm which screens are truly needed. |
| Integration points | Each connector, web service, message queue or external API used by Pega must be re-created and tested against Flowable's Java and REST interfaces. | Inventory all interfaces with owners and volumes, and retire integrations that no longer have consumers. |
| Data volume and history retention | Open case instances, attachments and audit history must be migrated or archived, and the retention rule decides how much data is in scope. | Set retention rules with compliance owners first, archive closed cases outside the engine, and migrate only open work where possible. |
| Identity integration | Flowable's identity management can be replaced through a custom service or an LDAP reference implementation, so roles, groups and access rules from Pega need explicit mapping. | Map Pega operator roles to directory groups before design, and confirm how your directory will be queried. |
| In-house Java and platform skills | Running Flowable means Java application development, database administration and operations work, which an internal team must own or a partner must supply. | Assess current Java and Spring skills honestly, and ask the partner which knowledge transfer and runbooks are included. |
| Governance and compliance requirements | Evidence for change control, access reviews, testing and audit trails must be built, since Flowable does not supply these controls by default. | Agree evidence requirements with assessors early and build them into the delivery plan. |
| Recurring costs after go-live | Infrastructure, database licences where applicable, patching, monitoring, upgrades such as the Flowable 8.0.0 move to Spring Boot 4, and support continue each year. | Plan an upgrade cadence, standardize deployment, and ask for support and upgrade terms as separate line items. |
Questions buyers ask before moving from Pega to Flowable
Is Flowable a direct replacement for Pega?
No. Flowable is a set of open-source process engines for BPMN, CMMN and DMN, with Java and REST APIs. It does not reproduce Pega's full low-code application builder, its rule-based case types or its decisioning studio as a drop-in product. Case logic, process models and decision tables can be re-expressed in CMMN, BPMN and DMN, but user interfaces, data model, integrations and any Pega-specific rules must be rebuilt or replaced with your own front end and services. Plan the work as a re-implementation of the parts you need, not a configuration change. Your inventory of rules will show which parts carry over cleanly and which need custom development.
How long does a Pega to Flowable migration take?
The duration depends on the scope, and no reliable figure exists without one. The main drivers are the number of case types and flows, how many rules are reusable, how much user interface must be rebuilt, the volume and history of case data to migrate, the integrations to re-wire, and how many case types you move in each phase. Phasing off Pega one case type at a time usually lengthens the calendar but reduces risk. Ask any provider, including DeployOpen, for a written scope that lists these items, its deliverables and its timeline before you commit. The scope is what turns an estimate into a plan.
What does our team need to provide for the migration?
The migration needs people who know the business processes and the Pega rules in production. Provide a current inventory of case types, flows, decision rules, data pages, integrations and reports, with an owner for each. Give access to a non-production Pega environment for export and comparison, sample case data with anonymized personal data where required, and named business approvers for each case type. You will also need an infrastructure owner for the Kubernetes or virtual machine platform, a database team and an identity source. Without these inputs, the rebuild spends its time discovering scope rather than delivering it.
Can our own team do the migration in-house?
It can, if the team has Java and Spring experience, workflow modeling skills for BPMN, CMMN and DMN, and front-end developers for the case interfaces. Your team also needs to own operations: deploying the engine, configuring the database, running the async executor, patching and monitoring. The main question is capacity and continuity. Re-implementation work is often done alongside running operations, so confirm who will maintain the models after the project ends. A fixed-scope engagement with DeployOpen, or a retainer for upgrades and support, is one option to consider in place of, or alongside, in-house delivery.
Do we need Flowable's commercial editions?
No. The Flowable engines are Apache-2.0 licensed and can run without a commercial agreement. Flowable also sells commercial products such as Flowable Work, Engage, Orchestrate and Design, which are built on the same engines and add low-code modeling, visual debugging, security controls, monitoring and governance. The open-source route gives you a community forum, while professional services and partners are offered separately. Decide which of those extra capabilities you need, such as visual modeling for business analysts, before you assume you will pay for them. Those features are a separate cost and should appear as a separate line in your comparison.
How do we handle cases that are already in progress?
Most teams keep in-flight cases on Pega until they close, and move only new cases to Flowable, which avoids moving live state. If open cases must move, the migration needs a mapping of each Pega case state to a CMMN case plan item or BPMN process state, plus a test run on copies of real data. Flowable can run the case models you build, but it does not automatically read Pega's internal case data, so the data migration is a project of its own. Agree on a cutover rule for each case type, including how work in progress is paused, transferred or completed, and test rollback before you start.
What support does Flowable's open-source license include?
Flowable's open-source license gives you the code and the right to run it, but not a vendor support contract. Community support is available through the community forum, and the engine's documentation and public repository are the first place to look. For production support with a response commitment, you will need a commercial Flowable subscription, a partner, or an independent provider under a written agreement. Ask any provider for the exact support hours, escalation path and patch policy in writing. Plan for the work of applying security patches and version upgrades yourself or under a retainer.
How do we keep security and compliance evidence after the move?
Start by mapping the controls that Pega currently provides, such as role-based access, audit trails, encryption and change control, to equivalent controls in your Flowable deployment. Flowable's engine handles process history, but access control, identity integration, logging and key management are part of your architecture. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports or certifications. Independent auditors and certification bodies perform those assessments, so confirm early which evidence they will require from you.
What a written migration scope should contain
A written migration scope should name every stage of the move before any Flowable engine is configured. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the document itself becomes the control for the project. It should cover five areas: a rule inventory of every Pega case type, flow, decision rule and integration; one pilot case type chosen to test the approach end to end; a data mapping from Pega case data to the Flowable runtime and history tables; cutover criteria that define when a case type leaves Pega; and a decommission plan for the Pega rules, environments and licenses that are no longer needed.
The client has to confirm several facts before the scope can be priced or timed. Confirm the Pega Infinity version in use and the deployment model, whether Pega Cloud or client-managed on Kubernetes, since that determines what must be exported and who operates the source platform during the move. Confirm the licensing terms and the end dates that govern the contract, so the cutover plan fits the period in which Pega remains available. List every system Pega calls or is called by, including identity, document and reporting integrations, because each one needs an owner on the Flowable side.
The scope should also name who approves each gate. Typically that means a business owner for each case type, a security reviewer for identity and access controls carried into Flowable, and an operations owner for the database, backups and monitoring that Flowable will depend on. Ask the implementation partner to state in writing which items are out of scope, such as custom Pega Java code or UI screens that will be rebuilt rather than converted. Those exclusions are the usual source of disagreement later, so they belong in the document from the start.
How DeployOpen plans, runs and supports a Pega to Flowable migration
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Pega to Flowable move, we start with a written scope that separates case types, flows and decision rules that map to Flowable's engines from those that need custom development, then build and document the result in your environment.
How we scope
- Inventory of Pega case types, flows, decision rules and user interfaces agreed in writing before work starts
- Classification of each rule as a direct CMMN, BPMN or DMN mapping, a custom build or a candidate for retirement
- Named deliverables, timelines and phase boundaries for each case type set, confirmed with your team
How we build
- Flowable engines deployed in your cloud account, data center or air-gapped network, using the database types your standards allow
- Rebuilt case and process models with tests for each migrated case type, including identity integration through the Flowable identity service interface
- Case data migration scripts, reconciliation reports and security testing of the new APIs and user interfaces
How we hand over
- Runbooks covering deployment, async executor behavior across nodes, backups and upgrades for the Flowable version you run
- Documentation of each migrated case type, decision table and integration, with evidence prepared for your compliance assessors
- Handover sessions with your platform and business teams, with a clear record of what remains on Pega during each phase
How we support
- Ongoing support, upgrades and continuous security testing available as a retainer after handover
- Monitoring and backup routines set up with your operations team, so cutover and phase-off decisions rest on your own data
- Upgrade planning for each Flowable release, including the Spring Boot and Java requirements in its release notes
