The Human Layer

It is possible to get surprisingly far into a technology portability discussion before talking about the people who would actually have to make it work.

We can define a vendor-neutral representation. We can identify the organisational delta. We can improve contracts and governance. We can imagine tooling that translates process and case semantics into a new platform.

And then the organisation still has to design, build, test, operate and improve the replacement capability.

A process is not portable if the knowledge required to sustain it is not portable too.

That is the final layer in the series, and in many organisations it may be the hardest one.

Platform expertise is part of the dependency

Mature BPM platforms build ecosystems around themselves: product specialists, architects, developers, administrators, implementation partners, certifications, delivery methods and communities of practice.

That ecosystem is another accelerator. It allows organisations to assemble delivery capability quickly and gives teams access to patterns learned across many implementations.

It can also create a genuine network effect. When multiple enterprises adopt the same framework, practitioners can compare approaches, form working groups around common problem statements, share lessons and build on solutions that have already been tested elsewhere. Vendor communities such as Pega's Expert Circles, Appian Community and Camunda's chapters and forums make that collective learning visible.

That should be counted as part of the value proposition, not dismissed as incidental ecosystem noise. A move away from a platform may mean leaving behind not only tooling but a mature body of shared knowledge and peer support.

But the same ecosystem also creates a human form of platform dependency.

A team may understand how to solve a problem very effectively in one product because years of experience have taught them which constructs to use, which ones to avoid, where performance problems appear and how the platform behaves under pressure.

Move to another product and much of that implementation intuition no longer applies directly.

The organisation has not lost the people. But some of their accumulated expertise has been anchored to the platform in exactly the same way that application behaviour can be anchored to proprietary constructs.

Not all knowledge is platform-specific

The encouraging part is that a large amount of capability should transfer.

Domain knowledge does not disappear because the workflow engine changes. Nor do strong skills in process analysis, decision modelling, service design, architecture, testing, integration, controls or operational management.

That suggests another useful split.

That mirrors the portability spectrum we used for process assets earlier in the series.

The objective should not be to pretend that every skill is vendor-neutral. It should be to understand which knowledge we want to retain and create a deliberate bridge for the knowledge that needs translation.

The people who know why matter most

During a large platform transition there is a natural temptation to focus on the people who know how the existing system works.

They are clearly important. Someone has to explain the source configuration, integrations, exceptions and technical behaviour.

But the people who know why it works that way may be even more valuable.

Why is that approval needed? Why does this case wait before progressing? Why does one customer segment take a different route? Why was that control introduced? Why is a rule deliberately stricter than the apparent policy minimum?

Those answers often sit with a mixture of operations specialists, product owners, risk teams, architects, analysts and long-serving engineers rather than in the process model itself.

If those people leave the transition before their reasoning has been captured, a technically successful migration can still lose organisational knowledge.

This is why the vendor-neutral representation needs intent and rationale alongside executable semantics. It gives human knowledge somewhere to land.

Reskill or replace?

Platform migrations often create a blunt workforce question: do we retrain the existing team or bring in people who already know the target technology?

In practice, I suspect the strongest answer is usually both.

A team made entirely of source-platform specialists may struggle to challenge old implementation patterns. It can accidentally recreate the previous product inside the new one.

A team made entirely of target-platform specialists has the opposite risk. It may use the new product elegantly while misunderstanding the business meaning that has accumulated in the old capability.

The transition team needs people who understand the source, people who understand the target, and people who can protect the business meaning between them.

That middle group is easy to underestimate. Enterprise architects, process analysts, domain specialists and experienced engineers can act as translators between implementation paradigms, provided they are working from a sufficiently clear representation of the capability.

Use the target community as an accelerator

A migration programme should not treat target-platform expertise as something that only comes from a delivery partner. The wider vendor community can be part of the transition strategy.

Community forums, expert groups, meet-ups and user networks can expose internal teams to established target patterns, common failure modes and alternative ways of solving problems that were previously expressed through source-platform constructs.

That matters because the goal is not to translate one vendor's implementation literally. It is to preserve the business intent while learning how the target ecosystem solves the problem well.

For large enterprises, there may be even more value in joining or creating working groups around common industry problems. Several organisations moving through similar platform or regulatory challenges can collectively test patterns, compare controls and influence vendors in ways that would be difficult for one customer acting alone.

Do not train people to reproduce the old platform

Reskilling also needs a clear objective.

If the target is Appian, jBPM, Camunda or another platform, the goal should not simply be to teach the existing team the buttons and syntax required to rebuild the old solution feature for feature.

The team needs to understand the new platform's philosophy: how it wants work to be modelled, where it expects rules to live, how it treats data, how it handles events, what it automates well and where its boundaries are.

Otherwise the migration can preserve the worst kind of lock-in: the old platform's mental model transplanted into the new product.

Semantic portability should preserve business intent, not freeze historical implementation choices.

Run the transition as a learning system

This suggests a different way to organise a migration programme.

Rather than treating skills transfer as a training workstream that happens alongside delivery, make learning part of the delivery model itself.

Done well, each migrated capability makes the next one easier. The organisation is not only moving applications; it is building a new delivery capability as it goes.

The implementation partner can become another anchor

There is a final irony worth calling out.

An organisation can spend millions reducing dependency on one platform and accidentally replace it with dependency on the consultancy performing the migration.

If the partner owns the translation tools, holds the only target-platform expertise, understands the mapping logic and leaves behind a solution the internal team cannot confidently change, the technology has moved but the strategic dependency has not.

So the same principles from Part 2 apply to the migration itself. What IP is the partner bringing? What knowledge is being created during transition? What will the organisation be able to operate and evolve independently afterwards?

Exit capability should include exiting the exit programme.

What this means for the original question

This series started with a tension in the BPM market.

Vendors create enormous value by making their platforms more opinionated: stronger industry frameworks, better case abstractions, reusable accelerators and increasingly AI-assisted development. Those capabilities help organisations reach outcomes faster and can materially improve the return on a platform investment.

That value also comes from execution. Automation removes manual work. Governed process models create consistency. Embedded controls reduce reliance on individual interpretation. Case history and audit evidence make the resulting operation easier to understand and assure. And vendor communities allow organisations to learn from a much wider pool of practitioners than their own delivery team.

The problem is not that those accelerators are proprietary.

The problem appears when the organisation's own knowledge becomes indistinguishable from the proprietary capability underneath it.

I do not think complete portability is a realistic goal. Different platforms are different for a reason, and a future transition will always involve engineering, redesign and learning.

But perhaps the bar does not need to be "move the application unchanged".

A better goal may be to preserve enough business meaning, controls, rights, provenance and organisational capability that changing platform does not mean rediscovering the business from scratch.

That means using open standards where they genuinely help, but not pretending BPMN or any single format can flatten the semantics of modern case management.

It means maintaining a vendor-neutral representation that can combine process, case lifecycle, decisions, data, events, operational metadata, controls, audit expectations and rationale.

It means knowing which part of the solution is the organisational delta, preserving the right to use it, and governing that knowledge while it changes.

It means accepting that translation will be imperfect while using tooling, AI and community knowledge to reduce the amount of rediscovery and manual reconstruction.

It means defining migration success broadly: not only financial benefit and functional coverage, but the preservation of automation, consistent process execution, business controls and auditability.

And finally, it means treating people and skills as part of the portability problem rather than an implementation detail at the end.

Optionality, not interchangeability

I keep coming back to that distinction.

The ambition should not be to make Pega, Appian, jBPM, Camunda or any other platform interchangeable. Trying to erase their differences would also erase much of the value they compete to create.

The architecture objective is smaller, but potentially much more useful:

Use the accelerator. Capture the value. Understand the dependency. Preserve the option to change.

Whether that can be made practical at enterprise scale is still an open question. But it feels like one worth testing.