Camunda 7 vs Operaton: which path fits a team still running 7.24
If your Camunda 7 estate is still on Community Edition, it has no further releases or security patches after the final feature release, 7.24, which was scheduled for October 14, 2025. Choose Camunda 7 Enterprise if your organization needs a paid, vendor-supported line through April 9, 2030, with paid extended support available through April 2032. Choose Operaton if an open, community-governed engine that keeps the REST API, database schema and deployable BPMN and DMN models is acceptable to your governance and risk owners.
The decision turns on four things. First, support obligations: Enterprise gives you a contracted vendor line, while Operaton ships half-yearly feature releases with monthly patches and supports each version for six months, with no traditional LTS line, so you need an upgrade rhythm you can sustain. Second, governance tolerance: Operaton has no single company in control and is still forming its governance, and its FAQ describes plans for a non-profit organization, so ask your auditors and procurement how that will be treated. Third, runtime baseline: Operaton 2.1 requires Java 17 and is tested on Java 17, 21 and 25, and it is built on Spring Boot 4.0.6, so confirm your application servers and frameworks can move there.
Fourth, migration capacity. Operaton's compatibility claims mean the engine swap is shorter than a rewrite, but you still need to run the OpenRewrite recipe in the migrate-from-camunda-recipe repository, rename the org.camunda packages to org.operaton, and test every custom listener and connector. Confirm the Enterprise contract terms with Camunda before you rely on them, and confirm with independent Operaton service providers who will carry production support for your team.
Which scenarios favor Operaton and which favor Camunda 7 Enterprise
This table maps common buying situations to the option that fits them better, with the reason for each. Read each row as a condition: if your situation matches the scenario, the right-hand column shows where the balance tips. Where a fact depends on your vendor or environment, the row says what to confirm before deciding.
| Scenario | Better fit | Why |
|---|---|---|
| Regulated buyer that needs a contractual support counterparty | Camunda 7 Enterprise | Camunda publishes Enterprise end of life as April 9, 2030, with paid extended support through April 2032. Operaton has no commercial edition, and its support comes from multiple independent providers, so a single contract party must be selected and confirmed in writing. |
| Regulated buyer that accepts several independent support providers | Operaton | Multiple service providers can support the same codebase, which avoids a single-vendor dependency. Confirm each provider's contract terms, response commitments and exit provisions before relying on them. |
| Team with an in-house Java platform group | Operaton | Operaton keeps the Camunda 7 REST API, database schema and models and requires Java 17, so an internal group can maintain it without a vendor license. Plan for the group to own patching every six months per release. |
| Team without an in-house Java platform group | Camunda 7 Enterprise | Operaton's six-month support window per release means upgrades arrive on a short cycle. Without internal capacity to test and apply them, a paid Enterprise line with longer support may reduce operational risk. |
| Estate on a database outside Operaton's supported list | Camunda 7 Enterprise | Operaton lists H2, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server and DB2, with minimum versions for PostgreSQL 14, MariaDB 10.11 and MySQL 8.4. Confirm your database version and the Camunda 7 Enterprise support matrix before deciding. |
| Estate on a runtime that Operaton 2.1 does not cover | Camunda 7 Enterprise | Operaton 2.1 requires Java 17 and is tested on Java 17, 21 and 25. Older runtimes or application servers need a check against the vendor matrix before any migration plan is set. |
| Team that wants to defer modernization | Operaton | Operaton 2.1 keeps database schema version 7.24 and API compatibility, so applications can move without a Camunda 8 rework. Camunda 7 Enterprise also keeps the same codebase until 2030, so both defer modernization; Operaton leaves the decision open for later. |
| Team that wants a fixed vendor roadmap to 2030 | Camunda 7 Enterprise | Enterprise end of life is set in writing by Camunda, while Operaton's governance is still forming and plans for a non-profit organization are not yet in place. Ask both parties for their roadmap commitments in writing. |
How the Camunda 7 and Operaton engines are built and deployed
Operaton was forked from the Camunda 7 Community Edition, so the two engines share a process model, a relational persistence layer and most of their APIs. The differences sit in the runtime baseline, the supported databases and how each engine is packaged and governed. Read the cards together before you commit to a path.
Shared engine and persistence model
Camunda 7 is a Java BPMN, CMMN and DMN framework whose process engine persists to a relational database through MyBatis. It exposes REST APIs and ships the Tasklist, Cockpit and Admin web applications, and it can run embedded in a Java application, as a shared engine or standalone. Operaton keeps this model, so a process application built for Camunda 7 should map onto the same components. Confirm each web application you use, because the Operaton distribution is the one that defines what you get.
REST API and schema compatibility
Operaton's repository states a fully compatible REST API, database schema and deployable BPMN and DMN models. For a migration, this means existing clients calling the REST API and existing process definitions are the main things to test, not a rewritten data layer. The 2.1 release notes keep database schema version 7.24. Check every custom listener, script and plugin you have written against the Operaton package namespace, since the org.camunda to org.operaton rename touches code that compiles against the engine.
Java 17 and Spring Boot 4 baseline
Operaton 2.1 requires Java 17 and is tested on Java 17, 21 and 25. It is based on Spring Boot 4.0.6 and Spring Framework 7.0.7, and its Quarkus extension is built on Quarkus 3.33.1 LTS. Camunda 7 applications on older Spring Boot 2 or 3 stacks will need dependency and runtime upgrades before they can run on this baseline. Plan the JVM and framework upgrade as a separate workstream from the engine swap, and test your own libraries against Spring Framework 7.
Database support and minimum versions
Operaton lists support for H2, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server and DB2. For the 2.1 line the documented minimum versions are PostgreSQL 14, MariaDB 10.11 and MySQL 8.4, with Oracle 21, SQL Server 2022 and DB2 support unchanged. If your production database is older than these minimums, the upgrade includes a database upgrade, which is a separate change with its own backup and rollback plan. Ask your DBA to confirm the version and the driver before scheduling the cutover.
Deployment as containers and charts
Operaton is distributed as official Docker images and Helm charts for Kubernetes, alongside Spring Boot, Quarkus and Jakarta EE integration and Tomcat and WildFly distributions. Teams that run Camunda 7 on application servers may keep that packaging, while teams with a Kubernetes platform can adopt the containers. Choose the packaging that matches your current operating model, and check whether your existing Camunda 7 deployment scripts and health checks depend on a packaging that Operaton does not provide.
Vendor and community support model
Camunda 7 Enterprise Edition keeps paid support, with 7.24 as a long-term support release and maintenance updates twice a year, in April and October. Operaton has no commercial edition and no single company in control. Its repository points to professional support and consulting from several independent service providers, and its governance is still forming. Ask any provider which Operaton releases they will patch, and how long each release is supported, since the Operaton FAQ describes a six-month window per release.
Side by side: license, support, compatibility and runtime
This table compares Camunda 7 and Operaton on license, release and support windows, governance, API and schema compatibility, package naming, runtime baselines, databases and distribution. Read each row as a question to put to your vendor or community: the support window and governance rows matter most for a production roadmap, while the compatibility and runtime rows decide how much code and infrastructure change a move would trigger.
| Capability | Camunda 7 | Operaton |
|---|---|---|
| License | Apache-2.0 repository, now archived at tag 7.24.0; Enterprise Edition is sold separately by Camunda | Apache-2.0 with no open-core model and no commercial editions |
| Release cadence | Final feature release 7.24 was scheduled for October 14, 2025; no further Community Edition releases or security patches | Half-yearly feature releases in April and October with monthly patch releases |
| Support window | Enterprise end of life extended to April 9, 2030, with paid extended support through April 2032 | Each major or minor version supported for 6 months until the next ships; no traditional LTS line |
| Governance | Single vendor, Camunda, controls the product line | Community-maintained with no single company in control; non-profit structure still being planned |
| REST API and schema compatibility | Native REST API and database schema at 7.24 | Compatible REST API and database schema at version 7.24; API-compatible with Camunda 7 CE 7.24 |
| Package namespace | org.camunda | org.operaton; migration needs the OpenRewrite recipe and import changes |
| Java and Spring Boot baselines | Confirm the supported Java and Spring versions for your 7.24 Enterprise build with Camunda | Requires Java 17, tested on 17, 21 and 25; based on Spring Boot 4.0.6 and Spring Framework 7.0.7 |
| Supported databases | Confirm the Enterprise database matrix with Camunda for your 7.24 deployment | PostgreSQL 14+, MariaDB 10.11+, MySQL 8.4+, Oracle 21, SQL Server 2022, DB2, H2 |
| Distribution | Camunda-published distributions, with Enterprise support terms | Official Docker images, Helm charts for Kubernetes, Spring Boot, Quarkus and Jakarta EE integration |
What each license and edition actually buys
The Camunda 7 Community Edition is Apache-2.0 licensed, and its code is available, but it has reached the end of its release line. Camunda's final Camunda 7 feature release, 7.24, was scheduled for October 14, 2025, and after that no further releases or security patches are made for the Community Edition. The main repository is archived on GitHub, with 7.24.0 as its last tag. For a team that runs the Community Edition, the license permits use, but it does not bring new fixes.
- No new releases: Nothing after 7.24 is published for the Community Edition, so features and dependency updates stop at that point.
- No security patches: Vulnerabilities found after the end of life will not be fixed by Camunda for this edition.
- Archived source: The repository is read-only, so issues and pull requests are not a route to a fix.
- Own maintenance: Patching the runtime, its Java baseline, its web applications and its database drivers falls to your team or a provider you hire.
Confirm with your security and compliance owners how they will record an unpatched component in your risk register before you rely on this edition for production workloads.
The Camunda 7 Enterprise Edition is a commercial product from Camunda. Its end of life was extended to April 9, 2030, and 7.24 is the long-term support release for that line. Camunda's announcement says the LTS release receives updates twice a year, in April and October, and that paid extended support is available from April 2030 through April 2032. Enterprise is a contract, so what it covers is set by the agreement you sign, not by the product name alone.
- LTS baseline: The supported line is 7.24, so your upgrade path stays on that release rather than moving to new feature lines.
- Scheduled updates: Updates arrive in April and October, which gives you a predictable window for testing and change control.
- Support to April 2030: Standard Enterprise support runs to the stated end of life date.
- Extended support to April 2032: Paid extended support is listed as available after the standard window, at an additional cost you must quote.
Before signing, ask Camunda for the written entitlements: which fixes are covered, response commitments, supported databases and Java versions, and what happens to your contract if you need a fix outside the scheduled updates.
Operaton is an Apache-2.0 licensed BPMN 2.0 engine that started as a fork of Camunda 7 CE. Its repository describes it as having no open-core model and no commercial editions, so there is no paid tier that unlocks features. Operaton is maintained by an open-source community with no single company in control, and its FAQ says governance is still forming, with plans for a non-profit organization to manage key decisions. Professional support and consulting come from multiple independent service providers, not from a single vendor.
- No commercial edition: Every feature is in the Apache-2.0 distribution, so there is no license fee to add.
- Support by provider: Support is bought from independent firms, so the scope, response times and fees depend on the provider you choose.
- Release model: Operaton ships feature releases in April and October with monthly patches, and each version is supported for six months until the next one ships. There is no traditional LTS line.
- Governance in progress: The community governance model and the planned non-profit are not final, so review how decisions are made before you commit.
Ask any provider for written terms covering patch timing, the six-month support window, and who is accountable if a vulnerability appears between releases.
A paid support contract is a service agreement. It usually covers access to fixes, defined response commitments and advice on your installation. It does not, by itself, change the license, rewrite your process models, test your integrations, or make your application compliant with a framework. It also does not remove the work of upgrading your Java runtime, your application server, or your database, which stay with your team or the implementation partner you engage.
- Covered: Named fixes for the supported versions, support channels, and any stated response times.
- Not covered: Custom code, third-party connectors, infrastructure, backups and the hardening of your hosts unless the contract says so.
- Scope limits: Fixes for versions outside the contract, or for modifications you made to the engine, may be excluded.
- Recurring cost: Support fees repeat every term, while migration and testing are usually one-time costs.
Ask each vendor or provider to list entitlements in writing, and confirm exact coverage, response commitments and exclusions in your own contract, because the product documentation does not set them.
What drives the running cost of each path
Each path moves cost between a vendor, your own staff and a services partner. The cards below show who is paid for each cost, which costs are one-time and which recur, and what moves them up or down. No price is given here, so use the list at the end of the section to scope a quote.
Infrastructure and hosting
Every path runs a relational database, Java application servers and the web applications in your own estate. Staying on Camunda 7 Enterprise, Operaton and CIB seven all carry this recurring cost, so it rarely separates the options on its own. What differs is the supported database and runtime matrix, which determines whether your current platform stays in place. Check the minimum versions for Operaton 2.1 against what you run now, because a database upgrade is a one-time cost that can ride along with the move.
In-house Java skills
Operaton keeps the Camunda 7 API, database schema and models, so your current Java developers and operators can keep working as they do today. The recurring cost is staff time for patching, monitoring and answering process questions with no vendor on the phone. Ask who on your team owns the engine upgrades twice a year, and whether that role is funded or added to an existing one. Staff turnover in a small Java team is the risk that most often turns a low-cost path into an expensive one.
Support contract
On Camunda 7 Enterprise, the vendor is paid for maintenance and patches through April 9, 2030, with paid extended support through April 2032. Operaton has no commercial edition, so support comes from several independent service providers, each sold on its own terms. CIB seven offers paid LTS and Enterprise editions. Recurring support fees are the largest difference between paths, so compare what each contract covers, not only the headline rate.
Upgrade effort
Operaton ships feature releases in April and October with monthly patches, and each release is supported for six months until the next one ships. That cadence means a recurring upgrade task roughly twice a year, not a multi-year cycle. Enterprise 7.24 receives updates twice a year in April and October, so the rhythm is similar but the support window is far longer. Budget upgrade testing as a recurring cost in either case, and ask any partner how many upgrade cycles their retainer covers.
Testing of custom code and extensions
Custom Java delegates, listeners, scripts and Spring Boot or Quarkus integrations must be retested on each engine release, and any Java 17 or Spring Boot 4 change in the stack adds to that work. Operaton 2.1 is tested on Java 17, 21 and 25 and based on Spring Boot 4.0.6, so run your own regression suite against those runtimes before committing. Expect this to be a recurring cost that grows with the number of process applications, and ask whether your partner will test extensions or only the engine.
Migration project
Moving to Operaton is a one-time project even though the schema and API stay the same. The work covers running the OpenRewrite recipe, renaming the org.camunda package to org.operaton, validating BPMN and DMN models and cutting over production instances. Use a fixed-scope written agreement that names the code areas, environments and acceptance tests. The recipe lowers the effort for the code change, but it does not remove testing, which is where most of the one-time cost sits.
How to move from Camunda 7 to Operaton in order
This sequence turns an inventory of Camunda 7 assets into a tested Operaton cutover, so each change is verified before the next one starts and the production switch carries no surprises.
Inventory BPMN, DMN and Java assets
List every deployed BPMN and DMN model, every custom Java delegate, listener, script task and connector, every Spring or Java EE configuration that references org.camunda packages, and every client that calls the REST API. Assign an owner to each item. This is done when the inventory covers all deployed artifacts and each one is tagged as unchanged, needs namespace updates, or needs rebuilding. Teams usually find references to the old package in build files and test code, so search those as well as the source tree.
Run the OpenRewrite recipe on a branch
Create a version-control branch and run the Operaton OpenRewrite recipe that migrates from Camunda 7 against the codebase. The recipe is in the migrate-from-camunda-recipe repository, and its job is to rewrite the org.camunda package references to org.operaton. Review the diff file by file, because the recipe handles source code well but may not cover XML, properties files or string literals in custom code. This step is done when the branch compiles and the diff contains only the changes you reviewed.
Update Java 17 and Spring Boot 4 dependencies
Set the build to Java 17 or later and move the framework dependencies to the versions in the Operaton 2.1 release notes, which are based on Spring Boot 4.0.6 and Spring Framework 7.0.7. Check your own libraries too, because Spring Boot 4 changes transitive dependencies that custom code may rely on. Build and run the unit tests. This step is done when the application builds with the Operaton artifacts and every unit test that does not depend on process execution passes.
Verify the database meets minimum versions
Confirm the production database engine and version against the Operaton 2.1 minimums: PostgreSQL 14, MariaDB 10.11 and MySQL 8.4, with Oracle 21, SQL Server 2022 and DB2 support unchanged. Because the schema stays at the Camunda 7.24 version, no schema upgrade should be needed if the database already meets the minimum, but confirm this with a schema check in a copy of production. Database owners should also confirm backup and restore procedures before anything touches the schema. This step is done when the version check is recorded and a restored copy of production starts cleanly against Operaton.
Test process instances and history in staging
Deploy the branch to a non-production environment restored from a recent copy of production data. Start new process instances, complete user tasks, trigger timers and message events, and run the job executor. Compare history and audit records for a sample of instances that were active during the copy. Test the REST clients that your applications and tooling call, because the REST API is documented as compatible but each client should be exercised. This step is done when agreed test cases pass, active instances continue from their saved state, and history matches the expected results.
Rebuild extensions and deployment pipelines
Rebuild the parts that do not transfer by copying: custom extensions that depend on Camunda-specific classes, plugin registrations, CI jobs that pull Camunda artifacts from their original repositories, container images, and Helm or Kubernetes manifests that point at the old distribution. Update monitoring and alerting rules that reference old metric or log names. This step is done when the deployment pipeline builds and deploys Operaton artifacts end to end in staging and every extension has its own passing test.
Cut over and keep a rollback path
Schedule the production switch with the business owners of the affected processes, and agree in writing who approves the go and who executes the rollback. Stop accepting new deployments on Camunda 7, let running instances reach a safe state where possible, take a verified database backup, and deploy the Operaton build. Watch job execution, incidents and REST errors after the switch. Keep the Camunda 7 artifacts and backup until the team has confirmed stable operation. This step is done when production processes run on Operaton, the rollback path has been rehearsed, and the old artifacts are archived.
Plan the upgrade cadence after cutover
After cutover, set a routine to apply Operaton's monthly patch releases and to review the half-yearly feature releases. Each major or minor version is supported for six months until the next one ships, and there is no traditional LTS line, so schedule the upgrade work before support for your current line ends. Ask your support provider, if you use one, to confirm response terms in writing. This step is done when the upgrade calendar is in place and the team knows which version it is running and when that version stops receiving support.
Where Camunda 7 to Operaton projects usually run long
Most of the effort sits in custom code, not in the engine. The engine itself keeps the REST API, database schema and deployable BPMN and DMN models, so the work concentrates in whatever your team wrote against Camunda 7. Start with custom Java listeners, delegates, scripts and expression functions that import org.camunda classes. Each one needs its package references changed to org.operaton, and any script or configuration that refers to fully qualified class names needs the same check. Third-party libraries pinned to Camunda 7 artifacts, such as connectors, custom form tooling or internal starters, are the next place delays appear. Ask each library's owner whether a build exists for the fork, and budget for replacing the ones that do not.
The surrounding application often costs more than the process code. Operaton 2.1 is built on Spring Boot 4.0.6 and Spring Framework 7.0.7 and requires Java 17, so any Spring Boot 3 application that embeds the engine must move its dependencies, auto-configuration and test slices together. Database work is separate: Operaton 2.1 keeps schema version 7.24 but sets minimum versions of PostgreSQL 14, MariaDB 10.11 and MySQL 8.4, so older database servers, drivers and connection pool settings need a dated plan. Confirm each version against the Operaton 2.1 release notes before you commit to a target stack, and treat the six-month support window per release as a reason to script the upgrade rather than repeat it by hand.
Testing long-running instances decides when the cutover is safe. Processes that wait days or months on timers, message events or human tasks will be in flight during the move. Inventory active instances by definition and state, then run a sample through the new engine in a staging copy of production data, including timer firing, compensation and incident paths. Keep the Cockpit and Tasklist views your operators rely on in the test plan, since they are part of the daily workflow even though the engine is the same. A DeployOpen fixed-scope written plan would list the code inventory, library decisions, Spring and database upgrade steps, the instance test matrix, and the rollback and backup criteria, with deliverables and a timeline agreed in writing before work starts.
Questions buyers ask before choosing between Camunda 7 and Operaton
Is Operaton safe to run in regulated production?
Operaton can run in production, but whether it is safe for your regulated environment depends on your own assessment, not on the fork's label. Operaton is Apache-2.0 licensed, keeps the Camunda 7 REST API and database schema, and its 2.1 release notes state it is feature complete and API-compatible with Camunda 7 CE 7.24. The FAQ also says governance is still forming and no single company controls the project. Ask your compliance lead which evidence your assessors expect from a community-maintained component, then test the engine against your own workloads, databases and patch process before you commit.
Who provides commercial support for Operaton?
Support comes from independent service providers, not from a single vendor that owns the product. Operaton's repository says professional support and consulting are available from multiple independent providers, and there is no open-core model or commercial edition. That means you choose and contract a provider, and you should confirm its response commitments, patch coverage and escalation path in writing. DeployOpen implements, hardens and supports self-hosted open-source platforms in your own infrastructure, but the scope of any engagement is agreed in writing before work starts.
What does a Camunda 7 Enterprise contract cost, and what drives the price?
Camunda does not publish a price in the sources used for this page, so request a written quote from Camunda. Enterprise maintenance for Camunda 7 is documented to run to April 9, 2030, with 7.24 as a long-term support release that receives updates twice a year, and paid extended support from April 2030 through April 2032. The main cost drivers are the number of environments and production deployments covered, the length of the term, and whether you need the extended support period. Ask the quote to separate one-time items from recurring subscription fees and to state what happens at renewal.
How long does a migration from Camunda 7 to Operaton take?
The duration depends mainly on the size of your process estate and how much custom code and integration depends on Camunda 7 internals. Operaton is designed to keep the REST API, database schema and deployable BPMN and DMN models, and it offers an OpenRewrite recipe that handles the package rename from org.camunda to org.operaton. The work that usually takes the most time is updating Java 17 and Spring Boot 4 dependencies, testing custom listeners and connectors, and validating against your database versions. Ask any provider for a written plan that lists the inventory, test scope and cutover steps before agreeing a timeline.
Can our own team migrate to Operaton without outside help?
A capable Java team can do the migration itself if it has the time, test coverage and release discipline to run it. The recipe and the compatibility claims reduce the rewrite work, but they do not remove the need to rebuild and retest your application, upgrade the runtime and confirm database behavior. Teams without regression tests for their process applications usually find that the testing is the real project. If you want outside help, DeployOpen can plan, implement and document the migration under a fixed scope agreed in writing, and retainers are available for ongoing upgrades.
What skills does our team need to run Operaton?
Your team needs Java and Spring or Jakarta EE experience, relational database administration, and the ability to operate a BPMN engine in production. 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, so application developers must be comfortable with that stack. Platform staff should know how to run PostgreSQL 14 or later, MariaDB 10.11 or later, or MySQL 8.4 or later, and how to deploy official Docker images or Helm charts. Engineers who know the Camunda 7 Cockpit and Tasklist workflow will find the operating model familiar.
What happens when an Operaton release leaves its six-month support window?
When a release leaves its window, it stops receiving fixes, so you must upgrade to a supported version. Operaton ships feature releases in April and October with monthly patch releases, and each major or minor version is supported for six months until the next one ships. There is no traditional LTS line, so you need a planned upgrade cadence. Build a routine that moves to each new minor release within the window, and ask your support provider how it handles patches for versions that are still in the window but no longer the latest.
How DeployOpen helps choose and implement either path
DeployOpen is a Chainscore Labs company that plans, implements, customizes, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure. For Camunda 7 versus Operaton, we start by agreeing on which path fits your process estate, then carry out the chosen move as a written, fixed-scope engagement.
How we scope
- Inventory of Camunda 7 process applications, BPMN, DMN and CMMN models, and custom Java delegates
- Review of database platform, Java runtime and Spring Boot or Jakarta EE versions in use today
- Written decision memo comparing staying on Camunda 7, buying Enterprise support or moving to Operaton
- Agreed deliverables, timelines and acceptance criteria documented before any work starts
How we build
- Trial migration of representative processes using the OpenRewrite recipe on a non-production copy
- Testing of the Operaton package rename, Java 17 runtime and supported database versions
- Hardening of the chosen runtime, including configuration, access controls and secrets handling
- Integration checks for REST API clients, Tasklist, Cockpit and external systems before cutover
How we hand over
- Runbooks covering deployment, upgrade steps and rollback for the selected engine and database
- Backup and restore procedures tested against the production-equivalent database platform
- Documentation of the chosen support model, release cadence and the upgrade calendar your team must follow
- Knowledge transfer sessions so your engineers can operate the engine after the engagement closes
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Scheduled review of each Operaton release against your six-month support window
- Retainer scope agreed in writing, covering which environments, versions and patch levels are included
- Quotes follow from the written scope, so ask for line items for scoping, migration, testing and retainer
