Nine platforms will take your Camunda 7 processes. That is why you are still deciding.

Same slide. Same four options, or five if someone has been reading. Somebody asks what it would cost, and the honest answer is that nobody knows, because none of the vendors publish a price. Somebody asks how long it would take. Nobody knows that either. The meeting ends the way it ended last time, which is that everyone agrees it needs a decision.

That has been going on for months.

Not because the people in the room are slow. Because the question cannot be answered from the outside.

Your Camunda 7 setup is a specific thing. A particular version. Process applications, Java delegates and listeners somebody wrote four years ago. External workers. Custom Cockpit plugins. Forms nobody has opened since the person who built them left.

Which platform suits that is a question about your code. It is not a question about the platforms.

So the discussion goes in circles, and underneath it sits something nobody says out loud.

If it goes well, it was a technical decision that went well. If a core process falls over in production, it has a name on it, and that name is in the meeting. So the safest thing any individual can do is ask for one more round of analysis. And the second safest thing is to wait until somebody else is in the chair — which is why, in most organisations that run on Camunda 7, the current owner inherited the problem from a predecessor who also did not solve it.

Meanwhile both directions look equally risky.

Stay, and you are running business-critical workflows on a platform that will never receive another feature. Camunda has said so plainly: 7.24 LTS is the last minor release, and no new feature-adding releases of Camunda 7 will be built. Move, and you are touching processes that currently work, with no test suite to tell you whether they still do afterwards — because almost nobody has that suite, and writing one sounds like a year of work before the actual project even starts.

Standing still feels dangerous. Moving feels dangerous. So the slide comes back next month.

Take the months this has been on the agenda. Multiply by the people in the room, by the hours each of them has spent on it, by what an hour of their time costs. That figure is what deciding has cost you so far, and it buys nothing — the migration still costs the same when you finally do it.

If you are on Enterprise, add the maintenance you are paying in the meantime for a platform that will never get another feature. Extended support past April 2030 is available for an additional fee, has no published price, and is not automatic — Camunda’s instruction is to contact your Customer Success Manager.

If you are on Community Edition, the arithmetic is simpler. There has been no release of any kind, including security patches, since 14 October 2025.

You asked the platform vendors. They were helpful and they all reached the same conclusion, which was their own platform. That is not dishonesty, it is structure — none of them can recommend a competitor. Every one of those conversations was useful. None of them produced a decision, because the answer to “which of these is right for us” was never going to come from one of the candidates.

You compared them yourself. This is where most of the months go. It fails for a reason that has nothing to do with effort.

The nine, so you can check the number rather than take it from us: Camunda 8, CIB seven, Operaton, Fluxnova, EximeeBPMS, OrqueIO, CadenzaFlow, Flowable, and staying on Camunda 7 Enterprise. Most people we speak to know three or four of them.

No vendor in this market publishes a price. Across all nine there is one exception, and it is not a realistic target for a BPMN estate.

Effort figures are worse. Three published numbers exist in total across all nine destinations, and every one is hedged or anecdotal: two illustrations in Camunda’s own migration documentation, and one customer testimonial on CIB’s site quoting around 25 person-days for a single application, with no statement of which phases that included.

Compatibility statements are scoped by what each vendor happens to have seen at its own customers — not by any published list of what is covered. Camunda documents its own migration blockers honestly and at length, across three separate documentation locations, with no assembled inventory anywhere.

You cannot build a comparison out of that. The reason is that the material does not exist, not that you missed it.

You brought in a consultancy. Most arrive with a destination already chosen. We counted the field in August 2026 — roughly sixteen firms advertising Camunda 7 migration across German-speaking Europe. One makes destination-neutrality an explicit position, and it is in Germany, not Switzerland. Two of the loudest advertise two different destinations on two different pages.

None of that is your failure. The decision cannot be made from public information. It can be made from your code.

Read the migration documentation for the platform you are most likely to pick. Search it for seven words: test, rollback, downtime, backup, schema, sql, revert.

On CIB seven’s Camunda migration page — the leading Camunda 7 fork — all seven return nothing. Go and search it.

The page tells you how to rewrite your Maven coordinates and your Java package names. It does not tell you how to know whether your processes still work afterwards, how to get back if they do not, or what happens to your database.

The tooling has the same shape. The migration recipe rewrites build coordinates, Java packages and text inside XML and YAML.

It does not touch a single .bpmn, .dmn or .cmmn file. It does not touch Gradle. It does not touch the database. It has no rules for Cockpit, Tasklist or Admin plugins. Objects already sitting in your database under the old namespace are not renamed, and reaching them afterwards throws ClassNotFoundException unless somebody enabled two properties that ship switched off.

So the migration is documented. The safety is not. That gap is the whole reason this stays on your agenda, and it is what we fill.

That is what breaks the deadlock. Right now, moving and staying feel equally risky because neither has evidence attached. Afterwards, one of them does. You are not asking your risk function to trust a consultancy — you are handing them a test run that either passed or did not, and they can read it themselves.

One more thing worth knowing, because it shapes how the work runs. The tests and the planning are the bulk of the engagement, not the migration itself. That is exactly why doing it in that order is the whole method rather than a detail of it.

That is the part that matters if you are the one who has to sign it off. You do not have to become the in-house expert on nine platforms to chair one meeting about them. You do not have to write the regression suite — that is the largest piece of work in the engagement and it is ours. You do not have to reassemble Camunda’s own migration blockers out of three separate documentation locations, or work out which of four vendors is contradicting itself.

What you do is walk us through what you have, sign off the test suite as covering your business cases, and read a dated result at the end. Everything between those three points is our problem, and the guarantee below puts money behind that.

Your processes run on a platform somebody chose on evidence, and the evidence is written down. A test suite that did not exist before now runs on demand and tells you the estate is intact. The item comes off the risk register.

Nobody asks you about Camunda in a meeting again, because there is nothing left to ask. The decision has a document behind it, the migration has a dated test run behind it, and both have somebody else’s name on the work.

AKB were running their business processes on Camunda 7. They handed the whole migration to us, we were the only vendor on the project, and it was delivered successfully.

Their numbers stay with them. We have no effort figure of our own from that engagement to give you either. What we can tell you is how the work was shaped: the test suite was the large piece, and the migration itself came after it.

We map it together. You walk us through what you have; we read the code, the infrastructure and the setup. This takes as long as your setup needs — it is a diagnosis, not a form.

Within 48 hours of your first message, we come back on the main risks and a practical first step.

You get the verdict and the roadmap. Written, dated, and yours whether or not you go further.

Migration day one. The 90-day clock starts. Work begins on the test suite.

Suite green on Camunda 7. You sign it off. Nothing moves before that.

Migration proper. We move the processes across, business unit by business unit, against the suite you signed off.

By day 90. The same suite passes on the destination platform.

Peak Code Consulting is a Swiss company, registered in Aarau, working on BPMN process automation and custom software for Swiss businesses.

We will not put a number on this until we have read your code. If you need a figure for a board paper next week, we cannot give you one, and any firm that does is guessing at your estate. That loses us engagements to people who will quote on a phone call. We would still rather lose them.

We run two migrations at a time. Not two hundred, and not on demand. When both slots are taken, the next start date moves, and it can move by months. If your timeline cannot survive that, take it to somebody with more capacity — genuinely, and we will say so on the first call rather than hold a slot we cannot honour.

The Vulnerability Report On What You Already Run. While we have your code open, we run your business units and front end through a security check and hand you the findings. It matters more than it sounds: if you are on Community Edition, that estate has had no vendor security patch since 14 October 2025, and nobody has looked.

The Continuity File On Whichever Platform You Pick. The written answer to the question your risk officer will ask and the vendor will not volunteer — who maintains this, under what licence, with what published support window, what happens if they stop, and whether you can get security advisories and an SBOM at all. Every destination has a version of this file. No vendor will write you theirs.

This fits if you are running business processes on Camunda 7, somebody has to make the platform decision, and you can give us read access to the code.

This does not fit if:

We run two migrations at a time. That is a delivery limit, not a marketing one, and when both slots are taken the next start date moves.

There is no countdown on this page and there is no deadline being invented for you. Camunda’s own position is that Enterprise customers are not yet under hard pressure. The constraint here is ours, not theirs.

Nine platforms will take your Camunda 7 processes. That is the reason this keeps coming back to the agenda, and it is not going to resolve itself in another meeting.

Within 48 hours you get our read on the main risks. After that you get two documents: which platform fits your code and why the other eight do not, and a dated plan for getting there. Both are yours whether or not you hire us.

If you do go ahead, your test suite runs green on Camunda 7 before anything moves, and green again on the destination platform inside 90 days — or CHF 5,000 comes off the invoice.

We run two migrations at a time.