Replacing a client's computer is a controlled change to a person's working environment, not a simple purchase. A managed service provider (MSP) may receive a request for a faster laptop, a replacement for damaged equipment, or a different device after an employee changes roles. The right response depends on the fault, business task, procurement authority, data and application dependencies, and the intended fate of the existing machine. A new laptop that reaches the client's office but cannot access the finance application has not delivered the requested outcome.
Before recommending new equipment, the service desk should identify the authorised requester, the actual problem, the present asset and what the employee must be able to do afterwards. Replacement, repair and temporary loan are different decisions. They have different costs, operational risks and handover responsibilities. This guide describes a practical evidence-led request process for a small MSP, with particular attention to managed Windows devices. It does not assume every client uses Microsoft Intune or Windows Autopilot; those products are examples whose functions must be checked against the client's real environment.
Confirm the reason for the replacement request
Start with the customer's own description: which task is failing, what symptom appears, when it began and who is affected. A laptop described as slow may have inadequate memory for an approved application, a failing storage device, an unsupported operating system, a configuration fault, or ordinary performance expectations that need clarification. A device with damaged power components may require safety assessment rather than an attempt to reproduce the failure at the helpdesk counter. Do not label an issue 'hardware end of life' simply because a customer wants a newer model.
Record the current asset tag, serial number, assigned user, management platform and any linked incident or warranty case. Verify the available evidence: device health, supported operating system, warranty position and relevant technical diagnostics. Where appropriate, consider a supported repair or reconfiguration as a separate option. The technical team should explain the likely effect on the user's work and the uncertainty in its diagnosis rather than asserting a guaranteed repair outcome. If the equipment is unsafe, stop the normal diagnostic path and use the organisation's approved competent safety procedure.
Separate a client-led refresh programme from an emergency break-fix request. A planned refresh may involve standardised specifications and staggered replacement dates; a failed laptop may require an urgent loaner and a temporary access route. Using one generic service request status for both makes business priorities and supplier dependencies difficult to understand.
Establish commercial authority and the actual specification
Identify who may approve a purchase, specification exception, delivery cost or change to the client's device standard. An employee's preference is relevant but is not necessarily procurement authority. Where the MSP recommends a model, document the reason in terms of workloads, supportability, intended lifespan and required peripherals. Avoid brand-led claims that are unsupported by the client's software requirements. Compare relevant application specifications and the organisation's approved endpoint management baseline before sourcing equipment.
Ask which programmes, identity systems, VPN connections, browser extensions, certificates and specialist peripherals must work. A standard browser-based role may differ substantially from a CAD, finance or media-production role. Check accessibility and remote-working requirements through the client's authorised process without collecting unrelated personal information. If the role's needs remain unclear, refer the technical specification for approval instead of purchasing the nearest available model to meet a scheduling target.
Confirm whether the client provides the equipment, owns the supplier account or has authorised the MSP to procure it. Record a quotation or supplier offer as such, not as an ordered or delivered asset. Model availability and estimated despatch dates can change; distinguish an estimate from a confirmed shipment. If the current device cannot support essential work, identify an approved spare or loaner as an interim service, with its own custody and return record.
Prepare identity, management and licensing before handover
New equipment needs to join the correct management and identity environment under the client's policy. Record the device's stable identity and intended custodian. For a Microsoft-managed fleet, Windows Autopilot is one option for preparing new or existing devices, but registration, assigned profiles, enrolment and policy application are not the same event. Microsoft's Autopilot registration guidance distinguishes hardware identity registration from a device appearing in Intune after user sign-in. The receiving technician should verify the actual tenant, required applications and policy state rather than assuming a successful registration means the user can work.
Confirm full-disk encryption, endpoint protection, supported updates, access control and approved authentication where these are required by the client's baseline. Avoid copying local administrator passwords, recovery keys or another employee's user profile into general setup notes. Use named accounts and approved credential methods. A preconfigured machine may still need specialist application licensing or supplier approval. Identify those dependencies in advance and leave unresolved access cases assigned to the proper owner.
Test a representative business task under an authorised identity or safe test account. Merely reaching a desktop proves very little. Check the relevant shared resources, software activation and required peripherals, then record any tests that could not be completed before the employee receives the machine.
Plan data migration without creating a second source of truth
Determine where the employee's working data is authoritative. Some files may already be held in managed cloud or network services, whilst specialist application data or configuration may remain on the local disk. Verify the required folders, application settings, browser profiles and approved synchronisation services against the client's data-handling policy. A successful copy command does not prove that a financial database opens correctly or that the user can access the records through their new account.
Before destructive operations, establish what must be retained, who owns it and whether a tested recovery option exists. A green backup indicator is not a guarantee that every unsynchronised local file is protected. Avoid using personal USB devices or uncontrolled consumer cloud services to move client information. If the existing machine is damaged and the storage cannot be accessed safely, involve the appropriate specialist and explain the limitations; do not promise full data recovery simply because the replacement hardware is available.
Where a transfer occurs, validate with the employee or authorised business owner. Choose meaningful examples, such as a current project file, the relevant finance application record and an approved shared folder. Keep a short record of what was transferred and what remains pending, without reproducing the client's confidential contents in the ticket.
Choose repair or redeployment only when the evidence supports it
A repair or reusable spare may be sensible when the fault is bounded, the device remains supported and the client authorises the work. It still requires an evaluation of downtime, warranty constraints, data protection and future support risk. A new purchase may be preferable when the present hardware cannot meet approved workloads or supported software and the cost of repairing it is disproportionate. The MSP should present these as conditional trade-offs based on actual facts rather than claim an unsupported universal winner.
If an existing device is being redeployed, ensure that previous account access and data are processed under a secure procedure. The UK NCSC's device-erasure guidance explains why simply deleting files is not generally equivalent to a secure reset, and notes that built-in restore or factory-reset actions erase content and require backup preparation. Device sanitisation is a separate decision from issuing a new computer. The same guidance warns that erasure methods have limits, so select the method according to the organisation's policy and risk.
Do not wipe the old machine merely because a replacement has been ordered. It may still be the only viable recovery source or approved short-term fallback. Plan the point at which migration is verified, retention decisions are made and the previous asset can be retired, returned or redeployed. Record which person can authorise each irreversible action.
Make cutover and user acceptance measurable
Agree a realistic handover window and support route. Confirm whether the employee will receive the replacement on site, by secure delivery or through a scheduled remote setup. A courier's delivery scan does not prove the employee has signed in and completed essential work. Where the user must complete multifactor authentication or self-service enrolment, provide approved instructions and an alternative way to contact support if authentication fails.
During acceptance, use the actual role as the standard. Ask the user to open key applications, access relevant business data, communicate through the expected tools and test a necessary peripheral. Record outcomes and remaining limitations in plain language. An application not yet licensed or a printer not yet available should not disappear when the central device ticket is marked delivered. Agree whether such exceptions are low-impact follow-up work or block the replacement from being accepted.
Verify that the replacement can be found through current support systems and linked to the correct user and client. Troubleshooting based on a previous hostname or obsolete asset record can waste time during a later incident. Keep the new model, serial, management identity and warranty reference in the approved location rather than scattered emails.
Close the previous asset lifecycle and learn from the request
The old machine still has a physical custodian and potentially important information. Decide whether it remains as an approved temporary fallback, is repaired for reuse, is returned to a supplier or proceeds to disposal. Verify actual custody and any accessories. A collection booking is not receipt; a disposal request is not evidence of completed sanitisation. Retain transfer and erasure evidence appropriate to the client's policy. Do not transfer client-owned equipment to a different customer simply because an MSP storeroom has available space.
Close the request with a clear business-level result: the authorised user can perform the agreed core tasks, the asset records are accurate, any remaining software or supplier work has an owner, and the previous equipment has a known next action. If a supplier date slips or a specialist application fails, update the client with verified facts rather than a made-up completion promise.
Review repeated replacement requests for patterns: unsupported devices, inaccurate specifications, poor enrolment, missing data checks or unclear purchase approval. A good MSP replacement workflow balances cost, continuity, information protection and supportability. The useful final test is not whether a new box arrived; it is whether the employee can work securely and the business can explain what happened to both devices.
Verified original references: Microsoft Learn, Windows Autopilot registration overview (product-specific registration versus enrolment distinctions, accessed 29 October 2026); UK National Cyber Security Centre, Erasing devices (UK organisational device reuse, backup and erasure precautions, accessed 29 October 2026). The applicable MSP contract and client environment determine the actual procurement and custody procedures.
Repair or redeploy the present device, or provision a new one?
Both options can support an authorised replacement request, but they have different preparation and evidence needs. Use the client's approved requirements, actual device condition and operating environment to choose.
| Decision point | Repair or redeploy existing device | Provision new managed device |
|---|---|---|
| Suitability | Confirm repaired hardware still meets approved role and supported OS. | Select a model against current role, peripheral and software needs. |
| Identity preparation | Remove prior user's access and prepare an authorised fresh assignment. | Register correct device identity and verify actual tenant enrolment. |
| Data control | Review old files, backup and appropriate erasure before reuse. | Migrate only required business information through approved services. |
| Key evidence | Repair result, custody history and verified safe reset where required. | Supplier/asset reference, Autopilot registration and actual working setup. |
| Acceptance | Verify security baseline and business tasks after reuse. | Verify policy, applications and user tasks; delivery alone is insufficient. |
Practical decision: Repair or reuse a supported machine when its actual condition, migration and sanitisation risks are acceptable. Choose a new device when approved business requirements cannot be met reliably by the old one. Neither path is complete until access and user tasks are verified. Side A source: NCSC, Erasing devices, UK device reuse and sanitisation precautions, published 2021, accessed 29 October 2026; does not measure repair cost or remaining hardware life. Side B source: Microsoft, Windows Autopilot registration overview, vendor-specific registration and enrolment process, accessed 29 October 2026; applies to supported Microsoft-managed deployments, not every laptop vendor or business. Table is original operational synthesis, with no invented comparative cost or failure figures.
Frequently asked questions
Should an MSP replace a slow laptop immediately?
No. Establish the affected work, current specification, observed fault, support status and whether an approved repair or configuration change would address the problem. Procurement remains subject to client authorisation.
Does Autopilot registration prove the new computer is ready?
No. Microsoft distinguishes device registration from Intune enrolment. Check the actual tenant, policies, applications, sign-in and representative business tasks before accepting the handover.
Can IT wipe the old computer as soon as the new one arrives?
Not safely without confirming backup, transfer, data retention and authorisation. NCSC guidance stresses preparation before erasure, and the client's policy determines the appropriate method.
What if the preferred replacement model is unavailable?
Confirm a genuine supplier estimate and ask the authorised business owner whether an approved alternative, repair or temporary loaner meets the role. Do not invent a delivery commitment.
When can the replacement request be closed?
When the authorised employee can carry out the agreed essential work, new asset and support records are correct, and the old device plus any outstanding exceptions have clear ownership.