Backup and cyber recovery platform migration playbook: change platforms and keep every restore point

Moving to a new backup platform creates a period in which the organisation's last line of defence against ransomware is split across two systems, and the restore points that matter most are often the ones the new platform cannot read. Backup platforms are replaced when a product reaches end of support, when workloads move to cloud and software as a service, when costs or licensing change, or after a ransomware incident exposed weaknesses. This playbook is for infrastructure, backup and security teams running that move. It covers what has to move besides backup jobs, how to handle historical restore points and retention obligations, how to protect the new platform from day one, cutover and rollback, and how to decommission old repositories without destroying data you are still obliged to keep. It is vendor-neutral and based on NIST and CISA guidance. Hardening a platform is covered in the Backup Security and Immutable Backup Guide; selecting one is covered in the Backup and Cyber Recovery Buyer's Guide.

Key takeaways

• Restore points are the hard part. Jobs and schedules can be rebuilt in days; years of retained backups in a proprietary format cannot be converted cheaply, so decide per dataset whether to re-seed, convert or age out.
• Never run a day without a tested restore path. The new platform must prove restores of critical systems before the old one stops taking backups.
• Harden first, migrate second. Immutability, separate administrator identities and multi-person approval for destructive actions belong in the new platform before any production data lands there.
• Keep the old platform restorable for the full retention period. Legal holds and retention schedules do not end because a contract does; plan a read-only "restore only" state and its cost.
• The backup platform's identities are prime targets. Hypervisor, database and SaaS connector credentials move with the platform; re-issue them rather than copying them.

What has to move

Start from a recovery objectives register: for each service, the recovery time objective, recovery point objective, retention requirement and its legal or business driver, and the restore order. NIST SP 800-34 Rev. 1 sets out this contingency planning discipline, and the Backup and Recovery Objectives Register Template gives a format.

Historical restore points: re-seed, convert or age out

Whatever the choice, verify integrity before relying on a migrated or retained copy. NIST CSF 2.0 RC.RP-03 asks that the integrity of backups and other restoration assets is verified before they are used for restoration, and NIST SP 800-53 CP-9(1) calls for testing backup information to verify media reliability and information integrity.

Secure the target before data lands

A new backup platform is attractive to attackers precisely while it is half built: default admin accounts, broad connector credentials and immutability not yet configured. CISA's #StopRansomware Guide warns that many ransomware variants try to find and delete or encrypt accessible backups, and recommends offline, encrypted backups, delete protection or object lock, and versioning. ATT&CK T1490 Inhibit System Recovery describes the technique.

• Separate administration identity: backup administrators use accounts that are not in the production directory's admin groups, with phishing-resistant MFA. See the Backup Identity Isolation Guide.
• Immutable copies: enable immutability or object lock on at least one copy, and test that an administrator really cannot shorten retention or delete a locked restore point.
• Multi-person approval: require a second approver for retention changes, deletion of restore points and disabling of immutability, where the platform supports it.
• Encryption and keys: encrypt backup data (CP-9(8)) with keys held outside the backup platform's own admin domain (SC-12).
• Separate storage: at least one copy isolated from the production network and identity plane (CP-9(3), CP-6).

The full hardening baseline is in the Backup Platform Hardening Guide.

The phased playbook

1. Phase 0: objectives and scope. Complete the recovery objectives register. Identify legal holds and retention schedules that outlive the old contract. Get a written decision on the historical data option per dataset.
2. Phase 1: inventory. Export the old catalogue: every protected source, job, target, copy and expiry date. Reconcile against the asset inventory (CM-8) to find unprotected systems and orphaned jobs.
3. Phase 2: build and harden the target. Deploy the new platform, isolated admin identities, immutable storage, key management, alerting to the SIEM. Do a hostile test: try to delete a locked backup with an admin account.
4. Phase 3: pilot. Protect a set of non-critical systems spanning each workload type (virtual machines, databases, file shares, a SaaS tenant, a container cluster). Run full and incremental cycles and restore each type.
5. Phase 4: migrate by wave, with overlap. Move workloads in waves, lowest criticality first. For each wave, the old platform keeps backing up until the new one has completed successful backups and at least one tested restore for every system in the wave.
6. Phase 5: recovery exercise. Before the last critical wave moves off the old platform, run a recovery exercise against the new platform that restores a critical service end to end, in its restore order, measuring RTO and RPO against the register (CP-4).
7. Phase 6: stop old backups, keep restores. Disable new jobs on the old platform. Put it into a read-only, restore-only state. Revoke its source credentials.
8. Phase 7: decommission by expiry. As retained restore points expire, retire storage. Sanitise media and confirm deletion of cloud storage once nothing remains under retention or hold.

Rollback

Rollback for a wave means re-enabling that wave's jobs on the old platform, which is only possible if old jobs were disabled rather than deleted and old credentials were not yet revoked. Keep a wave's old jobs disabled but intact until the new platform has met its RPO for that wave for an agreed period; as an NHI Mgmt Group recommendation, at least two full backup cycles plus one successful restore test per system. Revoke credentials at the end of that window, not before.

Credentials and connectors

Backup platforms hold some of the most powerful non-human identities in the estate: hypervisor accounts that can read every virtual disk, database accounts with backup rights, cloud roles with snapshot permissions and SaaS application registrations with tenant-wide read access. The ConnectWise Cloud Backup Breach 2026, in which Huntress reported unauthorised sign-ins by the backup application to 162 Microsoft 365 tenants in its own customer base, shows what a backup connector credential is worth to an attacker.

• Create new connector identities for the new platform with the minimum documented permissions; do not reuse the old platform's accounts.
• Record each one with owner, scope and rotation interval; see the Backup and cyber recovery platform integration security guide.
• Revoke old connector secrets, application consents and snapshot roles at the end of each wave's rollback window.
• Escrow old backup encryption keys with access logging; the GoTo Breach 2023 shows the cost of encrypted backups and their key being reachable together.

Workload-specific notes

• Virtual machines: changed block tracking and snapshot integrations are per platform; expect a full backup of every machine on first run and size network and storage for that seeding window. Remove leftover snapshots the old platform created, since orphaned snapshots consume storage and can hold sensitive data.
• Databases: log chains do not transfer between products. Take a fresh full backup on the new platform and confirm point-in-time recovery works before old log backups stop, otherwise there is a window where only the old chain can restore to a point in time.
• Software as a service: new connectors need new tenant consent; confirm coverage of every object type the old platform protected (mailboxes, shared sites, chat, configuration) and that the new connector's permissions are no broader than needed. See the SaaS Backup Buyer's Guide.
• Containers and Kubernetes: protect persistent volumes and cluster state such as namespaces and custom resources; the Kubernetes Backup and Recovery guide covers the specifics.
• Tape and long-term archives: keep a working drive and the software able to read the old format for as long as any tape is under retention, or restore and re-protect the sets you must keep. See the Tape Backup Security Guide.
• Identity systems: directory and identity provider configuration often sits outside VM backups; confirm the new platform, or a dedicated tool, covers it before old jobs stop.

Small versus large organisations

Small organisations often move from on-premises software to a cloud backup service. The key decisions are the same but simpler: confirm the provider's immutability and deletion delay, keep one offline or separately administered copy, and keep the old system restorable until retention expires. CISA notes that where a managed service provider runs backups, the same practices should be required in the contract. Large organisations should treat historical archives, tape libraries and legal holds as a separate workstream with legal sign-off, and run waves per business unit with a recovery exercise per critical service.

Detection and measurement

• Destructive actions on either platform: retention reductions, deletion of restore points, disabling immutability or encryption, new admin accounts, MFA changes. Alert in real time to the SOC.
• Job health: failed or skipped jobs, systems with no successful backup within their RPO.
• Old platform activity after freeze: any new job, login or credential use outside a recorded restore request.

Common failure patterns

• Switching off the old platform at contract end. Restore points still under legal hold or retention become unrecoverable.
• Losing the key with the appliance. Encrypted archives are kept, but the key management lived on the old appliance that was wiped.
• Copying jobs, not objectives. Jobs for long-gone servers are recreated, while new workloads (SaaS, containers) are never protected.
• Immutability configured "later". The new platform runs for weeks with deletable backups and default admin accounts.
• No restore before cutover. The first real restore on the new platform happens during an incident.
• Connector secrets left valid. The old platform's SaaS and hypervisor credentials remain active long after it stopped backing up.

Framework mapping

Practitioner checklist

• Recovery objectives register complete, with retention drivers and legal holds identified.
• Old catalogue exported and reconciled against the asset inventory.
• Historical data option chosen and approved per dataset.
• New platform hardened and hostile-tested before production data lands.
• Old encryption keys escrowed separately from old backup data.
• Waves defined with overlap; old jobs disabled, not deleted, until rollback windows close.
• Test restore completed for every critical system on the new platform.
• End-to-end recovery exercise run with measured RTO and RPO.
• Old connector credentials revoked per wave; old platform in restore-only state.
• Media sanitised and cloud deletion confirmed as each retained set expires.

Standards and references

• NIST: SP 800-34 Rev. 1 Contingency Planning Guide for Federal Information Systems
• NIST: SP 1800-11 Data Integrity: Recovering from Ransomware and Other Destructive Events
• NIST: SP 800-209 Security Guidelines for Storage Infrastructure
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• CISA: #StopRansomware Guide
• NIST: SP 800-88 Rev. 2 Guidelines for Media Sanitization
• MITRE ATT&CK: Inhibit System Recovery

Related NHI Mgmt Group resources: Backup and cyber recovery platform rollout playbook, Restore Testing and Recovery Assurance Guide, Backup and Recovery Testing Checklist, Securing the backup and cyber recovery platform itself, Ransomware Response and Recovery Guide.