Adam Migrations: moving CAD feature history between systems

Picture a supplier handoff at 4:30 on Friday. The model opens on the shared screen, but the receiving designer sees an imported solid where the source model had an editable feature tree. Their coffee goes cold while they trace which sketch controls the mounting tab. The geometry crossed the gap; the history that explains it did not.

Adam's Migrations tool is aimed at that handoff. Adam says it rebuilds a model's parametric history in another CAD system, checks each rebuilt step against the source geometry, and transfers model metadata. That's a bigger promise than moving a shape from one file to another, and it needs a harder review than a clean-looking demo.

DEVELOP3D published its launch report on 25 September 2026. Adam's Migrations page is undated, so 25 September is the report's publication date, not a separately verified release date. This is also a different job from the prompt-to-model generation covered in our AdamCAD review.

What Migrations says it does#

Adam's Migrations page describes a way to rebuild parametric feature history in a new CAD system. It says the tool verifies geometry at each step and transfers metadata. DEVELOP3D's report says the tool works feature by feature and includes product manufacturing information, or PMI, in the migration. Those are vendor claims reported by the publication, not results from an independent conversion test.

Adam's homepage describes its product as an AI workspace for hardware teams. The graphic below is a brand image, not a Migrations interface.

Adam's brand graphic. Source: Adam.

Adam's own Migrations animation. It shows the product pitch, not an independent geometry check. Source: Adam Migrations.

That distinction matters. If the receiving team only needs a reference solid, a neutral export can be enough. If the next designer needs to change dimensions and keep working through the model's history, the feature tree is part of the handoff. Our guide to text-to-CAD file formats covers the neighboring export problem; Migrations is trying to carry the authoring sequence across systems.

The system list needs a finer grid#

DEVELOP3D's report lists SOLIDWORKS, CATIA, Creo, Onshape, Autodesk Fusion, Inventor, and Siemens NX as systems Migrations works with. Adam's Migrations page, checked 27 September 2026, names the same seven systems and asks teams to review their source and destination with a representative model. That is useful context. It is not a version matrix or proof that every source-to-destination pair is ready.

The public Migrations page does not give a source-to-destination matrix, CAD version numbers, or a geometric tolerance. Its FAQ says Adam will confirm how the fields a team needs map to the destination. DEVELOP3D mentions PMI, but neither source lists which annotation types are included. A sales call can clarify those gaps; a launch animation cannot.

Adam's Migrations page invites teams to book a demo and bring a representative model; it offers no self-serve upload. Adam's pricing page, checked 27 September 2026, lists Personal, Teams, and Enterprise plans without prices. Before sending production data, ask where the geometry is processed, how long source files and results are retained, and how a team can remove them after evaluation.

What I would check before moving a library#

Adam asks teams to review a representative model. I would use that session to settle these points before touching the full library:

• Confirm the source and destination CAD versions, the direction of travel, and whether the exact pair is supported. A list of product names does not confirm every combination.
• Pick a representative model that includes the features and metadata the team depends on. A simple plate is a weak qualification part if the library is full of patterns, blends, derived configurations, sheet metal, assemblies, external references, or customer-specific properties.
• Ask for the geometric comparison tolerance and a report that shows failed, substituted, or skipped features. Make a small upstream edit in the destination model and check that downstream geometry rebuilds in a useful way. A close final shape can still leave a brittle tree behind.
• Ask which PMI items, dimensions, tolerances, materials, part numbers, and custom fields map into the destination system. “Metadata transfers” is too broad to sign off a manufacturing handoff.
• Before sending production data, ask where the geometry is processed, how long source files and results are retained, and how the team can remove them after evaluation.

Treat the sample as the real demo#

Keeping feature history across CAD systems would solve a problem designers still pay for in manual rebuilds and cautious supplier handoffs. Adam is pointing at the right part of the problem. The public material I checked leaves the qualification details open, so the representative-model review is the part I would take seriously.

Until the supported pairs, versions, tolerances, and failure reports are clear, I would treat Migrations as a promising tool to qualify, not a reason to retire a migration workflow that already survives production revisions. A feature tree earns trust on the next change request, when somebody edits the model under deadline and the supplier is waiting.