PC Fleet Upgrade Plan Without Downtime — Step-by-Step Scenario

Where downtime really starts during a PC refresh

Downtime rarely happens because of swapping the system unit itself. More often the usual work flow breaks: the user sits at a new PC and a needed app won’t start, folders are empty, the printer doesn’t print, or there’s no access to mail or internal systems. One “quick swap” becomes a chain of support tickets and task delays.

“Without stopping” in practice means something different: each person loses minimal time and returns to work the same day. For an office workstation a reasonable target is 30–90 minutes of active downtime per person (including login, app checks and printing). If it’s longer, the plan usually missed one of the bottlenecks.

Projects most often stumble over:

• Data. Files are not where expected (stored locally, on the Desktop, in old profiles) or some data is protected and won’t transfer.
• Access. Tokens, certificates, 2FA, VPN, domain policies, licenses for rare software.
• Peripherals. Printers with non-standard drivers, scanners, cash registers, card readers, specialized monitors.
• “Special” users. Accounting, HR, medical registries, engineers — each has their own software and rights.
• An inappropriate replacement window. Work is scheduled during peak times when an employee can’t be offline even for 20 minutes.

To avoid turning the refresh into emergency tuning, assign roles in advance. IT handles preparation and on-site support, InfoSec is responsible for access rules and compliance checks, procurement manages delivery timing and completeness, and department heads approve replacement windows and confirm the workstation is actually ready.

Example: in a 12-person team, PCs were replaced in one evening, but in the morning three employees couldn’t print to the network MFP and two had no working digital signature for the portal. Formally the hardware was updated, but the team was idle for half a day. This is almost always prevented if you define in advance what must work at the user’s first login and who confirms it.

Inventory: what to capture besides a list of machines

Inventory should describe not only “how many PCs” but how people actually work. The goal is simple: reveal dependencies in advance — peripherals, specific apps, remote access, and security/support requirements.

First define what you consider the “fleet.” Usually it’s not just desktops and laptops, but monitors (including a second screen), docking stations, keyboards, headsets, printers, MFPs, scanners, card readers, and UPS units. Downtime often comes from small things: a missing cable, a scanner driver, a monitor adapter or a docking port.

Collect a short card for each workstation. Don’t make it too complex, otherwise data will be approximate. Typically enough is:

• model and age, device type (desktop/laptop/all-in-one), serial number;
• OS and login method (local account or domain), key applications;
• specs that most often limit work: disk type and size, RAM, ports, Wi‑Fi;
• warranty/support status and repair history;
• user criticality and permitted replacement window (e.g. accounting at month end).

Then segment the fleet so you don’t plan everything the same way. Usually three groups are enough: standard office seats, specialized (POS, CAD, medical software, workstations with attached equipment) and remote/distributed (branches, home workers). This shows where special preparation is needed and where you can swap in batches.

Finally, define a minimal standard configuration for new PCs by role — not by department but by task: who needs a fast drive, who needs two monitors, who needs compatibility with specific peripherals. For example: a typical office user needs 1–2 monitors and an SSD; an accountant needs compatibility with key software and digital signatures; an engineer or designer needs more RAM and appropriate graphics; an operator/reception needs reliability and minimal manual setup.

A good inventory shows where all-in-ones make sense, where docking stations are required, and where to keep spare devices. In practice manufacturers and integrators like GSE.kz often start with a “workstation map” so the pilot and replacement go without surprises.

Wave-based planning: avoid paralyzing the business

A wave approach prevents a PC refresh from becoming mass downtime. You don’t change the entire fleet at once but in small batches: IT can prepare and support, and the business can cope without losing pace.

Waves can be organized by department (e.g. accounting, then sales, then back-office) or by workstation type. The second option is often more convenient: start with standard office PCs, then stations with peripherals (scanners, printers, digital signatures), and only afterwards the “special” roles with non-standard drivers and software.

How to choose a replacement window

The window depends on what you’ll do that day. The physical swap is best scheduled when there are fewer meetings: early morning or late in the day. Preparation (updates, image tuning, access checks) can often be done in advance and remotely if the computer stays with the user until the swap.

To avoid long coordination threads, set a few rules:

• physical swap and return of the old PC at an agreed time, 20–40 minutes per user;
• data migration and profile setup — in advance or the same day using a single template;
• for critical roles — a spare slot the same day for a follow-up visit.

How many PCs per week can you realistically replace

Team capacity is almost always lower than expected. Speed is influenced not only by “setting up a new computer” but by ticket queues, user calls and logistics. A practical rule: start with a pace your IT can sustain even in a bad week and scale up after the first wave.

Estimate capacity with a simple formula: how many specialists are involved, how many replacements one specialist can do per day without rushing, and how much time is needed for post-install support. For example, if two engineers can comfortably do 4 replacements each per day, then 40 PCs per week is a busy schedule accounting for user requests.

Where on-site visits are required and where remote work is enough

Mark in advance where on-site visits are high risk: branches without local IT, rooms with restricted access, users with multiple devices, and high-security areas. In other cases prepare as much as possible remotely: user accounts, policies, standard apps and a test login to key systems.

This turns the plan into a clear calendar: small waves, fixed windows, and known “hard” points. In Kazakhstan this is especially important when replacements happen across multiple cities and travel and on-site support must be coordinated in advance.

Pilot: a small launch that saves the whole project

A pilot finds problems where they are cheapest — before mass replacement. It’s a short run on a limited, diverse group after which you refine the image, instructions and support. Without a pilot even a good plan breaks on small details: the wrong driver, unexpected peripherals, a rare app installed only in one department.

Usually 10–20 users are enough, but diversity matters most. Include people from different roles: accounting, office staff, those who work with graphics or databases, and users with lots of peripherals. Include 1–2 “complex” setups: multiple monitors, a network printer and if present — a scanner or token.

What to check during the pilot

Checks should be short and repeatable so they scale to a replacement wave. It’s enough to ensure basic things work on the first try:

• login to the domain or corporate account and application of required policies;
• mail, calendar, shared folders and access to file resources;
• VPN and access to internal systems from outside the office;
• printing to 1–2 typical printers (network and local if encountered);
• 1–2 key department applications (for example, accounting software and client-bank).

After handing out pilot PCs give users 2–3 working days for “live” scenarios to surface. Collect feedback in a single place: a short form or a unified chat moderated by IT. Record facts, not emotions: what the user did, what they expected, what happened, how long it took and how often it recurred.

Pilot success is measured in numbers: average time to prepare a workstation, number of support tickets per user, and stability of key tasks (no recurring failures). If 80% of issues repeat, that’s good news — they can be fixed by updating the image, drivers or a short instruction, and the next wave will be calmer.

System image and data migration: a unified approach

A single image reduces chaos: new PCs behave the same and support is easier. This is critical for wave-based replacement when you can’t allow every install to become a mini-project.

What to include in the image

An image is more than Windows. It should cover basic needs for most users and meet security requirements:

• OS with current updates and settings for time, language and network;
• drivers and manufacturer utilities (video, network, audio, chipset);
• core applications: office suite, browser, PDF tools, remote support agents;
• security policies: encryption, password rules, screen lock, antivirus;
• standard settings: department printers, shared network resources, VPN if needed.

Decide separately how to handle rights and installs. Best practice: users don’t have admin rights; IT installs specialized software by request or by a preapproved role list (accounting, CAD, medical systems). In the pilot check which apps truly require admin rights and, if possible, solve it with configuration rather than giving broad privileges.

Data migration without surprises

Users judge migration by whether their familiar items are present in the first hour. Minimum to migrate: user profile, Documents and Desktop folders, browser bookmarks and passwords (if policy allows), mail archives, templates and signatures.

Example: a sales manager might have a local client database file, saved portal passwords and a large archive of emails. If you only migrate Documents, they will spend half a day restoring access and searching correspondence.

To avoid surprises, prepare a list of exceptions and manual cases and validate them in the pilot. Manual attention is usually needed for:

• local databases (1C/Access/specialized apps) and non-standard storage paths;
• rare printers and scanners with separate drivers;
• certificates, tokens, digital signatures and crypto providers;
• mail with large archives or non-standard clients;
• workstations with special rights and shared accounts.

Log these cases as separate work cards: what to migrate, who’s responsible and how much time is needed. Then each new wave follows a repeatable scenario rather than the memory of individual specialists.

Step-by-step scenario for replacing one workstation

When each engineer follows the same scenario the migration time becomes predictable and errors don’t spread across the wave.

Before the visit keep a final list: who the user is, where the workstation sits, needed software, which accesses and which peripherals are connected (printer, scanner, headset, second monitor). This reduces the chance of a late discovery of a special program or rare cable during the swap.

On-site scenario (usually 30–60 minutes)

1. Verify user and device. Check inventory and serial numbers and the kit contents (desktop or all-in-one, power supply, cables, mouse, keyboard).

2. Prepare the new PC in advance. It should already have the system image, updates, drivers and security agents. On site only bind it to the specific employee.

3. Transfer data and connect accounts. Copy work folders and templates, check mail, messengers and access to network resources. If the user has local keys, certificates or tokens, verify they work on the new device.

4. Perform the physical swap and test peripherals. Connect monitors, printers, scanners, headsets and camera. Do quick tests: print a sample page, scan, audio, webcam, access to shared folders.

5. Give a short orientation and record the result. Show where the main folders are, how to log in to corporate services and where to go for help. In the acceptance act note: what works, what was migrated, what remains to be done and rollback steps.

Example: when replacing an accountant’s old PC with a new desktop (e.g. from the L200 line) printing and access to the network folder with databases often break the day. These two items are better checked with the user present, not after they’ve left.

After replacement the old device must not be left “as is.” It should be labeled, packed, have its status recorded (working, for diagnostics, for disposal) and returned to the collection point. This keeps returns under control and prevents equipment from being lost between offices.

Logistics and support: make the replacement calm

Even a good plan can fail on small things: where people pick up new devices, where to return old ones, who is accountable for missing power supplies and why everyone suddenly lost access to the printer. Logistics and support must be as clear as the wave schedule.

Issuance and return point: less chaos, more control

A single route works best: the user comes, receives the new PC, hands in the old one and is checked off by the responsible person. To avoid queues, break issuance into slots (by department and time) and assign two responsible people: one to hand out and one to accept returns and verify completeness.

Labeling should be visible and consistent: a sticker or tag on the system unit, monitor and box. Record serial number, workstation and status: “issued”, “in progress”, “returned”, “for diagnostics”.

Accessories: small items that delay timelines

Most time is lost to “wrong cable” or “where’s my adapter.” The solution is simple: define a standard kit for each workstation type in advance (office, accounting, meeting room, mobile) and prepare a spare box with consumables. Account for headsets, Wi‑Fi adapters, HDMI‑DisplayPort adapters and monitor power supplies.

Before the wave quickly check three things at each desk: power, video cable and network port. That’s faster than troubleshooting on the replacement day.

User memo and support in the first days

A one-page instruction reduces tickets more than any chat. The memo should state: when and where to pick up a PC, what to bring; how to log in (and change the password if needed); where documents are stored and how to check mail and the printer; where to report issues and what to include (desk, name, problem).

For the first 2–3 days after a wave provide reinforced support: a dedicated line, a floor duty person or a mobile team. If contractual support is 24/7, agree in advance on a high-load window and criteria for “critical” tickets. GSE.kz, for example, advertises round-the-clock technical support and a country-wide service network — that’s convenient, but clear escalation rules still save time.

Common mistakes and traps when migrating to new PCs

The main cause of failures is not the hardware but the small things nobody noticed before the replacement day. Projects often fail where there are no clear lists, measurements and rules for non-standard workstations.

Mistakes that most often cause downtime

• No pre-verified list of applications and licenses. On replacement day it suddenly turns out a “critical program” installs only from a separate distribution or must be tied to the old PC.
• Peripherals and rare drivers are ignored. On paper everything is “USB,” but in reality there’s an old MFP, an old signature device, or a non-standard COM port.
• The pilot is done “for show.” No one records the time for preparation, data transfer and ticket closure, and the first wave becomes a real pilot for dozens of people.
• Waves are too large. IT can’t respond to tickets, users wait, managers get nervous and the team puts out fires instead of following the plan.
• No plan for “special” places (accounting, cash desks, medical labs, integrations and peripherals). They need a separate window, testing and sometimes a separate image.

How to prevent problems before the first wave

Make the pilot real: select 5–10 employees from different departments and time everything from handing over the new PC to ready-to-work minutes. Record every issue and solution, even if it seems “single.”

Then finalize two basic documents: a software list (version, license, installation source) and a peripherals list (model, connection type, driver). Note devices that cannot be quickly swapped for an equivalent.

Example: when updating workstations in a clinic the combination “prescription printer + scanner + medical software” often appears. If you check it in only one room and then replace 30 rooms at once, one driver issue will stop the queue. It’s safer to give such places a separate wave and a dedicated responsible person.

If an integrator runs the project, clarify in advance who is responsible for rare drivers and on-site support. With a local manufacturer and integrator like GSE.kz it is usually easier to organize service and quick replacements in regions, but responsibilities should still be assigned with roles and deadlines.

Quick checks: a checklist for start, wave and completion

Checklists aren’t bureaucracy — they catch small errors before they become downtime. The upgrade plan relies on a few short checks that take 10–15 minutes each.

Before project start

Before setting dates and notifying users make sure the basics are covered and each has an owner:

• inventory completed: models, OS, key apps, peripherals and special roles identified;
• roles assigned: who builds the image, who migrates data, who issues and accepts devices, who decides in case of failure;
• standards agreed: OS version, app set, security policies, accounts, encryption and password requirements;
• data rules understood: what is migrated, what is prohibited, where shared folders live, backup procedures;
• support plan ready: contact points, ticketing, response times.

Before a wave, on replacement day and after

2–3 days before a wave check readiness for this specific group. A common mistake is to rely on overall progress and forget about concrete workstations.

• system image approved, pilot closed: fixes applied and recorded as standard;
• user list confirmed by manager: who will be present, who needs data migration, who can work remotely that day;
• spare capacity available on the day: several backup PCs/laptops and a plan for failure cases (OS won’t boot, domain account issues, broken monitor);
• after replacement run quick tests: login, access to network folders, printing to the required printer, key apps, VPN and mail;
• returns are controlled: devices labeled, completeness checked (PSU, cables, peripherals), status and next steps clear.

Example: replacing 20 workstations in accounting and sales in one wave. If printing and VPN are checked only on the first desk, the wave can stall after lunch. If each desk runs a 2-minute check, problems surface immediately and are fixed while the user is present.

If you work with an integrator, agree in advance who will perform these checks on site. Even with 24/7 support and a service network, a short customer-side checklist saves hours.

Sample scenario: upgrading PCs across an organization without downtime

Organization: 120 workstations across three offices. One location has customer reception windows, so desks cannot be disconnected during the day and staff must return to work quickly after a swap.

They agreed on a simple rule: only replace devices in preapproved windows. If something goes wrong the old PC must be back on the desk within 15 minutes.

Schedule by waves so IT and users experience even load and reception remains open:

• pilot: 15 PCs across roles (reception, accounting, HR, managers);
• then 20–25 PCs per week, two fixed windows per office;
• reception hours: early morning or late day only, avoid peak times;
• reserve: 2–3 spare replacement PCs per wave;
• “tails”: a separate day at week’s end for complex cases.

They used a standard system image including OS, drivers, core apps, security settings and mandatory shortcuts so users didn’t have to rebuild their desktops. Data migration followed a short scenario: documents, templates, bookmarks, mail signatures and certificates.

Exceptions were only two specialized apps. For them they mapped: which PCs run them, required versions, USB keys and licenses, and who verifies functionality. These workstations were scheduled at the end of the wave with extra time so the overall pace didn’t slow.

To monitor progress they tracked simple metrics and compared the pilot to each following wave:

• average replacement time per workstation (from shutdown to ready);
• number of support tickets in the first 48 hours;
• repeat visits to the same desk (recurring issues);
• percent of returned old PCs missing components (PSU, cables, labels, inventory tag);
• share of exceptions from the standard image (to avoid a growing device zoo).

After the pilot they made two changes: added a missing printing plugin to the image and pre-signed drivers for two printer models. This reduced support tickets and sped up replacements.

Finally, lock the standard: future purchases should match the chosen configuration, and fleet updates are best done on a cycle (for example, every 3–5 years by office) to avoid a mixed-age fleet. If predictable supply and nationwide service are important, consider locally produced PCs and servers from GSE.kz with unified specs and support for your system image.