Alistair.PEditor
Replacing a member of staff's laptop sounds simple until someone discovers a locally stored project folder, a licence tied to the old computer or an authentication method that cannot be transferred as expected. A reliable device refresh is not just the moment new hardware is handed over. It is an operational transition that preserves authorised work, protects data and makes the old device safe to retire. Small IT teams need a practical workflow that identifies what the user actually needs, records dependencies, moves information through approved channels and verifies that the employee can resume normal tasks. The objective is continuity and security, not merely a successful operating-system login.
Confirm the purpose and scope of the replacement
Ask why the device is being refreshed. It may be at the end of its support life, failing repeatedly, unsuitable for an employee's software or subject to a normal replacement programme. Each reason affects urgency, budget, migration and acceptance. A new laptop that is faster on paper may still fail to run a specialist application or connect to an approved peripheral. Record the intended user, role, location, major applications and exceptional hardware requirements before choosing the replacement model.
Do not infer compatibility from a familiar product name. Staff in finance, design, field engineering or customer support may use very different software. Confirm operating-system support, device management requirements, encryption, network connectivity and any accessories that must continue to work. Ask whether a monitor, dock, printer, barcode scanner or smart card reader is required. A device refresh should be planned around the work that must continue after the swap, not only the processor or amount of memory in the specification.
Build an accurate pre-refresh inventory
Capture the old asset identifier, serial number, current custodian and management status in the authorised asset system. Confirm the user's assigned applications and known local data. A device management console may show installed software but still miss portable applications, local virtual machines, saved browser profiles or specialised plug-ins. Conversely, not every discovered application is required on the new machine. Review what is legitimate, supported and actually needed, avoiding a blind copy of outdated software.
Record any evidence that the old device has an existing fault or suspected security issue. A compromised endpoint should not be migrated as though it were merely slow. Follow the organisation's incident and recovery process for such exceptions, with approved decisions about data handling. A normal refresh register should make uncertainty visible instead of copying unverified assumptions into the new asset's record.
Determine where important information lives
Many organisations use cloud document storage, network shares and centrally managed email. That can simplify migration, but it does not prove every important file has already synchronised. Check relevant known folders, offline caches, approved local project data and application-specific storage. Ask whether there are unfinished documents or data needed for travel without connectivity. The user and business data owner should identify material that needs preserving, while IT verifies the approved method of transfer.
Avoid collecting more personal data than required. Work devices may contain material that belongs to the organisation alongside private or sensitive information, and handling should follow applicable employment, privacy and security policy. Do not copy entire profile directories to an unencrypted personal USB drive just because it seems convenient. Use approved transfer and backup services, and record whether a backup or synchronisation operation completed successfully. A progress indicator does not necessarily prove that each file opens correctly on the new machine.
Prepare identity, sign-in and recovery arrangements
Modern devices often depend on cloud identities, multifactor authentication, device registration and conditional access rules. Confirm that the new laptop can be enrolled through the approved management process and that the user's current account remains authorised. Some authentication methods are bound to hardware or require a controlled re-registration. Plan these steps before removing the old device, especially for users who depend on a single authenticator or hardware token.
Never ask a user to disclose their password or one-time code as part of the handover. The technician should follow supported provisioning and recovery procedures with appropriate authorisation. Verify that expected policies, encryption and security tools apply after enrolment, rather than assuming any successful sign-in means the device is compliant. The NCSC's identity and access guidance is helpful for the underlying principles, but the precise implementation must follow the organisation's current identity platform and approved configuration.
Install and license the necessary applications
Identify approved applications, versions, licence entitlements and configuration requirements. Some subscriptions are associated with a person and can be used on another eligible device, while other licences require deactivation, reassignment or vendor intervention. Do not treat the presence of an installer as proof of licence entitlement. Record software that cannot be transferred and who will resolve it before the user relies on the new machine.
Where settings or templates are important, confirm whether they are centrally managed or need a controlled migration. A specialist spreadsheet add-in, accounting profile or VPN configuration may determine whether the employee can actually work. Avoid importing obsolete security settings simply to make the new device look identical to the old one. Use the approved current configuration and test the application's genuine workflow with the user or business owner.
Test the new workstation using real work
Basic IT checks should include boot, management registration, encryption status, required network connectivity and access to supported resources. But acceptance also needs business-level evidence. Have the user open an ordinary document, send an approved test message, access the primary line-of-business application and use the required peripherals. If the employee works remotely, test an appropriate remote scenario rather than assuming that success on the office network proves success elsewhere.
Choose representative tests without exposing private customer information. For a finance user, it might mean opening an authorised sample report and confirming the correct application features. For a field employee, it might mean checking the VPN or secure access path on an approved network. Note what was actually tested and what remained unavailable. If an important vendor service cannot be tested immediately, keep the exception open with an owner rather than describing the refresh as fully successful.
Handle user preferences without reproducing bad configuration
Keyboard layout, accessibility settings, display scaling, browser bookmarks and approved application preferences can make a replacement device much easier to adopt. Ask which settings matter to the user's workflow and restore them through supported mechanisms. Do not assume every personalisation must be copied. Some old settings are obsolete, while others may conflict with current security policy or create unwanted privacy exposure.
Give the employee an understandable way to find files and reach support after the swap. Explain any visible differences, such as a new sign-in process, relocated application or changed print queue. A short orientation can prevent many avoidable tickets. In environments with accessibility requirements, involve the user in confirming that assistive software, keyboard controls and display settings actually work rather than treating a successful boot as sufficient.
Keep the old device controlled during the transition
Some organisations allow a brief overlap so the user can verify that work continues. Define the duration, custodian, network status and permitted uses. An old machine left active indefinitely can become an unmanaged security risk or a source of conflicting documents. If it remains temporarily available for recovery, keep it within the organisation's approved inventory and access controls. Do not let users take an unprocessed old device home simply because the new one appears to work.
Where a secure copy is retained for recovery, establish who can access it and when it should be removed. Avoid duplicating sensitive data across several temporary drives or personal accounts. Document any outstanding migration task that prevents decommissioning. The old asset should not vanish from the register while it still contains organisational information or requires an action from an external disposal supplier.
Choose an appropriate retirement and data-sanitisation route
After successful handover, follow the approved process for reallocation, repair, return, recycling or destruction. Data removal must match the storage technology, sensitivity and organisation's policy. Simply deleting files or resetting a device in an informal way may not meet the required assurance. The NCSC provides device security guidance and other security resources; organisations should use approved sanitisation methods and qualified services where required.
Record evidence of decommissioning, including the asset's new status, collection or disposal reference and responsible party. A certificate of destruction or verified sanitisation record may be necessary in some circumstances. Do not publish a blanket claim that all device resets securely erase every kind of storage. The method depends on the hardware and agreed security requirement, and any exception needs formal ownership.
Coordinate licensing and asset records after the swap
Update the asset register so the old and new devices have distinct identifiers, custodians and lifecycle states. Confirm that management platforms and security monitoring no longer show misleading duplicate entries. Remove obsolete device associations only through the authorised identity and management process; a careless removal could disrupt access to retained data or break legitimate recovery arrangements.
Review the software licence register to avoid paying for unused entitlements where reclaiming them is authorised. The replacement may also have warranty, leasing or supplier-return obligations. Capture the new support contact and warranty period in the approved system. These details matter after the initial excitement of the new laptop has faded, especially when the service desk needs to arrange a repair later.
Prepare exceptions and user communications
Explain the planned appointment, expected user participation, what data is being transferred and any period during which the user might not be able to work. Avoid promising a fixed duration without understanding the device, data size and application dependencies. Where a migration is incomplete, give the employee a clear workaround or next contact if it is safe to do so. A replacement should not be considered accepted merely because the user is no longer standing beside the technician.
Record unresolved applications, missing files, non-working peripherals and vendor dependencies with owners and next steps. Some defects may be minor, while others prevent normal work and require the refresh to remain open. Set acceptance based on essential tasks and risk, not a cosmetic checklist. If a critical application fails, escalate the issue through the support process and keep the old device or an authorised alternative available only where that is safe and permitted.
Use a final sign-off that means something
The user should confirm that core work can continue, and IT should verify device-management and security requirements. The business owner may need to approve exceptional risks. Record the old and new asset identifiers, key tests, data-migration outcome and retirement disposition. Make any conditional acceptance clear. This creates a record the next technician can use if a problem appears weeks later.
Across a refresh programme, review repeated blockers. If every new laptop requires manual recovery of a critical folder, improve data-storage policy or onboarding documentation. If dock compatibility is unpredictable, review the standard hardware selection. If sign-in repeatedly stalls, improve the approved provisioning sequence. A good refresh process becomes easier and safer with each cycle because the team learns from actual operational outcomes.
Source A: NCSC device security guidance for device-management principles. Source B: NCSC identity and access management guidance for controlled enrolment and permissions. Their general recommendations do not certify any particular device, disposal contractor or organisational procedure.