Could We Actually Move It?

So far this series has treated portability as an architecture problem: preserve the organisation's business meaning independently of the platform, understand which part represents the organisational delta, and govern that knowledge while the capability evolves.

But there is an obvious challenge to all of that theory.

Could we actually move it?

Not in the sense of exporting a package from one environment and importing it into another environment from the same vendor. Enterprise platforms already provide mechanisms for that.

The more interesting test is whether a capability implemented using one vendor's process and case abstractions could be represented neutrally enough to provide a meaningful starting point on a different platform.

I do not think the answer is a simple yes or no. It depends on what we mean by "move".

Start by rejecting the one-file migration

It is tempting to imagine a canonical file that can be exported from Platform A and imported into Platform B.

BPMN gets mentioned frequently because it gives us a recognised process notation and machine-readable schema. jBPM, for example, has long supported BPMN 2.0 XML as an executable process format. Appian describes BPMN as the basis for its process modelling experience and turns process models into executable workflows.

That sounds promising until case management enters the picture.

A rich case application may organise work through stages, milestones, states, related cases, events, rules, discretionary activity and data-driven behaviour. Flattening all of that into one process graph is likely to lose meaning even if the resulting BPMN is technically valid.

CMMN exists precisely because case-oriented work is not the same thing as a predefined activity sequence. The OMG describes it as complementary to BPMN and centred on cases, events, living information and work that may happen in less predictable orders.

The implication is important: there probably is no single canonical file.

The canonical model is a bundle of meaning

The vendor-neutral representation from Part 1 starts to look less like an export format and more like a bundle of related models.

BPMN, DMN and CMMN can potentially describe parts of that bundle. They do not remove the need for additional metadata, and they certainly do not guarantee that every target platform will support every construct in the same way.

But they demonstrate the more important point: standards can give us a vocabulary for meaning even when they cannot give us a universal deployment package.

A thought experiment: Pega to Appian or jBPM

Imagine an established case-management capability implemented in Pega. It uses a case lifecycle with stages and processes, conditional steps, child cases, decision rules, integrations, SLAs and organisation-specific exception handling.

It may also be delivering value in ways that are less visible in the process model itself: automating manual work, ensuring cases pass through the same governed path, enforcing business controls and retaining a history that operations, risk and audit can interrogate later.

We want to move that capability elsewhere.

The wrong first step would be to ask how to convert every Pega artefact into an Appian or jBPM artefact.

That immediately turns the exercise into a proprietary object-to-object mapping problem. It also risks preserving implementation choices that made sense only because of the source platform.

A better sequence might be:

The neutral representation becomes an intermediate language between two different platform paradigms.

The targets expose different problems

A target such as jBPM makes one part of the experiment relatively straightforward because BPMN 2.0 is a native execution format. Control flow that can be faithfully represented in BPMN has a clearer route into the target runtime.

But that does not magically solve the rest of the application. Case semantics, data, UI, integrations, security and operational behaviour still need an implementation. Even where a process is portable, the capability around it may only be rebuildable.

Appian presents a different shape of problem. Its process modeller uses BPMN concepts and executes process models, but Appian's own deployment mechanism packages process models and their related Appian objects for import into another Appian environment. That is useful product portability, not cross-vendor portability.

So a neutral model would still need translation into Appian's application structure, rules, interfaces, records and integrations.

The interesting thing is that both target scenarios could still benefit from the same vendor-neutral source. The amount of generation versus redesign would simply be different.

Translation will be lossy

This is probably the point where the concept needs to become realistic rather than elegant.

Cross-platform process translation will be lossy.

One platform may have a first-class case concept that another expresses through processes and records. One may support declarative rules where another expects explicit orchestration. One may provide sophisticated work queues or SLA constructs that need a different implementation elsewhere.

Trying to preserve exact technical equivalence could produce a poor target design.

The goal should be semantic equivalence where it matters, not structural equivalence everywhere.

If a source platform expresses an organisational rule as a proprietary declarative construct, the target does not need an identical construct. It needs to reach the same intended business outcome, with the same important constraints and controls.

That is a much more achievable definition of portability.

The vendor community can be part of the migration asset

There is a non-technical source of leverage here too. Mature platform communities contain years of practical knowledge about how different industries solve recurring workflow, case and automation problems.

Pega has forums, communities of practice and Expert Circles. Appian's community provides discussion and shared learning for developers. Camunda's community runs forums, chapters and meet-ups where users share company use cases and implementation approaches.

For an enterprise migration, those communities can help in two directions. The source community can help distinguish product convention from organisation-specific design. The target community can expose established ways of solving the same problem without recreating the source platform's mental model.

There is also a broader opportunity when several enterprises use the same vendor framework. Working groups around shared problem statements can turn one organisation's migration challenge into a reusable pattern rather than a private reinvention. That collective learning is not a substitute for architecture, but it can materially improve the quality of the translation.

Where AI could change the economics

This is also where generative AI starts to make the original idea more plausible.

Traditional migration tooling works best when there is a deterministic mapping between source and target objects. Cross-vendor BPM and case migration has too many semantic gaps for that approach to cover the whole problem.

An AI-assisted accelerator could operate differently.

It could inspect source configuration and documentation, infer the business meaning, compare it with the vendor-neutral model, identify ambiguity, and propose a target implementation using the destination platform's own patterns.

That would make it less like a compiler and more like a migration co-pilot.

The most valuable output might not be generated code. It might be a confidence-scored mapping:

That would make the migration problem visible much earlier and concentrate human effort on the places where architectural judgement is actually required.

How would we know the migration worked?

A successful migration cannot be judged solely by whether the target process looks like the source model, or even by whether the financial case lands as expected.

The stronger test is whether the target preserves the business outcomes that made the source capability valuable in the first place.

Historical execution data could become extremely useful here. Process mining and event logs could compare the real behaviour of the source capability with the reconstructed target, helping identify differences between the documented process and the one the organisation actually operates.

That creates an intriguing possibility: migration could combine design-time semantics with runtime evidence rather than trusting either one in isolation.

In that model, control equivalence and auditability become first-class migration acceptance criteria alongside functional and financial measures.

A head start, not a magic button

I do not think this experiment ends with one-click migration between BPM platforms.

Nor should that be the standard by which the idea succeeds or fails.

If a vendor-neutral representation allows an organisation to preserve its decisions, case meaning, process logic, data semantics, controls and operational intent, then a future migration starts from a very different place.

Instead of rediscovering the business through workshops and reverse engineering, the target team begins with a structured description of what needs to survive and where the source implementation depended on proprietary behaviour.

Some elements may genuinely move. Some will translate. Some will be rebuilt. Some should be redesigned because the new platform offers a better approach.

That still sounds like a significant reduction in migration uncertainty.

But there is one more dependency we have not addressed. Even if the organisation can move the process knowledge, can it move the capability to build and operate the replacement?

Technology does not transition itself. People do.