Technology lifecycle management
Know what loses vendor support, and when.
Lifecycle Copilot takes your CMDB export and last period's lifecycle sheet, and gives back a finished report. Every asset gets its EOL and EOS dates and a Manage, Renew or Retire call, with the reason written next to it.
● Pilot with one ITAM team · first tower: EUC Windows
| Asset | OS | OS EOS | Decision | Basis |
|---|---|---|---|---|
| WKS-04417 | Windows 11 23H2 Enterprise | 10-Nov-202617 days | Renew | Microsoft servicing date for 23H2, Enterprise edition. Matched on serial. |
| WKS-11902 | Windows 11 23H2 Pro | 11-Nov-2025past EOS | Retire | Pro edition ended a year before Enterprise. OS changed since last period, so the date was recomputed. |
| MAC-2208 | macOS 15 Sequoia | 30-Sep-2027341 days | Manage | Carried forward from prior sheet. Hostname unchanged, same serial. |
| WKS-07731 | Windows 11 24H2 Enterprise | —needs review | Review | Duplicate serial with conflicting values. Both rows kept and sent to review. |
The problem
The CMDB knows what you own. It doesn't know when any of it stops being supported.
The lifecycle dates live on Microsoft, Apple and Cisco support pages, per version and per edition. So the report gets built by hand, one tower at a time.
to refresh one tower by hand. It's out of date the week after it ships.
towers have never been done, because there was never time.
can run the whole process. When they're out, there's no report.
How it works
Six steps, the same way every time.
This is the method that already works by hand, turned into software. Matching stays deterministic. AI only helps where the answer is written in prose on a vendor page.
- 1
Ingest and check
Read the export, map the columns, and reject anything that looks like a copy of last period's file.
Rules - 2
Match
Serial first. Hostname only when it's unique in both files and the serials don't conflict.
Rules - 3
Carry forward
Matched assets keep their dates and decisions. If the OS changed, the OS dates are recomputed.
Rules - 4
Fill the gaps
Policy table, then same-model peers, then vendor rules, then cited research on vendor pages.
AI with citations - 5
Decide
Manage, Renew or Retire, with the rationale written out. A human override always sticks.
AI suggests, you approve - 6
Export
A six-sheet workbook that looks like the one your team already uses, with real Excel dates.
Rules
Rules it won't break
A wrong match quietly corrupts history. These rules stop that.
I1No fuzzy matching
Same hostname with a different serial means the hardware was replaced. That's not a match.
I2Fill blanks only
It never overwrites a value from the source or from a person.
I3Every value has a basis
Each derived date says where it came from, in the Remarks column.
I4Keep every row
Duplicates included. It's a reconciliation, not a cleanup.
I5Show the exceptions
Dropped assets and data quality issues ship as their own tabs.
I6Don't trust inbound columns
A real export once had a column copied row for row from the old file. Now that gets checked.
What you get
One workbook, six sheets.
Report
Every source row, in your existing column layout.
Summary
Totals: matched, new, dropped, blanks, duplicates.
Matching Logic
The rules used in this run, and any caveats.
Match Detail
For each asset: how it matched and what changed.
Dropped
Assets from last period that are gone now, with the reason.
Data Quality
Duplicate serials, reused hostnames, conflicts and anything odd.
Scope
Version 1 does one tower properly.
In v1
- EUC Windows tower
- Upload the current export and the prior sheet
- Deterministic matching, fully tested
- Policy lookup, peer inference and vendor rules
- Cited research for versions it can't resolve
- Decisions with rationale, plus review and audit history
- Six-sheet export
Not yet
- Live ServiceNow API
- Writing back to the CMDB
- More than one tower
- SSO and multiple tenants
- Dashboards and ticketing
- Acting on a Retire without a person
One tower, upload to workbook. Must match the known-good refresh.
Confidence shown, clickable citations, override screen.
All towers through a config registry.
Scheduled ServiceNow pull and a vendor EOL feed.
How we'll know
Tested against a refresh we already finished by hand.
The September 2026 EUC Windows refresh is the frozen test set. The right answer is already known, so the tool either gets the same result or it doesn't.
| Measure | Today | v1 target |
|---|---|---|
| Hours to refresh one tower | ~16 h | under 1 h |
| Match reproduction on the test set | by hand | 100% |
| Vendor dates without a citation | untracked | 0 |
| People who can run a refresh | 1 | 3 or more |
| Towers never done | 3 of 9 | 0 by v1.2 |
For agents
Machine-readable spec
If you're an agent building or reviewing Lifecycle Copilot, start here. The same data sits in the page as application/json under the id product-spec, and as schema.org JSON-LD in the head.