Why so many CADs? And can I switch between them?
I am often asked, especially by people who are new to the CAD world, what the differences are between all of the CAD tools on the market. What’s the best? And what happens if I don’t like the product I started with — can I switch?
There are no easy answers –to any of this– because it’s so dependent on the use case. You wouldn’t use a BIM (Building Information Modeling) product to design a mechanical assembly — though you could, since both model solids and surfaces and their relationships to one another. But it wouldn’t be ideal and you’d spend a lot of energy to make it work, that you could otherwise apply to innovative designs. Specialist offerings evolved to take out some of that friction and to tailor the product for specific use cases.
I recently took a trip down memory lane, back to when I first saw a CAD product in 1982. It was called Autokon, and helped the shipyard lofting department figure out how to flatten the complex curvatures of hull plates and arrange them on a flat steel plate for cutting. Back then CAD came on a dedicated computer with a teeny little monitor, a wired pen, and a small electronic drafting board … and it was awesome. I was hooked.
Autokon was a one-trick pony. All it could do was lofting, but that was the norm back then. Computers were nowhere near as powerful as they are now, the input device choices were limited, and the graphics were awful. Simpler was better for many reasons.
Even today, CAD products are targeted to meet specific end-industry requirements, the training and expertise of likely users in those industries, the types of systems that CAD output has to feed into, and so on. Libraries of starter parts are industry-specific, drawing/output standards may be, too. While you can do more or less anything with any CAD product, that may not be the most efficient way to go. As you explore CAD choices, think about functionality, cost, training, and what your project partners use. It’s a decision you’ll likely live with for a while.
But it doesn’t have to be permanent. You might have very good reasons for wanting to change, and need to consider whether soldiering on with what you have is better or worse than the cost of switching. And there is a cost. Always. Moving from one CAD product to another might be easy or … it might not. I wrote a case study about that a while ago for Siemens where I created a framework you can use to think about these things, from part conversion to training costs. I just updated it — take a look here (you do need to register).
Discover more from Schnitger Corporation
Subscribe to get the latest posts sent to your email.
Hello Monica,
Thank you for writing up this white paper.
The paper touches a few important key points to keep in mind when your CAD vendor decides to switch the underlying kernel. 
Let me offer some perspective here. In my¬†opinion, the costs of the Option 2 (“Same kernel, different CAD”) in the table seem to be significantly underestimated. Probably it is currently given in assumption that the CAD system does not add anything substantial on top of kernel’s data (i.e. if data of a CAD system A on top of kernel X has the same representation as data from a CAD system B on the same kernel X). Although geometry of each individual part is the same (as it’s essentially kernel X’s) there is a significant stack of proprietary CAD system’s data on top of it (such as feature tree, meta-data, PMI, etc).¬†
Thus, the user has to pay much greater migration costs than just retraining. Migration through the kernel’s file format will only transmit final geometrical representation (‘dumb B-Rep’ as sometimes called). Everything else will be lost. So if that ‘everything’ must be preserved then that option 2 can incur significantly higher costs than option 1 (“Same CAD tool, different kernel”).
In the option1, the CAD vendor realizes that he has the obligation to migrate his users and he will be investing heavily to¬†ease that migration pain. In the option 2, the user is at mercy of the system B’s data importer of the system A format. Unless systems A and B are of the same vendor, or there is good cooperation between distinct vendors (which is probably rather a rare case) things can be rather tough. In the option 1, the CAD vendor has control over its proprietary data and his new kernel’s vendor’s support to migrate geometrical data.
Just my two cents and opinion, which hopefully could be helpful.
(Although I have been following your posts for quite some time, this is my first comment here. Just some background of mine – I have been into CAD data exchange since 1997 (except a few years tenure in Intel) and started CAD Exchanger in 2009. In late 1990-es my team at Matra Datavision was developing converters from Euclid3 to CATIA V4 and V5, which is option 3 in your table, to migrate MDTV’s¬†customers. CAD data exchange pains is something¬†I have been dealing with through my professional life ;-) ).
Thank you again and best wishes,
Roman Lygin
Excellent perspective, Roman – thank you!