AMDT (AUVESY-MDT): The Company, octoplant and octovision

AMDT (AUVESY-MDT) makes the software that keeps a record of what is inside every PLC, robot, drive and HMI in a plant, and the means to put it back when something goes wrong. Its main product, octoplant, backs up device programs and configurations on a schedule, versions them, compares what is running against what was approved, and restores a known-good copy after a failure. Its newer product, octovision, turns that same data into a multi-site view of assets, firmware and known vulnerabilities.

Why that matters to a plant is simple. When a controller dies, gets wiped or gets changed by someone who did not write it down, the speed of recovery depends on one question: is there a recent, trustworthy copy of what was running? Most plants find out the answer during the outage. Tools in this category exist to make sure the answer is known before then.

This page covers AMDT the company, its history, where its two products sit in a plant, the end of life of its older products, and the facts a buyer should know. The eleven system pages below it go into each product, capability and comparison in depth.

AMDT, the company in one paragraph

AMDT is a German-American industrial software company headquartered in Landau in der Pfalz, Germany, with offices in Alpharetta (Georgia), Nanjing and Tokyo (About AMDT). It was formed in January 2022 by merging two older companies in the same niche: AUVESY, the maker of versiondog, and MDT Software, the maker of AutoSave. It now sells one platform, octoplant, which replaces both, plus octovision on top of it. AMDT describes its field as “production resilience and OT security for industrial manufacturers,” and it states that more than 3,200 industrial organisations use its software (amdt.com). It is a specialist: it does not make controllers, HMIs or networks, and it supports many vendors’ devices rather than one.

AMDT history: from MDT Software and AUVESY to octovision

The story is two companies solving the same plant problem on two continents, for decades, and then becoming one.

1987. MDT Software is founded in the United States and later settles in Alpharetta, Georgia. Its product, AutoSave, becomes a common change management tool in North American plants, particularly on Rockwell and process systems. AMDT still dates its own history from this year: “Advancing industrial resilience since 1987” (About AMDT).

2007. AUVESY is founded in Landau, Germany (POELLATH). Its product, versiondog, grows strongest in European automotive and discrete manufacturing, where plants run many vendors’ controllers and robots side by side.

2017. Brockhaus Private Equity buys AUVESY from its founders (POELLATH, above). AUVESY keeps growing as a European vendor with a broad device list.

April 2021. Hg agrees to take a majority stake in AUVESY, which at the time has about 90 staff and more than 700 customers in 45 countries (Latham & Watkins).

August 2021. Hg invests in MDT Software, which reports more than 400 customers and more than one million devices under management in 44 countries (Hg).

11 January 2022. The two companies merge as AUVESY-MDT, announced as serving more than 2,500 manufacturers in over 50 countries (press release). The logic is plain: two products doing the same job, one strong in Europe and one strong in North America.

2022. octoplant launches as the successor to both versiondog and AutoSave (Novotek). This is the moment the end of life of the two older products begins, even though the formal phases come later.

2023 to 2024. Leadership consolidates. Stefan Jesse, now Group CEO, shares the chief executive role with Dr. Tim Weckerle for a period. In May 2024, octoplant 101.3 makes TIA Portal compare and backup substantially faster and adds TIA Portal V19 support.

Around October 2024. The company rebrands from AUVESY-MDT to AMDT, with the tagline “We bring resilience to your production” (Novotek). The old auvesy-mdt.com domain now redirects to amdt.com.

August 2025. octoplant 105 ships: fixes from an Outpost24 penetration test, wider device support, a standardised asset inventory format, a REST export API and the first browser-based interface (Novotek UK).

6 October 2025. AMDT announces octovision, an enterprise visibility and vulnerability layer built on octoplant data (AMDT). This is the company’s first product that is not a direct descendant of versiondog or AutoSave. A month later it announces a strategic partnership with OpenSG in South Korea (AMDT).

7 April 2026. The octoplant Spring Release 107 adds a Project Integrator Tool for faster onboarding, Asset Lifecycle Management, an octovision Export API for CMDB and ticketing systems, and the AI chat assistant AMDT calls Companion (AMDT). A week later AMDT holds its first partner awards in Warsaw. The summer brings an octovision release focused on criticality, coverage and false-positive handling (octoplant.com).

September 2026. Dr. Christopher Neumann joins as Chief Product Officer (AMDT). As of October 2026, the executive board is Stefan Jesse (Group CEO), Alexander Fischer (CFO), Oliver Yates (CRO) and Dr. Neumann (CPO), with Dr. Diego Rapela as CTO in the wider leadership team (About AMDT).

The pattern is worth naming. For most of its history this was a backup and versioning business. Since 2025 it has been moving up the stack, from “what is in the controller” toward “what is the risk across all our sites,” and toward IT systems such as CMDBs and ticketing. That shift changes who in a plant cares about the product: no longer only the controls engineer, but also the OT security lead and the CIO.

The AMDT portfolio on the ISA-95 stack

AMDT describes its products as “two layers, one source of truth.” octoplant is the operational control layer: it talks to devices and engineering software, holds the versions and does the restores. octovision is the intelligence layer: it reads what octoplant already knows and presents it across sites, with vulnerability and lifecycle context.

octoplant and octovision at a glance, as of October 2026:

	octoplant	octovision
Job	Back up, version, compare and restore device programs and configurations	Show assets, firmware, CVEs and backup status across sites
Data source	The devices and engineering projects themselves, collected by scheduled jobs	octoplant’s data, “without network scanning or agents,” plus CSV imports
Main users	Controls engineers, maintenance, quality and validation	OT security leads, plant and engineering managers, IT teams
Deployment	On-premises server, clients and agents	On-premises; cloud and SaaS described as roadmap
Licensing	Core, Plus and Premium editions; per device, one licence per campus; no public prices	Not published; requires octoplant underneath
Learn more	octoplant	octovision

The design choice that defines both products is that they start from the device’s own content, not from network traffic. octoplant connects to a controller or reads an engineering project and pulls the actual program, configuration or parameter set. octovision then builds its inventory “without network scanning or agents,” using that data (AMDT). That is a different approach from network-based OT security tools such as Claroty or Nozomi, which listen to traffic to discover what exists. The two approaches answer different questions, and the alternatives page sets out where they overlap.

What octoplant reads spans the plant: PLCs and their engineering software, HMI and SCADA projects, robots, CNC machines, drives, switches, routers, firewalls, industrial PCs, and plain documents and files. AMDT states “180+ industrial device types natively supported” (amdt.com). The official device matrix sits behind the myAMDT login, so any list on a public page, ours included, is a set of examples. The supported devices page covers what is publicly known and how to verify it.

Where it runs matters as much as what it reads. Both products are, as of October 2026, mainly installed on the plant’s own infrastructure. octoplant runs as a repository server with clients and agents that reach devices in separated network segments; it uses a PostgreSQL database (version 17 as of release 105) and gained its first browser-based interface in that release (Novotek UK). octovision is on-premises today, with cloud and SaaS deployment described as roadmap, and AMDT’s two websites do not describe that roadmap in the same way. For a plant, this means three practical things:

1. The server is plant infrastructure. It needs a home on the OT network, a patching owner and its own backup, like any historian or SCADA server.
2. Network design decides coverage. Every device the server or an agent cannot reach is a device without a backup, so segmentation and firewall rules have to be planned with the tool.
3. Air-gapped and regulated sites are a natural fit, because nothing has to leave the site. Multi-site groups that want one cloud console should check the current octovision roadmap before assuming it.

Product lifecycle: versiondog and AutoSave end of life

For many plants, the most pressing AMDT question is not about octoplant at all. It is about the older product still running on a server in the corner: versiondog in many European plants, AutoSave in many North American ones. Both are being retired in favour of octoplant, on a phased schedule that AMDT’s partners have published (becolve, Novotek).

Phase	Period	What the vendor provides	What it means for a plant
Renewals only	2023–2024	No new licences. Existing maintenance can be renewed. Full support to the end of 2024	You can keep running, but you cannot add devices under a new licence. Start budgeting the migration
Limited support	2025	Critical security fixes and level 1–2 support only. No new device or editor support	Each new controller firmware or engineering software version you install may fall outside what the tool can read. Coverage starts to erode quietly
Consulting only	To end of 2026	Consulting only, no product fixes	The tool still runs, but nothing about it will improve. A failure of the server or database becomes your problem alone
After 2026	2027 onward	No support phase published	Treat it as unsupported software holding your recovery copies. Migration is overdue

One variant has its own end of life: AutoSave for System Platform (the AVEVA integration) is reported in the AVEVA Community to have reached end of life on 31 December 2025. That is a community report rather than an AMDT notice, so confirm it with AMDT and treat the variant as already unsupported.

The trap is that nothing visibly breaks. An AutoSave or versiondog server keeps running jobs after support ends. What changes is underneath: a plant upgrades a line to a newer TIA Portal or Studio 5000 version, the legacy tool cannot read the new project format, and the backup job for that controller quietly fails or stores something stale. Nobody notices until the day the copy is needed. The versiondog and AutoSave page covers what to check, and the migration to octoplant page covers how the move works.

octoplant itself follows a release cadence rather than a published lifecycle model. AMDT publishes no fixed calendar; the publicly announced releases are 101.3 (May 2024), 105 (August 2025) and Spring Release 107 (April 2026), and each added device and editor support. For a plant, the practical rule is to keep octoplant within a release or two of current, because device support for new firmware arrives through those releases.

AMDT company facts

Volatile facts are as of October 2026. Scale figures are AMDT’s own and vary between its two websites, so each is attributed.

Topic	Detail	Source
Legal heritage	AUVESY GmbH (Landau, now “AMDT Europe”) and MDT Software, Inc. (Alpharetta, now “AMDT Americas”)	About AMDT
Offices	Landau in der Pfalz (HQ), Alpharetta, Nanjing, Tokyo	About AMDT
Executive board	Stefan Jesse (Group CEO), Alexander Fischer (CFO), Oliver Yates (CRO), Dr. Christopher Neumann (CPO)	About AMDT
Wider leadership	Dr. Diego Rapela (CTO), David Petrikat (Strategy and Communication), Tim Völpel (CIO), Alexander Seibel (VP Global Channels)	About AMDT
Customers	AMDT states more than 3,200 customers; octoplant.com states more than 3,000	amdt.com, octoplant.com
Devices	octoplant.com states more than 1,000,000 devices rely on octoplant	octoplant.com
Coverage claims	“180+ industrial device types” (amdt.com); “160+ of the most common OT and IT vendors” (octoplant.com)	amdt.com, octoplant.com
Partners	AMDT states more than 100 channel partners in Preferred, Gold and Silver levels; its public directory listed 69 entries in October 2026	Partner Network, Where to Buy, our partner page
Headcount	LinkedIn places the company in the 201–500 employee band	LinkedIn
Industries	Automotive, Energy and Utilities, Food and Beverage, Machine and Plant Engineering, Manufacturing, Pharma	amdt.com
Public case studies	Bosch (a global backup service built on octoplant), thyssenkrupp Presta (24 plants), Siemens Energy in Trondheim	Bosch, thyssenkrupp Presta, Siemens Energy
Certifications	ISO/IEC 27001:2022, ISO 9001:2015, TISAX. A vulnerability-report form is published	Trust Center
Not found publicly	IEC 62443-4-1 or 4-2 product certification, SOC 2, a public SBOM or a PSIRT page	Trust Center
Pricing	Three editions (Core, Plus, Premium); no prices published	octoplant pricing

Two of these rows deserve a second look from a buyer. The case studies are useful because they are specific: thyssenkrupp Presta reports cutting line restoration “from several hours to minutes” across its plants (AMDT), and Bosch built an internal service, “B4M, Backup for Manufacturing,” on octoplant for its global locations. The certifications cover the company’s own information security and quality management, which matters to a supplier review. They are not a product security certification. A site working toward IEC 62443 should ask AMDT directly for its secure development evidence, as the compliance page explains.

The eleven AMDT system pages

Most asked

The four questions that bring most readers to AMDT, answered directly:

• octoplant editions and licensing: what Core, Plus and Premium include, how per-device licensing works, and why there is no public price
• Moving from versiondog or AutoSave to octoplant: what migrates, what does not, and a checklist for the move
• octoplant vs Copia: an approved-version model against a Git-native one, and which plants each fits
• octovision vulnerability management: CVE matching from exact firmware versions, criticality and false positives

What AMDT means for a plant

Buying a tool in this category is easy. Running it well for ten years is the real decision. In our view, these are the operating consequences a plant should weigh, whether it is adopting octoplant, migrating from a legacy product or deciding to do nothing.

Someone has to own it. octoplant sits between controls engineering, maintenance, IT and OT security, and in many plants none of those groups believes it is theirs. The server needs patching, the database needs backing up, and the jobs need someone who reads the failure report each morning. A backup tool with nobody reading its alerts is a false sense of security. Name an owner before the purchase order, and write the morning check into a role, not a person’s good intentions.

It changes how maintenance makes changes. Under a check-out and check-in model, the technician who fixes a timer preset at two in the morning is expected to work from the approved version and record the change afterwards. Illustrative scenario: a night-shift technician edits a sequence online to clear a jam, the line runs, and nobody tells day shift. With scheduled change detection, the next morning’s compare flags the difference against the approved version and shows exactly what moved. Without it, that edit surfaces months later as an unexplained behaviour after someone downloads an older program. The tool makes the change visible. Making it acceptable is a procedure the plant has to write.

It shortens recovery, if the restore has been tested. The value of a backup is decided on the worst day: a controller replaced after a fault, an HMI rebuilt after a disk failure, a line recovered after ransomware reaches the engineering workstations. A known-good, recent copy of each program is the difference between hours and days of downtime. A backup that has never been restored is a hypothesis. Plants should schedule restore tests the same way they schedule fire drills, starting with the assets that would stop the most production.

It gives security a view it does not otherwise have. Network monitoring shows which devices exist and how they talk. It cannot show whether the logic inside a controller changed, or put the right program back. octoplant and octovision answer those two questions, which is why OT security leads increasingly care about a tool that used to belong only to controls engineering. If the plant is also building network visibility, an OT network assessment is the natural companion to deciding where configuration data fits.

It turns audits from a scramble into an export. Regulated plants spend real effort proving who changed what, when and why. An audit trail generated by the tool, rather than reconstructed from memory and email, changes an audit finding into a report. The tool does not make a plant compliant on its own: procedures, training and validation still sit with the site.

It surfaces the installed base you did not know you had. The first full backup run is often the first complete list of what controllers, firmware versions and engineering software a plant actually runs. That list is also the starting point for obsolescence planning. A plant systems assessment uses the same inventory to rank risk before money is committed, whichever tool the plant chooses.

Doing nothing is also a decision. A plant still on versiondog or AutoSave after 2026 is running unsupported software that holds its recovery copies. A plant with no tool at all is relying on laptops, USB sticks and the memory of whoever wrote the code. Our warehouse controls recovery case study shows how much a partial set of backups matters once something has failed (it did not involve AMDT software).