octoplant Asset Lifecycle Management and OT Obsolescence Planning

octoplant asset lifecycle management is AMDT’s answer to a question every plant eventually faces: which of our controllers, HMIs, drives and network devices are ageing out of support, and what do we do about it before one fails? The feature arrived in octoplant’s Spring Release 107 in April 2026, described as a way to “track the status and lifecycle of your assets” and “identify outdated components and plan updates or migrations before they become urgent”. octovision surfaces the same information across sites, flagging what AMDT calls “aging, outdated, or unsupported assets”.

This page explains what the data is, where it comes from, and, more importantly, how to turn it into a migration roadmap and a capital plan. It sits under the octovision overview in the AMDT cluster.

What octoplant asset lifecycle management covers

Two kinds of fact meet in this feature:

• What you have. octoplant’s backup jobs read the hardware model, firmware version and engineering software version from each managed device. This is the same version-exact data that drives vulnerability management.
• What the vendor says about it. Whether that model or version is current, mature, announced for discontinuation or already discontinued. AMDT states on its innovation page that it uses AI agents to build and maintain obsolescence and lifecycle intelligence at the intelligence layer, not on production devices.

The Summer Release 2026 extended lifecycle enrichment to assets imported by CSV, so unmanaged devices from a discovery tool or a maintenance system can carry a lifecycle status too.

Lifecycle stages, and why firmware counts

Every major automation vendor publishes some form of lifecycle status, though the names differ. Rockwell, for example, uses Active, Active Mature, End of Life and Discontinued, defined on its product lifecycle status page and explained on our Rockwell Automation hub. In Rockwell’s definitions, End of Life means a discontinued date has been announced and the product is generally still orderable until then, which is the last-time-buy window in the table below. Other vendors use their own terms and dates. Which vendor schemes octovision normalises, and how, is not public as of October 2026.

Hardware status is only half of it. A controller model can still be on sale while the unit in your panel runs firmware that is eight years old. That firmware may carry unpatched CVEs, may need an engineering software version that no longer installs on a supported Windows release, and may not be restorable onto a replacement module shipped with newer firmware. In practice the restore problem catches plants first: the spare arrives, the old project will not load onto it, and a two-hour swap becomes a day.

Lifecycle signals and what to do about them

Signal in the data	What it means	Sensible action
Hardware active, firmware current	Supported and patchable	Keep backups current. Nothing to plan
Hardware active, firmware several versions old	Supported, but exposure and restore risk growing	Plan a firmware update in a normal window, with a backup before and a compare after
Hardware mature (newer model preferred)	Still supported; stop specifying it	Freeze new installs of this model; add to the roadmap horizon
Discontinuation announced	A last-time-buy window exists	Decide now: buy spares or schedule migration. Doing neither is a decision too
Discontinued, no vendor support	Repairs and spares on the secondary market	Migration is a matter of when; rank by criticality and spares on hand
Engineering software unsupported	The project may not open on a modern PC	Preserve a working engineering environment now; it is the recovery path

From octoplant asset lifecycle management data to a roadmap and capital plan

The value of octoplant asset lifecycle management is not the flag. It is that the flag arrives across every site in one format, which removes the most expensive part of modernization planning: walking the plant with a clipboard. A practical sequence:

1. Validate the inventory. Check octoplant job status and the managed versus unmanaged ratio described on the asset inventory page. A lifecycle view of 60% of the plant is a partial picture.
2. Group by line, not by device. Production stops by line. A roadmap that replaces one PLC per year on a line with six of them pays for six outages.
3. Overlay criticality and spares. A discontinued controller on a non-critical line with three spares on the shelf ranks below a mature one on the bottleneck with none.
4. Check the vulnerability overlap. Assets that are both obsolete and carrying unpatchable CVEs move up.
5. Sequence into windows. Tie each tranche to planned shutdowns over three to five years.
6. Price it. Hardware is usually the smaller cost. Engineering, testing and commissioning dominate.

Steps 2 to 6 are the work of a modernization roadmap. The individual migrations, such as legacy PLC platforms to current ones, are PLC migration projects. Our Rockwell PLC lifecycle and migration guide walks through that decision for the most common North American installed base.

An illustrative example. A food plant’s octovision view shows 14 controllers on a discontinued family across three lines. Without the overlay, that reads as one urgent project. With it, two sit on the bottleneck line with no spares, and those become year one. The rest follow with the next two annual shutdowns, and the capital request goes to finance as a three-year plan with a reason for each line item.

Obsolescence and recovery are the same conversation

A discontinued controller is a risk you can manage if two things are true: a verified, current backup of its program exists, and a compatible spare is on the shelf. Remove either and the risk changes character. Without the backup, a failure means rebuilding logic from an old file or from memory. Without the spare, it means a secondary-market search while the line is down.

That is why lifecycle data belongs next to backup data rather than in a separate spreadsheet. A lifecycle view that also shows the last successful octoplant job for each asset answers the question a plant manager actually cares about: if this unit dies tonight, how long are we down? The recovery side is covered on the disaster recovery page.

In practice, three numbers per line tell most of the story:

• Assets past vendor support, as a count and a share of the line.
• Assets without a recent verified backup, from octoplant job status.
• Spares on hand for the discontinued models, from the CMMS or the storeroom.

A line that scores badly on all three is next on the roadmap, whatever its age on paper. A line that scores badly only on the first can often wait a year, provided backups and spares stay in place and someone checks them.

Where it gets hard

• The source of lifecycle status is opaque. AMDT describes AI agents maintaining it, but not the underlying sources or how errors are corrected. Spot-check a sample against the vendor’s own lifecycle pages before you build a budget on it.
• Vendor terms do not line up. “Mature” at one vendor and “classic” at another may mean different things. Normalisation hides those differences.
• Unmanaged rows are weak data. A CSV import from an old asset register carries whatever model names someone typed years ago.
• Software lifecycles are easy to miss. Engineering workstations, HMI runtimes and their Windows versions age on their own schedule.
• The data does not know your spares. Stock on the shelf, repair contracts and secondary-market availability live in the CMMS and in people’s heads.

---

Related: octovision overview · octovision Vulnerability Management · AMDT AI Companion · versiondog and AutoSave end of life · AMDT hub