/refresh-cycle-planning

name: "Refresh Cycle Planning"
description: >
  Forward-looking hardware refresh planning: combining warranty expiration,
  EOL/EOS timing, and device age from whatever RMM and documentation platforms
  are connected into replace-now / plan-this-year / monitor tiers, laying those
  tiers onto a dated calendar, surfacing replacement clusters, and keeping an
  explicit insufficient-data bucket. Planning only — not quoting or procurement.
when_to_use: >-
  When building a forward-looking hardware refresh calendar or deciding
  which devices need replacing this year versus later. Use when: refresh
  planning, hardware refresh calendar, what needs replacing, capital
  planning for hardware, replacement schedule, budget for new hardware,
  which devices to replace next.

Refresh Cycle Planning

Overview

Most MSPs discover a hardware refresh need reactively: a device fails, or a client gets stuck on an OS that just hit end-of-support with no migration path, and the replacement conversation happens under time pressure with no budget lead time. This skill exists to move that conversation earlier — by combining three signals that are each individually useful but collectively much stronger — into a forward-looking calendar the account team can use in a quarterly business review or a capital-planning conversation, well before any of the underlying risk becomes urgent.

The three input signals, each covered by a sibling skill:

1. **Warranty expiration** (`warranty-tracking`) — when hardware coverage lapses. 2. **EOL/EOS timing** (`eol-eos-flagging`) — when the OS or hardware itself stops being supported. 3. **Device age** — how long the device has been in service, pulled from RMM first-seen/enrollment date or purchase date where available.

No single signal is sufficient on its own. A device can be young with an expired warranty (a warranty that was never worth much to begin with on a low-end model), old but still fully supported and under an extended warranty, or mid-life but running an OS that's about to lose support regardless of hardware condition. This skill's job is to weigh all three together into one defensible tier per device, not to rank on whichever signal happens to be loudest.

This is not a procurement or quoting skill — it produces a planning calendar and tiered priority list, not a purchase order. Handing the output to a quoting/sales workflow (e.g. `sales-pack`) or a PSA opportunity is a separate, deliberate next step, not something this skill does automatically.

Anti-triggers

• **ScalePad Lifecycle Manager roadmaps** — LM has its own initiatives,

goals, QBR meetings, and budget forecasting; use `scalepad-lifecycle-manager` rather than rebuilding its calendar here.

• **Drafting a per-client refresh quote list:** use

[Refresh Quote List](../refresh-quote-list/SKILL.md). This skill stops at the calendar.

• **Building or publishing a quote:** build it with `scalepad-quoter`

(which can also publish) or `connectwise-cpq-quotes`; a CPQ quote is published from the CPQ web app. Kaseya Quote Manager's tools are read-only, so a Kaseya quote is built in the Quote Manager web app. This skill produces a tiered calendar and device counts, never a dollar figure.

Discovering available tools first

Never assume which RMM or documentation platform is connected:

1. Call `conduit__search_tools` to discover connected RMM(s) (for device inventory, age, and warranty/lifecycle fields) and documentation platforms (IT Glue, Hudu — for warranty fallback data and, where tracked, purchase-date/asset records). 2. Cover all connected RMMs if more than one is present. 3. Only call concrete tools that discovery actually returned.

Key Concepts

Combining the three signals into a tier

Bucket every device into exactly one of three tiers. State the reasoning per device — a tier assignment without a visible rationale isn't actionable for whoever has to defend the capital ask.

| Tier | Criteria (any one is sufficient to qualify; more than one raises confidence) | What it means | |---|---|---| | **Replace now** | Warranty already expired on a high-criticality device, OR OS/hardware already past EOS, OR device age is well beyond the org's typical refresh cycle (commonly 4-5 years for desktops/laptops, longer for servers — use the org's own documented policy if known, otherwise state the assumption) with an additional risk signal present | Active risk today — should move to procurement discussion this cycle, not wait for the next planning window | | **Plan this year** | Warranty expiring within the next 6-12 months, OR OS/hardware approaching EOS within the next 6-12 months, OR device age approaching the typical refresh threshold without an immediate second risk signal | Not urgent today, but should be budgeted and scheduled within the current planning year so it doesn't slide into "replace now" under time pressure | | **Monitor** | None of the above thresholds met — warranty and EOL/EOS both comfortably out, device age within normal range | No action needed; keep it in the sweep for the next planning cycle |

Devices with insufficient data on all three signals (no warranty data, no resolvable EOL/EOS status, no age data) go into an explicit **insufficient data** bucket — never default an unknown device into "monitor," since that silently hides a coverage gap as if it were a clean bill of health.

Building the calendar

Once devices are tiered, lay them out on a forward timeline rather than just three flat lists:

1. For **replace now** devices, no date is needed — they're already actionable. 2. For **plan this year** devices, attach the specific driving date (the warranty expiration date or EOL/EOS date that put them in this tier) so the calendar shows *when* in the year the pressure actually lands, not just that it lands sometime this year. 3. Group by month or quarter where enough devices share a similar window — this is what makes t