Turnkey delivery with installation: defining scope of work in the contract

Why gray areas appear in “turnkey” contracts

Gray areas appear when parties say “make it work”, but don’t break that phrase into concrete results and boundaries. As long as the project runs smoothly, this seems convenient. Problems arise at acceptance: the client expects one thing, the contractor is sure they have already done everything.

A common reason is mixing fundamentally different things: supply of goods and performance of works or services. Supply usually concerns completeness, delivery times, packaging, warranty and documents. Installation and configuration are works: site conditions, accesses, source data and readiness criteria matter. When everything is written in a single paragraph, it becomes unclear what exactly is considered “delivered”.

At acceptance disputes are more often about what “commissioning” means than about whether equipment was delivered. For some it means “turned on, booted, lights on”. For others — “users work, data migrated, backup in place, an acceptance act signed and support is defined”. If criteria are not described, each side interprets the wording to its advantage.

Typical responsibility gaps almost always repeat: who prepares the site (power, racks, cabling, climate, grounding), who provides accesses and source data (accounts, domain, IP plan, security policies), what exactly is included in configuration (only basic setup or also integrations), who performs migration (scope, downtime window, rollback) and when support begins.

Practical example: a server was delivered and OS installed, but the customer expected the contractor to migrate databases, set up backups and confirm performance with a test. The contractor believed “turnkey” only covered supply and installation. As a result the acceptance act wasn’t signed, deadlines are tight and downtime already occurred.

A vague phrase “commission into operation” almost always leads to additional work without clear price, disputes over timing and situations where the system seems to work but no one takes responsibility for the final result. This is particularly noticeable in projects where “turnkey” includes hardware, configuration and data migration.

How to separate stages: delivery, installation, configuration, migration, support

To prevent a supply-with-installation contract from turning into a dispute about who “meant” what, it’s better to split the project into stages. For each stage fix three things: the result, the input conditions (what is needed from the customer) and the acceptance moment.

1) Delivery

Delivery is not just “boxes were brought”. The contract should fix the composition of the kit for each item, serial numbers (or the procedure for recording them), the list of accompanying documents and the procedure for checking conformity. It’s useful to separately describe delivery and on-site storage: who unloads, where equipment is temporarily placed, who is responsible for preservation until installation.

The stage result must read unambiguously: equipment transferred, matches specification, documents signed.

2) Installation and physical readiness

Installation is the physical mounting and preparation of the hardware for power-up: racks, fasteners, cabling, port and line labeling, cable routing. The most important thing here is boundaries. For example, whether laying new routes, drilling and ceiling works, relocating sockets, checking power and UPS, grounding work are included.

To avoid disputes at handover, predefine who provides consumables and infrastructure (racks, PDUs, patch panels, sockets), as well as access restrictions (entry rules, working hours, security escort requirements).

3) Configuration

Configuration is parameters and software part: BIOS/firmware, RAID, OS and driver installation, updates, accounts, access policies, domain join, network, monitoring and backup (if included). People often confuse “basic configuration” with “ready for business operation”. It’s easier to separate: what’s included in the basic package and what is a separate task (for example, fine security policies or configuration of specific applications).

4) Migration

Migration is a separate stage with its own risks and dependence on the source environment. The contract must describe what exactly is migrated (data, mail, profiles, applications, configurations), from where to where, volumes, who prepares accesses and source exports. Always specify the maintenance window and rollback plan: what we do if something doesn’t start after migration.

A simple rule: the contractor is responsible for migration according to the agreed plan, and the client is responsible for providing current passwords, accounts and confirmation which folders and databases are critical.

5) Support

Support begins after acceptance and should be described separately: contact channels, response time, recovery time, maintenance windows, priority definitions and what counts as an incident. It’s useful to immediately separate “what’s included” and “what is considered a change” (for example, adding users, network readdressing, moving services).

If the contractor both produces equipment and provides services, like GSE.kz, it is convenient to fix a single request and escalation procedure so there’s no gap between “this is a hardware warranty” and “this is configuration work”.

Boundaries of responsibility: where the contractor’s work ends

In turnkey projects disputes are usually not about price but about what is considered completed. It’s better to describe work boundaries not in general words but by stages and verifiable results.

Delivery vs installation. Delivery is kit composition, delivery, unloading, integrity check and handing over by waybills. Installation starts where responsibility for placement and connection appears: rack, mounting, cable routes, power, labeling. If the contractor does not perform, for example, rack preparation or cable routing, state this explicitly. Otherwise expectations will inevitably appear.

Configuration vs development/customization. Configuration is work within standard hardware and software capabilities: firmware, RAID, basic OS installation, drivers, domain join, creating accounts from a provided list. Customization is scripts, integrations, changes in business applications, non-standard security policies, reports and other tasks where a specification is needed to understand completion. If such works are possible, fix them as a separate scope: what is done, who approves and which document confirms the result.

Migration. Data and service migration rarely equals “configuration” because it depends on the quality of the source environment. Migration is better separated: list systems, switching order, allowable downtime, success criteria and distribution of responsibility for source data.

Support vs warranty. Warranty covers hardware defects. Support covers incidents, changes, updates and user requests. If an SLA is required, separate it from implementation: contact channels, response time, maintenance windows, what is an incident and what is a change request.

Also specify customer obligations. Most often these are accesses (accounts, domain, admin rights, VPN) and work windows; site readiness (power, cooling, racks, passes); providing source data and responsible approvers; user participation in tests and acceptance; confirmation of backups before migration.

Example: when installing servers into a rack (e.g., S200 series) the contractor is responsible for mounting and commissioning according to the checklist, and the customer is responsible for a ready rack, power and access to the server room. Then, if the server doesn’t power on, it’s clear where to look and who fixes it.

What must be fixed in the contract and appendices

Clarity is best placed in appendices. Keep the contract as the rules of the game and attach mandatory documents: they are easier to update and convenient for acceptance.

Start with the exact composition of delivery. If the spec just says “server” without model, configuration and contents, acceptance will almost always raise questions: are there enough ports, what software version, are licenses included, who provides keys. Also fix what the customer provides: accounts, IP addresses, racks, power, communication channels.

Practical minimum appendices:

• Equipment and software specification: models, configurations, versions, licenses, serial numbers, kit contents.
• Work plan by stages: what we do, what the output of each stage is, which documents confirm it.
• Responsibility matrix (for example, RACI): who performs, who approves, who provides inputs, who accepts.
• Access conditions and work windows: time, entry rules, escort, remote access.
• Acceptance protocol and readiness criteria: what we check, how we record remarks, deadlines for remediation.

The “readiness for acceptance” block is best formulated as testable statements. For example: equipment mounted and labeled, cables routed, as-built drawings exist; system powers on without errors, basic settings applied; migration completed per agreed list with report and verification checks; backup configured and restore test performed; post-launch support described.

If the contractor both supplies and implements (for example, an integrator and manufacturer like GSE.kz), it is important to separate roles within the team in the responsibility matrix and tie acceptance to stages. Then each step is closed by a document, not a verbal agreement.

Step by step: how to prepare a contract without gaps between stages

Contracts usually break at seams: goods delivered, racks mounted, but commissioning did not happen and it’s unclear who must finish small tasks. To avoid that, assemble the project as a chain of stages where each has inputs, results and an acceptance document.

First fix the base without which the work plan becomes guesswork: site addresses, access regime, work windows, requirements for noise/dust, presence of racks, power, grounding, cooling, communication channels. Note restrictions separately (for example, work only at night or services cannot be stopped).

Next agree the plan and control points: calendar schedule, responsible persons, control meetings, change and schedule procedures. Make changes through a clear procedure (amendment or change request), not via email.

Then describe each stage result in measurable terms. “Delivery” — kit and serial numbers. “Installation” — device mounted and connected per diagram. “Configuration” — listed parameters, accounts and policies. “Migration” — list of migrated data and verification checks. “Support” — reaction and recovery rules.

Also close typical gaps: input conditions from the customer (IP plan, domain, accounts, licenses, access to premises), acceptance format (stage acts, test checklists, verification results), and post-launch support (channels, hours, priorities, escalation). If deploying servers and workstations, separately state where infrastructure work ends and where the customer’s administrators’ responsibilities begin.

Acceptance and readiness criteria: how to measure the result

Disputes arise not because someone “did a bad job” but because the result cannot be unambiguously checked. Acceptance should answer four questions: what do we check, how do we confirm it, who signs and in what timeframe.

For supply with installation it is better to split acceptance by stages so handover doesn’t become one big act mixing everything.

Typical criteria look like this: for delivery — check completeness and serial numbers, inspect for integrity, presence of manuals and licenses; for installation — physical placement per plan, safety of fastenings, labeling, compliance with wiring diagram, power; for configuration — list of applied settings, firmware and software versions, roles and accesses, network parameters, transfer of admin access in an agreed form; for migration — exact scope of transfer and integrity checks (for example, sample verification, reports), maintenance window, success criteria and rollback plan.

It’s important to predefine what counts as “ready”. For example: “accounting users can log in, see data for the last 12 months, printing works, external access is closed, scheduled backups are created”. These are testable signs, not general words.

Defect protocol and closure

Even with good preparation remarks will almost always appear. To prevent them from blocking the entire acceptance, you need a separate defect protocol.

A simple workflow: the contractor hands over documents and demonstrates checks per checklist; the customer records remarks tied to location and manifestation; for each item set deadlines and closure criteria; after remediation sign the defect closure and the stage act.

Example: PCs and a server are installed in a rack, everything powers on, but some sockets are unlabeled and mail migration missed archives. If the protocol contains a criterion “archives for the last 24 months are available in the client, sample check of 20 mailboxes without discrepancies” and a remediation deadline, the issue is resolved faster and without mutual claims.

Common contract mistakes and how to avoid them

The main problem in supply-with-installation contracts is mixing different services with different acceptance rules in one document. As a result parties understand “delivered” differently, when support begins and who pays for rework.

One frequent mistake is combining hardware warranty and SLA support in the same clause. Warranty covers factory defects and repair or replacement under the manufacturer’s rules. SLA covers response and recovery times, escalation procedures and often monitoring. Separate them in different sections.

Second mistake — the phrase “configuration to customer needs” without a work list. This almost guarantees a dispute at acceptance. An appendix with a concrete list helps: which roles and policies are created, which services are deployed, which tests are run, what the “ready state” should be.

Often people forget requirements for source data for migration. If the customer does not prepare accounts, accesses, mapping tables or clean the data, deadlines shift and someone tries to blame the contractor. In the contract explicitly state what the customer provides before start, in which format, who confirms the list to be migrated and what is considered a successful migration.

Night work and downtime are another risk area. If you need migration “without stop”, specify maintenance windows, approval procedure, right to shift the window and who must be on call and sign night-shift results.

Finally, many do not describe what to do when hidden site limitations are found: missing required power, insufficient rack space, no grounding, blocked cable path. A site survey and a readiness act help; when limitations are found, follow a clear change request procedure: record, evaluate, agree on schedule and cost.

Example: during server installation it is discovered there are no free PDUs in the rack. If not specified, installation stalls. If specified, parties quickly agree on extra work or the customer provides the infrastructure.

Short checklist before signing

Before signing check that stages are separated so acceptance won’t raise “who should do this?” Better spend an hour clarifying than weeks on post-signature correspondence.

Make sure each stage has its result and acceptance document, and the customer’s input conditions are specified: access to premises, rack readiness, power and structured cabling, accounts and rights, source data, contacts and work window. Support should have measurable rules (response and recovery times, priorities, maintenance windows), migration — a data owner and verification criteria after transfer. Also define procedure for scope changes: how extra works are formalized, how price and deadlines are agreed.

Pay attention to the words “configuration” and “commissioning”. They often sound the same but differ in meaning. Configuration is parameters and settings. Commissioning is confirmation that the system works in the target environment and passed checks per readiness criteria.

Small example: when buying servers and deploying services, fix in advance who provides IP addresses, domain, accounts, access to current infrastructure and who signs test protocols. Even with an experienced integrator, disputes usually arise not because of hardware but due to unlisted dependencies on the customer side.

Example project: office + server room, migration and launch without downtime

Scenario: a company updates its server room and office workstations but can’t stop services for a day. They buy new rack servers and PCs and need to migrate users to a new domain, keep accesses and launch everything by the start of the working week. In such projects turnkey delivery usually breaks at the boundary: where installation ends and configuration begins, who is responsible for migration and what counts as a successful launch.

It’s convenient to fix work separation by stages with separate acceptance: equipment delivery, rack installation and connection of power and network, basic infrastructure configuration (hypervisor, domain, policies, basic roles), user and data migration, post-launch support. Even if the supplier also acts as the integrator, you must still describe boundaries for each stage, otherwise the dispute will be about “who should have done it”.

To migrate without downtime, contractually fix input conditions without which deadlines and results are not confirmed: list of users and devices and current access rights; list of critical services; maintenance window (night/weekend) and allowable downtime per service; access to current infrastructure and responsible person; confirmation of site readiness (rack, power, network, cooling).

Next agree which documents close stages and what is checked. Usually it’s a bundle: delivery act (contents, serial numbers), installation act (installed and connected), configuration protocol (what was configured and to what extent), migration act (list of migrated users, profiles, mail), then commissioning act and support parameters.

Points of dispute are always in details: “profile migration” — does it mean files only or also application settings; “domain configuration” — does it include group policies or just basic structure; “zero downtime” — does it mean zero minutes or fitting within an agreed window. These are resolved by defining boundaries of work, measurable acceptance criteria (test scenarios) and a list of exclusions (third-party apps and licenses).

Next steps: how to run a turnkey project without disputes

Before start collect all works and responsibility boundaries in one package, not scattered across emails, estimates and verbal agreements. When delivery, installation, configuration and migration are described in different places, a “that’s not ours” zone almost always appears.

Start with a project map: what you want to get and who is responsible for each result. It’s convenient to present this as a responsibility matrix: task, performer, input conditions (what the customer prepares), measurable result, deadline.

Minimal action plan before signing

Fix the scope and boundaries: what is included in delivery, what is installation, what counts as configuration, what exactly is migration and tests. Approve acceptance criteria in advance: which checks will be made, who attends, which documents are signed, what is considered “ready for operation”. Carry out a joint pre-project inspection of the site and accesses: power, racks, network, accounts, work windows, access to the server room. And agree the post-launch support model in advance: contact channel, response time, working hours, what is included and what is separate work.

Practical example: when migrating services to new servers and updating desktops, if the installation is completed but launch fails due to missing admin account and a closed switch port, a dispute would arise. If these input conditions are listed as the customer’s responsibility, disputes usually do not occur.

When to choose a single contractor

If you need one team accountable for hardware, implementation and ongoing support, it’s more convenient to work under a comprehensive contract. In Kazakhstan this often simplifies projects when the supplier not only delivers equipment but also takes on integration and support. For example, GSE.kz combines production of computers and servers in Kazakhstan with system integration and round-the-clock technical support through a service network.

Before final agreement ask one control question: “If something does not work on handover day, who must bring it to result, in what timeframe and by what signs will we understand it’s done?” If this is not answered in the contract and appendices, the document is not ready to sign.