What Happens to Your VDS Files When SAP Visual Enterprise Goes Dark

If your team has spent years building visual work instructions in SAP Visual Enterprise, you already know the value sitting inside those VDS files. Animated assembly sequences, annotated 3D models, step-by-step procedures your operators actually follow. That library didn't come cheap, and it didn't come fast.

So what happens to it when the authoring toolchain goes dark?

This isn't a distant concern. According to SAP's published maintenance schedules, various SAP ECC releases are moving through end-of-mainstream-maintenance milestones, with extended maintenance options available through 2030 depending on contract — and the broader SAP Visual Enterprise authoring ecosystem has its own separate product lifecycle that organisations should verify against SAP's Product Availability Matrix for their specific versions. The conversation is happening right now in engineering offices across aerospace, industrial equipment, and automotive supply.

Let's be specific about what 'going dark' actually means for your VDS library, and what your real options are.

The moment authoring freezes, the BOM doesn't

Here's the problem that most sunset timelines don't mention: your BOMs keep moving whether your authoring tool is supported or not.

Engineering releases an ECO. A component gets superseded. A variant gets added to the order. If your authoring environment is frozen, none of that reaches the instructions. The VDS file says one thing. The bench looks like another.

Operators fill the gap. Sometimes they ask a senior technician. Sometimes they improvise. Sometimes they build to the wrong revision and no one knows until the product fails inspection.

This isn't a hypothetical failure mode. It's what happens when instruction drift goes unmanaged, and it's exactly what freezing your authoring environment guarantees will start accumulating.

The floor is always one BOM change ahead of a frozen library.

What 'we'll just freeze and keep using them' actually costs

Freezing is the path of least resistance, and it's the one most teams take first. The VDS files still open. The viewer still works. Leadership isn't asking questions. So you hold.

The cost of holding is invisible until it isn't. Rework hours that don't get coded to instruction mismatch. A new operator who builds slowly because the step they're following doesn't match the assembly in front of them. A supervisor who spends two hours reconciling a variant discrepancy that should have been caught upstream.

None of that shows up in the 'cost of SAP Visual Enterprise sunset' calculation. But it accumulates every week, on every line, across every variant your library doesn't cover accurately anymore.

Freezing isn't free. It's deferred cost with compounding interest.

The re-authoring number is almost always wrong

Eventually someone proposes a re-author programme. The estimate goes to leadership and it looks manageable: tool licences, a project manager, maybe a dedicated author or two.

What that estimate almost never includes is subject matter expert time.

Your VDS library contains assembly knowledge that lives nowhere else. The sequence logic, the torque callouts, the 'do this before that or the housing cracks' details that came from your most experienced engineers. Re-authoring doesn't just mean rebuilding the steps. It means extracting that knowledge again, from the people who built the product, into a format a tool can capture.

For a complex aerospace or industrial equipment library, in our experience this can mean hundreds of hours of SME interviews, review cycles, and sign-off workflows before a single instruction goes back to the floor — though the actual figure will vary significantly depending on library size and complexity. The authoring tool cost is a fraction of it.

Most re-author programmes get approved on the tool number, then grind to a halt when the SME availability doesn't materialise. They're not a bad idea. They're just habitually under-costed.

What most manufacturers don't know about their own VDS files

Here's something technical that changes the conversation entirely.

A VDS file is not a proprietary black box in the way most people assume. Based on our engineering team's analysis of the format, VDS files use a SQLite-based container structure. SQLite is a widely used embedded database engine with a well-documented, open format. In our analysis, the geometry, assembly hierarchy, metadata, and transforms inside a VDS file are stored as structured data rather than an opaque binary blob — though SAP has not publicly documented the VDS internal format in full, and this characterisation reflects our own reverse-engineering work rather than a published specification.

This matters because it means a parser, not a re-author, is technically viable.

If a tool can read the SQLite container, walk the assembly hierarchy, and reconstruct the instruction data, the content in your VDS library doesn't have to be recreated. It can be imported. The knowledge is already encoded. It just needs a reader that knows what to look for.

This is not how most work instruction vendors approach VDS migration. The standard advice is to export through Visual Enterprise Generator, do a VEG round-trip, and land in whatever format the new tool accepts. That round-trip introduces fidelity loss, requires a working VEG installation, and doesn't solve the BOM disconnection problem anyway.

Native parsing sidesteps all of it. The file you have becomes the starting point, not something you discard.

The three options, honestly costed

Most teams model two options when SAP Visual Enterprise sunset becomes real. There's a third one that is often overlooked in initial planning.

Option 1: Freeze the library, keep the viewer running.
Low immediate cost. High accumulated risk. Instruction drift starts the moment the first BOM change doesn't propagate. The library becomes less accurate over time by design, and the floor absorbs the difference in rework, errors, and supervisor overhead.

Option 2: Re-author from scratch.
High cost, long timeline, significant SME burden. For a large library, this is a multi-year programme with genuine risk of never completing. The business case is hard to close honestly once you include the full SME component. Some organisations in aerospace and industrial equipment have started this path and remained mid-programme well beyond initial timelines — a risk worth factoring into planning even if individual outcomes will vary.

Option 3: Native migration to a platform that reads VDS directly.
If the new platform can parse the VDS container natively, you may not need to re-author from scratch. You're importing what you have, reconnecting it to the live BOM thread, and letting the instructions stay current as things change. The time to value can be significantly shorter than a full re-author programme, though actual timelines will depend on library size, complexity, and integration requirements. Other vendors in the work instruction space — including PTC Creo Illustrate, Cortona3D, and Theorem Solutions — also offer VDS-related migration or conversion capabilities, and the options available to any given organisation will depend on their specific technical environment.

The cost and risk profiles are very different. The honest version of this analysis includes all three.

What happens to your VDS files if you do nothing

The files don't disappear. The viewer probably keeps opening them. But the library starts aging from the moment authoring stops.

Every BOM change that doesn't reach the instruction is a gap. Every variant that gets added without a corresponding instruction update is a gap. Every new operator who follows a step that no longer matches the assembly is a gap.

Over time, the library you spent years building becomes a liability instead of an asset. Not because it was poorly made, but because it was never given a path forward.

That's the actual cost of 'going dark'. Not the licence fees. The drift.

There is a path forward that doesn't start with a blank page

The following section is authored by Virtualspace and describes their own product.

Virtualspace RealFusion was built specifically for this situation. It reads VDS and VZXML files natively, without a VEG round-trip, parsing the VDS SQLite container directly. The approach has been validated against a number of customer libraries; the assembly hierarchy, transforms, and metadata have come across intact in those deployments — though results will depend on file versions and library complexity.

From there, the instructions reconnect to the live BOM thread, carrying the Engineering BOM through to the Manufacturing BOM and down to the Order BOM with variant configuration at the order level. Where RealFusion is integrated with upstream PLM and ERP systems, changes can propagate downstream — though this depends on the customer's specific integration configuration and BOM governance processes.

The library you already have becomes the starting point. Not something you throw away.

If you're working through the SAP Visual Enterprise sunset conversation right now, or trying to cost the options honestly before leadership asks, we'd like to talk.

See how RealFusion handles VDS migration at virtualspace.io

Virtualspace RealFusion is the Smart Production Management platform that connects PDM through PLM, MES, and visual work instructions on a single data thread.