After returning from 3DEXPERIENCE World 2026, I found myself having many variations of the same conversation I had with engineers – no one was asking how to move SolidWorks CAD to the cloud or how it will be replaced – they were asking something more practical – how to improve productivity and work with rich set of data everyone needs to handle these days. What is actually changing compared to the work engineering teams were doing for the last decade and what should we do about it?
In my recent Beyond PLM article, After 3DEXPERIENCE World 2026 — Where Is the New Center of Gravity for the SolidWorks Ecosystem, I wrote that what struck me most was what remains remarkably stable in SolidWorks. That observation resonated strongly because it reflects the reality many engineering teams live with today. Engineering teams remain productive. Suppliers understand the data. Hiring engineers is still straightforward. From a mechanical design perspective, very little feels fundamentally broken.
For many SolidWorks teams, however, the question is no longer just CAD productivity. It is how to manage software, electronics, product data, and change processes as products become more connected and engineering decisions involve more disciplines. And this is where something around SolidWorks is quietly shifting.
In this article I want to write about understanding why many SolidWorks organizations feel increasing friction when managing rich sets of information in engineering organization and beyond. Companies are trying to reduce the cost of change, communication efficiency and decision process.
SolidWorks Openness and Windows Platform
One of the reasons SolidWorks became so successful was its balance between capability and accessibility. That was the key revolutionary achievement by the SolidWorks team. It allowed engineering teams to build real products without requiring complex CAD workstations, infrastructure, and it enabled collaboration through files that could move between companies and tools.
The file-based model created openness. Suppliers could participate. Data could travel. Ecosystems formed naturally around shared formats.
That stability still matters. Engineering organizations depend on predictability. They build processes, supplier relationships, and hiring practices around tools that behave consistently over long periods of time.
But stability has an unintended consequence. When one part of the system remains stable while everything around it evolves, friction appears somewhere else.
Today, that friction rarely comes from modeling geometry. It comes from everything that happens before and after the model exists.
Products are increasingly multi-disciplinary. Mechanical, electrical, software, and supply chain realities influence decisions earlier than before. These inputs shape engineering outcomes, but they do not naturally live inside CAD files.
Traditional SolidWorks PDM systems were designed primarily to manage files and revisions. They solved an important problem – ensuring engineers worked on the correct versions of models and drawings. But modern engineering increasingly requires visibility beyond files themselves.
The CAD environment remains stable. The environment around decisions does not.
What Is Actually Changing
The industry often frames change as desktop versus cloud or traditional tools versus platforms. This is how the change was framed in CAD, PDM and PLM space for the last 10-15 years- “we are moving to the cloud”. CAD vendors did it. PDM/PLM vendors did it. However, after working with many OpenBOM customers, in practice, I can see the shift is more subtle.
Engineering decisions have become more collaborative and more continuous.
Changes rarely begin as formal revision change anymore. They start as conversations. A supplier issue appears. Cost targets shift. Manufacturing raises a concern. Electrical changes ripple into mechanical design. These discussions happen long before a change request exists.
At the same time, most organizations now operate across multiple tools. Even companies deeply committed to SolidWorks rely on ECAD/PCB systems, simulation environments, cloud collaboration tools, and software repositories. The product already spans several environments.
What is often missing is the context connecting them.
Teams compensate with meetings, spreadsheets, and personal memory. People remember why decisions were made, until they don’t. Over time, the organization keeps the files but loses the reasoning behind them.
This is where change becomes expensive. Not because engineering became harder, but because understanding previous decisions requires rediscovering context that was never captured.
Why SolidWorks PDM Alone Is No Longer Enough
SolidWorks PDM remains effective for controlling files and revisions. It is a super successful product. It ensures engineering work progresses in an organized way and protects design integrity.
But file control alone no longer represents the full scope of product data management.
Engineering decisions now involve supplier availability, cost targets, manufacturing constraints, and cross-disciplinary dependencies. Much of this information exists outside the file lifecycle (and outside of SolidWorks PDM). As a result, the BOM increasingly becomes the place where engineering, manufacturing, and supply chain realities intersect.
In many organizations, the engineering BOM (often in Excel or online spreadsheet) is the first place where this transition becomes visible. The BOM connects CAD files to parts, parts to suppliers, and decisions to outcomes. It becomes the structure through which teams understand the product as a whole.
This does not replace PDM. It extends the scope of what product data needs to represent.
From Files to Product Memory
In the Beyond PLM article, I described how the center of gravity in the SolidWorks ecosystem is gradually moving away from geometry and 3D parts/assembly creation toward information organization.
Files describe outcomes. They capture geometry, drawings, and revisions. But they rarely capture intent. They do not explain why one option was chosen over another or how external constraints shaped a decision.
Over time, companies do not lose models. They lose decisions.
When decisions disappear, engineering slows down. Teams hesitate to change designs because the consequences are unclear. The same trade-offs are analyzed repeatedly. Knowledge resets between projects.
The next productivity improvement in engineering will not come from faster modeling. It will come from preserving context as products evolve.
I increasingly think of this as product memory — the accumulation of decisions, relationships, and understanding that allows organizations to move forward without repeating the same thinking cycle. Check my article – Context Graphs: Beyond Systems Of Records
Importantly, product memory does not come from storing more data. It comes from working in a way where decisions remain connected to the product structure itself.
Where Change Actually Happens
One of the most interesting observations across SolidWorks organizations is that formal change processes are rarely where change truly happens.
Formal workflows exist to record decisions – PDM Workflow (approval). The real work happens earlier.
Engineers explore alternatives. Manufacturing evaluates impact. Procurement checks availability. Cost implications are discussed. Multiple options coexist for some time before alignment emerges.
Only after that alignment exists does a formal change get created.
Many systems were originally designed for a document-driven world where work progressed sequentially. Today, work evolves through exploration and coordination across disciplines. Teams need a place where change can be understood before it is finalized — where alternatives can exist temporarily without disrupting released definitions.
When that space exists, change becomes lighter. Fewer surprises appear at release. Decisions become easier to explain later. And the organization gradually accumulates knowledge instead of losing it.
This is where the transition from files to product memory really begins.
A Practical Path for SolidWorks Teams
Most organizations do not need dramatic transformations. Unless they have an issue managing CAD files and they are looking for cloud based PDM, the changes that matter are usually structural and incremental.
Many SolidWorks teams begin this transition by improving Digital BOM management first, because the BOM naturally connects CAD files, parts, suppliers, and changes decisions.
Successful teams tend to separate product identity from individual files so information such as suppliers, alternates, and cost considerations can evolve independently from geometry.
They maintain clear product snapshots that represent what is currently released, while allowing ongoing exploration to continue elsewhere.
They encourage cross-functional discussions earlier, before formal workflows begin, reducing late-stage change friction.
And over time, they move away from spreadsheets as the primary coordination mechanism between engineering and the rest of the company.
None of this replaces SolidWorks. It simply acknowledges that product knowledge now lives beyond CAD.
How This Shapes Our Thinking at OpenBOM
At OpenBOM, these observations have influenced how we think about the role of product data systems.
Engineering teams are not asking for more control over files. They are asking for continuity — the ability to understand how decisions evolved and how changes connect across disciplines.
This is why our recent work around modern cloud-based PDM for SolidWorks and multi-CAD environments focuses on keeping engineering workflows familiar while making product information easier to connect and understand across the organization – Getting Started with OpenBOM 2026: Managing CAD Files and Versions (PDM)
Over time, this leads naturally toward different structures for product data (engineering, manufacturing, maintenance, supply, procurement). Information becomes connected through relationships rather than stored as isolated records – parts connected to suppliers, changes connected to decisions, and decisions connected to outcomes.
When those relationships remain visible, systems begin to behave less like storage and more like organizational memory.
Only on top of that foundation do intelligent tools become truly useful. Otherwise, automation simply accelerates confusion.
Stability and Transformation Can Coexist
SolidWorks succeeded because it solved a real problem in a practical way. That foundation remains valuable.
The transformation happening now is not about replacing CAD. It is about adapting to a reality where engineering decisions are connected across disciplines and evolve over time.
The center of gravity is moving slowly – from files toward relationships, from revisions toward context, from control toward coordination and product memory.
For SolidWorks teams, the practical path forward is not disruption. It is continuity. Building structures that allow product knowledge to stay connected as tools and processes evolve.
The question is no longer which system owns the process.
The question is whether your product knowledge survives change.
Interested in how OpenBOM can help you?
REGISTER FOR FREE and talk to us.
Best, Oleg
Join our newsletter to receive a weekly portion of news, articles, and tips about OpenBOM and our community.
