EngineeringMechanical EngineeringLicensing
SOLIDWORKS Licence Models & Entitlement Planning
Licensing is where engineering capacity meets commercial commitment. The administrative question is rarely how many entitlements to buy — it is how to make the ones already held available to the right person at the moment they need them, and that is usually a configuration problem rather than a purchasing one.
- Group · Licensing
- Series · Administration
- Baseline · SOLIDWORKS 2026
- Reading · 16 min
01 What a Licence Entitles
Licensing is where engineering capacity meets commercial commitment. The administrative question is rarely how many entitlements to buy — it is how to make the ones already held available to the right person at the moment they need them.
Two properties determine everything that follows. The first is how the entitlement is bound: to a specific machine, or to a pool served on demand. The second is how products layer: a base tier plus separately entitled add-ins, each of which is consumed when it is activated rather than when the application launches.
Understanding the second point prevents a recurring and avoidable problem. An engineer who leaves an analysis add-in loaded all day holds that entitlement all day, whether or not any analysis is running. In a small pool that single behaviour can block a colleague, and it will not appear in any purchasing analysis because the entitlement looks fully utilised.
Commercial terms, product tiers, subscription arrangements and the entitlements bundled with each tier change over time and vary by territory and reseller agreement. This page covers the administrative mechanics, which are stable. For what a particular agreement actually entitles, refer to the agreement and to your reseller — not to general guidance.
02 Standalone Licensing
An entitlement activated against a specific machine. Simple, infrastructure-free, and inflexible in ways that matter more as a team grows.
Where it works
- A seat with a single, dedicated, regular user.
- Sites with no server infrastructure and no appetite to introduce it.
- Environments where network reliability makes a licence server dependency unattractive.
- Very small teams where concurrency is never a constraint because everyone works simultaneously anyway.
Where it costs you
- Machine changes. Moving a seat requires deactivation on the old machine before activation on the new one. A failed machine that cannot be deactivated needs reseller intervention.
- Imaging. Machine-activated entitlements do not survive disk imaging. The application must be installed after the image is applied.
- Idle capacity. An entitlement bound to a machine is unavailable while that engineer is on leave, on site, or working elsewhere.
- Shared workstations. Shift patterns and hot-desking are poorly served — the machine is licensed, not the person.
The single most common standalone administration failure is a machine retired, wiped or failed without the entitlement being deactivated first. Recovering the entitlement then requires a support request and evidence. Add deactivation to the hardware decommissioning checklist so it happens as part of the process rather than being remembered afterwards.
03 Network Licensing
Entitlements held in a pool by a licence manager service and issued on demand. Returned automatically when the application closes or the add-in is unloaded.
The model decouples the entitlement from the machine and from the person. Any client that can reach the licence server draws from the pool; when the session ends, the entitlement returns. Where the number of seats exceeds the number of people working simultaneously — which is almost always true above a handful of engineers — this converts directly into effective capacity.
What it adds
- Concurrency rather than ownership. Twenty engineers sharing twelve entitlements is workable where the peak is twelve; twenty standalone seats would be required otherwise.
- Administrative control. Reservation, exclusion, idle reclaim and consumption ordering become available — covered in the network licence administration page.
- Machine independence. Imaging works, hardware replacement is trivial, and shared or hot-desked workstations are served properly.
- Offline working through borrowing. An entitlement can be taken off the network for a bounded period.
- Measurement. Usage logging replaces assumption about demand with evidence.
What it costs
The licence manager becomes production infrastructure. It must remain powered, reachable and correctly configured; its ports must be open; and it must be upgraded ahead of the products it serves. A workstation pressed into service as a licence host will eventually be rebooted at the worst possible moment.
04 Choosing Between Them
| Consideration | Standalone | Network | Comment |
|---|---|---|---|
| Infrastructure required | None | Licence server | The server is lightweight but is a production dependency once in place |
| Seats exceed concurrent users | No benefit | Direct saving | The core economic argument; measure before assuming the gap exists |
| Shared or hot-desked workstations | Poorly served | Native fit | The machine is licensed under standalone; the session is licensed under network |
| Machine imaging in the build process | Incompatible | Works | Standalone requires installation after imaging |
| Hardware replacement | Deactivate first | Trivial | Standalone recovery after a failed machine needs reseller involvement |
| Offline and remote working | Inherent | Via borrowing | Borrowing removes the entitlement from the pool for its full term |
| Occasional use of premium add-ins | Full seat each | Shared pool | Often the strongest single argument for network licensing |
| Administrative overhead | Minimal | Ongoing | Server maintenance, reactivation, firewall and upgrade sequencing |
The choice is not all-or-nothing. A common and sensible arrangement is standalone entitlements for a few dedicated full-time design seats where availability must never be in question, with a network pool covering everyone else and all add-in products. Add-ins in particular benefit almost universally from pooling, because their utilisation is intermittent by nature.
05 Product Tiers & Add-in Entitlements
Entitlements layer. Understanding how they are consumed is what makes sizing accurate rather than guesswork.
A base entitlement provides core modelling and drawing capability at a defined tier. Additional capability — analysis, routing, electrical, rendering, data management client access — is entitled separately. Under network licensing these behave as distinct pool items.
Consumed on activation
An add-in entitlement is drawn when the add-in is loaded, not when the application starts. It returns when the add-in is unloaded or the session closes.
Implication: an add-in left loaded holds the entitlement for the whole day.
Independent of base tier
An add-in entitlement attaches to whichever base tier is in use. It is not bundled to a particular one.
Implication: pool sizing for add-ins is a separate calculation from base seats.
Ordered consumption
Where several base tiers are held, the pool draws in a configurable order — by default favouring the lower tier available.
Implication: without ordering set, premium seats can be consumed by basic work.
Add-ins can be configured to load at startup. Where that is set fleet-wide through the deployment image, every engineer draws every enabled add-in entitlement the moment they open the application, regardless of whether they use it. In a pooled environment this exhausts small add-in pools immediately. Enable add-ins per group in the image, and leave load-at-startup off for intermittently used products.
06 Sizing From Evidence
Purchasing should be the last response to a capacity complaint, not the first. Two patterns account for most reported shortages, and neither requires additional entitlements to resolve.
- Step 1Enable usage loggingTurn on reporting on the licence manager and let it run for a full month, covering a normal workload cycle including any month-end or project deadline peak.
- Step 2Establish true peak concurrencyDistinguish peak simultaneous use from total entitlements held. The gap between them is the capacity already available and not being realised.
- Step 3Identify idle holdingLook for entitlements held continuously across a working day, particularly add-ins. These are almost always sessions left open rather than work in progress.
- Step 4Apply reclaim before purchaseShorten the idle timeout and apply it to add-ins as well as the base tier. This alone frequently resolves a reported shortage.
- Step 5Apply reservation and orderingReserve entitlements for roles that must never be blocked; set consumption order so premium tiers are not consumed by basic work.
- Step 6Re-measure, then decideRun another measured period. If genuine contention remains at peak, the case for purchase is now evidenced rather than asserted.
Genuine peak contention concentrates into a few hours and affects many users at once. It is solvable by timeout and reservation adjustment first, and by purchase if that is insufficient.
Idle holding shows a small number of users holding entitlements — often premium add-ins — continuously for occasional use. It is solvable by timeout and consumption ordering, and buying more entitlements simply provides more for the same behaviour to absorb.
07 Entitlement Lifecycle
Reactivation
Activation-based network entitlements require periodic reactivation — typically annually. This is a scheduled administrative task, not an event to discover on expiry. Diarise it, and treat a failed reactivation as an incident with a defined response, because the failure mode is the whole pool becoming unavailable simultaneously.
Version precedence
The licence manager must be at or above the version of the products it serves, and once upgraded it continues to serve earlier versions. This is why it is upgraded first in any release sequence and can be moved well ahead of the main event — it removes a task from the critical window without affecting current users.
Subscription status
Access to new releases, support and certain services generally depends on an active subscription arrangement. Where a subscription lapses, the consequence is usually not loss of the entitlement already held but loss of the right to move to newer releases — which becomes binding when a platform retirement forces an upgrade. Track subscription expiry alongside platform retirement dates; the two together determine your actual upgrade freedom.
Serial numbers, entitlement counts by product, the licence server identity, activation dates and reactivation due dates should be recorded outside the systems they describe. An administrator reconstructing this after a server loss, or a successor inheriting the role with none of it written down, is a wholly avoidable difficulty.
08 Entitlement Planning Checklist
- Model chosen deliberately. Standalone, network or mixed, decided against measured concurrency rather than inherited from the original purchase.
- Add-ins pooled. Intermittently used add-in entitlements are on the network pool rather than bound to individual machines.
- Startup loading reviewed. Add-ins are not set to load at startup fleet-wide where their use is occasional.
- Usage logging enabled. Peak concurrency is known from a measured month, not estimated.
- Reclaim configured. Idle timeout set deliberately and applied to add-ins as well as base tiers.
- Consumption order set. Where multiple tiers are held, the draw order prevents premium seats being consumed by basic work.
- Reactivation diarised. Due dates recorded with an owner and a reminder ahead of expiry.
- Deactivation in the decommissioning process. Standalone entitlements are released as part of hardware retirement, not afterwards.
- Inventory recorded externally. Serial numbers, counts, server identity and dates held outside the systems they describe.
- Subscription and retirement dates tracked together. Upgrade freedom is understood before an upgrade is needed.
09 Frequently Asked Questions
How many network entitlements do we need for twenty engineers?
There is no ratio that survives contact with a real team. The determinant is peak simultaneous use, which depends on how many people model full-time versus occasionally, whether work is deadline-clustered, and whether shifts overlap.
The reliable method is to measure. If you are moving from standalone and have no measurement, start by matching your current seat count, enable logging immediately, and adjust at the first renewal on evidence. Sizing down on measured data is straightforward; discovering under-provisioning during a deadline is not.
Engineers complain there are never licences free at month end. Do we buy more?
Not until three things have been checked. First, whether the idle timeout is doing any work — a generous default means sessions left open over lunch or overnight continue to hold entitlements. Second, whether the timeout applies to add-ins, which by default it may not. Third, whether consumption order is set, so basic work is not drawing premium tiers.
Those three adjustments resolve a substantial proportion of reported shortages at no cost. If contention persists after a measured period with them in place, the purchase case is then evidenced — and the evidence is what makes it approvable.
Can we run the licence server on an existing file server?
Yes. The service is lightweight and co-hosting on an existing always-on server is common and reasonable. What matters is that the host is genuinely always on, is not rebooted on an ad-hoc basis, and is included in the change control that governs any other production server.
What does not work is hosting on a workstation. It will be shut down, updated or rebooted at some point without reference to who is currently working, and the whole team loses access simultaneously.
What happens if the licence server becomes unavailable?
Sessions already holding an entitlement generally continue for a grace period, but new sessions cannot start and add-ins cannot be activated. In practice the team stops working within the hour.
The mitigations are borrowing ahead of a planned outage, treating the server as production infrastructure with defined availability, and — for a genuinely critical environment — discussing redundant server configurations with your reseller. Most organisations find that treating it as a monitored production service is sufficient, provided that decision is made explicitly rather than by default.
Series context. This page is part of the KEVOS® SOLIDWORKS environment administration series. It presents general administration practice and is written to be release-independent wherever possible. Where specific versions, limits or supported platforms are cited, they reflect the SOLIDWORKS 2026 release family and should be verified against current vendor documentation before being relied upon for procurement, platform or upgrade decisions.
SOLIDWORKS is a registered trademark of Dassault Systèmes SolidWorks Corporation. Product names are used here for identification and reference only. KEVOS® is independent and is not affiliated with, endorsed by, or a reseller for Dassault Systèmes.