AutoSave to octoplant Migration: What Moves, What to Check and a Plan

An AutoSave to octoplant migration, or the same move from versiondog, is the route most plants on the legacy products will take now that both are in their final, consulting-only phase as of October 2026. The short answer to “what does it involve?” is this: an inventory, a pilot that proves your history survives, a staged move, a period of running both tools, and a deliberate retirement of the old one. This page covers what has to move, the tools and services AMDT offers, how licensing changes, a nine-step plan, a pre-migration checklist and the risks.

The context, including the end-of-life phases and the alternatives to octoplant, is on the parent page, versiondog and AutoSave. Background on each product is on versiondog and MDT AutoSave.

What has to move in an AutoSave to octoplant migration

AMDT does not publish the mechanics of the migration on its public sites as of October 2026. Partner Novotek states that octoplant “already offers all versiondog functions” (Novotek, our translation), which says the target can hold what versiondog held. It does not say every item moves without work. So treat the list below as what you must confirm, not as what is promised.

Item	Why it matters to the plant	What to confirm
Archives (latest version of each device)	The copy you restore from on the worst day	Every device arrives, including ones the legacy tool backs up rarely
Version history	Explains why a program looks the way it does; supports troubleshooting and audits	All versions, with dates, authors and comments, not only the latest
Jobs (scheduled backup and compare)	Catches drift without anyone remembering to look	Schedules, targets, comparison rules and alert recipients
Users, roles and approvals	Decides who can check out, approve and restore	Role mapping, and whether approval steps change
Audit trail	Evidence for auditors under 21 CFR Part 11, NIS2 or NERC CIP	Whether historical entries carry over or stay in the legacy system
Device connection settings	Paths, credentials and agents that reach each device	Network routes, especially across segmented subnets

The plant consequence. Illustrative scenario: a site migrates the latest version of every PLC and moves on. Six months later a quality investigation asks what a filler program held during a particular week. The answer is in the legacy archive, on a server nobody kept running. The migration preserved the backup and lost the evidence.

The Project Integrator Tool and AMDT’s services

The Project Integrator Tool arrived in octoplant Spring Release 107 on 7 April 2026. AMDT says it lets “deployment tasks that previously took days or weeks” be completed “within hours.” It is presented as a tool for rolling octoplant out across a plant, which is most of the effort in setting up a new estate. Whether it imports a legacy AutoSave or versiondog archive directly is not stated publicly. Ask before you plan around it. The wider release history is on octoplant release notes.

AMDT’s services relevant to a migration, as listed on its sites in October 2026:

• Migration & Expansion: the named service for moving to octoplant and growing coverage
• Implementation & Commissioning: setting up the server, clients and agents
• Job Optimization: tuning schedules and comparisons once jobs are running
• IQ/OQ Services: installation and operational qualification for validated plants
• Training: instructor-led courses, the eAcademy and the myAMDT portal

AMDT’s partner network also delivers migrations, which can be useful where a local partner already knows the site.

How licensing changes

octoplant licensing, per its pricing page:

• Per device, with one licence per campus
• Unlimited jobs; documents do not count as devices
• Three editions: Core (up to 50 devices, single site), Plus (100+ devices) and Premium (250+ devices, regulated or large sites, all-inclusive)
• No prices are published, and the per-edition feature split is not public

What that means for a migration. The device count drives the edition and the cost, so the inventory in step one of the plan is also the basis of the quote. A site near an edition threshold should know which side it falls on before negotiating. Regulated sites should confirm which edition carries the features their validation depends on. The detail is on octoplant editions and licensing.

An AutoSave to octoplant migration plan

1. Inventory the legacy estate. Every device, its vendor, firmware and editor version, every job, every user and role. Note which devices the legacy tool has not captured since new device and editor support stopped in 2025.
2. Decide what history you need. For a validated or audited site, usually all of it. For others, agree a cut-off with quality and engineering, in writing.
3. Check device coverage. Match the inventory against AMDT’s current support matrix, which sits behind the myAMDT login. See supported devices.
4. Size the licence. Count devices per campus and map them to an edition.
5. Design the target. Server, clients and agents across the plant’s network segments. See octoplant architecture.
6. Pilot one area. Migrate it, then prove three things: full history is present, a Smart Compare against the running device is clean, and a test restore works.
7. Migrate in batches, area by area, with the jobs rebuilt and checked as each area moves.
8. Run both tools in parallel for an agreed period, and compare their results.
9. Cut over and retire. Make octoplant the system of record, then keep the legacy archive readable, or exported, for as long as your retention rules require.

Pre-migration checklist

• Contract dates for the legacy tool confirmed with AMDT, in writing
• Device, editor and job inventory complete, with owners named
• Devices the legacy tool could not capture since 2025 listed and backed up by other means
• History retention requirement agreed with quality, engineering and OT security
• Device coverage confirmed against the current matrix
• Licence quote based on the actual device count per campus
• Validation scope agreed for any GxP system, with IQ/OQ planned
• Network paths and credentials to every device documented
• A test restore defined for at least one critical device per area
• A plan for read access to the legacy archive after retirement

Where it gets hard

Lost history. The commonest quiet failure in any tool migration. A migrated archive that holds only the latest version looks complete until someone needs last year’s.

Editor versions. Archives created with old editor versions may need those versions to open them, and equipment upgraded since 2025 may never have been captured at all. Both show up only when you look.

Validated environments. The versiondog GxP edition has no confirmed named octoplant equivalent in public sources. A validated site should treat the move as a change under its quality system, with IQ/OQ, and read 21 CFR Part 11 before starting.

Two tools at once. During the parallel run, technicians need to know which tool is the record for which machine. Write it down at the panel, not only in a project plan.

Ownership. The migration touches engineering, maintenance, IT, OT security and quality. Without one accountable owner, it stalls at the inventory. An owner’s engineer can hold that role and keep the vendor and partner to a defined scope.

Back to versiondog and AutoSave or the AMDT hub.