Automation Change Management: Backup, Version Control and Change Control for OT

Automation change management is the practice, and the class of software, that makes sure a plant always holds a known and restorable copy of what is running inside its control systems, knows who changed it, and can tell when the running version no longer matches the approved one. It covers PLCs, HMIs, SCADA servers, robots, drives, CNC controls and the network devices between them.

Most plants already believe they have this covered. In our experience on plant assessments, the belief usually rests on a shared folder, a laptop or an integrator’s archive, and nobody has tried to restore from it. The gap only shows itself on the worst day: a failed processor, a ransomware event, an engineer who has left. This page explains what the discipline is, why operational technology needs it in a different form from IT, what it costs not to have it, which tools exist, and how to judge where your plant stands.

What automation change management covers

The category bundles five capabilities. Vendors package them differently, but a plant needs all five, whether it buys them or builds them.

Capability	The question it answers	What it changes on the plant floor
Backup	Do we have a current copy of what is running in every device?	A failed controller or robot can be reloaded in hours instead of rebuilt in days
Versioning	What did this program look like last month, and which version is approved?	Engineers can roll back a bad change and stop arguing about which file is right
Compare	What exactly differs between two versions, or between the device and the approved copy?	A night-shift edit becomes visible the next morning instead of at the next breakdown
Change control	Who may change what, with whose approval, and is there a record?	Contractors and OEMs work inside a process; audits have evidence instead of memory
Configuration-based asset inventory	Which devices, firmware and software versions do we actually run?	Vulnerability and obsolescence decisions rest on facts read from the devices

The five depend on each other. A compare is only as good as the backup it compares against. Change control without a compare is a policy nobody can enforce. An inventory built from backups is accurate only for the devices the backup reaches. That dependency is why the category exists as software at all: doing each piece by hand is possible, and keeping all five in step by hand across two hundred devices is not.

How the category grew up

Automation change management is older than most plants assume. MDT Software, founded in 1987 in Georgia, built MDT AutoSave to back up and version controller programs, and it became a familiar name in North American plants (Hg). In Germany, AUVESY was founded in 2007 in Landau and built versiondog for the same job, with a focus on mixed-vendor European plants. Rockwell, meanwhile, built FactoryTalk AssetCentre for its own estate, and other automation vendors added compare and archive functions inside their engineering tools.

For two decades the category was a niche maintenance tool. Three things changed that.

Consolidation. Hg took majority stakes in AUVESY and MDT in 2021, and the two merged as AUVESY-MDT in January 2022, later renamed AMDT. The same year it launched octoplant as the successor to both versiondog and AutoSave, and both predecessors are now being retired (Novotek). Our versiondog and AutoSave page covers what that means for plants still running either one.

Software practice arrived in OT. Git-native start-ups such as Copia Automation and Software Defined Automation brought source-control habits, cloud delivery and, more recently, AI features. At the same time the automation vendors made their own engineering tools Git-aware, so versioning an engineer’s project stopped being a separate purchase.

Security made it a board-level question. Ransomware in manufacturing, regulation such as the EU’s NIS2 directive, and insurers asking about OT backups turned “can we recover the controllers?” into a question executives ask. Vendors responded by tying change management to vulnerability and asset data: AMDT launched octovision in October 2025, and Copia now describes itself as a “first responder” for OT incident recovery (TNW).

Why OT needs it differently from IT

IT has run change management for decades, and plants with a mature IT function sometimes assume the same tools cover the shop floor. They do not, for five reasons.

The content lives inside the device. A PLC’s program, a robot’s paths and a drive’s parameters are not files on a server that a generic backup agent can copy. They are read out through a vendor’s protocol and engineering software, one family at a time. AMDT, one vendor in this market, puts the point bluntly in its own positioning: industrial recovery is not file recovery (amdt.com).

The device can be edited while it runs. Online editing is a feature of most controller platforms, and it is how breakdowns get fixed at two in the morning. It also means the authoritative version of a program is whatever is in the controller now, which may not be anything stored anywhere.

The tools age with the machine. A line commissioned in 2009 may need an engineering software release that only installs on an old operating system. A perfect backup that nobody can open is not a recovery plan. We cover this toolchain problem on the FactoryTalk AssetCentre page, and it applies to every vendor.

The plant is multi-vendor. One packaging line can hold a Rockwell controller, a Siemens safety PLC on an OEM skid, a FANUC robot, SEW drives and a Cisco or Stratix switch. Each has its own format, its own tool and its own notion of a version.

A restore is a physical act. Downloading a program to a controller changes how a machine moves. It needs the right version, a safe machine state, a qualified person and a test before production resumes. That is change management in the IT sense, but with a safety case attached.

What it costs not to have it

These four scenarios are illustrative, drawn from patterns that recur across manufacturing rather than from any single site. Each one is ordinary, and each one is expensive.

The lost program after a failure. A processor fails on a Friday night. Maintenance finds a backup on the engineering server, dated two years ago. They download it and the line starts, but a reject gate now fires late, because the timing fix made online eighteen months ago was never saved. Two shifts of scrap later, someone reconstructs the fix from memory.

The undocumented night-shift change. A technician raises a timer preset to stop a nuisance fault. It works, nobody records it, and three months later an engineer downloads an offline project for an unrelated change and silently reverts it. The nuisance fault returns, now on a different shift, and the team spends a week chasing a problem that was solved once already.

The integrator who leaves. A small integrator holds the only current copies of an OEM machine’s programs and the passwords to the safety controller. The firm closes, or the engineer who knew the machine moves on. The plant discovers it owns a machine it cannot legally or practically change. Our guide to working with system integrators covers how to write ownership of source code into the contract before this happens.

The ransomware event. Encryption reaches the SCADA servers and the engineering workstations. The controllers keep running, but nobody can see the process or change it, and the only copies of the programs were on the encrypted engineering PCs. Recovery now depends on whether anything was stored offline. Our PLC ransomware recovery page walks through the sequence.

The common cost is time. In each case the plant had the knowledge once and lost track of it. Unplanned downtime is where that loss is paid, and our article on manufacturing downtime shows how quickly the hours add up.

The tool landscape, by archetype

The market splits into a handful of archetypes. They overlap at the edges, and several vendors are moving toward each other, so treat the table as a map rather than a ranking. Facts are as of October 2026 and come from the vendors’ own pages or the press coverage linked.

Archetype	Examples	What it does best	Where it stops
Multi-vendor change management platform	AMDT octoplant (successor to versiondog and MDT AutoSave)	Broad device coverage including robots, drives and CNC; approved-version model; on-prem; audit trail	Prices and the device matrix are not public; mainly on-premises
Single-vendor change management	Rockwell FactoryTalk AssetCentre	Deep in a Rockwell estate; scheduled backup, compare, audit, disaster recovery	Third-party coverage is narrower; sits on a Windows and FactoryTalk stack
Git-native source control for PLC code	Copia Automation	Git workflows, visual diffs of ladder, function block and structured text, DeviceLink backup from devices	Cloud-first delivery; coverage centred on PLC families
Cloud “industrial DevOps” platform	Software Defined Automation (SDA)	Browser-based engineering, multi-vendor version control, automated backup, virtual PLC management	Young company; cloud dependency needs an OT security review
OT configuration and compliance platform	Industrial Defender, Octave Cyber Integrity	Configuration baselines, change detection and compliance reporting, strong in utilities and process	Built for security and compliance, less for engineering workflow
OEM-native Git in the engineering tool	TIA Portal, SIMATIC AX, FactoryTalk Design Studio, CODESYS, TwinCAT, PLCnext, Ignition 8.3	Versioning where engineers already work, often free	One vendor at a time; does not back up running devices
Network-based OT security	Claroty, Nozomi, Dragos, Armis	Passive and active device discovery, threat detection	Sees that a device exists, not the logic inside it; cannot restore it

The trend that matters for buyers: versioning on the engineering side is becoming a standard feature of every vendor’s IDE. The value that is harder to commoditise sits in four places: coverage of the whole mixed and legacy fleet, comparing what is running in the device against what was approved, a restore that has been tested, and audit evidence. Weigh the tools on those four. Our PLC version control software comparison does that tool by tool, and the AMDT alternatives page looks at the same field from one vendor’s position.

A maturity model for automation change management

Most plants sit somewhere between level 0 and level 2. The useful question is not which level is “right” but which level the plant’s risk and regulatory exposure demand.

Level	Name	What it looks like	Typical recovery after a controller loss
0	Ad hoc	Programs on laptops, USB sticks and an integrator’s server. Nobody can say which copy is current	Days, sometimes a rewrite
1	Collected	A central share exists. Uploads happen after projects and when someone remembers	A day, with uncertainty about what was lost
2	Automated	Scheduled uploads from networked devices, versions retained, a restore tested at least once	Hours, for the devices covered
3	Controlled	Running versus approved compare, alerts on drift, a check-out and approval workflow, an audit trail, restore drills	Hours, with confidence that the restored version is the right one
4	Integrated	Configuration data feeds vulnerability management, obsolescence planning and the CMDB or ticketing system across sites	Hours, and the incident itself is easier to investigate

Where to aim. A single-site discrete manufacturer with modest regulatory exposure gets most of the benefit at level 2, provided the restore is genuinely tested. A pharmaceutical plant under FDA 21 CFR Part 11, a utility under NERC CIP, or a company inside the scope of the EU’s NIS2 directive will need level 3 at minimum, because those regimes ask for evidence of controlled change, not only for backups. Level 4 earns its cost in multi-site organisations that already run a vulnerability management or ITSM programme and want plant data inside it.

Assess honestly. The common mistake is to score the plant on the devices that are easy to reach. The level is set by the weakest critical asset: a robot cell with no backup at all keeps a site at level 0 for that line, whatever the dashboard says about the PLCs.

Move one level at a time. The jump from 0 to 2 is mostly technical: a server, network paths, credentials and scheduled jobs, plus one honest restore test. The jump from 2 to 3 is mostly organisational: agreeing who approves changes, what happens to an online edit the next morning, and how contractors check work in. The jump to 4 is mostly integration with the security and IT teams. Plants that try to buy level 4 on day one usually end up with an expensive level 1, because the habits underneath were never built.

Where the standards ask for it

Plants rarely buy automation change management because a regulation names it. They buy it because several regulations and frameworks ask for evidence that only this capability produces. The summary below is general; read the text of the regime that applies to you.

Framework	What it expects that this capability supports
IEC 62443	Control system backup, configuration management and change control as part of an industrial security programme
NIST Cybersecurity Framework 2.0	An asset inventory under Identify, and tested recovery under Recover
NERC CIP (North American utilities)	Configuration baselines and change monitoring under CIP-010, and recovery plans under CIP-009
FDA 21 CFR Part 11 and EU Annex 11	Audit trails and controlled change for computerised systems in regulated manufacturing
EU NIS2 directive	Risk management measures that include backup management, disaster recovery and business continuity (Article 21)

For the OT-specific reading of these frameworks, NIST’s Guide to Operational Technology Security (SP 800-82 Rev. 3) is the most practical single document: it explains why control systems need different handling from IT and how to apply security, backup and recovery practice to them.

The pattern across all five is evidence. An auditor does not accept “we back up the PLCs.” They ask to see the last backup of a named controller, the record of the last change and who approved it, and the result of the last restore test. A tool at maturity level 3 produces that evidence as a side effect; a manual process produces it only when someone stops to assemble it. The AMDT cluster covers the regulated cases in more depth on its compliance page.

How to build the business case

The case for automation change management rarely fails on the numbers. It fails because it is presented as a software purchase instead of as a reduction in a risk the plant already carries. Five steps make it concrete.

1. Count the devices that hold logic or configuration. PLCs, safety controllers, HMIs, SCADA and historian servers, robots, drives with parameter sets, CNC controls, managed switches and firewalls. Most plants undercount robots and drives by a wide margin.
2. Rank them by consequence. For each line, estimate how long a rebuild would take today if the device were lost, and what an hour of that line is worth. An illustrative line worth $15,000 an hour that would take two days to rebuild carries $720,000 of exposure from a single controller loss, before scrap and missed shipments.
3. Estimate the recovery time with the capability in place. A tested restore from a current backup typically turns days into hours. The difference, multiplied by the frequency of failures and incidents you can document, is the avoided cost.
4. Add the costs that are easier to see. Engineering time spent finding the right file, commissioning delays caused by mismatched versions, audit findings, cyber insurance questionnaires that ask about OT backups, and the time a new engineer needs to learn a line with no change history.
5. Price the whole capability, not the licence. Implementation, onboarding of each device family, network access for the backup server, the person who owns the tool, and the annual restore drills. A tool that nobody owns decays back to level 1 within a year.

Start with an inventory. You cannot cost the risk of devices you have not listed. A plant systems assessment produces exactly that baseline: what is installed, what version, what is backed up, what can still be opened and what would stop production longest if it were lost. It is the input to any tool selection, whichever vendor wins.

The guides in this section

Most asked

• How do we recover PLCs after ransomware? The runbook, in order, and the offline copies it depends on
• What does FactoryTalk AssetCentre do in a Rockwell plant? The backup and change-audit gap, and how to close it
• What happens now versiondog and AutoSave are end of life? The phases and what a plant on either product should do
• How does octoplant compare with Copia? Approved-version model against Git-native, side by side

What it means for a plant

Ownership comes first. The software is the easy part. Someone has to own the backup jobs, review the drift alerts, approve changes and run the restore drills. In most plants that person sits in controls engineering, with IT supporting the servers and the network paths. If nobody is named, the tool becomes another unmonitored server.

Role	What it owns in automation change management	What goes wrong without it
Controls engineering	The tool, the backup jobs, the approved versions and the restore drills	Jobs fail silently and the repository drifts out of date
Maintenance	Recording or reversing online edits by the next working day	Night-shift fixes are overwritten by the next download
IT	Servers, storage, network paths and the offline copy	The backup server shares the fate of the systems it protects
OT security	Using firmware and version data for vulnerability and incident work	Two inventories that disagree, and nobody trusts either
Quality and validation (regulated plants)	Approval records and audit evidence	Evidence is assembled by hand before each audit
Integrators and OEMs	Checking work in and handing over an as-left version	The plant’s history starts with a version nobody can explain

Maintenance works differently. Technicians still make online fixes at night, and they should be able to. What changes is that the fix is visible the next morning, and someone decides whether it becomes the approved version or gets reversed. That is a cultural change, and it lands better when it is presented as protecting the technician’s fix from being overwritten.

Contractors and OEMs work inside a process. Commissioning ends with an “as-left” version that matches the documentation, and the plant holds it. Our systems integrator scope of work guide shows how to write that requirement into the contract.

The long tail costs the most. The first eighty percent of devices onboard quickly. The rest, the serial-only controller, the robot on a separate cell network, the OEM skid with a locked project, take most of the effort. Budget for them explicitly, because they are often the assets nobody else can rebuild.

Security and engineering share a source of truth. The OT security team gets firmware and software versions read from the devices; engineering gets backups that double as incident recovery material. The OT asset inventory page explains how that inventory complements network monitoring.