EngineeringMechanical EngineeringTechnical Reference
SOLIDWORKS Administration in Practice
Running SOLIDWORKS well across a team is an engineering management problem, not a software installation problem. This reference sets out the six domains a CAD administrator actually owns — platform, deployment, licensing, data management, standards and continuity — and the decisions inside each that determine whether design data stays trustworthy.
- Discipline · Mechanical Engineering
- Type · Technical reference
- Baseline · SOLIDWORKS 2026
- Reading · 22 min
01 Executive Summary
Most organisations buy SOLIDWORKS as a design tool and inherit an administration burden they never scoped. The cost of that gap is rarely visible as a licence line item — it appears as rework, wrong revisions reaching the shop floor, and unrecoverable data.
A managed SOLIDWORKS environment is defined less by the software than by the decisions surrounding it: how workstations are specified, how the client is deployed and kept consistent, how licences are allocated under contention, where controlled data lives and who may change its state, which templates and library components are authoritative, and what happens on the day the vault server fails.
These decisions are interdependent. A workstation specification that ignores certified graphics drivers surfaces later as "SOLIDWORKS keeps crashing." A Toolbox left on individual machines surfaces later as three different M10 bolts in one bill of materials. A backup routine that captures the database but not the archive folders surfaces, once, as a total loss.
Version-specific figures below reflect the SOLIDWORKS 2026 release family. Requirements, supported operating systems and supported SQL Server versions change with every annual release and service pack. Treat the numbers here as a planning baseline and verify against the vendor's current published system requirements before committing to hardware, an operating system or an upgrade window.
Product architecture, capability tiers and commercial terms are also subject to change. Where this page describes behaviour that determines whether data survives — backup composition, upgrade sequencing, version compatibility — confirm against the current administration and installation guides for your release.
02 The Administrator's Domain Map
Six areas of responsibility. They are listed in dependency order: each one assumes the one before it has been settled.
Platform & Workstation
Operating system, processor, memory, storage and — critically — certified graphics. Sets the ceiling on everything above it.
Failure mode: unexplained instability that gets misattributed to the software.
Deployment & Configuration
Administrative images, option editors, silent and pushed installs, and the settings that arrive locked or unlocked on every seat.
Failure mode: configuration drift — no two workstations behave the same way.
Licence Administration
Standalone versus network licensing, reservation and exclusion rules, borrowing policy, idle timeouts and consumption order.
Failure mode: engineers idle at peak load while licences sit checked out and unattended.
Data Management
Vault architecture, workflow states, revision schemes, permissions and the boundary between working and released data.
Failure mode: the wrong revision is manufactured, and nobody can prove which one was right.
Standards & Libraries
Templates, sheet formats, custom properties, Toolbox and design library — the shared vocabulary of every drawing the business issues.
Failure mode: inconsistent documentation and unreliable bills of materials.
Continuity & Change
Upgrade sequencing, version compatibility, backup composition, restore rehearsal and rollback.
Failure mode: a recoverable incident becomes a permanent loss of intellectual property.
CAD administration sits awkwardly between engineering and IT, and is frequently owned by neither. IT typically controls the servers, the domain and the backup regime; engineering understands revision control, drawing standards and what the data means. Assigning the role to one side alone reliably produces gaps. The workable pattern is a named CAD administrator inside engineering with defined server-side access, working to an agreed interface with IT — not a shared responsibility that resolves to nobody's.
03 Platform Foundations
Hardware specification for CAD is not a general-purpose IT decision. The performance profile of parametric modelling is unusual, and the graphics requirement is a certification question rather than a raw-power question.
Baseline requirements
The 2026 release family requires a 64-bit professional or enterprise edition of Windows 11; consumer Home editions are not supported, and Windows 10 support ended with the 2025 SP5 release. Published minimums sit at roughly 3.3 GHz processor clock, 16 GB of memory, a certified workstation graphics card, and a solid-state drive with meaningful free capacity retained. These are installation minimums, not working specifications.
| Tier | Typical workload | Memory | Graphics class | Notes |
|---|---|---|---|---|
| Entry | Parts, small assemblies to a few hundred components, drawings | 16–32 GB | Entry certified workstation card | Adequate for detailing and component design; struggles as assemblies grow |
| Mainstream | Assemblies to several thousand components, routine simulation | 32–64 GB | Mid-range certified workstation card | The realistic default for production design work in 2026 |
| Heavy | Very large assemblies, complex surfacing, large-scale analysis | 64–128 GB | Upper-tier certified workstation card | Memory is usually the binding constraint before the processor |
| Visualisation | Photorealistic rendering and animation | 64 GB+ | High-VRAM card with ray-tracing acceleration | The only tier where GPU compute capacity, not certification, dominates |
Why clock speed still beats core count
Parametric rebuild is largely sequential: features in the design tree are evaluated in order, so single-thread performance — instructions per clock and sustained frequency — governs the responsiveness engineers actually feel. Core count matters for simulation solvers, rendering and some background operations, but a high-core, low-frequency processor will feel slower in day-to-day modelling than a fast four- or six-core part. Specify for the dominant workload, not the impressive specification sheet.
Certified graphics is not optional
SOLIDWORKS renders through OpenGL and depends on driver features that vendors validate specifically for the application. Consumer gaming cards have ample raw capability but lack the certified professional drivers; the practical consequences are absent advanced display modes, graphical artefacts and instability in large assemblies. The correct procedure is to select a card from the published hardware certification list and install the driver version certified for your release — not simply the newest driver available.
Antivirus scanning. Real-time scanning of CAD file types and working folders degrades open, save and vault check-in performance substantially. Establish documented exemptions for SOLIDWORKS file extensions, local vault view folders and archive locations.
Disk imaging. Cloning a machine with SOLIDWORKS already installed is not a supported activation path. Install after imaging, or use network licensing where the entitlement is not bound to the machine.
Uncertified drivers. A general Windows driver update pushed fleet-wide can silently move every workstation off its certified driver version. Exclude CAD workstation graphics drivers from automatic update policy.
04 Deployment & Configuration Control
Installing SOLIDWORKS individually on each workstation guarantees divergence. The administrative image exists to make one configuration decision and apply it identically, repeatedly, and on upgrade.
The administrative image
An administrative image is a prepared installation source containing the selected products and a stored configuration. It is created through the Installation Manager, then customised with the Administrative Image Option Editor (sldAdminOptionEditor.exe), which holds global settings plus per-group and per-machine overrides — serial numbers, licence server address, installation paths, Toolbox location, add-in selection and the client settings file.
Obtain the complete installation set rather than a streamed install, so the same source serves upgrades and image creation.
Build on local disk for speed and stability, then copy the completed folder to the network share.
Set global options, then define groups for teams that need different add-ins or Toolbox paths.
Export system options from the Settings Administrator and reference the resulting file so seats arrive pre-configured.
User-initiated, silent, or pushed via scheduled task — see the comparison below.
Deploy to a small representative group, validate add-ins and macros, then open to the fleet.
| Method | How it runs | User rights needed | Supports automatic upgrade | Best suited to |
|---|---|---|---|---|
| Guided (HTA) | User opens the launcher page in the image folder and confirms | Local installation rights | Yes | Small teams; environments where users control their own upgrade timing |
| Silent executable | Executable in the image folder runs without interaction | Local installation rights | No | Scripted rollouts under existing software distribution tooling |
| Automatic push | Scheduled task executes on target machines under the system account | None for the user | Managed | Managed fleets where users are not local administrators |
Use UNC paths, never mapped drives. A mapped drive letter does not resolve under the system account used by pushed installs, and behaves inconsistently when an installer is run as a different user. Address the image share as \\server\share\image-folder from every client, identically.
Keep the root path short. The image expands into a deep subfolder structure; a long root path pushes component paths past the limit and produces obscure mid-install failures. Keep the root well under sixty characters.
Governing system options
The Settings Administrator tool produces a settings file that the image applies to each client. Two independent controls exist for every option: whether the setting is applied, and whether the user may subsequently change it. This distinction matters. Locking file locations, template paths and Toolbox paths prevents the drift that undermines standards. Locking preferences that are genuinely personal — mouse behaviour, colour schemes, view manipulation — generates resentment without protecting anything.
Lock: file locations (templates, sheet formats, design library, Toolbox), default template assignments, units and drafting standard defaults, performance settings with known-bad values, and update or backup paths.
Apply but leave unlocked: display quality defaults, spin and zoom behaviour, and anything where the correct value varies by person or hardware.
Publish the list. An administrator who can explain why each locked setting is locked meets far less resistance than one who simply removes controls.
05 Licence Administration
Licensing is where engineering capacity and commercial commitment meet. The administrative question is not how many licences to buy, but how to make the ones you hold available to the right people at the right moment.
Standalone versus network
A standalone licence is activated against a specific machine. It is simple, needs no infrastructure, and suits a seat with a single dedicated user. It also travels badly: transferring it between machines requires a deactivation and reactivation cycle, and it is incompatible with machine imaging workflows.
A network licence is issued from a licence manager service that holds a pool and hands out entitlements on demand, reclaiming them when the application closes. This is the appropriate model wherever seats outnumber concurrent users, where shift patterns or shared workstations exist, or where add-in products are used intermittently by many people. It introduces a dependency: the licence server and the network path to it become production infrastructure.
Network licensing — controls worth configuring
- Reservation. Guarantee specific entitlements to named users or groups so a critical role is never blocked.
- Exclusion. Prevent groups from consuming premium tiers they do not need, keeping those seats available.
- Idle timeout. Reclaim licences left open on unattended machines. Defaults are generous; shorter windows materially improve availability.
- Borrowing policy. Control who may take a licence offline and for how long — borrowed entitlements leave the pool for their full term.
- Consumption order. Where multiple tiers are held, direct which is drawn first so premium seats are not consumed by basic work.
- Usage logging. Enable reporting to replace assumptions about demand with measured peak concurrency.
Operational requirements
- Firewall. The licence service uses dedicated ports that must be open inbound on the server and outbound from clients. Blocked ports are the most common cause of "no licence available" reports.
- Server availability. The licence host must stay powered and reachable. A workstation pressed into service as a licence server will eventually be rebooted at the worst moment.
- Periodic reactivation. Activation-based network entitlements require periodic reactivation. Diarise it; do not discover it on expiry.
- Version precedence. The licence manager must be at or above the version of the products it serves, and it serves earlier versions once upgraded — which is why it is upgraded first.
Before adding seats, enable usage logging and observe a full month. Two patterns recur. The first is genuine peak contention concentrated into a few hours — solvable with a shorter idle timeout and reservation rules before any purchase. The second is a small number of users holding premium entitlements continuously for occasional use — solvable with consumption ordering. Purchasing is the last option, not the first.
06 Data Management Architecture
A folder structure and a naming convention are a filing system, not a data management system. What distinguishes managed data is enforced state: a file is demonstrably in work or released, and the transition between the two is controlled, recorded and irreversible without a further controlled action.
What a vault actually consists of
The architecture is frequently misunderstood, and the misunderstanding is what makes backups fail. Three server roles cooperate, and the file content and the metadata live in different places.
File content lives on the archive server as ordinary files on disk. Metadata — data card values, folder structure, references, users, permissions and history — lives in the database. Neither is complete without the other, and a restore is only clean when both were captured at the same point in time. This single fact drives the entire continuity section below.
Capability tiers
Two tiers are commonly available. The lower tier is bundled with higher CAD editions and runs on the free database engine; the upper tier is licensed separately and requires a full database licence. The functional difference is not cosmetic.
| Capability | Standard tier | Professional tier | Why it matters |
|---|---|---|---|
| Database engine | Express edition | Full edition | Express imposes a hard database size ceiling and restricts processor and memory use |
| Workflows | One, limited states | Unlimited | A single workflow forces documents, CAD and purchased data down one approval path |
| Multi-site replication | Not available | Available | Decides whether a second engineering office is workable over a WAN link |
| Web and remote access | Not available | Available | Determines how suppliers, production and field staff reach released data |
| Programmatic interface | Not available | Available | Required for ERP integration and automated data exchange |
| Scheduled database maintenance | Manual or scripted | Native scheduling | Directly affects whether backups are automated or depend on someone remembering |
| Commercial model | Bundled with higher CAD editions | Separately licensed per user | Total cost includes database licensing, server hardware and implementation |
Server topology
Small environments can run all server components on one dedicated machine. Beyond roughly fifteen users, separate the database engine from the archive server: the database is processor- and memory-intensive, the archive is storage- and throughput-intensive, and they compete badly for the same resources. Host the operating system and database on redundant solid-state storage; give the archives dedicated high-throughput volumes with capacity headroom, since every version of every file is retained.
It is technically possible and reliably regretted. Desktop editions are licensed for single-user desktop use rather than multi-user server workloads, and they lack the management, scalability and resilience features that server editions provide. Desktop-class hardware also lacks the redundancy expected of a system holding the organisation's design record.
Designing the workflow before deploying it
The most common implementation error is treating vault deployment as an IT project and configuring the workflow afterwards. The workflow encodes the organisation's engineering change process; if that process is unclear, the vault will simply make the ambiguity permanent and harder to modify. Establish, in writing, before configuration begins:
- The revision scheme, and precisely what event increments it
- The states a document passes through, and who may approve each transition
- What "released" means operationally — what is permitted to happen to the file afterwards
- How change is initiated, recorded and closed out
- Which roles may read released data without being able to alter it
- How legacy data will be migrated, and what will deliberately not be migrated
07 Standards & Library Governance
Templates, sheet formats and library components are the shared vocabulary of everything the engineering function issues. Left ungoverned, they diverge quietly and the divergence surfaces in the bill of materials.
Templates and properties
Every part, assembly and drawing template should originate from one controlled location referenced identically by every workstation — a network share addressed by UNC path, or a designated vault folder. Local copies defeat the purpose entirely.
Custom properties deserve particular discipline because they propagate into bills of materials, drawing title blocks and downstream business systems. Define the property set once — description, part number, material, finish, mass, revision, designer, approval — with fixed internal names and, wherever the value is drawn from a known set, a controlled list rather than free text. Retrofitting a property schema across an existing data set is expensive; getting it right before the first template is issued costs nothing.
Toolbox — the highest-risk shared library
Standard hardware libraries are integrated with hole-creation tooling and generate configurations on demand. This convenience is exactly what makes them dangerous when uncontrolled: each workstation generates its own configurations, and the same nominal fastener ends up represented differently across the business.
Governing rules
- One shared location — a UNC network path or a vault folder — referenced identically from every client. Never mix local and shared references.
- Restrict write access to administrators. Ordinary users should not be able to alter library content silently.
- Configure the library fully before production use: part numbering, descriptions, configuration naming and custom properties.
- Where the library is vault-managed, set the client cache to refresh on log-in so users see current content.
- Back it up on the same schedule as any other controlled data. A customised library represents real accumulated work.
The version trap
Upgrading the library upgrades it to the new major version. If any workstations remain on the previous release, they can no longer use it — and the upgrade is not conveniently reversible.
Two consequences follow. Maintain a separate library location per major version, named with the version year, whenever a mixed-version period is anticipated. And upgrade the library once, centrally, with a verified backup taken first — never as an incidental side effect of the first client upgrade someone happens to run.
Maintain a short controlled document recording the authoritative location of every shared resource — templates, sheet formats, library, materials, drafting standards, macros — together with its owner and the date last reviewed. It takes an hour to write, replaces a great deal of tribal knowledge, and is the first thing a successor will need.
08 Upgrade Planning & Sequencing
Annual releases arrive whether or not the organisation is ready. Upgrading is a change-control exercise with a strict order of operations and one property that makes it unusually unforgiving.
A file saved in a newer major version cannot be opened in an earlier one. A single engineer upgrading ahead of the group and saving into shared data can render that data inaccessible to everyone else. Upgrade timing is therefore a coordination decision affecting the whole team, not an individual preference — and it extends to external parties who receive native files.
Compatibility rules that govern the sequence
- Licence manager first. It must be at or above the version of the products it serves, and once upgraded it continues to serve earlier versions — so it can be moved well in advance of the main event.
- Data management client and server must match. The vault client year-version must equal the server year-version. There is no partial upgrade: once the server moves, every client must follow before it can reconnect.
- CAD integration spans several years. A current-year vault typically integrates with the current and two preceding CAD releases, which allows CAD upgrades to be staged even though the vault client cannot be.
- Verify the platform prerequisites. Supported operating system and database versions are retired on a published schedule. Check both before scheduling, since either may turn a software upgrade into an infrastructure project.
Server-side upgrade sequence
- AheadUpgrade the licence managerPerform this days in advance and confirm entitlements are active. It continues to serve current-version clients, so it removes a task from the critical window.
- AheadValidate prerequisites and add-insConfirm operating system and database support, then test third-party add-ins, macros and integrations against the target release in a non-production environment.
- T−0Quiesce the systemHave users check in all work and log out. Uncommitted work in a local cache is not protected by any server-side backup.
- T−0Take the full backup setArchive folders, archive server configuration and every vault database — captured together, and verified before proceeding. This is the rollback position.
- T−0Stop the archive servicePrevents further client activity and ensures the archive content is static for the duration.
- T−0Upgrade the server softwareUpgrade the archive server, database server service and any replicated archive servers.
- T−0Upgrade the vault databasesA separate step using the dedicated database upgrade utility. Software upgrade alone leaves the schema at the previous version and clients unable to connect.
- T−0Verify on the serverConfirm licence activation at the new version and log in to the administration tool before touching any client.
- T+Upgrade the first client and shared librariesUpgrade one client, then the vault-managed library — once, deliberately, with the backup already verified.
- T+Roll out the remaining clientsDeploy from the prepared administrative image. Sequence CAD users first, then non-CAD vault users.
Conventional practice has been to wait for the third service pack before adopting a new annual release. That is a risk-appetite judgement rather than a rule. Weigh it against three factors: whether a specific new capability solves a live problem; whether third-party add-ins and internal macros are certified for the release; and whether a supported-platform deadline forces the move regardless. Whatever is decided, decide it deliberately and publish the date — the failure mode is not upgrading early or late, but upgrading unevenly.
09 Backup, Restore & Continuity
This is the domain where an administrative shortcoming converts directly into permanent loss of intellectual property. It also has the highest rate of undetected failure, because an untested backup looks exactly like a working one.
Three artefacts, captured together
A complete backup captures all three of the following, at a consistent point in time. Two out of three does not constitute a recoverable position.
File archives
The physical files on the archive server, held across a fixed set of folders. These are ordinary files on disk and can be captured by any conventional backup tool.
Missing this: metadata survives with no file content behind it.
Archive configuration
A separate settings export produced from the archive server configuration tool, containing login definitions and archive paths.
Missing this: a restore that requires manual reconstruction of settings under time pressure.
Vault databases
Every vault database plus the shared master database on the instance.
Missing this: files exist on disk with no structure, references, history or permissions.
Archive content and database content must correspond. If the database backup is taken hours after the archive backup, the restored vault will contain metadata referring to files that were not captured, and files with no metadata. Recovery from that state is possible but requires manual reconciliation — precisely the work nobody wants during an outage. Schedule both together, and use the vault's log-in blocking control to hold activity for the window where practical.
Failure-mode assessment
| Exposure | Low likelihood | Moderate likelihood | High likelihood |
|---|---|---|---|
| Severe consequence | ModerateSite loss with off-site copies held. Recoverable, but recovery time depends entirely on rehearsal. | HighArchive and database backups out of sync. Common, and discovered only during a restore. | HighBackups never test-restored. The most frequent condition, and indistinguishable from safety until tested. |
| Moderate consequence | LowSingle client workstation failure. Loss confined to work not yet checked in. | ModerateDatabase engine capacity limit reached on the entry tier. Predictable and monitorable. | HighShared library or templates outside the backup scope. Rebuild cost is measured in weeks. |
| Contained consequence | LowService pack regression. Reversible via a documented rollback position. | LowLicence server outage. Disruptive for hours, no data consequence. | ModerateConfiguration drift across workstations. Continuous low-grade cost rather than a single event. |
Practices that make the difference
- Automate what the platform allows, script what it does not. Native scheduling is a feature of the full database edition; on the free edition, database backups must be scripted deliberately. Environments that rely on a person remembering will eventually have a gap on the day it matters.
- Rehearse the restore. At least annually, restore the complete set to an isolated test system and confirm the vault opens, files retrieve and history is intact. This is the only evidence that a backup regime works.
- Separate the copy from the source. Backups on the same server protect against nothing worth planning for. Hold a copy on separate infrastructure and move a set off-site on a defined cycle.
- Include the periphery. Templates, sheet formats, libraries, macros, the administrative image and its settings file, and the licence configuration all represent accumulated work and are routinely left outside backup scope.
- Address the client cache through process. Local working copies cannot be practically backed up. The control is a check-in discipline: work in progress returns to the vault at defined points, not only at completion.
- Write the recovery procedure down. The person performing the restore may not be the person who designed the backup. Document the sequence, credentials required and expected duration, and store it somewhere that survives the outage.
10 Administrator's Quick Reference
A condensed audit list. Any item that cannot be answered confidently is a finding.
Foundation
- Named owner. A specific person holds CAD administration, with defined server-side access and an agreed interface to IT.
- Certified graphics. Every workstation runs a certified card on a certified driver version, excluded from automatic driver updates.
- Antivirus exemptions. Documented exclusions exist for CAD file types, working folders and archive locations.
- Supported platform. Operating system and database versions are within support for the release in service, with retirement dates known.
Deployment and licensing
- Current administrative image. An image exists for the release in service, addressed by UNC path with a short root path.
- Settings file in force. System options deploy from a controlled settings file, with a published list of what is locked and why.
- Licence rules configured. Idle timeout, reservation and consumption order are set deliberately rather than left at defaults.
- Usage measured. Licence logging is enabled and peak concurrency is known from data rather than estimated.
Data and standards
- Single source for shared resources. Templates, sheet formats, library and materials each have one authoritative location, referenced identically everywhere.
- Property schema defined. Custom properties use fixed internal names with controlled value lists where applicable.
- Library write access restricted. Only administrators can alter shared library content; the version strategy for mixed-release periods is decided.
- Workflow reflects the real change process. States, approvers and revision rules are documented independently of the software.
Continuity
- All three artefacts captured. Archives, archive configuration and every vault database, taken together at a consistent point.
- Off-server and off-site. Copies exist away from the source infrastructure on a defined cycle.
- Restore rehearsed. A full restore has been performed to a test system within the last twelve months, with the result recorded.
- Procedure documented. A written recovery sequence exists and is accessible without the systems it describes.
- Upgrade path planned. Sequence, compatibility constraints and rollback position are established before any upgrade window is booked.
11 Frequently Asked Questions
We have a disciplined folder structure and naming convention. Do we still need a data management system?
A folder structure records where a file is. It does not record what state that file is in, who approved it, what changed between versions, or which released revision was current when a particular batch was manufactured. Convention also depends on universal compliance, and degrades under deadline pressure — precisely when the consequences are highest.
The practical test is whether you can answer, quickly and with evidence, what revision was released on a given date and who authorised it. If that requires reconstruction from email and memory, the filing system is not performing data management.
Standalone or network licences?
Standalone suits a dedicated machine with a single regular user and no infrastructure appetite. Network suits everything else: shared workstations, shift patterns, occasional users of premium tiers, and any environment where seats exceed likely concurrent demand.
The trade is infrastructure dependency. Network licensing introduces a server that must remain available and reachable, and firewall configuration becomes a production concern. In return you gain reservation, exclusion, timeout and consumption controls that materially increase effective capacity from the same entitlement count.
Can some users stay on the previous release after the vault server is upgraded?
Not for the vault client, which must match the server year-version exactly. Once the server moves, every vault client must move before it can reconnect.
The CAD application is more flexible: a current-year vault typically integrates with the current and two preceding CAD releases, so CAD upgrades can be staged over weeks. Plan the vault client cutover as a single coordinated event and the CAD rollout as a sequence.
Should we wait for a later service pack before upgrading?
The conventional guidance to wait for the third service pack is a reasonable default for organisations with no pressing need, but it is a risk-appetite position rather than a technical rule.
Override it when a new capability addresses a live constraint, or when a platform support deadline forces the move. Delay beyond it when critical add-ins or internal automation are not yet certified. The genuine failure mode is neither early nor late adoption — it is an uneven fleet, where file format progression makes shared data inaccessible to part of the team.
Can the data management servers be virtualised?
Virtualisation is commonly used and supported within defined bounds; check the current published list of validated environments for your release. The constraints that matter in practice are storage throughput for the archive volumes and guaranteed rather than shared resource allocation for the database.
The failure pattern is a virtual machine placed on general-purpose shared storage alongside unrelated workloads. Check-in and check-out performance degrades noticeably, and the cause is difficult to isolate from inside the application.
How much of this can we defer until we are larger?
Deferrable: full data management deployment, multi-site replication, ERP integration, and formal workflow automation. These scale with organisational complexity and are reasonable to postpone.
Not deferrable: the property schema, the template set, the shared library location, and the backup regime. Each of these becomes progressively more expensive to correct as data accumulates, because the correction has to be applied retrospectively across everything already created. The first hundred parts are cheap to get right and expensive to fix.
12 References & Further Reading
Vendor documentation is the authoritative source for version-specific detail and is revised with each release. Consult the edition matching the release in service.
- SOLIDWORKS Installation and Administration GuideDassault Systèmes. Administrative image creation, the option editor, deployment methods, settings administration and upgrade procedure. Published per release.
- SOLIDWORKS PDM Installation GuideDassault Systèmes. Server topologies, archive and database server configuration, replication and vault database upgrade. Published per release.
- SOLIDWORKS PDM Administration GuideDassault Systèmes. Workflow, state and permission configuration, data card design, and library management within a vault.
- System Requirements and Hardware Certification listingsDassault Systèmes. Supported operating systems, database versions, certified graphics hardware and validated driver versions. Revised continuously — the definitive check before any hardware or upgrade decision.
- SolidPractices technical guidance seriesDassault Systèmes. Practitioner guidance on network and hardware considerations, backup and restore procedures, and shared library setup.
- Data management release notesDassault Systèmes. Per-release compatibility statements, including supported database versions, component prerequisites and end-of-support milestones.
Note on scope. This page 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.