How to export your data from Pega Platform

How to export your data from Pega Platform before a move

Pega's documented export tools give you rule archives, not case data and not a process model that Flowable can run unchanged. The Export wizard produces application, ruleset and product archives, Deployment Manager moves rules between environments, and the prpcServiceUtils command-line tools support scripted export. If your driver is a renewal, a licensing change, a residency requirement or lock-in, start here: these archives document the Pega rules you built, which is the input to your inventory. Confirm in the documentation for your exact Pega Infinity version which archive types, options and file formats each tool supports, and whether the command-line utilities are available in your deployment.

What does not come out cleanly is the work that is actually running. Case instances, their history, work objects in flight, attachments and the data behind your reports belong to the Pega data model, and the archives do not carry them into a form Flowable can execute. Flowable runs BPMN, CMMN and DMN models, so each Pega case type and flow has to be re-expressed in those notations, and each decision rule re-implemented in DMN or code. Ask Pega which routes exist for extracting case data from your environment, including any reporting or data-access options, the output formats they produce, and any volume or retention limits. Do not assume that a rules archive is a data backup.

Plan the export as three checks. First, inventory the archives against the case types in scope and record which rules have no equivalent in your target engine. Second, confirm the data extraction route with Pega for your hosting model: on Pega Cloud the vendor operates the platform, while on Pega's client-managed cloud your team handles infrastructure operations, so backup and export responsibilities sit with you. Third, keep the archives and extracts under your own retention and residency controls, and record who approved each export. Illustrative: a team that exports rulesets in week one but discovers in week eight that case history cannot be extracted will rebuild its migration plan around that gap.

What Pega's export tools produce and what to check in each

This table lists the documented Pega export paths, what each one produces, and where scope or limits need confirmation. Read it as an inventory of what leaves Pega. Rule archives carry Pega rule definitions, which must be re-implemented on Flowable, so use the final column to build your question list for Pega before planning the move.

Export path	What it produces	Scope and limits	Confirm with Pega
Export wizard: application archive	An archive of one application's rules and their versions	Covers the application definition; confirm whether data instances and work items are included	Archive file format, size limits and whether it imports into other Pega Infinity versions
Export wizard: ruleset archive	An archive of selected rulesets and their rule versions	Limited to the rulesets you select; shared or dependent rulesets need separate handling	How dependencies are resolved and whether locked or checked-out rules are exported
Export wizard: product archive	An archive bundling applications and rulesets for a product	Packages the product definition; confirm whether it carries case or work data	Whether product archives include data instances and how they are versioned
Deployment Manager	Packaged movement of artifacts between Pega environments	Built for environment-to-environment promotion; confirm whether output can be written to your own storage	Package layout, supported source and target versions, and any Pega Cloud restrictions
prpcServiceUtils command-line tools	Scripted export of rules and selected data from an environment you operate	Suited to repeatable, scripted exports; scope depends on the utility and options used	Exact command syntax, output format, authentication method and throughput limits for your version
Case and work data	Case instances, attachments and processing history	Usually outside rule archives; check whether a data-level export exists for each case type	Export method, attachment format and how history and audit records are included
Hosting model	Determines who runs exports and where the files are stored	On client-managed Pega Infinity, your team controls infrastructure and storage; on Pega Cloud, Pega operates the environment	Which export operations Pega Cloud permits and how archives are delivered to you

What Pega archives do not carry to a new platform

Pega's export tools move Pega rules and packaged applications, but the artifacts that run a business process on Flowable are mostly rebuilt, not copied. The cards below cover what the archives leave behind and the workaround for each, so the migration plan accounts for them before a cutover date is set.

Pega rules are not BPMN, CMMN or DMN

Pega rules are stored in Pega's own rule model, so an export of case types, flows and decision rules is a Pega package, not a portable process model. Flowable reads BPMN, CMMN and DMN files, so each case type or flow must be re-modeled as a standard diagram or decision table. Use the exported rule inventory as the blueprint, and ask Pega to confirm which rule types the archive includes and which it only references.

UI and portal definitions

Pega's user interface, sections, harnesses and portal configurations are generated from Pega rules and do not map to Flowable, which has no built-in UI layer for these. Plan to rebuild screens in your own front-end or a separate forms tool, and confirm with Pega whether any UI rules are included in the application archive or must be exported separately.

Running case instances and history

An archive holds the application definition, not the cases currently in progress. Open work items, assignments and case history typically need a data extract through a documented Pega interface, then a mapping into Flowable runtime and history tables. Agree in writing how in-flight cases will finish, either in Pega until closure or by migrating them, and confirm the history retention Pega applies.

Integration connections and credentials

Connectors, data pages, service definitions and their stored credentials are tied to Pega's configuration and secrets handling. Archives do not transfer usable passwords or tokens, so each external system connection must be recreated in Flowable services and re-authenticated with new credentials. Ask Pega which connector metadata can be exported and which secrets must be re-entered by your team.

Reporting and decisioning data

Reports, decision strategies, adaptive model data and the metrics they depend on live in Pega's data layer and are not part of the rule export. Keep reporting in a separate analytics store and extract the data you need through a supported interface, then re-create decision logic as DMN tables. Confirm with Pega which decisioning artifacts can be exported and which must be rebuilt.

The export sequence and how to verify each step

This sequence turns Pega's documented export tools into a verified, checksummed set of archives with a written inventory, so you know exactly which rules and case data you hold before any migration work starts.

Freeze scope and inventory applications
Before exporting anything, record which applications, versions, rulesets and case types are in scope, and freeze changes to them for the export window. Someone on the Pega development team and someone from the business owner group should sign off on the list. The inventory is complete when every application and ruleset has a name, version, owner and the environment it was exported from. Keep this list as your baseline for every later check.
Export each application with the Export wizard
For each application on the inventory, run the Export wizard in Pega Platform (or Deployment Manager if your environment uses it) to produce an application archive, ruleset archive or product archive. Export from one named environment and record which user ran the export and when. The step is done when each application has a downloaded archive file and the wizard reports no errors. Confirm the current export options and archive formats in Pega's documentation for your Infinity version, since the wizard's behavior varies by release.
Script prpcServiceUtils for repeatable runs
If you need the same exports to run again, or across several environments, wrap the documented prpcServiceUtils command-line tool in a script and store it in version control. Parameterize the environment URL, credentials source and application list, and never hard-code passwords in the script. The step is complete when a scripted run reproduces the archives from the manual run with the same contents. Confirm the exact command syntax and supported options with Pega's current tool documentation and your platform team.
Extract case data through documented interfaces
Rules do not contain live case data, so pull case instances separately using the interfaces Pega documents for data extraction, such as its reporting or data export functions and the REST services it exposes for case retrieval. Filter by case type and date range as defined in your inventory, and write output to an encrypted location with access restricted to the migration team. The step is complete when record counts per case type match the counts reported by Pega for the same filters. Confirm with Pega which extraction interface suits your version and data volume.
Verify archive contents against the inventory
Open or list each archive and compare its contents with the inventory from the first step. Check that every application, ruleset and version is present, and note any rule types or dependencies that the export did not include. Record discrepancies in an exceptions log with the reason and the person who accepted it. The step is done when every inventory line maps to an archive entry, or to a logged exception that someone with authority has signed off.
Store checksums and evidence together
Generate a SHA-256 checksum for every archive and every case data extract, and write them to a manifest file stored separately from the archives. Keep the inventory, the exceptions log, the script version, the operator names and the export timestamps in the same evidence folder. The step is complete when the manifest can be re-verified by recomputing checksums on a different machine and the results match. This evidence supports any later audit trail or data residency review.
Confirm restore and readability before decommissioning
Before any Pega environment is retired or frozen, test that the archives can be read by someone outside the original export team. Open the rule archives in a non-production Pega environment or review the contents with the Pega team, and confirm that the case data extracts load into your target analysis tool. The step is done when a named reviewer signs off on the results. Keep the signed report with the manifest, since it shows what you can reconstruct, not only what you copied.

Why Pega archives move rules rather than portable process models

Pega's export tools move Pega rules, not portable process models. An application, ruleset or product archive packages rule instances such as case types, flows, data transforms, decision tables and UI sections in Pega's own rule format, and only a Pega runtime interprets that format. Treat the archive as a specification to read and re-implement on Flowable, not as a file a BPMN engine can execute. Before you export anything, inventory which rule types the application uses and which of them carry logic you must rebuild, because that inventory, not the archive size, determines the effort.

Flowable works from a different starting point. Its engines execute standard BPMN 2.0 process models, CMMN case models and DMN decision tables, and it exposes Java and REST APIs under the Apache 2.0 license. Those models are readable outside the product, which is why they can be version controlled and reviewed in your own repositories. Pega's rule model combines processes, data, decisions and user interface in one proprietary structure, so a mapping exercise is needed for each rule type. Confirm with Pega which rule types your version exports in each archive, and confirm the same for any Pega-hosted components, since some configuration may not appear in an application archive at all.

Documented migration tooling exists for some other platforms. Camunda publishes a Data Migrator for moving running Camunda 7 process instances to Camunda 8, and the Operaton repository describes a REST API, database schema and deployable BPMN and DMN models that stay compatible with Camunda 7, along with an OpenRewrite recipe for migrating code. Those paths show what a vendor-supported migration looks like. Nothing comparable is supplied here for Pega rules, so ask Pega and your Flowable partner to confirm in writing what, if anything, can be converted automatically before you plan the work on that assumption.

Who runs the export under Pega Cloud and client-managed cloud

Under Pega Cloud, Pega operates the underlying infrastructure as a managed service. Your platform team does not run the clusters, databases or Pega Infinity nodes that host the application, so the hosting layer is Pega's responsibility under your agreement. Exports are typically initiated by your administrators through the documented Pega tooling available inside the environment you can reach, while Pega's operations staff control the layer beneath it.

Infrastructure operation: Pega runs the hosting layer, including platform availability and maintenance, as part of the service you license.
Access for exports: Your administrators use the Export wizard and application-level tooling inside the Pega environment. Do not assume host-level or database access is available.
Storage of archives: Confirm where generated archive files are written, how long Pega keeps them, and how you retrieve them into storage you control.
Backups and schedules: Ask Pega how backups are taken and whether you can request an export on a schedule that fits your exit plan.
Support boundaries: Establish in writing which export problems Pega supports and which fall to your own team.

Check the access model, retrieval route and retention terms in your agreement before you schedule any migration milestone that depends on an export.

What to plan before the Pega contract ends

The export itself is the easy part to start. The harder decisions are contractual, calendar-based and staffing decisions that have to be settled before the contract ends. Each card below names what to put in writing from Pega before you rely on an export.

Confirm export scope and access rights

Ask Pega in writing which application, ruleset and product archives you are entitled to produce, whether that covers all ruleset versions and data instances, and whether your contract allows exports to continue after termination. Confirm which roles in your organization can run the Export wizard, Deployment Manager and the prpcServiceUtils command-line tools, and whether those roles need Pega-issued credentials. An export you cannot legally or technically run at the end of the contract leaves you with no archive.

Align the export window with releases

Map your planned export dates against the Pega Platform release cadence and the support lifetime of the version you run, so that you export from a version you can still reproduce and restore. Ask Pega which version your contract covers, when hotfixes stop for it, and whether an upgrade is needed before export. Exporting from an out-of-support version can leave you with archives that are hard to load into a later environment.

Keep a read-only reconciliation period

Plan a window in which Pega stays available in read-only form after the final export, so your team can compare exported rules and case counts with the source system and close gaps. Ask Pega in writing whether a read-only or reference environment is included, for how long, and what it costs. Without this period, discrepancies found during re-implementation may no longer be checkable against the original.

Retain archives and checksums

Store each archive, its manifest and a checksum in your own records system under your retention policy, and record who ran each export and when. Confirm with your legal and compliance team how long case data and rule history must be kept, and whether Pega case data exports fall under that schedule. Keeping a checksum next to each archive lets you show later that a file was not altered.

Plan developer capacity for rule rebuilds

Pega rules export as Pega rule archives, not as portable BPMN, CMMN or DMN models, so re-implementing case types, flows and decision logic on Flowable is developer work that has to be scheduled. Estimate with your team how many Pega-skilled and Java-skilled engineers you need and when they start, and ask any implementation partner for a written scope and timeline before the export window closes. Illustrative example: a team that has not started rule inventory by the final export date may need the read-only period to finish it.

Questions teams ask before exporting from Pega

How much effort does a full export from Pega Platform take?

The effort depends mostly on how much Pega content you have and how much of it is customized. The number of applications, the number of rulesets and their versions, the volume of case and work data, and the amount of Java or custom rule code all add work. Each application needs to be packaged, checked for dependencies, and tested in a clean environment. Ask your Pega administrator to inventory applications, rulesets, data classes and integrations before you scope the work, since that inventory is what turns a vague estimate into a written plan.

How long does an export take, and what sets the timeline?

The timeline is set by the inventory, the number of export and verification cycles, and the availability of people who know the applications. Archive creation itself is usually the shortest step. The longer steps are reviewing which rules are still in use, deciding what to keep, validating that archives import cleanly into a test environment, and agreeing on data retention rules with data owners. Any change freeze or compliance review on the Pega environment also extends the schedule. Ask for the timeline to be tied to specific milestones in a written scope.

What does the internal team need to provide for the export?

You need three groups. Pega administrators run the Export wizard or Deployment Manager, manage access and confirm the Pega version and hosting model. Developers who know the rules explain customizations, Java code and integrations that the archive will not describe in business terms. Data owners decide which case records must be kept, for how long, and who may see them. Without named people in each group, exports stall at the first unclear rule or dataset.

Can our own team run the Pega export without outside help?

Yes, if your team already administers Pega and has the access to run the documented tools. The Export wizard, Deployment Manager and the prpcServiceUtils command-line tools are part of the product, and an experienced administrator can produce application, ruleset and product archives. What is harder is judging completeness and deciding what each archive means for a non-Pega target. Check the exported output against your inventory, and confirm the exact tool steps for your Pega version with Pega's documentation or your Pega support contract.

What does outside help cover during the export?

Outside help usually covers the parts that need cross-discipline judgment: the inventory, the decision on which rules to keep or retire, the test restores into a clean environment, the documentation of what each archive contains, and the handover of case data plans. DeployOpen plans, implements, documents and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope.

Are the Pega archives enough to move our cases to Flowable?

No. Pega archives move Pega rules and their packaging, not portable process models. A Flowable target needs BPMN, CMMN and DMN models, forms, identity integration and data migration written for that engine. Archives tell you what existed and how it was configured, which is valuable for planning and for audit evidence of the source system, but the rebuilt processes still require design and development. Treat the archives as the source record, then plan the re-implementation as a separate workstream.

Do we need to keep the Pega archives after migration?

Often yes, at least for the period your retention policy and regulators require. Keep archives in a controlled location with access logs, record their checksums, and document which Pega version produced them. Confirm retention obligations with your compliance and legal teams, since they depend on your sector and jurisdiction. Note that a retained archive is only useful if someone can still read its format, so record the Pega version needed to interpret it.

How DeployOpen works on this

DeployOpen treats a Pega export as a written, fixed-scope engagement that starts with an inventory of what Pega actually holds. We map each application, ruleset and data source to the Flowable engine work it would need, then agree deliverables and timelines in writing before any export or rebuild begins.

How we scope

Inventory the applications, rulesets, case types and archives your team plans to export from Pega Platform.
Identify which exported artifacts are Pega rules and which are data that needs a separate extraction path.
Agree in writing which export tools, environments and evidence formats the engagement covers.
Confirm the Pega version and client-managed or Pega Cloud hosting, since these shape the export options.

How we build

Run the Export wizard, Deployment Manager or prpcServiceUtils steps in a copy of your environment first.
Store archives in your own infrastructure with access controls and checksums recorded for each file.
Build a Flowable proof of concept for one case type so mapping gaps surface early and are documented.
Test restored data and processes in a non-production environment before any cutover decision.

How we hand over

Deliver an export runbook listing each command, input, output location and the person who ran it.
Document a rule-to-model mapping that shows what carries over to BPMN, CMMN and DMN and what does not.
Provide a gap register of Pega rules that need custom development, UI rebuilding or a retirement decision.
Walk your engineers through the Flowable deployment so the knowledge stays with your team.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover Flowable version upgrades, such as tracking the 8.0.0 release notes for Spring Boot changes.
Plan backup and recovery for the Flowable database and exported archives under your own retention policy.
Ask any support provider to confirm response terms and scope in writing before you sign.

How to export your data from Pega Platform