Microsoft licenses in the Terms of Reference: wording for required rights

Why you should detail licenses in the TOR

If you write simply "Windows" or "Office" in the TOR, the supplier may deliver a product that matches the name but grants different rights. The common result is unpleasant: you cannot upgrade to the required version, you cannot legally install an older version for compatibility, or you cannot transfer the license when replacing a PC.

Both parties face risks. The customer risks acceptance issues (the acceptance committee asks for proof, but there is none or the documents are insufficient), licensing audits and costs for buying missing licenses. The supplier risks a contract dispute: the goods were delivered, but the customer expected something else because rights and license type were not fixed in the TOR.

Usually disagreements come down to four things: edition and version (for example, Home/Pro/Enterprise), delivery channel (OEM, boxed/retail, corporate/volume programs), activation method and supporting documents. Even with the same name, terms of use and the set of documents can differ.

Before publishing the TOR, close several questions: where the software will be used (new PCs, existing devices, virtual machines), whether upgrade/downgrade rights are needed and to which versions, whether license transfers between devices are required, and which documents you want to see at delivery and acceptance.

A simple example: a school needs an office suite for 200 computers, but some classes use templates for an older version. If the TOR does not specify downgrade rights and the list of supporting documents, the delivery may be unacceptable even though "Office" is listed on the invoice.

Basic terms: what exactly you are buying

In Microsoft procurements it’s important to separate three things: the product itself (Windows, Office, etc.), the right to use it (what you are allowed to do) and the proof (which documents demonstrate the right at acceptance and during checks).

A license in the everyday sense is not a box or a key. It is a contractual right to use the software under certain conditions: on which device, for which user, whether it can be transferred, whether another version may be installed. Proof usually consists of supply documents (contract, invoice, waybill, acceptance certificate) and licensing materials (certificate/letter, data from a corporate portal, license card, keys/activation if applicable).

The delivery type is often confused, and it determines installation and transfer rules. OEM is usually tied to a specific device and delivered with the PC; transfer to another device is generally not permitted. Retail (boxed/electronic retail) more often allows transfer, but with limitations (e.g., only one device at a time). Volume (corporate programs) typically provides more flexible rights, but they depend on the chosen program and contract terms, and supporting documents differ from retail.

Another common error area is the licensing metric. If you don’t state it explicitly, the supplier may offer something you didn’t expect. With per device licensing, licenses are counted per device (a typical mistake is buying "for a department" without counting specific PCs). With per user licensing, it’s counted per user (a typical mistake is buying "for devices" although access is needed by dozens of employees from personal accounts).

Finally, Software Assurance (SA) is not an "additional key" but a bundle of rights and services for a limited period. SA often grants upgrade rights to new versions and affects the legality of downgrades. For example, if a government agency buys PCs with OEM Windows and later plans a centralized move to a higher edition, it’s better to state in the TOR whether SA or another program granting the needed rights is required.

What should be in any TOR phrasing

To avoid license disputes at acceptance, the description must be specific. Not just "Windows/Office", but exactly what edition and under what conditions you receive the right to use it.

Phrase the requirements so the supplier cannot substitute a different license type with other rights.

Mandatory parameters that prevent ambiguity

The minimal set to include in the text:

• Product and edition: exact name (for example, Windows 11 Pro, Windows Server Standard, Microsoft Office Standard), and architecture/version if important.
• Licensing channel: OEM, boxed (FPP), corporate (Volume), subscription (for example via CSP). Different channels have different transfer rights and supporting documents.
• Language: interface language and the right to multi-language installation if needed (for example, RU and EN).
• Quantity and metric: "per device", "per user" or "per server/cores" (for servers) with exact numbers.
• Term: perpetual or subscription for N months, plus the rule when the term starts (from activation or delivery).

It’s useful to add 1–2 sentences about your real scenario: where it will be installed, how activation should work, and which rights are critical (upgrade, downgrade, transfer).

Compatibility with your current infrastructure

Briefly state that the product must install and activate in your environment: domain/Active Directory, proxy presence, internet restrictions, installed OS and office versions. If you use a standard system image, require compatibility with it.

Example: "Supply 200 Office licenses in the Standard edition, per user, supporting installation on Windows 10/11 workstations and compatibility with the organization’s domain infrastructure; interface language RU with the option to add EN. Supplier must specify license type in their proposal and confirm with delivery/use documents."

How to request upgrade rights: examples

An upgrade is needed when you want to lawfully move to a higher edition (for example, Standard to Datacenter) or want the right to receive new versions while the right is valid.

Don’t mix two different requests: (1) buying a higher edition now and (2) the right to update to future versions. Updates are not always included by default, so in the TOR explicitly ask whether it’s included in the supply or purchased separately (for example, via Software Assurance or subscription).

Example requirement wording (upgrade)

Требование: предоставить лицензии Microsoft с правом обновления (Upgrade Rights) на новые версии продукта в течение срока действия права обновления.

Условия:
- Право обновления должно быть включено в поставку или поставлено отдельной позицией с указанием срока действия.
- Обновление должно позволять переход на следующую основную версию продукта без доплаты за лицензию.
- Если право обновления обеспечивается подпиской/соглашением, указать тип, срок и количество лицензий.

Before publishing the TOR, clarify what you want to upgrade exactly: edition, version, or both. Ask the participant to state the licensing type (OEM, corporate, subscription), because that determines the availability and conditions of upgrades.

How to tie it to acceptance: which proofs to request

To prevent the upgrade right from remaining "verbal", link it to proofs for acceptance. For example, require: a set of documents confirming the upgrade right (name, quantity, term, agreement ID or number), primary supply documents with the same items, confirmation of assignment of licenses to the organization (supplier letter or a screenshot/export from the licensing admin portal), and a description of the procedure by which the customer gains access to upgrades (who and where downloads the distribution, how the version is recorded).

How to correctly phrase downgrade rights: examples

A downgrade is needed when new software does not match the real environment: a specialized accounting or medical application is certified for a specific version of Windows or Office, drivers for old hardware are not supported in the new version, or legacy plugins and macros remain in use.

A common mistake is confusing the "downgrade right" with "delivery of an older version." Usually you buy a current license but receive the right to legally use an earlier version. Therefore, explicitly request the right rather than writing "install Windows 10 instead of Windows 11" without clarification.

Example wording (universal):

"Supply Microsoft licenses [product/edition] in quantity [N] with the provision of downgrade rights (use of earlier versions) in accordance with the manufacturer’s rules. The customer must have the right to use any of the following versions: [list allowed versions, e.g., Windows 11 Pro with the right to use Windows 10 Pro]. Delivery must ensure legality of using the chosen version at acceptance and during the license term."

To remove ambiguity, add a closing phrase:

"The supplier confirms that the purchased license grants the right to install and use an earlier version without requiring a separate purchase of a license for the earlier version."

For supporting documents, ask for specifics so acceptance does not become a dispute over "just words." For example:

• documents confirming license type and rights (certificate/contract/EULA/confirmation in the portal, if applicable)
• delivery set and identifiers (keys, license numbers, edition details)
• supplier letter/certificate confirming the downgrade right for the specified products and versions
• instructions on how the customer can document the downgrade right during audits

If the purchase is made together with PCs or servers, it’s useful to explicitly state that the downgrade is needed "for compatibility with existing application software and/or hardware." This reduces the risk the supplier will substitute the requirement for a "right" with installing "at their discretion."

License transfers between devices: how to write it in the TOR

License transfer is often confused with reinstallation. Reinstallation means installing the same product again on the same PC (for example, after a disk failure). Transfer means the usage right must move to another device (replacement of an old PC with a new one, repair involving replacement of a motherboard, fleet upgrade).

Transfers are not possible for all license types and not in every scenario. Instead of saying abstractly "the license must be transferable," request a concrete right and conditions: when transfers are allowed, how often, what counts as "the same device," and which proofs are required.

A good phrasing fixes the event (why the transfer occurs), the procedure (what to do with the old PC) and the documents (what proves the transfer).

Example TOR wording (adaptable to your product and licensing program):

"Supplied licenses must grant the right to transfer the usage right to another device in case of: (a) planned workstation replacement, (b) equipment failure and replacement of key components, (c) fleet upgrades. Transfer is allowed provided the software is removed from the original device and the operation is recorded in the customer’s IT asset register. The supplier must list limitations (if any): minimum interval between transfers, deactivation/removal requirements, cases where transfer is prohibited."

To avoid disputes at acceptance, tie transfers to asset accounting. The TOR can require that during a transfer the customer records old and new inventory numbers, device serial numbers, transfer date and reason (replacement/repair).

Also request what the supplier provides to confirm the transfer: documents confirming legality and license type; data for registration and accounting (numbers, user/device bindings); written rules for transfer and limitations; instructions for actions when replacing a PC or performing repairs.

Step-by-step: how to prepare the TOR section about Microsoft

To keep licensing wording from becoming an acceptance dispute, start with an inventory and end with verifiable document requirements.

1. Collect initial data: which devices will be covered, how many, where they are used (office, remote, mixed, server rooms), which versions and editions are already installed. Record exactly what needs legalization or replacement.

2. Choose the licensing model for the scenario. For office PCs the edition (Pro vs Enterprise) and delivery type are often critical. For servers and virtualization clarify in advance whether access will be via VDI/terminal sessions and whether client access licenses are needed.

3. Put rights (upgrade, downgrade, transfer) in separate short points: what is allowed, under what conditions, what counts as a violation.

4. Specify which proofs you accept: product name and SKU, delivery channel, quantity, license agreement, primary documents (invoice, waybill, acceptance certificate), and data that allow you to match the license to the delivery.

5. Plan acceptance and storage: who verifies edition and rights, where keys and documents are stored, what is considered nonconformity. If you buy a batch of office PCs from a system integrator with Windows preinstalled, state in advance whether installing Windows 10 instead of Windows 11 is allowed (if downgrade rights exist) and which documents the supplier must hand over.

Typical mistakes and pitfalls in phrasing

The most common problem is vague wording like "license for Windows" or "Office." Without edition, version, language, license type and delivery channel the supplier can deliver a different product that still formally meets the vague requirement. It’s important to name the product precisely (Windows Pro, Windows Enterprise, Office Standard etc.) and specify whether it is a new license or an upgrade.

A second pitfall is to require transfers where they are not allowed. For example, OEM licenses are often tied to the device and should not be "moved" to another PC. If a project buys new workstations while planning to transfer rights from old ones, split these into separate items and describe rules in advance.

Another confusion is "installing software" versus "transferring rights." You can receive an installed system but lack proof of the usage right. This is especially painful during audits and when registering assets.

Quick self-check of phrasing:

• no precise product name, edition and version
• license type and delivery channel not specified
• upgrade/downgrade expected but not described
• transfer mentioned without specifying which license types it covers
• server and clients mixed in one line without separating rights and components

In server projects people often buy only the server license and forget client access licenses (CALs) or separate components. As a result the system is installed but not legally usable.

Short checklist before publishing the TOR

Review the text as an acceptance specialist: can you unambiguously understand what the supplier must deliver, which rights you will receive and by which documents this is proven.

The document should contain five things:

• Exact composition of supply: product, edition, version (or a "not lower than" rule), language, quantity and metric (per device, per user, per cores, etc.).
• Rights as separate phrases: upgrade, downgrade, transfer (if allowed) and transfer limitations.
• Supporting documents: exactly what you expect and in which form (agreements/terms, proof of usage rights, keys/credentials, delivery channel data, identifiers).
• Acceptance procedure: what is checked (contents, metric, rights, documents), who signs, where and how the confirmation set is stored for audit.
• Compatibility and minimum requirements: architecture, RAM, disk, device role (workstation/server), virtualization restrictions if planned.

Quick test: if you buy PCs for a classroom and some software must run on an older version, ensure downgrade is explicitly stated and acceptance lists which documents prove that right.

If licenses are purchased with hardware (workstations or servers), add a note: the supplier confirms compatibility of the chosen edition and metric with device configurations and usage scenarios.

Example real situation and suggested wording

An organization updates 120 PCs. Finance and reception require new versions, while a classroom runs specialized software that works only on an older Windows and Office. There is also a risk of failures in the first year, and the right to transfer a license to a replacement PC is important.

Below is a fragment that covers upgrade, downgrade and transfer questions.

TOR fragment (example wording):

1. Provide perpetual usage rights for OS/office applications with stated edition, language, license type (OEM/FPP/Volume) and quantity.
2. For 80 workplaces require the right to use the current product version at the delivery date (updates within the acquired edition if allowed by licensing rules).
3. For 40 workplaces require the right to downgrade to version: (specify version), while preserving rights of the purchased base edition.
4. When replacing a faulty PC under warranty, transfer of the usage right to the replacement device within the same organization is allowed provided the rules of the specific license type are followed.

To ensure smooth acceptance, request proofs immediately and don’t accept delivery based only on invoice wording.

Documents for delivery and acceptance (example):

• License certificates or confirmations (by license type).
• Purchase documents: invoice, waybill, acceptance certificate.
• Confirmation of downgrade right (supplier letter referencing licensing rules, not promises beyond the rules).
• Data for accounting: device lists, serial numbers, license bindings.

After delivery keep records: who uses which edition on which PC, where the proof is stored, who is responsible for transfers upon replacement. If PCs are supplied by a system integrator or manufacturer, for example GSE.kz (gse.kz), it is convenient to agree the registry and acceptance formats in advance so documents match the installed setup.

Next steps: how to prepare for procurement and acceptance

Start with specifics: how you will use the software and which rights you need. The clearer the scenarios, the fewer surprises at delivery and audits.

Collect input briefly: where users work (office, remote, mixed), whether there are server roles and RDP/VDI access, whether PC replacement is planned during the license term, whether upgrade/downgrade to specific versions is required, and whether transfers between devices are important and under what conditions.

Before publishing the procurement ask potential suppliers in writing to clarify two things: which rights actually come with the proposed license and which documents you will receive at acceptance. This filters out offers that "promise everything" but provide no proof.

Agree acceptance responsibilities in advance: who verifies licensing and where proofs are stored. In practice it’s convenient to split roles: on delivery day an IT specialist checks names and license types against the specification, and the procurement officer checks the document set.

If transfers are critical (for example, you plan to replace part of the fleet in a year), include this in the TOR from the start. Otherwise you risk tying licenses to old hardware and buying duplicates.