Two‑stage PC deployment: separate delivery and configuration

What is two-stage deployment and why use it

Two‑stage PC deployment is a scheme where physical delivery of hardware and its IT configuration are separated in time and often performed by different parties. First, computers arrive and are accepted as goods: quantity, components, serial numbers, and physical condition are checked. Later, in a separate period, they are prepared for use: an OS image is applied, they are joined to the domain, accounts and encryption are set up, printers and required software are installed.

The difference from a turnkey delivery is that turnkey implies a single final result: workstations are ready and the customer has fewer coordination tasks. In a two‑stage scheme the customer gains flexibility: you can spread the budget over time, ease pressure on the IT team during peak weeks, wait until the network, premises or security policies are ready.

This approach is usually chosen when deadlines are tight or work cannot be stopped. Hardware may arrive on time while the infrastructure is not ready, or vice versa: the IT team is ready but delivery is delayed. Another common trigger is disputes about responsibility: the supplier says everything was delivered, while the IT contractor claims the equipment doesn’t match the spec or wasn’t accounted for.

Control often breaks between delivery and configuration. Boxes are stored “temporarily” without tracking, power adapters get lost, batches are mixed. Later it turns out some PCs lack proper licenses or drivers. Deadlines and quality suffer, and it’s hard to pinpoint when the issue occurred.

Before signing a contract it helps to record a few items: what counts as the result of each stage; who is responsible for storage, inventory and safekeeping between stages; what the timelines and checkpoints are and what is considered a delay; who creates the golden image, installs software and checks compatibility; and how acceptance is documented (acts, serial numbers, test protocols).

For example, when procuring a batch of workstations for a public institution you can accept the computers into a warehouse and configure them later when security policies are approved. In such projects it’s convenient when one partner combines the roles of manufacturer and integrator (for example, GSE.kz): it’s easier to agree responsibility for hardware-image compatibility and support. Even when stages are separated, clear boundaries are needed: what exactly is handed over at each step and who signs for it.

When it makes sense to separate delivery and IT configuration

Splitting physical delivery and configuration is worthwhile when the two stages operate under different constraints: logistics requires speed, while configuration depends on people, access and approvals. That way you can close the “hardware” part faster and schedule IT work in a suitable window without idling due to paperwork or organizational delays.

When hardware must arrive quickly but configuration can wait

This is common when you urgently need to refresh a fleet because of wear, regulations or a budget deadline. Equipment can be accepted into a warehouse or dedicated room and configured later—in the evenings, weekends or by department.

This approach works well for staged rollouts: 200 PCs arrive today, 50 are configured and replaced this week, another 50 next week. It reduces load on the IT team and avoids stopping department work.

When delivery and configuration are done by different contractors

Separation helps if one contractor handles delivery and another performs mass workstation configuration and on‑site work. It’s then easier to assign responsibilities: the supplier covers completeness, serial numbers and warranty documents, while the IT contractor handles the system image, domain, security policies, accounts and commissioning.

To avoid “who’s to blame” disputes, separate the stages formally with distinct acceptance acts for delivery and for workstation readiness after configuration.

When access to facilities is restricted

In hospitals, schools and financial organizations you often can’t enter every room to replace hardware. There may be passes, restricted zones, escort requirements, or bans on connecting unknown media. In such cases it’s more logical to first deliver and inventory equipment, then configure it on a preapproved schedule in small batches with designated contacts from the customer.

When software and security approvals take time

If the software list, licenses, policies, domain structure or security requirements are not yet finalized, waiting for configuration may be impractical. A two‑stage approach saves time: the hardware is already on site and configuration begins as soon as the image and rules are approved.

This is especially useful when coordinating software from major vendors (for example, Microsoft, Oracle, SAP) while preparing access and accounts.

A practical rule: separate stages if the hardware can be safely received and stored, and if the schedule risks stem from access, approvals and department schedules.

When not to split the stages

A two‑stage scheme is convenient when there is time, space and people to keep the process under control. But there are situations where splitting stages almost guarantees delays, disputes about responsibility, and extra risks. In those cases it is simpler and cheaper to deliver and configure as a single project with one deadline and one accountable party.

Signals that turnkey is better

Splitting often fails when at least one of these applies:

• A single final deadline is required. When the result must be “workstations ready,” two teams may shift blame at the boundary: who accepted, who stored, who damaged, who must reinstall.
• No proper storage or intermediate acceptance area. If boxes sit in a corridor or office without tracking, you waste time searching, risk shortages and damage, and it’s hard to prove when a problem occurred.
• The IT team is small and overloaded. Two stages require more oversight: accept the hardware, record serial numbers, arrange site access, then start configuration later and sign acceptance again.
• High security and access chain requirements. The more handling and contact points (warehouse, temporary storage, different contractors), the harder it is to track who accessed devices and media.
• PCs must be ready on delivery day. For a new office, classroom, branch or shift start in a medical facility, delaying configuration after delivery may halt operations.

Simple example: a bank branch receives 40 PCs on Monday morning and an inspection starts on Tuesday. If configuration is planned “later,” you need secure storage, people for acceptance and control, and time to deploy the image, encryption and accounts. In such cases it’s often better to agree on delivery of preconfigured workstations with clear acceptance.

If you work with a manufacturer and system integrator who can cover the entire cycle from delivery to commissioning (for example, GSE.kz), a single‑stage, single‑deadline format often reduces risks and saves management time.

Roles and responsibility: don’t lose the accountable party

If you choose a two‑stage deployment, the most common problem is not the hardware but blurred responsibility. While boxes are in transit, stored and awaiting configuration, it’s easy to lose clarity on who should notice defects, who keeps the schedule and who is liable for loss.

A good rule: each stage must have one owner and a clear acceptance criterion. That prevents “not our fault” disputes from eating weeks.

Who is responsible for what

Split responsibilities with clear boundaries and record them in the contract, terms of reference or work procedures.

• The equipment supplier is responsible for completeness (cables, power adapters, documents), conformity to specification and factory defects found during initial acceptance.
• The IT team (internal or contractor) is responsible for the OS image, drivers, joining the domain, accounts, security policies, email and corporate system access.
• The storage operator (organization or contractor) is responsible for safekeeping between stages: risk of damage, loss, substitution, storage conditions and control of issuance.
• The project manager (one “point of contact”) is responsible for coordination, schedule, escalation and recording decisions.

The point of contact doesn’t need to perform all tasks personally but must collect statuses and decide on blockers (no access to the server room, missing domain accounts, logistics delay).

Documents that close stages

Documents are not bureaucracy; they protect timelines and responsibility.

After delivery, record serial numbers, number of units, external condition, basic power‑on (POST) results and a list of comments. Between stages, use a separate handover act for storage: who accepted, where stored, how sealed, and who has access.

After configuration close the technical part: report on the image and versions, list of installed applications, evidence of domain join, list of created accounts and groups, and verification of key accesses. The final step is an acceptance act for the batch with the signature of the responsible unit.

Example: a school received 80 PCs in June and plans configuration in August. If serial numbers and completeness aren’t recorded in June, in August you can’t prove whether a missing power adapter was absent from the start or lost in storage. With acts and a single point of contact such issues are resolved in hours, not weeks.

Step‑by‑step process: from procurement to ready workstations

A two‑stage scheme works only if the process is broken down into clear actions and deliverables.

First, fix the specification and a basic device registry. The spec should include models and components as well as OS, encryption, domain, access, and warranty requirements. Prepare a unified list of serial numbers (or a template to fill during acceptance). This registry links delivery, warehouse, configuration and commissioning.

Next, create a schedule with milestones and buffers. Buffers are not to extend deadlines but to avoid blocking the launch because of one delayed machine or signature. Typical checkpoints: specification and owners approved; hardware accepted by quantity and serial numbers; reference configuration ready (image, policies, software set); pilot completed on a small group; mass deployment finished and users signed off.

Prepare the reference configuration in parallel. It’s not only a disk image but also a list of mandatory software, security settings, update policies, network parameters, naming templates and account structures. If you deploy centrally (for example, via an integrator or manufacturer with a service network), agree where the reference is stored and who can change it.

When equipment arrives, perform incoming inspection at the site or warehouse: reconcile serial numbers, completeness, external condition, power on and basic self‑test. Log discrepancies immediately and record them in an act so responsibility doesn’t blur between delivery and configuration.

Before mass configuration run a pilot: 5–10 workstations from different departments. For instance, in a hospital choose registry, a doctor’s office and accounting—they use different printers, rights and applications. Use pilot results to adjust the reference and only then start mass imaging.

Final step — user handover. Simplify acceptance by agreeing short “ready to work” criteria (domain login, key apps open, printing, network shares access, acceptable boot time, updates). Deployment ends when the user actually works, not just when the machine is configured.

Timeline control and acceptance: a simple milestone system

Projects usually drag because milestones are vague: delivery seems to have arrived, configuration seems to be ongoing, but who confirms readiness and on which day is unclear. To avoid months of delay, agree several checkpoints and how they are evidenced.

Measurable milestones

Set milestones by verifiable facts and documents. Usually 4–5 points are enough:

• Delivery accepted into the customer’s warehouse (act, list of serial numbers).
• Pilot batch ready (e.g., 5–10 PCs configured and verified against a checklist).
• 50% of the fleet configured (by device registry and statuses).
• 100% configured and handed over to operation (signed acceptance).
• All remarks closed (all nonconformities resolved and logged).

Track progress by devices in the registry: “received”, “configured”, “issued to user”, “accepted by IT or security.” This reduces disputes compared to vague “we’re almost done” reports.

Separate acts for delivery acceptance and configuration acceptance

At delivery acceptance check what can’t be proven later: completeness against the invoice and order, serial number recording, external inspection (damage, seals), power‑on test and basic diagnostics, and photo evidence. Record discrepancies in an exception act.

Close the configuration stage with a separate act: functionality check (accounts, network, printing), security requirements (policies, encryption if needed), required apps installed, and handover to the responsible unit with date and signature.

Record changes with a simple rule: any deviation from the golden image or agreed spec is logged as a change request containing who changed what, when and why, and who approved it.

If timelines shift, agree on a rescheduling mechanic in advance: update the calendar weekly, freeze changes during mass configuration and prioritize critical departments first. For large batches handled by system integrators like GSE.kz, such discipline often makes the difference between “we made it” and “we finish next month.”

Equipment between stages: storage and inventory without chaos

The riskiest gap in a two‑stage deployment is when hardware has arrived but isn’t configured or issued yet. This is when mixups, losses and disputes most often occur.

Where to store and how to choose a location

Common options: the customer’s warehouse, the contractor’s temporary warehouse, or a dedicated room on site (e.g., a locked office). Choose based on priorities: security, quick access or simple acceptance.

For large deliveries with configuration starting in several days, store where there is security and clear access control. If equipment is needed in cabinets within 1–2 days, an on‑site room saves transport time. Integrators often combine approaches: main batch in a guarded warehouse and only the next shift’s devices moved to site.

Inventory, access and protection

Avoid managing “by boxes”; instead track by planned installation location: department, room and responsible person. This is crucial when different configurations look the same.

Practical minimum controls:

• Label each unit with an internal ID and destination (e.g., “Polyclinic, room 214”).
• Reconcile serial numbers at acceptance and before handing to configuration.
• Photo record pallets or shelves and seals (phone photos are acceptable if documented).
• Seal storage areas and control keys.
• Visitor log: who entered, when and why.

Storage conditions are often underestimated. Even new boxes suffer from humidity, dust and temperature swings. Use a dry room with ventilation, no direct sunlight and basic theft protection. If you plan power tests, prepare power strips and breakers to avoid overloading circuits.

Also agree responsibility boundaries: from which moment risks transfer to the customer or the contractor and what proves the handover (act, registry with serial numbers, signature). This prevents equipment becoming a “no‑man’s land” that delays the project.

How to plan configuration to avoid rework

The goal of configuration in a staged approach is that users don’t need return visits for minor issues: wrong driver, missing certificate or account lockout.

Reference image and update rules

Start with a reproducible reference image (or configuration template) applied to all PCs. Include only common items: base drivers, corporate apps, management agents and standard policies.

Major upgrades (for example, a new office suite version) are better scheduled after launch when workstations are stable. Define which changes are allowed before acceptance and which require post‑acceptance change requests.

Licenses, access and security

Separate installation from rights issuance. Provide licenses and accounts as late as possible but ensure users can work on day one.

Confirm security provisions in advance: disk encryption, password policy, restriction of local admin rights (or a clear temporary elevation process), antivirus and monitoring agents. If tokens, certificates or 2FA are user‑bound, don’t bake them into the image—prepare a handover package at user issuance.

Before mass configuration, agree network dependencies: domain, VPN, proxy, corporate certificates, and access to file shares and mail. A common cause of rework is incompatible network drivers or VPN clients with the chosen OS version discovered at the last step.

Keep the minimal pre‑handover checks short:

• PC boots, device manager shows no problems, drivers installed.
• Device joins the domain or registers in the management system.
• VPN/proxy work and key internal services are accessible.
• Security policies applied (encryption, antivirus, rights).
• User login works without last‑minute manual approvals.

A practical approach is a pilot of 5–10 PCs for different user types (doctor, accountant, registry) and record the result as the golden standard. If supplier and integrator are different, agree on a configuration passport format and who is responsible for hardware‑image compatibility. When one partner covers delivery and deployment (as in some GSE.kz projects), there are usually fewer disagreements.

Example: 300 PCs for a regional hospital with no downtime

A regional hospital needed to replace 300 PCs across three buildings: clinic, inpatient ward and laboratory. Operations are 24/7, so “shut everything down for the weekend” was not an option. Each PC also had to be tied to a room, a responsible employee and an acceptance act.

They chose a two‑stage approach. First, delivery to a central hospital warehouse: one acceptance point, one commission, one inventory. Responsibility didn’t spread across buildings and floors. Boxes were accepted in one place, quantities and serial numbers were checked, and only then allowed to proceed to configuration.

Configuration was the second stage, done in batches of 25–40 workstations. Each building had short work windows (e.g., 19:00–22:00) to avoid disrupting patient intake and nurse posts. For each batch a route was prepared: which rooms, which users, which peripherals (scanners, printers, readers) and which network port.

Software and access surprises were common: different medical system versions, plugins, drivers and network folder rights. They ran a pilot on 10 of the most complex rooms (registry, lab, procedure room). After agreeing the image (OS, updates, antivirus, app set, security settings) they mass‑imaged the remaining batches. This reduced rework and resolved disputes before mass deployment.

Simple documents and milestones worked best:

• A serial number registry with statuses: “received”, “configuring”, “installed”, “commissioned”.
• A distribution sheet mapping units to rooms with responsible persons and installation dates.
• A signed batch deployment schedule by IT and department heads.
• A batch acceptance act (not one act per PC).

The key rule for timelines and responsibility was staged acceptance and risk transfer. The supplier was responsible for completeness and safekeeping until the warehouse; the IT team for compliance with the golden image and workstation operability; and the department confirmed the room was ready to operate the new PC. This setup avoids blame games and saves days spent searching for boxes and unconfirmed installations.

Common mistakes and a quick pre‑start checklist

Failures are usually organizational, not technical, and surface during peak work.

Common mistakes

The first is no unified serial number registry and installation mapping. Some PCs end up in the wrong room and later no one knows where a unit shown as in the warehouse actually is. This becomes painful when monitors are swapped, licenses are added and models get mixed.

Second, configuration starts before the reference image and security policy are approved. Teams configure dozens of machines only to discover a different app set or encryption requirement is needed. Rework follows and deadlines slip.

Third, no schedule owner and no regular control on peak days. When delivery, warehouse, IT and customer departments follow different calendars, everyone blames someone else for delays.

Fourth, acceptance “by boxes” without basic power‑on tests. The box is present, but a week later a faulty power supply or RAM shows up and it’s hard to prove when the failure occurred.

Quick pre‑start checklist

Before starting the project, check these basics:

• Roles: who owns the registry, schedule, warehouse, configuration and acceptance.
• Schedule: milestones for delivery, pilot, mass configuration and access windows.
• Registry: serial numbers, components, storage location, final installation place, status.
• Storage: dedicated area, seals or access control, issuance rules.
• Pilot: 5–10 PCs to verify image, security, printing and resource access.

After the pilot prepare clear acts: what is accepted physically and what is accepted as a ready workstation (with power‑on test, network, domain and key applications). If delivery and configuration are split across teams, agree in advance who closes mass preparation and who provides support. Sometimes it’s simpler for one partner to handle delivery, preconfiguration and service (for example, GSE.kz) to avoid hunting for the “responsible” party at stage boundaries.