TIBCO ActiveMatrix BPM. IBM BPM. Oracle BPM. Metastorm. Bizagi on-prem. The approval flows and casework they carry are as critical as ever — but the platforms under them are orphaned, squeezed, or forked. Marcus, Kinetech's AI Mendix developer, reads the process definitions those platforms export and rebuilds each process as a modern Mendix application: gated by your approvals, proven with published evidence, owned by you.
01 · The clock
This isn't one product's end-of-life story — it's a pattern across a whole product generation. The engines got old, the vendors moved on, and the "upgrade" on offer is a re-platform of your processes either way. The only real question is where they land.
| Platform | Where it stands | What "staying" actually costs | What Marcus reads |
|---|---|---|---|
| TIBCO AMX BPM | 4.3.0/4.3.1 support ended Dec 2025; 5.x is a re-platform | Renewal escalation on a platform generation the vendor has closed out | Business Studio projects — XPDL 2.1 process XML |
| IBM BPM / BAW | 21.0.x in extended support; 8.x estates unsupported | S&S plus an eventual Cloud Pak migration project | .twx exports — a zip of XML artifacts, Coaches included |
| Oracle BPM 12c | Premier ends Dec 2026; OIC lacks a parity workflow engine | Extended support fees against a closing window | BPMN 2.0 XML inside SOA composites |
| OpenText Metastorm | Legacy line; successor is AppWorks with no automated path | A rebuild deferred, not avoided | .xep exports — zipped XML of maps, stages, actions |
| Bizagi on-prem | Sales ended 2022; support ended Dec 2022 | Running unsupported, or the vendor's cloud rebuild | BPMN 2.0 export plus model metadata |
02 · The differentiator
Under every one of these suites sits the same anatomy: a process model, task forms, business rules, an org model, and a worklist — serialized as XML your platform will export today. Marcus reads those exports and derives the full functional specification of each process, before a single workshop is booked.
| BPM artifact | What Marcus extracts | Where it lands in Mendix |
|---|---|---|
| Process models (XPDL / BPMN / .twx / .xep) | Activities, sequence and parallel paths, deadlines, escalations | Mendix Workflows — user tasks, parallel splits, timer-driven escalations |
| Task forms & Coaches | Field inventories, layouts, bindings, visibility rules | Pages bound to the workflow's case data |
| Business rules & expressions | Routing conditions, validations, calculations, embedded script logic | Microflows and decision logic — documented and testable |
| Org models, roles & teams | Positions, groups, capabilities, task-assignment rules | User roles with Entra/LDAP single sign-on |
| Worklists | Queues, priorities, claim/assign behavior | The Mendix task inbox |
| Integration touchpoints | Service calls, data mappings, system connectors | REST/SOAP/OData integrations — inventoried per process |
| Audit & reporting history | Instance history and audit tables in the runtime database | Archived to your warehouse or read-only history entities |
Why this matters: the migration tools that exist convert process diagrams. The application around the diagram — the forms, the rules, the roles, the security — is where the rebuild cost lives, and that's exactly what Marcus rebuilds, tests per role, and proves with published evidence.
03 · How a migration runs
In-flight instances are the objection that stalls every BPM migration, so we plan for them explicitly: freeze new starts on the legacy platform, start new cases in Mendix, and let the legacy worklist drain to zero. Only genuinely long-running processes need state-level migration — identified and scoped in the assessment, never discovered mid-project.
The same four approval gates that govern every Marcus engagement govern each migrated process — held by you:
The extracted specification of each process — activities, rules, roles, integrations, what carries forward — approved by you before a line of the model is written.
The translated org model — who can claim, act on, and see each task and case — presented in plain English for sign-off.
Modern, branded design directions for the task and case screens presented before pages are generated. You pick; Marcus builds to it.
Each process reaches you only after all quality gates pass; it cuts over only when you accept it, evidence in hand.
04 · The date
Here is the commitment we will put in writing. The assessment does not end with a range — it ends with a date, sized from your actual extracted complexity. Miss that date and the assessment fee comes back. We can promise a date because we never quote a calendar before reading your source.
The assessment names the date. Miss it, and the assessment fee comes back.
That is a real term, not a slide. It is affordable to us for one reason: the clock below starts only when a complete artifact pack is in our hands, and it pauses only for your own approval gates.
| One process family plus its task UI | Complete artifact pack → UAT-ready |
|---|---|
| Compact — one process, ≤15 activities, largely generated forms | 3–4 weeks |
| Departmental — 2–4 related processes, custom task UI, 3–6 system touchpoints | ~45 days typical |
| Load-bearing — process families with heavy ESB or BPEL orchestration, custom coaches, a rules engine | 10–16 weeks |
| Each further process family in the same estate | 30–40% faster |
Sizing model, not a price list — the assessment reads your actual source and returns one date. Bands assume a single rebuild boundary agreed at the scope gate.
The date is only honest if the inputs are complete, so here is the whole list up front. Nothing on it is unusual, and most of it exists already.
Three approval gates are yours: scope, permission ratification, design sign-off. We answer each within three business days. Time beyond that on your side moves the date by exactly that much — and nothing else does.
Production cutover on your change calendar. SSO and network provisioning by your IT. Third-party licenses or vendor contracts we don't control. Remediation of source-data quality problems the assessment flagged. Anything added after the scope gate.
Functional parity against the approved specification, running on your migrated data in a parallel environment, with production security enforced and tested per role, all nine quality gates green, and documentation published. Your users click through it.
The process XML extracts cleanly across all of these platforms — one pipeline reads them. What moves a BPM date is everything around the process: straight-through ESB and BPEL orchestration, which we will tell you to leave with an integration platform rather than rebuild in Mendix, and in-flight instances, which run down on your calendar under a separate plan and are not part of this clock.
05 · Why Mendix
Every landing zone your migration shortlist will contain solves part of the problem. The BPM applications your business actually runs on — forms, rules, roles, data, and a process engine in one — deserve a platform that is all of those things at once.
The honest boundary: straight-through, system-to-system orchestration with no human tasks — ESB and BPEL-style integration flows — fits Camunda or an iPaaS better than Mendix. The assessment disqualifies those explicitly. We'd rather migrate fewer processes and be right about all of them.
06 · Straight talk
| Area | The honest position |
|---|---|
| Process logic | Activities, routing, deadlines, and escalations transfer from the exported models. Embedded script logic (Coach JavaScript, Metastorm JScript) is read and re-implemented as microflows — reviewed in the spec you approve, not transliterated blindly. |
| In-flight instances | Run-down, not state migration, for the vast majority. Genuinely long-running cases (multi-year claims, matters) get an explicit state-migration plan — scoped and priced before you commit. |
| Reporting history | Your legacy runtime database is queryable SQL; history is archived to your warehouse or imported as read-only entities. We do not promise live continuity of the legacy platform's own reports. |
| Custom integrations | Service calls and connectors are inventoried per process from the exports. Standard REST/SOAP/SQL touchpoints rebuild cleanly; exotic custom brokers are named in the assessment with a per-item plan — this is where discovery pricing lives, stated up front. |
| Straight-through orchestration | Integration-only flows without human tasks are disqualified from the Mendix scope and pointed at Camunda or your iPaaS. It makes the migration smaller and the recommendation credible. |
| Your org model | Positions, groups, and assignment rules map to Mendix roles with Entra/LDAP SSO — ratified by you at the permission gate, and proven with per-role tests including negative cases. |
07 · Quality & security
Watch real build evidence land on the live Build Console, and see the delivery lifecycle at our interactive explainer.
08 · Engagement & pricing
Send your platform exports — .twx, .xep, XPDL, BPMN. Marcus reads them and returns a scored inventory: processes, forms, rules, roles, and integration touchpoints, each classified migrate / retire / disqualify, with complexity-scored fixed quotes for the first wave. About two weeks.
Credited toward onboarding if you proceed.
Each process quoted from its actual extracted complexity — not a day-rate guess. Built, tested per role, documented, and delivered through the approval gates with published evidence, then run down on the legacy side.
Best for a first wave of 3–10 processes.
For large process estates: a Marcus instance works your migration backlog continuously. Priced on what the work is, how many lanes run in parallel, and how fast you need it — always with Kinetech engineer review and an escalation SLA.
Bring your own Claude access: roughly 15–25% off the monthly.
Every figure here is an indicative range; your actual range is confirmed in writing before anything is charged. On bundled plans, heavy build months may incur metered usage beyond the included allowance; your quote states the allowance plainly. Your applications, models, and repositories are contractually yours.
09 · The questions you should ask
It makes big-bang migration impossible — which is why nobody credible proposes one. The run-down pattern sidesteps the problem for most processes: freeze new starts on legacy, start new cases in Mendix, drain the old worklist over weeks or months while both run side by side. The exceptions — genuinely long-running cases that can't wait out a drain — are identified in the X-Ray and given an explicit state-migration plan with its own price. You'll know which bucket every process is in before you commit to any of them.
For the engine, often yes — and for developer-led, integration-heavy orchestration we'll recommend it ourselves. But Camunda is deliberately an engine, not an application platform: it does not provide your task forms, case screens, or end-user experience. For human-task applications, choosing Camunda means signing up for a second project to rebuild the UI in something else. Mendix delivers the process, the forms, the data, and the security as one tested application — which is what your users actually touch.
Read what the incentive buys: a rebuild of your processes on the same vendor's next platform, priced attractively precisely because the rebuild locks you in for the next decade. If the move were an upgrade, it wouldn't need incentives. Since the work is a rebuild either way, the decision worth making is which platform you'd choose if you were choosing fresh — and whether the vendor whose commercial behavior triggered this evaluation is the one to re-commit to.
They're in the exports — positions, groups, capabilities, and assignment rules are part of what Marcus extracts. They map to Mendix user roles and access rules, wired to your Entra or LDAP directory, and the mapping isn't asserted: you ratify the translated permission model in plain English before build, and every release publishes per-role test evidence including negative cases — the reviewer who shouldn't approve their own request demonstrably can't.
The history lives in your legacy platform's runtime database, which is ordinary SQL. We archive it to your warehouse or import it as read-only history entities alongside the new process — queryable and auditable, clearly separated from live cases. What we won't promise is live continuity of the legacy platform's own report screens; that honesty is cheaper than discovering it at cutover.
Mid-renewal is exactly when the math is clearest. The X-Ray takes about two weeks and prices your first migration wave as a fixed number — which turns your renewal conversation from "pay the uplift or else" into a comparison between two known costs. Several processes can run down inside a final renewal term; the assessment tells you whether yours can before you sign anything.
10 · Next step
Pick your highest-volume approval process, a case-management process, and the one with the hairiest org-model rules. Export them — .twx, .xep, or XPDL — and we'll return the scored specs: what carries forward, what changes, what we'd disqualify, and a fixed price to rebuild each. Judge the approach on your own processes, not on a slide.
Marc Lehane · Solutions Architect / CTO, Kinetech · [email protected]
Kinetech Cloud · San Antonio, TX · How we deliver · Live Build Console
You are reading Your platform — deeper detail on step 4, Why now?.
That is the pressure. What it costs to answer it is not one number — three things move it.