Asset lifecycle end to end: four dates decide your entire replacement budget

There are two different jobs hiding under "asset management." One is custody: what do we own, who has it, did it come back. The other is lifecycle: what is aging out, what is out of warranty, what has to be budgeted for next year and the year after.

Most tools do the first well and the second not at all, and the tell is which fields are populated. Custody runs on assignment and location. Lifecycle runs on four dates and one number: purchase date, warranty expiry, end-of-life date, and cost.

Why those four

Purchase date gives you an age distribution, which is the only honest basis for predicting how much of the fleet turns over in a given year. Warranty expiry tells you which failures you will absorb rather than claim. End-of-life tells you which machines stop receiving security updates regardless of whether they still work. Cost turns all of it into a number a client can put in a budget.

Each is useless alone. Together they answer the only asset question an owner actually asks: what is this going to cost me, and when.

An asset list that cannot produce next year's replacement budget is an inventory, not a lifecycle programme.

The number nobody reports: untracked

Here is the failure mode that makes lifecycle dashboards dangerous rather than merely incomplete. If forty percent of your devices have no warranty date, a dashboard that shows "three devices expiring in 30 days" is technically correct and practically a lie — it is reporting on the subset that happens to have data, and presenting it as though it describes the fleet.

So the tracked-versus-untracked count belongs on the dashboard next to the buckets, not on a data-quality page nobody opens. It converts the headline number from a claim about your fleet into a claim about your fleet's known portion, which is what it always was.

Bucketing, and why the past-due bucket is separate

The useful shape is expired, then expiring within 30, 60, and 90 days, with end-of-life tracked as its own list rather than folded in. Expired gets its own bucket because it is a different conversation: not "plan for this" but "you are already carrying this risk, here is what it costs to keep carrying it."

End-of-life stays separate from warranty because they fail differently. An out-of-warranty machine is a financial exposure. An end-of-life machine is a security exposure, and it does not become safe again by being reliable.

Make the alerts arrive, and make them stop repeating

A lifecycle dashboard nobody opens is a report nobody reads with extra steps. The dates have to come to you — a scheduled scan that raises an alert as each device enters the look-ahead window, escalating once the date is actually past.

The critical design detail is deduplication. An alert raised per device per dimension, deduped, means re-scanning does not pile up. Without that, a daily scan produces a daily copy of every alert, the alert list becomes noise within a week, and the feature has actively made things worse than the spreadsheet it replaced.

What this is in Nexus

The inventory module carries a lifecycle layer over the device records: a dashboard bucketing non-retired devices by warranty status with an end-of-life list alongside, tracked and untracked counts, total inventory value, an acquisition histogram by purchase year, and a refresh plan that projects replacement budget forward by year. A scan runs daily per tenant and raises deduped alerts as warranty and end-of-life dates approach and again once they pass. It computes entirely from fields the device record already holds — no separate lifecycle database to keep in sync with the inventory it describes.