What happens to protected data if the backup software platform is replaced?
Replacing a backup software platform does not automatically delete protected data, but the existing backup sets may not be readable by the new platform. Data should therefore be migrated or retained in its original format, with encryption keys, retention metadata and restore capability checked before the old system is withdrawn.
When a backup software platform is replaced, the protected data normally remains in its existing storage location, but its usability depends on how the replacement is carried out. The key issue is not simply whether backup files still exist; it is whether the organisation can identify, interpret, restore and manage those files after the change.
A backup platform usually maintains more than a collection of files. Its supporting information may include job definitions, backup catalogues, timestamps, dependency relationships, deduplication references, compression details, encryption settings and records of which items belong to each recovery point. Some of this information may be stored separately from the backup data itself. If only the storage repository is retained while the catalogue or configuration is lost, recovery can become slower and more manual.
There are generally three ways to handle the existing data:
- Retain the legacy platform: The old software and its repository remain available for the period required by the organisation’s retention, contractual or regulatory obligations. The replacement platform handles new backup jobs, while the legacy system is used when an older recovery point is needed.
- Convert or migrate the backup sets: Where the old and new platforms support a compatible migration path, backup data and its associated metadata are transferred or converted. The exact scope varies: some migrations preserve complete recovery points, while others only import selected workloads or allow data to be restored and backed up again in the new format.
- Restore and re-protect: Data is restored from the old repository and then backed up using the new platform. This creates new backup sets but does not automatically reproduce every historical recovery point, catalogue entry or retention characteristic from the previous system.
The appropriate method depends on the backup format, storage architecture, workload type, encryption arrangement and the length of time historical backups must remain recoverable. A platform replacement should therefore begin with an inventory of repositories and protected workloads, rather than with the installation of the replacement software alone.
That inventory should identify where each backup is stored, which system created it, the workloads and recovery points it contains, the retention period that applies, and the credentials or keys required to access it. It should also distinguish between complete backups, incremental data, snapshots and replicated copies. This matters because an incremental backup may depend on an earlier full backup or on other files in the same backup chain. Moving one component without its dependencies can leave an apparently intact set unusable.
Encryption requires particular care. Encrypted backup data may remain present after a software change but be inaccessible without the relevant keys, certificates, passphrases or key-management records. Those items should be transferred or preserved under controlled access, with a documented ownership and recovery process. Storing keys only inside the outgoing platform can create a preventable dependency during decommissioning.
Before the old system is removed, the replacement arrangement should be tested against representative recovery scenarios. A sound test checks more than whether a backup job completes. It should confirm that administrators can locate the required recovery point, authenticate to the repository, recover the relevant files or systems, and verify that the restored data is usable. Application data may also need an application-level check rather than a simple file-level comparison.
Testing should include older recovery points if those are being retained, not just newly created backups. It should also cover the failure of a component that is easy to overlook, such as a catalogue server, repository index, encryption key store or service account. The results should be recorded so that any limitation of the migrated or retained data is understood before the original platform is withdrawn.
During a transition, organisations commonly run the old and new arrangements in parallel. This can provide time to establish new backup jobs, confirm recovery, and allow existing retention obligations to expire naturally. However, parallel operation needs clear ownership and monitoring. Administrators should know which platform is authoritative for each workload, which repositories must be preserved, and when a legacy copy can be safely disposed of.
Decommissioning should take place only after the retention schedule, legal or contractual requirements and recovery tests have been reviewed. The process should include a final configuration record, confirmation that no required backup chains or keys depend on the outgoing system, secure disposal of obsolete media or storage, and removal of unused credentials and access permissions. A replacement is complete when the organisation can demonstrate a controlled recovery process, not merely when the new software has been installed.
A platform replacement can preserve the backup content while losing the operational records that explain how it was created and managed. Historical job reports, verification results, administrator actions, deletion records and repository audit logs may be held in the outgoing platform rather than alongside the backup files. If these records support internal governance, contractual evidence or regulatory enquiries, they should be exported and retained in a readable format before the old system is withdrawn.
The exported records should identify the workload, recovery point, creation date, retention status and any verification or access activity associated with the data. Keep them linked to the relevant repository and protect them from unauthorised alteration. This gives administrators and auditors a reliable record of the backup history, even where the replacement platform cannot recreate the original reports or dashboard views.