The upgrade is where most PLM platforms take their revenge. It is the recurring cost that does not appear in the sticker price, the reason large estates run years behind and the single strongest reason to think hard before customising anything — the argument we made at length comparing Aras to Windchill.

Aras handles this differently, and the difference is real. But "Aras does the upgrade for you" gets rounded up to "Aras upgrades are effortless," and that rounding error is how an otherwise smooth upgrade goes sideways. This paper is about the half of an Aras upgrade that is still yours, because doing that half well is the whole game.

What the subscription actually does

Under the Aras subscription, upgrades are a service Aras performs, and the scope is unusually broad. Aras's own material states the upgrade includes all the labour to upgrade the database including any customisations you have made, and that the amount of customisation does not change whether you can upgrade (Aras, Subscriber Platform Upgrades; subscription benefits). Because the business model is metadata rather than compiled code — ItemTypes, forms, workflows and methods held as data — carrying your configuration forward is a tractable job rather than a rewrite, which is the architectural reason the promise can be kept.

The mechanics are worth knowing, because they tell you where your work sits. The service is performed remotely: you provide your database, Aras delivers back an upgraded environment and then — this is the important part — you perform your own in-house verification testing and report the results. Integrations and CAD connectors are handled separately from the core platform upgrade.

Read that sequence again, because it draws the line precisely. Aras owns the platform upgrade and the migration of your customisations. You own the verification, and you own the surrounding integrations. That is the half this paper is about.

The one thing that quietly derails it

If an Aras upgrade goes wrong, it is usually not the platform and not the customisations. It is the integrations — the ERP connector, the CAD connectors, the custom REST clients, the reporting feeds — because those are the part explicitly outside the core upgrade, and they are the part nobody inventoried before starting.

An integration is a contract between two systems, and an upgrade can change one side of it. A method signature moves, a REST response gains a field, an authentication flow tightens — and the connector that has run untouched for three years quietly stops, often without a loud error, in exactly the silent-failure way that CAD references break.

So the first rule of an Aras upgrade is not about Aras at all: inventory every integration before you begin, and own a test for each one. If you do not know how many external things talk to your instance, that number is your real upgrade risk, and it is knowable in an afternoon.

Verification: test use cases, not screens

"You perform your own verification testing" is a sentence that decides whether the upgrade succeeds, and most teams under-scope it into a click-around smoke test: open a part, open a change, looks fine, sign off. That tests whether the screens render. It does not test whether the business still works.

Verify the way a migration should be verified — against use cases, not counts:

  • Run your most complex real workflow end to end, with a real approver, not a happy-path demo one.
  • Exercise your heaviest customisations — the ones with server logic — under the conditions that actually stress them, not just their existence.
  • Fire every integration and confirm data crosses in both directions.
  • Run where-used and impact queries on real parts and check the answers match the pre-upgrade system.
  • Have a real user do a real day's task on the upgraded environment, unaided, and watch.

Write this test set down once and it becomes a reusable asset — because with Aras you will upgrade again, cheaply, and a standing verification pack turns each future upgrade from a project into a checklist.

The 30-month clock, and why you should not sit on it

Here is the honest constraint, because a paper that pretends Aras never needs upgrading is a brochure. Aras provides upgrade services for each release for thirty months from that release's date, after which the release reaches end of life (Aras upgrades). So there is a clock — it is simply a generous one, and it resets every time you stay current.

The mistake is to treat "we can upgrade cheaply whenever we like" as "we can upgrade whenever we get around to it," and then drift toward end of life anyway. The entire value of the model is that staying current is cheap and low-risk — so the correct posture is to use that, upgrade on a comfortable cadence well inside the window and never accumulate the multi-version gap that makes other platforms' upgrades so painful in the first place. A team that lets an Aras instance go end of life has paid for the cure and declined to take it.

What the numbers say, honestly sourced

The evidence for how different this is comes with a caveat worth stating: the best-known figures are from a CIMdata study that Aras commissioned in 2021, so weigh them as an interested party's data — but they are specific and they match what practitioners report. That study put typical Aras upgrades at around three months against eleven to fourteen elsewhere, at a fraction of the cost, with 87% of Aras customers saying customisations did not inhibit the upgrade (summary).

A named, checkable example carries more weight than a commissioned survey: Kawasaki Robotics runs Aras for 1,300 users across more than 1.2 million items and reports completing each upgrade within two to three months despite in-house customisation (case study). That is the promise landing in practice, at real scale, with the customisation that the promise says will not get in the way.

The playbook, in one page

Before. Inventory every integration and CAD connector — this is your real risk list. Know your heaviest customisations and what stresses them. Clean obvious data problems first, so you are not verifying against a mess. Confirm which release you are on and how far it sits from end of life.

Hand-off. Give Aras a representative database, not a stripped-down one — you want the upgrade tested against your real complexity, not a toy.

Verify. Run the use-case test set above, not a smoke test. Test integrations in both directions. Have a real user do real work. Report results precisely, so Aras can act on specifics rather than "something feels off."

After. Keep the verification pack. Schedule the next upgrade inside the window rather than waiting for a reason. The whole point of this model is that current is cheap — so stay current.

Aras does the hard structural part that sinks upgrades elsewhere: the platform and your customisations come forward as a service, because they are data rather than code. What remains is genuinely yours — verifying that your business still works and keeping your integrations honest — and it is very doable, provided you treat it as real work rather than assuming "included" meant "handled."

Working paper, written by a consultancy that implements on Aras. If you are planning an upgrade and want the integration inventory and verification pack built before you hand over the database, get in touch.