Why 'just re-author in a new tool' isn't really a migration plan

The gap between 'import' and 'migrate'

When you ask a work instruction vendor how they handle VDS files, most of them will point you toward an export workflow. Get VEG to generate something they can read, usually a PDF or a set of images, and bring that across as a starting point for re-authoring.

That's not migration. That's starting over with your old files open in another window for reference.

The assembly hierarchy is gone. The part metadata is gone. The relationship between the 3D scene and the instruction steps is gone. What's left is a flat image and the memory of what the instruction used to mean.

What a VEG round-trip actually costs

Leaving aside the tools question for a moment, the round-trip workflow assumes you still have a working VEG environment to export from. For many teams, that's already a problem. SAP VEG is sunset. Licensing is complicated. The person who knew how to run the export workflow left two years ago.

Even when the round-trip works technically, the business case rarely survives the estimate. A 500-file VDS library, rebuilt from scratch using exported images as reference, is a year-long programme at conservative resourcing. Most manufacturers simply can't justify it while also running production.

The native parsing difference

RealFusion takes a different path entirely. We reverse-engineered the SQLite-based ZV-4 container that SAP uses for VDS files and verified our parser against real customer libraries. There's no VEG round-trip.

The full assembly hierarchy, part transforms, and metadata land on the RealNet data thread in minutes. Your authors start from a scene that already reflects the structure of your product, not a blank canvas.

That changes the economics of migration completely. Instead of a multi-year re-authoring programme, you're looking at a proof of value you can run against your own VDS files before you've committed to anything.

What Sophie needs to know

If you're the SAP solutions architect evaluating this claim, the natural question is: how does this behave inside our SAP stack?

RealFusion integrates natively with SAP ECC and S4. It speaks the same data language SAP Visual Enterprise users already know. SAP VEG remains available as an outbound-only publishing channel to HANA and BTP if you need it. You don't have to rebuild your integration layer or retire your SAP investment to move forward.

The architecture is designed to sit alongside your existing SAP workflows, not replace them.

The question worth asking vendors

When you're evaluating work instruction platforms for a post-VEG migration, ask each vendor to parse one of your actual VDS files and show you what comes across. Not a demo file. Yours.

If the answer involves exporting from VEG first, or re-authoring the scenes, or a professional services engagement before you can see any content, that tells you something about the real cost of the migration they're proposing.

We'll parse your VDS files directly. That's where we'd suggest starting.