Flowable vs Operaton: which fits a Camunda 7 Community exit
A team still running Camunda 7 Community Edition after its October 2025 end of life needs a new engine, and the first question is how much code it can afford to change. Operaton fits when the goal is to keep the existing application running with minimal change. It was created as a fork of Camunda 7 CE, states a fully compatible REST API and database schema, keeps deployable BPMN and DMN models working, and offers an OpenRewrite recipe for migrating from Camunda 7. Its 2.1 release is API-compatible with Camunda 7 CE 7.24 and keeps schema version 7.24. The trade-off is governance: Operaton is maintained by a community with no single company in control, its governance is still forming, and a non-profit organization is planned but not yet established. Confirm whether that model satisfies your procurement and risk owners before you commit.
Flowable fits when the team wants its own engine, its own release line and a vendor-backed path for support. Flowable 8.0.0, released on February 27, 2026, is based on Spring Framework 7 and Spring Boot 4, and drops Spring Boot 3 support. Flowable's engines are Apache-2.0 licensed and cover BPMN, CMMN and DMN, but the API and schema differ from Camunda 7, so the move involves more change to code and data. Flowable's documentation covers its own process of migration, and its commercial products and professional services are offered separately. Check the exact migration scope and tooling with Flowable before estimating effort, since the in-place migration claim needs to be validated against your own process definitions, history and extensions.
Three decisions should drive the choice. First, measure the acceptable code change: if the application depends on Camunda 7 Java APIs and schema, Operaton keeps that surface intact, while Flowable requires adapting it. Second, confirm the Java and Spring versions in use, because Operaton 2.1 requires Java 17 and is tested on Java 17, 21 and 25, and Flowable 8 requires Spring Boot 4, so an application still on Spring Boot 3 faces a separate upgrade either way. Third, state the governance and support the organization requires, including whether a single accountable vendor is mandatory and whether a community-governed project is acceptable. Ask each candidate for its supported database versions, its patch and release cadence, and a written support scope before scheduling a proof of concept.
Which scenario points to Flowable or Operaton
This table maps common Camunda 7 exit scenarios to the option that usually fits better, with the reason and the condition under which the other option would still win. Read each row against your own codebase, governance needs and support requirements before deciding.
| Scenario | Better fit and reason | When the other option still wins |
|---|---|---|
| Large custom Camunda 7 codebase that must keep its Java API and database schema | Operaton. It is documented as API-compatible with Camunda 7 CE 7.24 and keeps database schema version 7.24, so existing code and data need the least change. | Flowable can still win if the team is willing to refactor its Java calls, since Flowable is a separate engine line with its own APIs and migration tooling. |
| Team that wants an engine line with its own roadmap and a single maintainer organization | Flowable. Its engines are Apache-2.0 and maintained by Flowable, which sets the release direction for BPMN, CMMN and DMN. | Operaton can suit teams that prefer a community-governed project, although its FAQ says governance is still forming and no single company is in control. |
| Regulated buyer that needs a named vendor for contractual support | Flowable, if a vendor contract is a hard requirement. Flowable offers professional services and partners separately from its open source engines. | Operaton can still fit if the buyer accepts support from several independent service providers rather than one contracted vendor. Confirm each provider's scope in writing. |
| Team already running Spring Boot 4 | Check the version pairing. Flowable 8.0.0 is based on Spring Framework 7 and Spring Boot 4, and Operaton 2.1 is based on Spring Boot 4.0.6, so both fit this stack. | If your stack must stay on Spring Boot 3, Flowable 8.0.0 is not an option, and you should confirm which Operaton line supports your version before deciding. |
| Team that needs a predictable long-term support window | Confirm before choosing. Operaton ships half-yearly feature releases with monthly patches and supports each version for 6 months, with no traditional LTS line. | Flowable may suit teams that want a vendor-set release cadence, but confirm its support windows directly with Flowable for your target version. |
| Team that must minimize migration risk to its production data and history | Operaton, because its schema compatibility means existing data stays in the same shape, and it documents an OpenRewrite recipe for moving from Camunda 7. | Flowable can still be the right choice when the team plans a broader engine change anyway and will test its in-place migration path against a copy of production data. |
| Team that wants to run the engine on Kubernetes with official container artifacts | Operaton, which lists official Docker images and Helm charts for Kubernetes alongside Spring Boot, Quarkus and Jakarta EE integration. | Flowable can still fit when the team embeds the engine in its own Java application or runs the Flowable REST application as a separate service, and packages it on its own pipeline. |
How each engine is built, embedded and deployed
Flowable and Operaton both run as Java engines, but they reach production through different baselines, APIs and integration points. The cards below cover where each engine runs, which interfaces it exposes, which databases it supports and where operations work will concentrate. Each card lists what to confirm in a test environment before you commit to either path.
Embedded or standalone service
Flowable's engines can be embedded as a JAR in Java SE applications, servlet containers, Spring applications or Java EE servers, or used over HTTP through the Flowable REST application. Operaton is distributed as a Spring Boot, Quarkus and Jakarta EE integration, plus Tomcat and WildFly distributions and Docker images. Confirm which deployment shape your existing Camunda 7 applications use today, because that determines how much of the wiring carries over unchanged.
REST and Java API surface
Both engines expose Java APIs and REST interfaces. Operaton states its REST API is fully compatible with Camunda 7 CE, which matters if clients, workers or monitoring tools already call that surface. Flowable's REST API is a separate application with its own version line, so client code written against Camunda 7 endpoints will need comparison and testing. Run your highest-volume API calls against both candidates and diff the responses before choosing.
Supported database lists
Flowable's documented database types include H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and its configuration docs note a millisecond precision issue on MySQL versions below 5.6.4. Operaton supports H2, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server and DB2, with minimum versions of PostgreSQL 14, MariaDB 10.11 and MySQL 8.4 in its 2.1 release. Confirm that your database versions meet each engine's minimums, and that your DBA can support the schema path you choose.
Java and framework baselines
Flowable 8.0.0 is built on Spring Framework 7 and Spring Boot 4, drops Spring Boot 3 support, and moves its default JSON library to Jackson 3. Operaton 2.1 requires Java 17 and is tested on Java 17, 21 and 25, and it is based on Spring Boot 4.0.6 and Quarkus 3.33.1 LTS. A team still on Spring Boot 3 will have to upgrade before Flowable 8 fits, while Operaton's baseline is closer to its Camunda 7 origins. Map your current Java and Spring versions against both baselines first.
Async executor and clustering
Flowable's async executor runs timers and asynchronous jobs from a thread pool and coordinates nodes through lock owners and lock expiration times stored in the database, so jobs locked by a failed node are picked up by others. Operaton inherits the job executor model from Camunda 7, so its clustering behavior should match what your operations team already knows. Test a node failure during timer-heavy processes on each candidate and confirm that jobs are recovered and not duplicated.
Identity service integration
Flowable allows identity management to be replaced by overriding its identity service implementation or by implementing the IdmIdentityService interface, and an LDAP implementation is provided as a reference. Operaton's identity handling follows the Camunda 7 model, so custom identity providers and group mappings written for Camunda 7 need review rather than assumptions. Confirm how each engine resolves users and groups from your directory, and test authorization rules for candidate groups and tasks.
Side-by-side capabilities, versions and support windows
This table compares Flowable's engine line with Operaton's Camunda 7 compatible fork on licensing, standards, versions, platform baselines, databases, compatibility and support. Read the Operaton column as a statement about API and schema continuity, and the Flowable column as a statement about a separate engine that requires its own migration work. Items marked as a question to confirm depend on vendor statements that were not verified for this page.
| Capability | Flowable | Operaton |
|---|---|---|
| License | Apache-2.0 open-source engines for BPMN, CMMN and DMN. Commercial platform sold separately on top. | Apache-2.0 BPMN 2.0 engine. No open-core model and no commercial editions. |
| Standards coverage | BPMN, CMMN and DMN engines with Java and REST APIs. | BPMN 2.0, DMN 1.3 and CMMN 1.1 compliance listed in its 2.1 release notes. |
| Current release lines | Flowable 8.0.0 released February 27, 2026, following 7.2.0 (August 21, 2025) and 7.1.0 (October 7, 2024). | Operaton v2.1.0 published April 24, 2026. Latest stable patch v2.1.5 published September 18, 2026. |
| Spring Boot and Java baselines | 8.0.0 is based on Spring Framework 7 and Spring Boot 4, with no Spring Boot 3 support. | 2.1 is based on Spring Boot 4.0.6 and Spring Framework 7.0.7, requires Java 17 and is tested on Java 17, 21 and 25. |
| Supported databases | H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. MySQL below 5.6.4 lacks millisecond precision. | H2, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server and DB2. Minimum PostgreSQL 14, MariaDB 10.11 and MySQL 8.4 in 2.1. |
| Camunda 7 API and schema compatibility | Not a compatibility target. Moving to Flowable means adopting its engine and data model, so confirm what its in-place migration covers and how the LEAP tool handles your process data and history. | Feature complete and API-compatible with Camunda 7 CE 7.24, keeping database schema version 7.24. Migration recipe available on OpenRewrite. |
| Release cadence and support windows | Versioned major and minor lines. Ask Flowable for its published support window for each line before you commit. | Half-yearly feature releases in April and October, monthly patches, each line supported 6 months until the next ships. No LTS line. |
| Identity extension points | Identity management can be replaced by overriding IdmIdentityServiceImpl or implementing IdmIdentityService. An LDAP reference implementation is provided. | Inherits the Camunda 7 extension model. Confirm identity provider integration against the Operaton documentation for your deployment. |
| Commercial support | Community forum for open-source users. Professional services and partners offered separately, and Flowable's commercial products are sold on top. | No vendor support. Professional support and consulting come from multiple independent service providers. Governance still forming, with a non-profit planned. |
What is free, what is paid and who owns each engine
Flowable's BPMN, CMMN and DMN engines are open source under Apache-2.0, and the company that maintains them also sells a separate commercial platform built on the same engines. The free engines give you the process execution, case management, decision rules, Java and REST APIs, and the freedom to embed or run them without a license fee. The commercial layer is a different product with its own terms.
- Open-source engines: Apache-2.0 licensed BPMN, CMMN and DMN engines that you can embed in Java applications or run as a service.
- Commercial platform: Flowable Work, Engage, Orchestrate and Design add low-code modeling, visual debugging, security controls, monitoring and governance on top of the same engines.
- Community support: Open-source users get access to a community forum.
- Paid services: Professional services and partners are offered separately from the license, so the scope and cost of help are defined per engagement.
- Ownership: Flowable's company controls the roadmap for the engine and the commercial products.
Confirm with Flowable which modules you would need, whether any of them sit behind the commercial platform, and what support terms apply to your deployment.
Operaton is an Apache-2.0 licensed community fork of the Camunda 7 codebase. It has no open-core model and no commercial editions, so there is no paid tier that unlocks features. Support comes from multiple independent service providers, and the project's governance is still forming, which affects who decides the direction of the project.
- Licensing: Apache-2.0 for the whole project, with no separate enterprise license.
- No commercial editions: The repository states there is no open-core model and no commercial edition to buy.
- Independent support: Professional support and consulting come from several independent providers rather than a single vendor.
- Governance still forming: The FAQ says no single company controls the project, governance is still forming, and there are plans to establish a non-profit organization to manage key decisions.
- Cost shape: Your recurring spend is the support contract you choose, the hosting you run, and the internal effort to maintain it.
Ask any support provider which Operaton versions they cover, what their response commitments are in writing, and how they handle a change in the project's governance.
Camunda 7 Enterprise Edition is the vendor-backed route for teams that want a company accountable for patches on Camunda 7. Camunda extended the Enterprise end of life to April 9, 2030, with 7.24 as a long-term support release, and paid extended support available through April 2032. The Community Edition, by contrast, has no further releases or security patches after 7.24.
- Extended end of life: Enterprise end of life is April 9, 2030, per Camunda's February 2025 announcement.
- Paid extended support: Extended support is available through April 2032 and is sold by Camunda.
- Long-term support release: 7.24 is the release line Camunda designated for long-term support.
- Why buyers compare it: Teams that need a vendor contract for Camunda 7 patches often weigh this option against open forks that have no paid patch commitment from a single company.
- Recurring cost: Enterprise subscriptions and extended support are recurring fees, so the total depends on the terms in the quote.
Confirm the subscription price, what extended support covers, and whether it applies to your exact Camunda 7 version and database before you plan around the 2030 and 2032 dates.
What drives the running cost of each path
The first cost to separate is the one-time migration from the recurring upkeep that follows. On the Flowable path, your internal engineering team, or the partner you hire, pays for the code changes that move off the Camunda 7 API and onto Flowable's Java and REST APIs, plus the testing of every process, service task and listener that depends on them. Operaton is a different shape: it keeps the Camunda 7 API and database schema, so the one-time work is usually smaller in code, but you still pay to verify that the fork behaves as expected on your own databases, application servers and Java 17 or newer runtimes. Confirm with each vendor which parts of your process models they expect you to change, and which they expect to run unmodified.
The recurring cost depends on who sets the pace of upgrades. Operaton ships half-yearly feature releases with monthly patches, and each version is supported for six months with no traditional LTS line, so someone on your team must plan a regular upgrade cycle or accept an unsupported runtime. Flowable's own release line moves on its own schedule, and Flowable 8.0.0 changed the Spring Boot baseline, so each major version can bring a framework upgrade with it. Optional fees also differ. Flowable's commercial platform is a separate paid product built on the same engines, and third-party Operaton support is bought from independent providers, so ask whether either fee is in your budget at all.
When you request a written quote, ask for the scope of code changes, the number of processes and integrations covered, and the test environments the provider will build and maintain. Ask for the upgrade cadence they will follow, how many patch cycles are included per year, and whether security patches are handled within the retainer or billed separately. Clarify support hours, response expectations for production incidents, and who owns database changes during upgrades. Finally, ask what happens if you need to move again: the effort to leave either path is part of its running cost, and a Flowable open source overview and the Operaton FAQ are good starting points for the questions to put to each vendor.
What moves, what gets rebuilt and the order of work
This sequence shows which Camunda 7 assets carry over unchanged, which need conversion or rebuilding, and how to prove each step in a rehearsal before any production cutover.
Inventory processes, integrations and custom code
The team lists every deployed BPMN, DMN and CMMN model, every Camunda 7 API call made by applications, every custom Java delegate, listener, identity provider and job configuration, and every database and version in use. For an Operaton path, the inventory should note any
org.camundapackage imports, because the package namespace changes toorg.operaton. For a Flowable path, the inventory should flag every dependency on Camunda-specific APIs, since the code must be rebuilt against Flowable's interfaces. The output is a written list with an owner and a disposition (carry over, convert, rebuild or retire) for each item, reviewed by the architecture and security leads.Build a test environment that mirrors production
The platform team provisions a non-production environment using the same database engine, version and Java runtime as production, along with the same identity source and external systems or realistic stubs for them. On the Operaton path, the team checks the documented schema continuity and minimum database versions in the 2.1 release notes against its own servers, since PostgreSQL 14, MariaDB 10.11 and MySQL 8.4 are the stated minimums. On the Flowable path, the team confirms the supported database type and version list in the configuration docs. The environment is ready when a copy of production data can be loaded and the current Camunda 7 application runs against it without errors.
Run the Operaton path through the OpenRewrite recipe
For teams moving to Operaton, the engineers apply the OpenRewrite recipe from the migrate-from-camunda repository to the application source, then review the diff for changes the recipe does not cover, such as custom configuration files, property keys and build descriptors. The engineers then point the application at Operaton with the existing database schema and run the full regression suite. The output is a version-controlled branch with a reviewed diff, a passing regression run and a list of manual changes, which the owner signs off before the rehearsal.
Convert process data and rebuild engine-specific code for Flowable
For teams moving to Flowable, the team follows Flowable's documented migration path for converting process definitions, running instances and history, and then rebuilds the custom API calls, identity service integration and execution listeners against Flowable's Java and REST interfaces. Identity code is the largest rebuild risk: the Flowable docs describe replacing the identity service by overriding the default implementation or implementing its interface, with an LDAP reference implementation. The team should confirm with Flowable whether any in-place data conversion step applies to its specific Camunda 7 version before committing to a plan. The output is a converted test database and a rebuilt code branch that passes the same regression suite.
Rehearse the migration end to end
The team runs the complete migration on a fresh copy of production data at least once, timing each stage, recording every error and manual step and checking that running process instances continue to completion after conversion. The rehearsal includes timers and asynchronous jobs, because Flowable's async executor recovers expired locks through lock owners and expiry times in the database, and the team must verify that job ownership moves cleanly across nodes. The output is a rehearsal log, a reconciled count of active instances, tasks and history records, and a go or no-go decision recorded by the change board.
Cut over with a documented rollback
During the production window, the team freezes new starts on the Camunda 7 system, drains or migrates in-flight work, applies the tested migration or deployment, and switches traffic to the new engine. The rollback plan is written before the window opens and tested in the rehearsal, covering restore of the database snapshot and redirection of callers. The output is a signed cutover record listing the time of freeze, migration result, reconciled counts and the rollback point that stays available until the team accepts the result.
Monitor after cutover and retire the old stack
After cutover, the operations team watches job execution, failed jobs, API error rates, database locks and history growth against the baseline captured in the test environment. On the Flowable path, the actuator endpoint at
/actuator/flowablecan support monitoring of running processes if the team uses Spring Boot starters. On the Operaton path, the team should set its own upgrade cadence, since Operaton ships half-yearly feature releases with monthly patches and supports each version for six months, with no traditional LTS line. The stack is retired only after a defined acceptance period, and the output is an acceptance record and a dated upgrade plan.Price the cost of a later switch
Whichever path the team chooses, the switching cost grows with every custom integration, every rebuilt identity connection and every year of accumulated history. An Operaton choice keeps the Camunda 7 API and schema, so a later move to another engine would repeat most of this sequence. A Flowable choice requires code that targets Flowable's interfaces, so a later move would also repeat the rebuild. Before committing, the team should confirm with each vendor or community body the support terms, the upgrade path to future major versions and the process for data export, and should ask a quoting partner to price this sequence against the written scope of its own inventory.
Where Flowable and Operaton projects usually run long
The longest part of a Camunda 7 exit is rarely the engine swap itself. Overruns usually start in custom code that sits on top of the engine: Java delegates, execution and task listeners, custom form or identity logic, and any bespoke integration that calls Camunda 7 APIs directly. Operaton keeps the Camunda 7 API and schema, so that code is the cheapest part to carry over, while Flowable requires a rewrite of every touchpoint that uses Camunda-specific classes or package names. Inventory every listener, delegate and identity hook in both directions before estimating anything. Identity integration deserves its own line item: Flowable documents replacing the identity service through IdmIdentityService or an override of IdmIdentityServiceImpl, which means your LDAP or directory logic must be re-implemented and tested, not just repointed.
Clustering and asynchronous behavior cause the second group of overruns. Flowable's async executor coordinates nodes through lock owners and lock expiration times stored in the database, so your team must verify job pickup, timer firing and lock recovery under node failure in a staging cluster, not on a single developer machine. History configuration and async history settings also change how much data each transaction writes, and both engines need that load profile tested with real process volumes. Check database floors early: Operaton 2.1 requires PostgreSQL 14, MariaDB 10.11 or MySQL 8.4 at minimum, and Flowable's MySQL guidance notes that versions below 5.6.4 lack millisecond precision. DBA time for version upgrades, schema migration rehearsal and backup validation is usually the constraint, not developer time.
Your team must supply process owners who can sign off on BPMN behavior, a DBA for schema and version work, and a staging environment that matches production database and cluster topology. Spring Boot and Java upgrades add risk on both paths: Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 with no Spring Boot 3 support, and Operaton 2.1 requires Java 17 and is tested on Java 17, 21 and 25. Build long-running process tests (timers, multi-week waits, compensation and retries) that run in CI, because these are the scenarios that fail late. External help shortens the timeline most when the custom listener count is high, when identity or clustering behavior is undocumented in your environment, or when no one on the team has operated a BPMN engine under load. Ask any partner to put listener inventory, cluster test plans and DBA tasks in the written scope.
Questions buyers ask before choosing Flowable or Operaton
How much effort does a move off Camunda 7 take?
The effort depends mostly on how much Camunda 7 surface your code and data use, not on the engine name. Count the process definitions, custom Java delegates and listeners, REST clients, external task workers, database size and history retention, and the Spring or Java EE version your application runs on. Operaton states that it is API-compatible with Camunda 7 CE 7.24 and keeps the database schema at version 7.24, so a move there is mostly a dependency, package and namespace change, with an OpenRewrite recipe offered for the namespace step. A move to Flowable needs a code-level port of the Camunda API calls and a data migration plan, because Flowable has its own API and schema. Ask each vendor for a written inventory-based estimate of both paths before you compare them.
Can our own team do the migration without outside help?
A team with strong Java, Spring and database skills can often do the Operaton path with its own staff, because the main steps are build changes, package renames and regression testing against the same schema. A Flowable move is harder to run in-house when the team has no experience with a different engine API, the history tables are large, or the process models rely on custom Camunda extensions. Either way, the work needs someone who owns the test suite, the production cutover and the rollback plan. Outside help is most useful for the parts your team has not done before, such as schema migration rehearsals or performance testing under production load.
How long does a Camunda 7 migration project usually run?
Project length is set by the number of processes, the number of integrations, the amount of history you must keep, and how many environments need a controlled cutover. Change freezes, compliance evidence and sign-off from process owners often take longer than the code work itself. No duration is given here because no researched figure was supplied for this comparison. Ask each vendor, and any implementation partner, for a timeline tied to a written scope with named milestones, test exit criteria and a cutover window. Compare the two paths on the same scope so the timelines are comparable.
Does Operaton's compatibility mean no code changes at all?
No, compatibility lowers the change load but does not remove it. Operaton's 2.1 release notes describe API compatibility with Camunda 7 CE 7.24 and an unchanged database schema version, but the package namespace changed from org.camunda to org.operaton, so imports, configuration references and any Camunda-specific artifacts must be updated. The required Java version is 17, and you must check your Spring Boot, Quarkus or application server versions against the supported set. Confirm with Operaton which of your extensions, scripts and connectors fall outside the compatibility claim, and test them on a copy of production data.
How does support differ between a community fork and a vendor engine?
Operaton is maintained by an open-source community with no single company in control, and its FAQ says governance is still forming. It has no commercial editions, and professional support and consulting come from several independent service providers. Flowable's open-source engines are Apache-2.0 licensed, and Flowable offers a community forum for open source users, with professional services and partners sold separately, while its commercial platform is built on the same engines. A vendor engine gives you one accountable company for roadmap and support contracts, while a fork gives you a choice of providers but no single owner. Ask each side for its support terms, response commitments and what happens if the lead maintainer changes.
How often do the two engines ship updates, and what should we plan for?
Operaton ships half-yearly feature releases in April and October, with monthly patch releases, and supports each major or minor version for six months until the next one ships, with no traditional LTS line. That cadence means your team must plan regular upgrades to stay supported. Flowable's release history includes major version 8.0.0, released February 27, 2026, which dropped Spring Boot 3 support, so an upgrade to Flowable 8 can also require a framework upgrade. Check each vendor's current support policy in writing before you commit, and factor the recurring upgrade work into your operating budget.
What does the work need from our own engineers and operators?
Plan for ongoing ownership, not only a one-time project. Your staff will need to own the application build, the database and its backups, the upgrade calendar, the monitoring of async job execution, and the security patch process. On the Operaton path, the skills are mostly those already used for Camunda 7. On the Flowable path, engineers must learn the new API, the configuration model and the Spring Boot starters. Whichever path you choose, name an owner for each duty, and ask any implementation partner which parts it runs, which it hands over and which it only documents. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in the client's own infrastructure under fixed-scope agreements, and ongoing support is available as a retainer.
How DeployOpen helps you choose, implement or migrate
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Flowable or Operaton decision can be tested against your real Camunda 7 deployment before any code moves. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How we scope
- We inventory your Camunda 7 processes, custom Java delegates, listeners, REST clients and database schema before recommending a path.
- The written scope states which engine, database and application server versions are in and out of the work.
- We agree the identity integration approach, including how users and groups are supplied to the engine, before any build starts.
How we build
- We run the chosen engine in a non-production environment, deploying your BPMN models and comparing behavior against your current engine.
- Migration rehearsals cover your largest process instances, timers and asynchronous jobs, with results recorded for review.
- We set up deployment, configuration and hardening in your cloud account, data center or air-gapped network, following your own standards.
How we hand over
- You receive runbooks covering deployment, database upgrades, backups and restore steps for the platform you select.
- Documentation records the custom code, configuration decisions and any deviations from upstream, so your team can maintain them.
- Handover includes knowledge transfer sessions with the engineers who will operate the platform after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial engagement.
- Upgrade plans follow the release cadence of the engine you choose, so your team knows what to expect and when to act.
- Ask any provider, DeployOpen included, to confirm in writing which release lines, patch windows and support terms apply to your deployment.
