MSP hardware lifecycle roadmap: decide what to replace and when
An MSP hardware lifecycle roadmap should tell the client what needs replacing, why, when to decide, and what the whole change will cost.
"The firewall is old" leaves the account manager with a difficult sales conversation. "The vendor no longer supports this model, both offices depend on it, and we need approval before the planned cutover" gives the client a decision.
For a vCIO running client reviews from Connectwise Manage, start with the assets that can change a budget or a service commitment. Reconcile the RMM record, the purchase record, and the vendor's support information. Then bring the recommendation to the person who can fund it.
Use the register and decision rules below before building the replacement quote. A birthday alone is a poor procurement policy.
Separate age, warranty, support, and suitability
Four facts often get compressed into one red status. Keep them separate.
| Fact | Evidence to collect | What it changes |
|---|---|---|
| Age | Purchase and deployment records, with unknown dates identified | Your refresh planning assumption |
| Warranty or service coverage | Exact asset entitlement, coverage end, response terms, and exclusions | Available repair or replacement support under that coverage |
| Vendor support | Model and software version matched to the vendor's lifecycle notice | The supported maintenance path and relevant deadlines |
| Suitability | Required workload, application compatibility, capacity, and client standards | Whether keeping the asset meets the client's actual need |
A warranty ending does not establish that security updates end on the same date. An active warranty does not prove that the operating system or application remains supported. End of sale, end of software maintenance, and end of support may also be different milestones. Record the vendor's exact term and consequence.
Endpoint compatibility deserves its own check. Microsoft's Windows 11 requirements include a compatible processor, UEFI with Secure Boot capability, and TPM 2.0. Device age or remaining warranty cannot establish those facts. Have the technical validator confirm eligibility and the client's application requirements before recommending retention or replacement.
NIST's Cybersecurity Framework 2.0 separates hardware inventory, asset prioritization, and lifecycle management in ID.AM-01, ID.AM-05, and ID.AM-08. It does not prescribe a universal replacement birthday for your client's equipment. Your recommendation still needs the asset's condition, support facts, and business consequence.
Copy this asset-to-decision register
Keep one row per asset or genuinely equivalent group. A group should share the same support position, business dependency, proposed action, and decision owner. Split the row when those facts differ.
| Field | What the account manager needs |
|---|---|
| Client, site, and asset reference | A record the technical team can reconcile to the actual equipment |
| Business dependency | The service, site, or user group affected by failure or change |
| Technical validator | The person confirming the condition and proposed replacement path |
| Purchase and deployment dates | Known dates, their sources, and any uncertainty |
| Warranty or coverage | Entitlement, end date, response terms, and source |
| Vendor support milestone | Exact model/version, lifecycle term, date, consequence, and source |
| Condition and suitability | Relevant incidents, capacity, compatibility, and standard-stack exceptions |
| Recommended action | Replace, extend coverage, investigate, or retain |
| Decision needed by | The approval date that still leaves time to deliver the change |
| Target change window | The proposed service interruption and client availability |
| Budget components | Equipment, support, licensing, labor, dependencies, and retirement work |
| Client approver and status | Who can authorize the spend; pending, approved, declined, or completed |
| Next action and evidence | Named owner, due date, scope or quote reference, and completion record |
Copy this header into your working sheet:
client,site,asset_reference,business_dependency,technical_validator,purchase_date,deployment_date,coverage_terms,coverage_end,coverage_source,vendor_support_milestone,support_date,support_consequence,support_source,condition_and_suitability,recommended_action,client_decision_due,target_change_window,budget_components,client_approver,decision_status,next_action,action_owner,action_due,scope_or_quote,completion_evidence
Unknown support status belongs in investigate, with an owner and a date. Do not silently convert an empty field into either "supported" or "replace immediately."
The MSP renewal calendar handles notice deadlines and vendor actions. Link its relevant row rather than maintaining a conflicting second set of dates here.
Choose the action before choosing the replacement
Use these decision rules as a review aid. They are proposed operating rules, not a vendor policy or a substitute for technical judgment.
| Action | When it fits | Evidence required before the client decision |
|---|---|---|
| Replace | The asset cannot meet a required workload, support position, or agreed standard, and the replacement path addresses that gap | Verified gap, business consequence, viable scope, budget, and delivery window |
| Extend coverage | The asset remains suitable and the available coverage addresses the identified repair/support exposure | Actual coverage offer and terms, remaining support path, and comparison with replacement |
| Investigate | Missing or conflicting facts prevent a defensible recommendation | Named fact-finding task, owner, deadline, and any necessary interim controls |
| Retain | The asset still meets the need and its support and recovery position are acceptable | Recorded rationale, review date, and triggers that would reopen the decision |
An expired warranty on a suitable device with an acceptable recovery plan can lead to a different recommendation from unsupported edge equipment carrying the client's internet connection. Avoid a rule that gives both the same red label and calls the prioritization finished.
If the client chooses to defer a replacement, record the consequence, any agreed interim measures, the approver, and the review trigger. A deferral does not extend vendor support or create spare equipment. Silence does not authorize the change.
Work backward from a useful change window
A target quarter needs an approval date inside it or before it. Start with the latest workable change window, then allow time for discovery, client approval, procurement, staging, and validation.
Here is an illustrative planning scenario. These durations are assumptions, not delivery promises or market benchmarks.
A client wants a network refresh completed by March 31, 2027. The MSP allows 21 calendar days for procurement, 14 for staging and change preparation, and seven for the client's approval process. Assume these stages run sequentially, with no overlap. The options need to reach the approver by February 17. Discovery must finish before then.
If a supplier confirms a longer lead time, an application owner cannot attend, or the client has a change freeze, move the decision earlier or change the plan. A quarterly label cannot negotiate with a delivery date.
Use the MSP IT budget template to place the selected work into the client's overall spending plan. Keep the lifecycle row focused on why this asset needs a decision and which facts support it.
Budget the change around the box
A lifecycle allowance based only on hardware price leaves the project team to explain the rest later. Build the allowance from the work the client will actually need.
The following is hypothetical client pricing for one network refresh. It is scenario math, not a Scopable price, supplier quote, customer result, or recommended rate.
| Illustrative budget component | Client allowance |
|---|---|
| Replacement equipment | $3,600 |
| Support or subscription coverage | $600 |
| Discovery and configuration review | $500 |
| Staging and change preparation | $700 |
| Cutover work | $900 |
| Validation and documentation | $300 |
| Retirement and disposal work | $200 |
| Total allowance before applicable tax | $6,800 |
The allowance assumes those are the required components. Record exclusions, any recurring charges and their terms, and the commercial validity of the eventual quote. Add cabling, site access, shipping, spares, travel, or application remediation when the actual scope requires them. Do not hide undefined work inside an unexplained labor number.
Before converting the allowance into a fixed offer, the technical validator should confirm:
- Current configuration, dependencies, access, and a usable configuration backup.
- Compatibility with the intended network or application design.
- The cutover window, client contacts, and expected interruption.
- Rollback criteria, rollback method, and available equipment.
- Acceptance checks, documentation, support ownership, and the retirement path.
The hardware markup and margin worksheet handles landed cost and selling-price arithmetic. This roadmap establishes what must be priced. Procurement should still verify supplier availability and terms before an order is placed.
Bring one recommendation to the client review
The client should be able to approve a next step without translating an asset export. Use a short decision note:
Asset or group: [exact reference and site]
Business dependency: [what relies on it]
Verified lifecycle fact: [coverage, support, condition, or compatibility]
Consequence: [what retaining the current setup means]
Recommendation: [replace, extend coverage, investigate, or retain]
Alternative and tradeoff: [viable option and its consequence]
Budget basis: [included components, recurring terms, and exclusions]
Decision needed by: [date and reason]
Client approver: [name and role]
Next authorized action: [discovery, quote, purchase, or scheduled change]
Owner and completion evidence: [person and required record]
A useful talk track is plain: "This device supports [service]. We confirmed [specific fact]. We recommend [action], with an allowance covering [work]. To use the planned change window, we need [decision] by [date]. The alternative is [option and consequence]."
Keep approval boundaries explicit. Approval to investigate is not approval to purchase. A funded roadmap item still needs the applicable quote and change authorization. Close the lifecycle row after the agreed work and acceptance evidence are recorded, then update the asset and support records.
Carry the decision into the QBR workflow
Use the lifecycle register as evidence for the review, with the source records attached to the client context. Scopable's vCIO and QBR workflow supports client-linked reviews, reusable templates, and reviewed assessment, opportunity, agreement, and roadmap context. The account manager still verifies the hardware facts and owns the recommendation.
Start with the equipment behind the next meaningful client decision. A smaller register with reconciled facts is easier to defend than a complete-looking export nobody can explain.
Start Scopable for free to evaluate the client-review workflow with one real hardware replacement decision.
