OpenRoads Designer Versions, Schemas, and the Reality of Delivery Requirements
Managing software versions is not a new challenge for teams, but with the pace of OpenRoads Designer (ORD) releases and evolving schemas, it has become a more visible and potentially more disruptive topic. Recent discussions and presentations in relation to schema management highlight improvements in Bentley’s tooling and processes. At the same time, real-world delivery constraints introduce considerations that are often understated.
This post is not intended to refute Bentley’s guidance, but rather to add a complementary perspective informed by day-to-day experience supporting consultants, DOTs, and public agencies.
Schema Management Has Improved — That Matters
There’s no question that schema upgrades in OpenRoads Designer are more stable today than they were years ago. Moving projects forward to a newer schema, when done carefully and with periodic validation, is less disruptive than it once was. For many organizations, this progress has reduced fear around upgrades and opened the door to more proactive version management.
From a purely technical standpoint, Bentley is correct: the tools exist, and they continue to get better.
The Missing Variable: Delivery Requirements
Where the conversation often diverges from reality is at the point of project delivery.
For many consultants, especially those working with DOTs and other public agencies, the determining factor should not be what is technically possible, rather what is contractually required. Agencies are often explicit about the software version their standards are created with and require the same for DGN based deliverables. Additionally, many agencies strictly enforce these version requirements.
In these environments:
- Deliverables are commonly required in a specific OpenRoads Designer version.
- Substituting a newer version is rarely accepted.
- Requests for exceptions or justifications are often unsuccessful.
As a result, the safest and most predictable approach is straightforward:
When DGN files with civil content are to be delivered, design work should be done in a compatible ORD version aligned with the agency’s required schema standards.
Upgrade vs. Conversion: A Practical Distinction
It’s also helpful to distinguish between upgrading project files compared to conversion of project files.
Upgrading a project forward to the newest allowable version (for example, when an agency updates its standards) is generally stable and usually recommended. Conversion, working in a newer version than required and then downgrading files prior to delivery introduces unnecessary steps, risk, and time with little upside.
In practice, working ahead of the delivery version can:
- Lock files to newer schemas
- Potentially introduce unsupported content
- Require additional downgrade workflows
- Complicate collaboration with additional project stakeholders
- Add QA overhead that doesn’t directly benefit the project
The Case for Multiple Environments
While maintaining multiple ORD versions can sound burdensome, it is often simpler—and safer—than attempting to force all projects into a single version strategy. Separate environments aligned to delivery requirements tend to be more predictable and less prone to subtle issues than heavily modified and arbitrarily aligned configurations.
This leads to another common pitfall.
Don’t Hide the Complexity
A well-intentioned goal among CAD and BIM managers is to shield users from complexity. However, versioning and schema differences are not problems that can be hidden indefinitely. When users don’t understand the implications of working in the wrong version, issues tend to surface later during coordination, delivery, or QA when they are more expensive to fix.
In our experience, informed users make better decisions. Transparency around versions, schemas, and delivery implications reduces risk rather than increasing it.
Testing New Versions of OpenRoads
EnvisionCAD has found that when reviewing new OpenRoads versions, it is valuable to test the new version using the same workspace as previous version, at least for preliminary review. By using the old workspace, without updating the schema, avoids the need to maintain parallel workspaces until a level of confidence in the new version is achieved. EnvisionCAD recommends full schema update for the workspace for final testing.
A Simple Rule of Thumb
While every organization is different, a practical guideline holds up well:
- Agency / DOT work:
Align design work with the required delivery version. - Non-agency work:
You may have flexibility to standardize and migrate projects forward on your own schedule.
The impacts of such a strategy will include:
- The need to maintain multiple versions of OpenRoads on every computer.
- The need to maintain multiple versions of various workspaces.
- An education effort for all designers to enhance understanding of schemas and the need to match each project to a specific version of OpenRoads Designer and workspace.
Final Thoughts
Bentley’s continued investment in schema management and upgrade tooling is important and valuable. At the same time, successful version strategies must account for contractual requirements, agency expectations, and the realities of project delivery.
There is no single “correct” approach—only approaches that fit the work you do and the clients you serve. The most effective strategies tend to be the ones that balance technical capability with practical constraint.
