Our users operate on a global scale, delivering security-critical projects across all areas of infrastructure design, engineering, and operations. Project delivery regulations continuously evolve, and right now—as we accelerate enabling digital transformation for multiple workflows—it is paramount that our Bentley Support Policy remains current. Many aspects of our industry, company, and user base lead to this update, including, but not limited to the following:

• The importance of information and cyber security is paramount. Only by continuously monitoring the fast-evolving threat landscape and updating the software as necessary to stay ahead, we can ensure that our users are protected in every step of a project lifecycle, from exchanging files in the design phase to operations of critical infrastructure assets.


• The length of time a product version remains supported and available in the market has a strong correlation with the potential security risks associated with that version. Hence, time-bound application version support lifecycle is necessary for evolving security risks to be effectively managed and mitigated, while providing users a clear timeline to plan major upgrades.


• As we continuously expand and improve our portfolio of infrastructure engineering software, to keep providing our users comprehensive and clearly defined support expectations, we need to occasionally update the terms and conditions on what we support and how we do it.


• A closer alignment with industry best practices will enable our users to better manage Bentley applications within their software portfolios as well as enable Bentley to better utilize a growing ecosystem of technologies and services by third-party vendors to improve our offerings.

Technical support describes the methods by which the user can contact Bentley’s Technical Support department and the level of assistance that one can expect to receive.

Maintenance describes the types of software updates the user can expect to receive for a version, depending on a version support phase that applies to it. Version support phases will be further defined in the sections below.

The following table outlines compatibility categories.

Compatibility category	Description
Data backward compatibility	Data created with previous versions is supported without loss of fidelity
API compatibility	No breaking API changes
Cross-application compatibility	No items removed from the list of supported versions of other Bentley and third-party applications (e.g., supported ProjectWise Design Integration versions)
OS compatibility	No items removed from the list of certified operating systems

Empty heading

Compatibility assurances for each version type are detailed in the table below.

Version type	Data backward compatibility	API compatibility	Cross-application compatibility	OS compatibility
Major version	✓*	P	P	P
Minor version	✓	✓	✓	✓

Empty heading

✓ – Included P – Breaking changes may be occasionally introduced. Supporting documentation and upgrade assistance tools (if necessary) will be provided with any breaking changes to make the process of upgrading as simple and streamlined as possible. * – Occasionally, may require an automated or user-assisted file format/database schema conversion.

Version release cadence defines how often application versions are released.

As part of our application versioning changes, for most of the applications covered by this policy, we are adopting an annual release cadence (i.e., a single major version release per calendar year). The number and cadence of minor version releases may vary.

As part of our application versioning changes, Bentley is moving to a more consistent version naming and version number scheme. One notable aspect of this is the use of the calendar year of the original release date, helping users to easily determine the support timeframe for the version. Application Version Name is defined in the following form: <Application name> <Major version>

Version name part	Description
<Application name>	Full name of the application. E.g., “OpenRoads Designer.”
<Major version>	Name of the major version in the form <YYYY> [Update <N>], where: YYYY – major version year. Calendar year of the original release date. N – major version sequence number. Used when releasing multiple major versions per year and specifies sequential number of the version within the year. The value starts with “0” for the first major release. Included in the name starting with the second major version, i.e., staring with the value “1.” Example: The first major version release in 2023 is named “2023.” The second major version released in the same calendar year is named “2023 Update 1” and so on.

Application Version Number consists of 4 parts, where each part is a zero-padded number and is defined in the following form: AA.BB.CC.DD The following table outlines a convention for version number parts.

Version number part	Description
AA.BB	First two version number parts correspond to a major version, where: AA – last two digits of the major version year, BB – major version sequence number.
CC	Minor version number. Value is reset to “00” when incrementing AA or BB.
DD	Build number. Value is reset “01” when incrementing any other version part.

Examples

Version number part	Description	Description
MicroStation 2023	23.00.00.102	Major version – 2023 Build – 102
MicroStation 2023	23.00.02.42	Major version – 2023 Minor version – 2 Build – 42
MicroStation 2023 Update 1	23.01.00.99	Major version – 2023 Update 1 Build – 99
MicroStation 2023 Update 2	23.02.03.07	Major version – 2023 Update 2 Minor version – 3 Build – 7

CONNECT Edition versions released prior to January 1, 2023, will be supported at least until December 31, 2025*. For applications with a less frequent release cadence, the support period may be extended beyond December 31, 2025, to ensure that CONNECT Edition versions released prior to January 1, 2023, are supported for at least 12 months after the release date of the next major version.

* – If an application enters Expiring Support before December 31, 2024, the support period will last until the end of the Expiring Support phase, which may be prior to December 31, 2025.

V8i SELECTseries 10 reached end of support on December 31, 2021, concluding support discontinuation for V8i and earlier generation versions. Please see our prior announcement on this change for more information here. There are no changes to the support status for these versions.

Examples 1 & 2: Version Support phase transitions for an application in the Continuous Support phase

Example 3: Version Support phase transitions for an application in the Continuous Support phase