ProcessMaker 2 → 3 Migration - Gaddiel Essuman-Acquah

Problem

GTBank’s workflow platform was on ProcessMaker 2, which was reaching end of vendor support. Migrating to ProcessMaker 3 was non-negotiable, but the platform underpinned 65+ business workflows across approvals, compliance checks, finance, legal, and operations, touching 500+ daily users. Any disruption would ripple through every department.

PM2 and PM3 are different products under the same brand: different runtime (Symfony vs older PHP), different APIs, different BPMN engine. There was no automated migration path. Every workflow had to be rebuilt.

Approach

Rebuilt every workflow in PM3 from scratch, in parallel with PM2 staying live until cutover.

BPMN-first redesign. Modelled every workflow in BPMN before implementation, capturing the actual business logic rather than the PM2 quirks. Many workflows had accumulated workarounds for PM2 limitations that PM3 made unnecessary.
PHP/JavaScript implementation. Workflow logic, validations, and integrations rebuilt in PM3’s PHP/JS environment. REST API integrations connected to other bank systems where PM2 had used direct DB calls.
Performance optimisation. Caught and fixed performance bottlenecks during the rebuild (PM2 had been slow; users had learned to wait). Cleaned-up workflows ran 40% faster.
Manual-step reduction. Every workflow was reviewed for opportunities to automate steps that PM2 had required to be manual. Cut manual intervention across the workflow portfolio by 30%.
Phased cutover. Migrated workflows in waves by department, with PM2 and PM3 running in parallel for two weeks per wave. Rollback was always one config flip away.
User training. Delivered training materials that cut onboarding time by 50% (users came to the migrated workflow already knowing how to use it).

”Like-for-like” is usually the wrong frame for a major platform jump. PM2 workflows had accumulated workarounds that disappeared in PM3 entirely. Rebuilding from BPMN beat translating PHP, every time.

Architecture

PM2 workflow legacy + quirks

→

BPMN model business logic, cleaned

→

PM3 build PHP · JS · REST

→

Parallel cutover 2-week wave per department

Each workflow took the same trip: legacy PM2 form back to its BPMN essence, then forward to a clean PM3 implementation, then a two-week parallel-run window before the department flipped over. PM2 and PM3 lived side by side for the duration, so rollback was always one config flip away.

What it shipped

500+ users migrated across the bank without operational disruption

65+ business workflows rebuilt and delivered

+40% average workflow runtime improvement

Manual intervention across the workflow portfolio fell by 30%. User onboarding time to the new platform dropped by 50%, thanks to training materials prepared in advance of each wave.

Reflections

Don’t translate, redesign. Treating a major platform jump as “like-for-like” carries forward all the workarounds the old platform forced. Modelling from BPMN catches the ones the new platform makes unnecessary.
Phased cutover with parallel running is non-negotiable for systems with hundreds of users. The two-week parallel window per wave caught a few edge cases that didn’t surface in testing.
Pre-launch training materials are worth their weight. The 50% reduction in onboarding time wasn’t from making PM3 simpler. It was from users arriving prepared.
Performance gains came from the rebuild, not the platform. PM2 had been slow because nobody had time to clean it up. PM3 inherited fresh BPMN with no accumulated workarounds.