Exstream upgrades fail in predictable ways, and almost all of them trace back to two decisions made carelessly: what the upgrade unit is, and what counts as proof that output is unchanged. The strategy set below was established in the HP 8.x era and remains recognizably current through CE 25.4 classic.
Choose the upgrade unit deliberately
The design environment, design database, package files, and production engine do not have to move together. That is a feature, and each combination is a different strategy with different risk:
A full upgrade replaces everything: desktop software, database, rebuilt packages, new engine. Every application gets the new functionality, and every application needs retesting. Largest surface, highest test burden, simplest end state.
An engine-only upgrade installs a newer production engine while leaving the design environment, database, and existing packages in place. Historically a supported way to pick up an engine defect fix. The costs: no new design features, and a version mismatch between local design execution and production that the team must keep in mind daily.
An incremental upgrade moves selected applications through an interim upgraded database into the destination. Work can continue in the original environment, but the same application temporarily exists in more than one database. Back up the destination before each load, control against overwriting existing objects, and retest after loading, because the destination database can change an application's context.
An as-needed upgrade updates the design environment, database, and engine, but keeps old packages on the old engine until each application is repackaged and approved. Stable applications avoid immediate retesting, at the price of running multiple engine versions in production, which the operational controls must make explicit. Most defensible when applications have very different change frequencies.
Use backward-compatibility switches during diagnosis
The engine's backward-compatibility mechanism can temporarily restore earlier behavior.
In current classic releases, -ENABLE_BACKWARD_COMPAT=<version> applies the switches implemented since that version, the two-version form selects a range, and the engine can produce the list of switches that actually apply to your application.
Use that list to isolate a specific changed behavior, compare outputs, understand the cause, and then remove the switch. Two warnings from both the historical and current guidance: applying all switches can roll back defect fixes along with behavior changes, and a compatibility switch left permanently enabled is an undocumented fork of engine behavior that someone will eventually rediscover as a mystery.
The regression unit is a package-and-engine run
Upgrade testing needs a controlled package-and-engine run, representative inputs, and checks across every affected output path. The repeatable unit is a scripted package-and-engine run: batch packaging rebuilds named applications reproducibly, and batch engine scripts recreate output against different engine installations using identical driver data, control inputs, package selection, and output destinations.
The comparison set must include every output type and production condition the upgrade touches, including sorting and bundling when they are part of the live path. Compare output pages, font resolution, accessibility metadata, sorting behavior, report files, and resource references. An application that opens in the new Designer proves nothing about its package and output under the new engine, and packages are version-sensitive artifacts: do not assume a package built by an older engine equals one rebuilt by the new one.
Release notes are test inputs
Back up databases before conversion, run database maintenance in the current version first, and upgrade a copy before touching the original. Read the release notes and known-issue lists for every version you cross, major and maintenance, before testing. A maintenance release generally targets fixes; a major release can change functionality and output. The notes tell you where to concentrate the comparison set, which makes them inputs to the test inventory, not paperwork to consult after a failure.