CloudBees CD/RO v2026.06.0

Released: July 2, 2026

This page provides important notices about releases that may affect your upgrade efforts to the newest CloudBees CD/RO release.

Upgrade notes

The following upgrade notes affect this release:

End of support for PostgreSQL 14

End of support for PostgreSQL 14 in the future releases. Please plan to upgrade your database before you upgrade CloudBees CD/RO.

PostgreSQL 14 reaches end of life in CDRO version 2026.09

Starting with release 2026.06, CloudBees CD/RO no longer supports MySQL version 8.0 and PostgreSQL version 13 as system databases. PostgreSQL version 14 remains supported in this release but will no longer be supported as a system database in a future CloudBees CD/RO release. Plan to upgrade your database to a supported PostgreSQL version above 14 before upgrading CD/RO to a future release to ensure a supported upgrade path.

Gateway API configuration now uses TLSRoute

The cloudbees-flow Helm chart now uses TLSRoute by default for the built-in Flow Server (8443), STOMP (61613), and Flow Repository (8200) services instead of TCPRoute. This change enables CloudBees CD/RO deployments to use only the Gateway API Standard-channel CRDs and allows multiple deployments to share a single LoadBalancer IP and port through SNI-based routing, while preserving end-to-end TLS termination at the backend pods. Before upgrading, update Gateway listeners for these ports to use protocol: TLS with tls.mode: Passthrough, verify that your Gateway API controller supports TLSRoute, and ensure clients connect using hostnames that send SNI information. Customers who prefer to continue using TCPRoute can explicitly opt out through Helm chart configuration; however, TCPRoute requires the Gateway API Experimental-channel CRDs. Kubernetes version 1.31 or later is recommended for the Standard-channel TLSRoute v1 CRD.

For more information refer How to configure Kubernetes Gateway API.

Upgraded CloudBees Analytics OpenSearch to version 3.6.0

CloudBees Analytics OpenSearch is now upgraded to version 3.6.0. This upgrade provides the latest OpenSearch enhancements, bug fixes, performance improvements, and security updates, helping ensure a more stable and secure analytics platform.

Ingress-nginx subchart deprecated

Starting in March 2026, the upstream ingress-nginx controller reached end of support and no longer receives security updates. As a result, the cloudbees-flow Helm chart no longer enables the bundled ingress-nginx controller by default. Existing deployments that rely on the previous default behavior may lose external ingress connectivity after upgrading unless they explicitly enable the bundled controller or configure an alternative ingress or Gateway API implementation.

Action required: Before upgrading, determine whether your deployment depends on the chart’s default ingress-nginx configuration. If so, choose one of the following migration options:

  • Migrate to Gateway API by enabling gatewayApi. For more information refer How to configure Kubernetes Gateway API.

  • Explicitly retain the bundled controller by setting ingress-nginx.enabled: true (temporary option).

  • Use your own ingress controller by enabling ingress and configuring the appropriate IngressClass.

    However, the bundled ingress-nginx sub chart is available in CloudBees CD/RO release 2026.06.0 for compatibility but, it will deprecated in future releases. Plan to migrate to a separately managed ingress controller or a Gateway API implementation before upgrading to a future release.

Upgrade kubectl argo rollout to version 1.9.0

The kubectl argo rollout plugin is upgraded to version 1.9.0.

Upgrade Apache Zookeeper to version 3.9.5

Apache Zookeeper version is upgraded from version 3.9.4 to version 3.9.5.

Upgraded Jetty to the latest secure version

CloudBees CD/RO now ships with an upgraded, security-patched version of Jetty. The REST API now strictly enforces the Content-Type: application/json header on requests that carry a JSON body. Clients that previously sent JSON payloads without this header will receive an error and must be updated to include:

Content-Type: application/json

Action required: Jenkins integrations If your Jenkins instance integrates with CloudBees CD/RO via the CloudBees CD plugin, upgrade the plugin to version 1.42 or later from the Jenkins plugin marketplace. Older plugin versions do not set the required Content-Type header and will fail to communicate with CD/RO after this upgrade.

Updated underscore.js to version 1.13.8 to address security vulnerabilities

Updated the Underscore.js dependency to version 1.13.8 across all frontend modules to address known security vulnerabilities and ensure consistent dependency versions throughout the frontend codebase.

Installation notes

The following information is a running list of installation notes intended to help understand changes across versions:

CloudBees Software Delivery Automation Helm charts are deprecated

Starting with CloudBees CD/RO release 2025.03.0, CloudBees will no longer release/support CloudBees Software Delivery Automation Helm charts. Instead, you must now install CloudBees CD/RO with CloudBees Analytics and CloudBees CI as separate components.

If you are currently using the CloudBees Software Delivery Automation Helm charts, CloudBees has provided automation scripting and instructions to help migrate your environments. For more information, refer to KBEC-00522 - Migrate from CloudBees Software Delivery Automation Helm chart to product Helm charts.

Remove support for EOL platforms

Starting with v2025.03.0, CloudBees CD/RO no longer supports the following end-of-life (EOL) platforms, as they are no longer actively maintained:

  • RHEL 7 (EOL: June 30, 2024)

  • Ubuntu 18.04 (EOL: May 31, 2023)

  • CentOS 7 (EOL: June 30, 2024)

Remote agents running on v2024.12.0 or earlier can still operate on servers running Ubuntu 18, RHEL 7, and CentOS 7 and are compatible with v2025.03.0 or later servers. However, to upgrade to v2025.03.0 or later, you must first upgrade the underlying operating system to a supported version. For more information, refer to the supported platforms pages:

You must upgrade to a supported platform prior to upgrading to v2025.03.0 or later. If you upgrade to v2025.03.03 or later, and your operating system is not supported, CloudBees CD/RO will not behave as expected and the local agent will not run. Additionally, if you do upgrade to v2025.03.0, and your operating system is not supported, to fix related issues, you must:

  1. Downgrade to your previous version.

  2. Update to a supported operating system.

  3. Upgrade to v2025.03.0 or later again.
DOIS service will be removed in CloudBees CD/RO Helm chart

In v2024.06.0, CloudBees Analytics migrated from using Elasticsearch (dois) to OpenSearch (analytics). Currently, in CloudBees CD/RO Helm charts, both the dois and analytics services are created by default, which was done to prevent data loss for users upgrading without previously migrating their Elasticsearch data.

However, if you already migrated to OpenSearch, to prevent unneeded resources from being created, you must manually configure your values file to disable dois. This creates additional steps in the upgrade process for users.

In an upcoming release (target v2025.06.0), the Elasticsearch (dois) service will be removed from CloudBees CD/RO Helm charts. Once this occurs, you must migrate your data to OpenSearch before upgrading to the release. If you do not, and you are still using the dois service for your analytics data, upgrading to the release may result in permanent data loss.

For more information on migrating your Elasticsearch (dois) data to OpenSearch (analytics), refer to Upgrade Kubernetes CloudBees Analytics environments to OpenSearch.

EC-Artifact v2.0.0 is not bundled with this release

For EC-Artifact v2.0.0, the plugin has been migrated to PDK. Additionally, v2.0.0 includes an improvement to the migration process for objects, such as releases, pipelines, and related configurations, by utilizing a new API introduced in CloudBees CD/RO v2025.03.0 and later.

However, EC-Artifact v2.0.0 is not bundled with CloudBees CD/RO v2025.03.0. Instead, this v2025.03.0 includes EC-Artifact v1.2.1.

After upgrading to CloudBees CD/RO v2025.03.0, you can install EC-Artifact v2.0.0 from the Plugin Catalog. The installation process will migrate existing objects, such as releases, pipelines, and related configurations, to align with the updated architecture. The duration of the migration process depends on the number of objects in your environment.

EC-Artifact v2.0.0 is not compatible with CloudBees CD/RO v2024.12 or earlier. Attempting to install it on an unsupported release will result in a failure that displays an Unsupported version error message.
Upgrading EC-SendEmail may be required prior to upgrade

In v2024.06.0, EC-SendEmail v1.2.0 was bundled with CloudBees CD/RO and included a fix for backward compatibility issues with scripting to automatically migrate affected objects. If you have already upgraded to v2024.06.0 or later or already installed EC-SendEmail v1.2.0 in your current environment, the migration process has already occurred, and no further action is needed before migrating to v2025.03.0 or later.

If you are migrating from v2024.03.0 or earlier, or you have not already installed EC-SendEmail v1.2.0:

  • For v2025.03.0, EC-SendEmail v1.2.1 is bundled, and features an improved version of the migration script that utilizing a new API introduced in CloudBees CD/RO v2025.03.0.

  • You can not install EC-SendEmail v1.2.1 in v2024.03.0 or earlier environments, because the API introduced in v2025.03.0 is not present and the installation fails.

  • When upgrading to v2025.03.0 or later, your CloudBees CD/RO objects will be automatically migrated during the upgrade. While it is possible to upgrade directly v2025.03.0 or later and allow your object to be migrated as part of the upgrade, it may cause the upgrade to time out and fail depending on the number of objects in your enviroment.

To avoid possible upgrade issues, CloudBees recommends:

  1. To first upgrade to EC-SendEmail v1.2.0 in your current version, and allow the migration to happen.

    • When migrating objects, the duration of the process depends on the number of objects (pipelines, releases, etc.) in your environment. For benchmark testing on the process, refer to SendEmail plugin release notes.

  2. After your objects have been migrated, upgrade to v2025.03.0 or later.

EC-SendEmail upgrade to v1.2.0

EC-SendEmail v1.2.0 is bundled with CloudBees CD/RO v2024.09.0. To avoid slowness while upgrading CloudBees CD/RO to v2024.09.0, update EC-SendEmail to v1.2.0 in your current environment prior to attempting the upgrade. Failing to perform this step may cause your CloudBees CD/RO upgrade to take a long time due EC-SendEmail updating objects.

For more information, refer to SendEmail plugin release notes.

Support for nginx-ingress will be deprecated from CloudBees CD/RO Helm charts in upcoming release

In Kubernetes v1.22, nginx-ingress was deprecated and replaced with ingress-nginx, and since then, most major cloud providers have removed support for Kubernetes v1.21 or earlier. Because of this, nginx-ingress will be removed from CloudBees CD/RO Helm charts in v2024.06.0, and no longer be supported by CloudBees CD/RO for Kubernetes.

If your project still uses nginx-ingress in your CloudBees CD/RO Kubernetes Helm charts, you must update them to use ingress-nginx prior to upgrading to future releases of CloudBees CD/RO. For help updating from nginx-ingress to ingress-nginx, refer to Before upgrading from Kubernetes v1.21 or earlier to v1.22 or later.

Plugins that use SSL/TLS certificate validation must be updated

When upgrading to v2024.03.0, plugins that use SSL/TLS certificate validation must be updated to their newest released version, due to changes in Perl libraries. If you do not upgrade these plugins, when running plugin procedures with Ignore SSL issues parameter enabled, SSL issues are not ignored and may cause issues in your pipelines and procedures.

When upgrading to v2023.12.0 on Kubernetes, new Analytics server certificates are required

When upgrading to v2023.12.0 on Kubernetes, you must regenerate your Analytics server certificates. If you attempt to upgrade to v2023.12.0 with certificates generated using image tags for v2023.10 or earlier, the Analytics server (flow-devopsinsight) fails to start. For more information on generating Analytics server certificates, refer to Configure CloudBees Analytics server certificates.

Remove support for Perl v5.8 from CloudBees CD/RO

In v2023.12.0, CloudBees CD/RO has been updated to use Perl v5.32, and no longer supports Perl v5.8. This update was made to improve the overall security posture of CloudBees CD/RO.

Starting with v2023.12.0, both ec-perl and cb-perl utilize Perl v5.32, and automation scripts that currently use ec-perl will be redirected to use Perl v5.32. Meaning, functionally using ec-perl and cb-perl is identical from v2023.12.0 and later. Additionally, instances of ec-perl within the CloudBees CD/RO documentation have been updated to cb-perl.

However, when upgrading to v2023.12.0 or later, there is a requirement for your agents to use cb-perl because of plugin dependencies. CloudBees CD/RO agents v10.3 and later are installed with cb-perl. However, if your environment uses v10.2 or earlier agents, you must update them when upgrading to CloudBees CD/RO v2023.12.0 or later.

Additionally, there are functional changes between Perl v5.8.9 and v5.32.1 that may impact your current automation. Before upgrading your agents to v2023.12.0, you can test your custom-coded steps that use ec-perl with cb-perl, using one of the following options:

  • In your custom-coded steps, replace all shell references to ec-perl with cb-perl, which already uses Perl v5.32, and run your custom-coded steps.

  • In ec-perl (<INSTALLATION_DIRECTORY>/bin), remove PERLDIR="$ECHOME/perl-legacy", which will then default to use Perl v5.32, and run your custom-coded steps.

    • In default installations, ec-perl is located in:

      • Windows: C:\Program Files\CloudBees\Software Delivery Automation\

      • Linux: /opt/cloudbees/sda/

      • Mac & ARM (legacy installer): /opt/electriccloud/electriccommander/

For help troubleshooting or migrating existing automations, refer to KBEC-00515 - Potential issues when upgrading from ec-perl v5.8 to cb-perl v5.32.

Kubernetes boundAgent images removed from Helm charts

In v2023.10.0, the cloudbees-flow Helm charts were updated to use global images (.values.global). As part of this change, boundAgent.imageRepository was removed from the bound agent Helm chart default values. Bound agents are now treated as child-chart deployments and created from cloudbees-flow-agent.values.images chart values.

If your projects use bound agent custom images, this change will cause upgrade issues since the CloudBees CD/RO Helm chart will not attempt to load your bound agent custom image. For information on using bound agent custom images, refer to Installation and deployment.

Unmatched DSL entries are by default treated as properties

When passing values in DSL, unmatched entry types are treated as properties. This is expected behavior. However, in some instances, this may result in unexpected errors. For instance, providing an array as a value when only a single value is expected results in the error message:

Could not parse XML: multiple values provided for argument 'value' where only one value is expected.
▼

To bypass this behavior, you can either:

  • Disable this behavior with the server setting: /server/settings/useAPIContextForDslProperties=false.

  • Use the Groovy keyword def with the variable definition in the DSL code.

Kerberos keytabs management will be discontinued

In v2023.10.0, CloudBees deprecated the Kerberos keytab APIs and removed the Kerberos keytabs management feature from menu:Configurations [SSO Configurations]. If your projects currently use Kerberos keytabs, they are unaffected. For information on configuring new keytabs, refer to Configuring single sign-on with Kerberos.

Behavior to update lists of Global Personas has changed

In previous CloudBees CD/RO versions, when adding new personas using the modifyGroup and modifyUser APIs with the --personas argument, new personas would completely overwrite the list of existing personas, leaving only the newly added ones (default: replace).

In v2023.10.0, this behavior changed to only append the new personas passed using --personas to the existing personas list (default: merge). However, if you want to overwrite the list of existing personas with a list of new personas passed using --personas, you can do so using the --clearPersonas true argument.

If you are currently using automation to replace your complete list of personas when adding a new one, you must now include --clearPersonas true argument or any new personas will only be appended to the existing personas list.

ec-jruby and ec-jython wrappers deprecated

CloudBees deprecated the CloudBees CD/RO ec-jruby and ec-jython wrapper programs with v10.11. The wrapper programs are no longer installed as part of CloudBees CD/RO tools.

Potential backward incompatibility

CloudBees CD/RO Docker images are now based on UBI minimal instead of UBI standard, as in previous releases. Some packages are not installed on our Docker images by default. This may cause backward incompatibility if your environment depends on these tools and utilities. CloudBees CD/RO Docker images now use microdnf as a package manager and yum and dnf package managers are no longer available. To retain backward compatibility, CloudBees CD/RO provides a symlink for microdnf as dnf. These package managers are not 100% compatible, which may cause unexpected errors and require modification of the scripts.

CGI module and support removed

CloudBees removed the CGI module and support with v.2023.02.0. After you upgrade your CloudBees CD/RO server to v2023.02.0, you must also upgrade your CloudBees web server.

UI file upload limits are now controlled by PHP in /opt/cloudbees/sda/apache/conf/php.ini.

For default parameter values and more information, refer to Configuration settings preserved after an upgrade.

Duplicate applications warning

CloudBees CD/RO v10.9 included a fix for an issue that caused duplicate applications for applications created in the UI. The upgrade process fails when there are duplicate applications. CloudBees resolved this issue for MariaDB, MySQL, and Postgres databases. Ensure that your current installation does not contain applications with duplicate names. You can rename or delete the applications. You must remove duplicate applications by ID using the deleteObjects API. You cannot delete duplicate applications by name. For more details and scripts to assist with this process, refer to KBEC-00513 - How to resolve applications with duplicate names before upgrading from a version prior to v10.9.

Apache ZooKeeper required update

The ZooKeeper version bundled with CloudBees CD/RO v10.5 was updated from v3.4.6 to v3.8.0. CloudBees CD/RO v10.5+ requires ZooKeeper v3.8.0. For installation and upgrade instructions, refer to Install ZooKeeper and Upgrade a clustered environment.

Legacy services applications and container entities

In CloudBees CD/RO v10.3, the legacy Services applications and Traditional applications with containers were deprecated and removed. Before you upgrade to CloudBees CD/RO v10.3 or later, you must migrate your applications to the current microservices application model.

Legacy webhook triggers

As of v10.8, webhook triggers configured and scheduled before v10.1 have been deleted. Polling triggers configured and scheduled prior to v10.1 continue to work, but they are not available from the UI to review or run.

CloudBees CD/RO server installation binaries are signed for traditional installations so that you can verify their origin and authenticity. Verifying binaries is an optional step in the installation process that can help prevent a man-in-the-middle attack. For more information, refer to Verify installation binaries.

Upgrading gateway agents

All gateway agents that meet the following criteria must be updated to CloudBees CD/RO v10.2+:

  • Your enterprise implements a multi-zone environment.

  • Agent versions are a combination of pre-v10.2 and v10.2+.

  • The access route to a v10.2+ agent is configured through a pre-v10.2 gateway agent.

Configuring autostart services for Linux installations

Linux installations that you perform as a non-root user or without sudo permissions cannot automatically start the CloudBees CD/RO server, web server, repository server, or agents. Instead, you must set up the service autostart after installation is complete. Refer to Configure autostart for non-root/non-sudo Linux installations to learn more.

Upgrading your CloudBees CD/RO environment
Before starting an upgrade, make sure to back up your existing CloudBees CD/RO data.
Upgradable versions

Upgrades to CloudBees CD/RO 10.x are supported only from ElectricCommander 5.0. For upgrade instructions, refer to the Upgrade on traditional platforms.

Updating the MySQL configuration before upgrading

Since release 8.0.1, CloudBees has instructed customers using a MySQL database to add the following two lines to their MySQL configuration:

init_connect='SET collation_connection = utf8_unicode_ci, NAMES utf8'
skip-character-set-client-handshake

Before upgrading CloudBees CD/RO, you must remove these lines or comment them out. Otherwise, jobs will not start.

Ensuring the correct default MySQL default collation

Make sure that the default collation for the MySQL database schema is set to utf8_unicode_ci or utf8_general_ci and that no table in the schema overrides this setting. The CloudBees CD/RO server checks this configuration on startup and logs errors in the server log if it is not set correctly.

If the collation is not configured correctly, entering non-ASCII text into CloudBees CD/RO can cause errors. For example, setting a release name to a non-ASCII value, and attempting a search, causes an exception.

If your MySQL database schema, or any tables within, are set to a non-UTF-8 collation order, refer to the Knowledge Base article KBEC-00385 - Converting a MySQL Database From Latin-1 to UTF-8 for detailed instructions about safely converting your schema to UTF-8. [NMB-26521, NMB-27459]

Upgrading agents that run the ec-groovy job step in multizone deployments

In multizone CloudBees CD/RO deployments, CloudBees CD/RO agents that are in a different zone than the CloudBees CD/RO server must be upgraded to version 9.0 or later for the ec-groovy job step to run successfully on those agents. You must also upgrade the gateway agents that lead back to the server’s zone, including those in any zones in between the agent’s zone and the server’s zone. [NMB-27490]

For details about multiple zones and gateway agents, refer to Zones and gateways.

Removing the SSL 2.0 Client Hello or SSLv2Hello protocol from your security configurations

CloudBees recommends removing the SSL 2.0 Client Hello or SSLv2Hello protocol from your security configurations for all components. [NMB-27934, NMB-29326]

  1. Upgrade agents to the latest operating system version for security reasons.

  2. If this warning appears on the Automation Platform UI:

    Note: We recommend removing `SSL 2.0 Client Hello` format from server configuration and upgrade older agents as indicated on the Cloud/Resources Page to avoid security risk.
    ▼

    then enter the following command on the CloudBees CD/RO server:

    $ ecconfigure --serverTLSEnabledProtocol=TLSv1.2
    ▼
Upgrading the CloudBees Analytics server

This section provides information about upgrading the CloudBees Analytics server.

Potential breaking change: Elasticsearch update

The Elasticsearch version shipped with CloudBees Analytics v10.2 has been updated from v6.6.2 to v7.10.2. As such, this update may create breaking changes in your custom reports. All changes related to the new version are described in Elasticsearch documentation.

Your customs reports may be affected due to changes for missing document values handling. The doc['field'].value now throws an exception if the document is missing a value for the field field. To check if a document is missing a value, you can use doc['field'].size() == 0.

  • It is not possible to upgrade CloudBees Analytics v9.0.1 and below to CloudBees Analytics v10.2.0 and above. The installer exits with an error and an appropriate message when such an update is attempted. If you need to upgrade CloudBees Analytics v9.0.1 and below, you must first upgrade to a version between 9.1.0 and 10.1.0, or 9.0.2 and above. After that, you can upgrade CloudBees Analytics to v10.3.0 or higher. [NMB-31030]

  • For previous CloudBees Analytics upgrades from v9.0.1 and below: CloudBees Analytics data may contain obsolete indexes that are incompatible with CloudBees Analytics v10.2.0 and above. To work correctly, it is necessary to re-index these indexes before an upgrade. The installer prompts you to do this before upgrading.

    • In console mode and UI mode, the installer displays the following prompt if outdated indexes are detected:

      One or more Elasticsearch indexes were created in an obsolete version of Elasticsearch.
These indexes must be re-indexed for the upgrade to be successful.
Do you want to start the reindexation? [n/Y]
      ▼

      After an affirmative answer, the installer automatically reindexes and continues the upgrade.

    • In silent mode, the installer reindexes automatically.

  • Backing up and restoring custom settings

    The CloudBees Analytics installer overwrites the elasticsearch.yml configuration file with a new file. This file includes a Custom Settings section, which lets you add Elasticsearch settings not managed by the CloudBees Analytics server without being lost during an upgrade. The installer preserves the settings in the Custom Settings section. [NMB-25850]

  • Upgrading CloudBees Analytics clusters

    The principle of forming a cluster in CloudBees Analytics has changed in v10.2 due to the update of Elasticsearch v7.10.2. In this regard, an additional action is required to upgrade to CloudBees Analytics v10.2 or later:

    When updating the first master node, you must explicitly specify that it is the first node to be updated. If this action is not performed, any cluster that is being updated is placed out of service.

    All installers have been instrumented to accommodate this change. Refer to Upgrade the CloudBees Analytics server for more details. [BEE-2717]

  • CloudBees Analytics server configuration notes

    For a production environment, CloudBees recommends that you install the CloudBees Analytics server on a system separate from systems running other CloudBees CD/RO components (such as the CloudBees CD/RO server, web server, repository server, or agent). If you must install it on the same system (such as for testing or other non-production or trial basis situations), refer to CloudBees Analytics server with other components for details.

    If your CloudBees Analytics server is configured with multiple nodes in a Kubernetes environment, you must pre-generate your certificates. For more information, refer to Install CloudBees CD/RO within Kubernetes.
CloudBees CI operations center configurations

After upgrading to CloudBees CD/RO v10.7 from v10.0.x, you may need to rework your CloudBees CI operations center configurations.

  • In v10.0.x, CloudBees CI operations center URLs specified in configurations are silently appended at runtime with the /cjoc path component.

  • In v10.1, URLs are used as defined in configurations. The /cjoc component is not appended. To maintain pre-v10.1 runtime compatibility, the v10.1 upgrade process modifies CloudBees CI operations center URLs in existing configurations by hardcoding the /cjoc path component. You need to rework existing URLs in configurations where appending the /cjoc path component is inappropriate.

Configuration notes

The following information highlights important configuration notices from previous releases:

Performing a full import

During a full import, the import operation might hang in the following scenarios. To import successfully into CloudBees CD/RO 8.0 and newer versions, perform the appropriate workarounds [CEV-15447, CEV-11873]:

  • A manual process step in a process has formal parameters. The workaround is to remove the entry related to the property sheet for the job step that is associated with the manual process step.

  • In the exported XML file from an earlier release, two pipelines are in different projects, and both pipelines have no gate tasks. The flow associated with the pipeline is duplicated under both projects. The workaround is to remove the flow element under the projects.

Limitations

When an application is cloned from one project (the original project) to another (the destination project), the tier maps for the application point to the environments with the same names in the destination project. To deploy the application to the environments in the original project, you must first create tier maps connecting the application to those environments.