EngineeringMechanical EngineeringOperations
SOLIDWORKS Upgrade Planning & Version Compatibility
Upgrading is straightforward technically and difficult organisationally, because one property of the data model makes it a whole-team decision. File format progression is one-way — a single engineer upgrading ahead of the group and saving into shared data renders it inaccessible to everyone else.
- Group · Operations
- Series · Administration
- Baseline · SOLIDWORKS 2026
- Reading · 18 min
01 A Coordination Problem
Annual releases arrive whether or not the organisation is ready. Upgrading is straightforward technically and difficult organisationally, because one property of the data model makes it a whole-team decision rather than an individual one.
File format progression is one-way. A file saved in a newer major version cannot be opened in an older one. A single engineer upgrading ahead of the group and saving into shared data renders that data inaccessible to everyone else — silently, and irreversibly without going back to a backup.
Everything else follows from that. The upgrade is not a rollout that can proceed at whatever pace each machine happens to allow; it is a coordinated cutover with a compatibility matrix, a sequence, and a set of rollback positions that expire as the sequence progresses.
Compatibility rules are declared per release and have changed historically. Verify the specific matrix for your source and target releases against current release notes before scheduling. Where a data management server is in scope, its own prerequisites — database engine and server operating system versions — must be confirmed independently.
02 The Compatibility Matrix
Four rules govern the sequence. Each determines what must move before what, and one of them removes the possibility of a staged rollout entirely.
| Rule | Consequence for sequencing | If violated |
|---|---|---|
| File format is one-way | Nobody may save into shared data at the new version until everyone can read it | Data inaccessible to colleagues; recoverable only from backup |
| Licence manager at or above products served | Upgrade it first — and it may be moved days or weeks early | Clients on the new release cannot draw entitlements |
| Vault client must match vault server year-version | No staged rollout of the vault client; it is a single coordinated cutover | Clients cannot connect at all after the server moves |
| Vault integrates with several CAD releases | CAD upgrades may be staged even though the vault client cannot | Integration unavailable if a CAD release falls outside the supported span |
Administrators plan a gentle staged rollout, upgrade the vault server, and discover that every engineer not yet upgraded is locked out immediately. There is no partial state and no grace period.
Plan the vault client cutover as a single event affecting everyone on the same day. The CAD application can then be staged separately over the following weeks, within the span of releases the vault supports.
Shared library versions
The shared hardware library upgrades to the new major version and becomes unusable by workstations still on the previous release. Where any mixed-version period is anticipated for the CAD application, plan separate library locations per major version with the year in the folder name, decided before the upgrade rather than during it.
03 Deciding When to Adopt
Conventional practice is to wait for the third service pack. That is a reasonable default and a risk-appetite position, not a technical rule.
Move earlier
- A new capability addresses a live constraint with a measurable cost.
- A defect affecting your work is resolved in the new release.
- A customer or partner has moved and native exchange requires it.
Move later
- Critical add-ins or internal automation are not yet certified.
- A major project is at a stage where disruption is unacceptable.
- Platform prerequisites would turn it into an infrastructure programme.
Move regardless
- An operating system or database version reaches end of support.
- Subscription terms require currency for support entitlement.
- Hardware refresh forces a platform the old release does not support.
It is uneven. A fleet where some engineers have upgraded and others have not is the condition that file format progression punishes, and it arises whenever the decision is left to individuals or allowed to drift.
Whatever is decided, publish the date and hold it. An organisation that upgrades late but together is in a far better position than one that upgrades early and partially.
Skipping releases
Moving across two or more annual releases in one step is possible and sometimes sensible, but it compounds risk: more add-in compatibility to verify, larger platform prerequisite gaps, and more accumulated behavioural change for engineers to absorb at once. Where a vault is in scope, confirm the database upgrade path supports the jump directly rather than requiring an intermediate step.
04 Pre-Upgrade Validation
The work that determines whether the upgrade window is uneventful. It happens weeks earlier, in a non-production environment.
- Platform prerequisites. Confirm operating system, database engine, connectivity driver and any embedded component versions are supported at the target release. This is the check most likely to change the plan.
- Hardware certification. Check installed graphics cards and driver versions against the certification listing for the target release. A card that has dropped off the list converts a software upgrade into a hardware programme.
- Third-party add-ins. Confirm each is certified for the target release and obtain the compatible version. This is the most common cause of a rollout being halted mid-way.
- Internal automation. Macros and any programmatic integration must be tested against the target release. Interfaces change between versions and failures are often silent rather than obvious.
- Downstream integrations. Anything reading data out — ERP connectors, reporting, document management — should be verified against data produced by the new release.
- Representative models. Open a range of real assemblies and drawings in the target release and confirm they behave. Rebuild behaviour and drawing view generation are where regressions surface.
- Backup verified. A tested, restorable backup taken and confirmed before anything is touched.
A validation exercise that opens a few simple parts confirms the installer worked and nothing else. The regressions that matter appear in complex assemblies, in drawings with many views and annotations, and in the automation nobody thought to mention.
Run the validation against genuine current deliverables, and have the pilot group produce real output through the normal approval route before the fleet moves.
05 The Upgrade Sequence
- Weeks beforeUpgrade the licence managerIt continues to serve current-version clients, so this can happen well in advance with no user impact. Reactivate and confirm entitlements immediately afterwards.
- Weeks beforeComplete validationPrerequisites, add-ins, automation, integrations and representative models all verified in a non-production environment.
- Days beforeBuild and configure the new imageNew administrative image in a new folder, configured, with the settings file attached. Pilot it to your own machine.
- T−0Quiesce the vaultAll users check in work and log out. Uncommitted work in a local cache is protected by no server-side backup.
- T−0Take and verify the full backup setArchives, archive server configuration and every vault database including the master, captured together. This is the rollback position for everything that follows.
- T−0Stop the archive servicePrevents further client activity and holds archive content static for the duration.
- T−0Upgrade server softwareArchive 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 entitlement activation at the new version and log in to the administration tool before touching any client.
- T+0Upgrade the first client and shared librariesOne client, then the shared hardware library — once, deliberately, with the backup already verified.
- T+0Vault client cutoverAll vault clients on the same day. No partial state is possible.
- T+daysStage the CAD rolloutBy team, with gaps, within the span of releases the vault supports. Verify configuration consistency as you go.
- T+weeksClose outConfirm every seat is at the intended version and configuration, then retire the previous image and library.
06 Rollback Positions & When They Expire
Rollback is available at some stages and not others. Knowing where the point of no return sits is what allows a decision to halt to be made confidently.
| Stage | Rollback available | Mechanism |
|---|---|---|
| Licence manager upgraded | Not needed | Continues to serve earlier versions; no impact to reverse |
| Server software upgraded, databases not yet | Yes, with effort | Reinstall previous server version; databases untouched |
| Vault databases upgraded | Restore only | Full restore of the backup set. The schema change is not reversible in place |
| Shared library upgraded | Restore only | Restore the library backup taken beforehand |
| Clients upgraded, no files saved | Yes | Reinstall the previous client from the retained image |
| Files saved at the new version | Effectively none | Only a full restore, losing all work since the backup |
Up until an engineer saves a file at the new version, most of the sequence can be reversed with a restore. After that, reversing means losing that work — and in a vault, that work is now the current version of something.
This is why the pilot must precede the fleet, and why the decision to proceed past the database upgrade should be taken deliberately with the server-side verification complete, rather than as momentum.
07 Post-Upgrade Verification & Communication
Verification
- Version consistency. Every seat at the intended release and service pack. A mixed estate is the failure the whole exercise exists to avoid.
- Configuration intact. File locations, template paths, library path and locked settings all resolving as intended on a sample of machines.
- Library source correct. A hardware component inserted on a sample machine comes from the shared library, not a local copy created during the upgrade.
- Historical data opens. Assemblies created before the upgrade open with all references resolving.
- Automation runs. Macros and integrations execute against the new release in production, not only in test.
- Vault operations complete. Check-out, check-in, transitions, notifications and any conditions all functioning.
Communication
Engineers need three things stated plainly and in advance: the date, what changes for them, and where to get help. Add one more that is specific to this domain — a clear instruction not to save shared data at the new version until the cutover is complete, with the reason given. An engineer who understands why format progression matters will comply; one told simply not to will eventually forget.
At close-out, capture the confirmed configuration — release, service pack, file locations, library path, add-ins per group, prerequisite versions — into the standards register. It becomes the baseline for next year's upgrade and the first comparison point when a machine starts behaving unlike its peers.
08 Upgrade Checklist
- Compatibility matrix confirmed. Source and target release rules verified against current release notes, not assumed from a previous upgrade.
- Platform prerequisites checked. Operating system, database engine and driver versions all supported at the target release.
- Hardware certification checked. Installed graphics cards and driver versions on the certification listing for the target release.
- Add-ins and automation validated. Every third-party add-in and internal macro tested in a non-production environment.
- Representative models tested. Real assemblies and drawings, not test files, through the normal approval route.
- Licence manager upgraded early. Days or weeks ahead, reactivated and verified.
- New image built and piloted. Configured, in a new folder named for the release, installed to the administrator's machine first.
- Full backup taken and verified. Archives, archive settings and every database including the master, captured together, restore-tested if practical.
- Library backup taken separately. Before the shared hardware library is upgraded.
- Vault client cutover planned as one event. Every vault client on the same day; no staged approach attempted.
- Mixed-version library strategy decided. Separate locations per major version where any CAD staging period is planned.
- Rollback points understood. The team knows where reversal ceases to be available and who decides to proceed past it.
- Save instruction communicated. Engineers told not to save shared data at the new version until cutover completes, with the reason.
- Post-upgrade verification completed. Version consistency, configuration, library source, historical data and automation all confirmed.
- Verified state recorded. Configuration baseline captured in the standards register at close-out.
09 Frequently Asked Questions
Can we let engineers upgrade when convenient?
Not where data is shared. File format progression means an engineer who upgrades early and saves into shared work makes it unreadable to everyone still on the previous release. The damage is not visible at the time and is only reversible from backup.
Where a vault is in place the question is moot for the vault client, which cannot be staged at all. Where no vault exists, the discipline has to come from policy and explanation — and explanation works better, because engineers who understand the mechanism will not do it.
We are three releases behind. Should we jump straight to current?
Often yes, but validate the path first. Confirm the database upgrade utility supports the jump directly rather than requiring an intermediate step, and check whether any platform prerequisite has changed more than once across the span.
The compounding risk is add-in and automation compatibility plus the volume of behavioural change engineers absorb at once. Allow a longer validation phase and a longer stabilisation period than a single-release move would need, and expect the pilot to surface more than usual.
What if something fails part-way through the server upgrade?
Stop rather than pressing on. Where the failure occurs before the vault databases are upgraded, the previous server software can be reinstalled against untouched databases. After the database upgrade, the only reversal is a full restore of the backup set — which is why that backup must be verified before the sequence begins rather than merely taken.
Diagnose before resuming. Resuming a partially failed upgrade without understanding the cause typically produces a state that is neither the old version nor the new one, and that is considerably harder to recover from than a clean restore.
How much downtime should we plan for?
The server-side sequence — backup, server software, database upgrade, verification — is typically a few hours for a modest vault, longer where archive volume is large or where the backup itself takes substantial time. A weekend window is comfortable for most environments and allows for a problem without pressure.
Client rollout is the longer tail but need not be downtime: the vault client cutover is quick per machine, and the CAD rollout can be staged across working days. Plan the server window generously and the client rollout gradually, rather than compressing both into one event.
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.