Knowledge base/Pricing & support/How are upgrades handled across a 70-year asset lifecycle?

Context

Software changes. Standards evolve. Your asset still has to be readable in 2095. This is the question that distinguishes serious long-term asset software from short-term project software. We treat each major release as a managed migration, never a forced upgrade.

Backwards-compatible standards, long-lived release branches, standards co-evolution.

Explanation

Three mechanisms keep upgrades manageable:

Mechanism 1

Backwards-compatible standards

Because the data is stored in open standards (RDF, ISO 15926-11), every major Weaver release reads the previous releases' data without conversion. If we ever need a breaking change, the migration is documented in the open standard, not in a Weaver-internal format.

Mechanism 2

Long-lived release branches

Major releases get long-term support, typically 7+ years. Customers on regulated assets aren't forced to upgrade on our schedule; they upgrade when they're ready, with full release-engineering support.

Mechanism 3

Standards co-evolution

Weaver participates in the working groups for ISO 19650, ISO 15926-11, buildingSMART. When standards change, Weaver adapts in step. Customers inherit the standards updates automatically.

The architectural commitment is that the asset's information remains readable not just for the lifetime of any one Weaver release, but for the lifetime of the asset. That is the whole point of building on open standards.

Was this article helpful?