versiondog: AUVESY's Version Control Software and What Became of It

versiondog is the version control and change management software that AUVESY, a company from Landau in der Pfalz, Germany, built for industrial automation. It kept a versioned record of what was inside a plant’s PLCs, robots, HMIs and drives, across many vendors, and it let engineers see what changed between versions. Since the 2022 merger that formed AUVESY-MDT, now AMDT, versiondog has been succeeded by octoplant, and as of October 2026 it is in the last, consulting-only phase of its retirement.

This page covers where versiondog came from, what it did, the GxP edition, why its device-support releases mattered to a plant, and what carried into octoplant. The retirement schedule itself sits on the parent page, versiondog and AutoSave.

Where versiondog came from

AUVESY was founded in 2007 in Landau and described itself as a provider of “software solutions for version control and change management in automated industrial environments” (POELLATH). versiondog was its product.

2017: Brockhaus Private Equity bought AUVESY from its founders (same source).

April 2021: Hg agreed a majority stake. At that point AUVESY had about 90 staff and more than 700 customers in 45 countries (Latham & Watkins), and POELLATH reported that it managed more than five million industrial devices.

January 2022: the merger with MDT Software. Hg had invested in MDT, the maker of AutoSave, in August 2021. The two companies merged as AUVESY-MDT on 11 January 2022 (press release). The Landau business is now AMDT Europe, and Landau remains the group headquarters.

Its installed base was European at heart. A Landau company with a German private equity owner grew up selling to European plants, and that is where we would expect most versiondog estates to sit today. In our reading, much of octoplant’s European base traces back to versiondog, while much of its North American base traces back to MDT AutoSave. The 45-country footprint shows it was never only European, so treat this as a centre of gravity, not a boundary.

What versiondog did

AMDT’s partner Novotek states that octoplant “already offers all versiondog functions” (Novotek, our translation). The capability set therefore maps onto what octoplant documents today:

• A central archive of programs and configurations for each device, with every version kept
• Check-out and check-in, so an engineer edits the approved version in the native engineering tool and returns it with a comment. See check-in and check-out
• Comparison of one version against another, or of the stored version against what is running. octoplant’s version is Smart Compare
• Scheduled jobs that upload from devices and compare against the approved version, so drift is found without anyone remembering to look
• An audit trail of who changed what, and when

The plant consequence is the same as for any tool in this class. Illustrative scenario: a night-shift technician changes a timer preset to keep a filler running and does not tell anyone. The next scheduled job uploads the program, compares it with the approved version, and flags the difference by morning. The change is either approved and checked in, or reversed. Without the job, it surfaces months later as an unexplained behaviour that nobody can trace.

The versiondog GxP edition

versiondog had a GxP edition for validated plants in pharmaceuticals and life sciences, where FDA 21 CFR Part 11 and EU Annex 11 govern electronic records. In such a plant the tool that holds the record of a controller’s program is itself a computerised system that must be validated: its installation and operation qualified, its audit trail trusted, its access controlled.

What we could not confirm is whether octoplant has a direct, named GxP equivalent. The public sources do not say. What AMDT does sell, as of October 2026, is IQ/OQ services (installation and operational qualification). For a validated plant on the versiondog GxP edition, the move to any successor is a validation project, not a software update. The detail is on audit trail and 21 CFR Part 11.

Why versiondog’s device-support releases mattered

Like every tool in this class, versiondog was only as current as its last release. What mattered to a plant was what each release carried: support for new device firmware and new editor versions. A tool that cannot read the format a new editor saves in cannot back it up, compare it or restore it.

When an automation vendor released a new engineering software version, a plant using versiondog waited for a versiondog release that could read the new format before it could safely upgrade. There was always some lag between the two. From 2025 the lag became permanent, because the limited-support phase excludes new device and editor support. A versiondog plant that has upgraded an editor since then may have equipment the tool cannot properly back up or compare.

What carried into octoplant

versiondog element	In octoplant	What to check
Archive and version history	AMDT offers Migration & Expansion services for the move	That full history, not only the latest version, arrives intact
Check-out and check-in workflow	The same approved-version model	Role names and approval steps may differ
Compare	Smart Compare: graph, table or text views	Whether old versions compare cleanly against new uploads
Scheduled jobs	Jobs, unlimited under octoplant licensing	Job schedules and alert recipients after the move
Device and editor support	Added to octoplant only; AMDT states 180+ device types	Your specific devices, against AMDT’s current support matrix
GxP edition	No confirmed named equivalent; IQ/OQ services offered	Your validation scope before the change
Licences	Per device, one licence per campus, in Core, Plus and Premium editions	Your device count against the edition thresholds

Sources: octoplant pricing, amdt.com, Novotek. Device coverage claims are AMDT’s own; check the current matrix, which sits behind the myAMDT login.

Where it gets hard

History is the asset, and it is easy to lose. Years of versions record why a program looks the way it does. A migration that moves only the latest version keeps the backup and throws away the explanation. Confirm on a pilot that history arrives.

The people who set it up have moved on. Many versiondog installations were configured years ago. Job definitions, folder structures and naming conventions often live in one engineer’s head. Write them down before the migration, not during it.

Mixed estates. Since 2023, new licences have been octoplant only, so many sites run both. Two tools means two places to look during a breakdown and two sets of credentials to manage.

Unreadable versions. Equipment upgraded since 2025 may never have been properly captured. An inventory of devices and editor versions, of the kind a plant systems assessment produces, shows where the gaps are.

Read access after retirement. Even after a clean migration, an auditor or an engineer may need to open a legacy record. Decide before cutover whether the versiondog server stays up read-only, is exported, or is kept as an archived virtual machine, and name the person responsible for it.

Validated plants carry the most work. The GxP question has no public answer yet, so a validated site should budget for qualification of the successor from the start.

For the path forward, see Migration to octoplant, and compare with the North American sibling, MDT AutoSave. Back to versiondog and AutoSave or the AMDT hub.