One question, clients have often asked "If I change my backup vendor, will I be able to access my old backups?" The answer is always yes, as there has always been a way to do this but Its going to take a lot of time, has high risk associated with it, it doesn't retain the backup meta data (retentions, original backup dates etc), and its going to cost many thousands of dollars to perform it.

The costs of not migrating data should not be overlooked. If you change vendors, but don't migrate data you will either end up maintaining a smaller footprint environment for legacy restores or outsourcing your recovery to a specialist company, sending media offsite when a restore is required, if you can determine which media it is on. Maintaining the legacy software and hardware, plus the cost of managing the media for the life of the data (7 years or so).and for the retaining of skilled resources to administer the legacy environment need to be taken into consideration. Alternately, using a specialist recovery company can work out to be a costly exercise, security of media and data in transit need to be assured, along with the impact of extended time to recover. Where data is not managed through a single solution, additional issues will arise where Application or Database data will require, additional steps or processes to make that data usable after it is retrieved.

When planning a "switch-out" of a backup vendor, consideration needs to be given to the integration of the new solution into the existing environment. Backup products are not simple, due to the inherent complexity of the software systems they are protecting, such as operating systems, databases and messaging applications. Each backup vendor has their own unique interface and their own format for storing data, the way they access the data for backup and restore also differs as they use bespoke agents or outdated APIs. All these issues make makes this less of a case of a "switch-out" and more of a managed transition.

To reduce the risks through a managed, automated, cost effective way, that keeps original catalog meta data, and allows for the recovery of the legacy backups, directly through the new backup vendors software we have created Tranzman, to empower the move and make migrations simple.

Tranzman migrates the catalog first, this is much faster than the traditional restore and backup approach, and allows for the legacy backup product to be retired sooner.

When a catalog has been migrated, you can either use Tranzman for "recovery on demand" or to perform an "automated duplication". Both of which are done using Tranzman data readers without the need for the original backup vendors software. You can decide if you want to convert all your data in an automated way, or if you want to reduce the migration costs and can retain some tape infrastructure, you only need to convert what you need when you need to restore it.

Backups are for disaster recovery and archiving is for discovery – at least, that’s what some people believe. In reality, this is not the case. Many organisations have been using backup technology to hold on to data offline over the long term. However, if an organisation needs to change its backup technology, it might no longer be able to access the aforementioned data.

Stone Ram has created the Tranzman appliance. This allows the contents of an existing backup environment to be ingested directly into a replacement backup environment. Tranzman enables you to read media (e.g. disks and tapes) held in the legacy backup environment, so you will no longer need legacy backup software. Our Tranzman solution works by intercepting calls for the media and converting the backup data to the required format used by the new environment at the point of recovery (or duplication).

A world first
With Tranzman, recovery and migration of backup data is possible without needing the original backup software. For example:

1) Catalog migrations

Catalog conversion and ingestion: Tranzman exports the legacy backup catalog, converts it, and imports it into the new backup environment to provide a single interface for all your restore requests.

Catalog mergers: Tranzman can be used to append imported catalog data to an existing catalog so multiple backup environments can be merged. Tranzman enables full or partial mergers of catalog data.

2) Backup Data Restores

Restores: With Tranzman, legacy data can be restored using your current backup product. For example, if data is on a legacy tape, Tranzman intercepts the restore request before identifying and converting the backup data to a native format which your existing backup product can process and read. When the conversion is complete, the restore will automatically continue.
 
Backup data migration: Tranzman also assists organisations that need to move all their legacy backup files onto modern backup technology. It converts and duplicates each image to native media in the target backup environment. Target environments include tape, disk and cloud-based destinations. Tranzman can be set up to be fully automated, and doesn’t need the vendor’s software to complete the process.

This article investigates the categories most organisations fall into when faced with the prospect of a backup product migration. Factors that usually crop up when considering changing or upgrading backup products include:

• Unease about legacy data conversion
• Reducing legacy product maintenance costs
• Retaining backup data for more than 12 months
• Backup data that is on legal hold.

The world of IT is constantly changing to keep up with the demands of businesses striving to improve efficiency or resiliency. As organisations adopt new technologies, the supporting IT infrastructure needs to be adapted to protect the new technologies. Most organisations fall into one of these groups.

The Anti-changers
Belief: They remain with a vendor because they believe that change will be painful and will disrupt the day-to-day business too much.
Result: The business suffers and becomes less competitive because it’s not benefiting from modernisation, which delivers faster (and better) ways of protecting data, along with cost reductions and new efficiencies.

The Pick ‘n’ Mixers
Belief: They supplement their existing vendor with new technology (often from a new vendor) to provide any required additional functionality.
Result: In trying to meet specific business requirements, these organisations end up implementing multiple point solutions. Administration and maintenance costs increase, and resource usage becomes inefficient.

The Parallel Runners
Belief: They migrate to a new vendor and retain a smaller footprint of the legacy environment in case they have a need for recovery.
Result: Although this approach has its advantages, the legacy environment is expensive because it needs skilled resources, extra hardware, software licences and maintenance agreements.

The Manual Switchers
Belief: They migrate everything through a process of recovery and re-backup.
Result: This is time-consuming and requires many resources, although it does provide the opportunity to decommission the legacy environment after the migration has been successfully completed.

Six options for backup migration plans
There are six options to consider when planning a migration. Selecting the right one depends on various factors, including automation, volume of protected data, retentions and compliance

1. Keep a smaller footprint of the legacy environment to use for restorations. This is an appealing choice if the volume of expected restores is very small and if staff have the skills to administer restores.
2. Decommission the legacy environment and pay for a third party to recover data if you need it. This is useful if the hardware can be reused because it allows for tapes to be sent off-site and the current environment to be decommissioned. This does not suit environments using disk-based backups. If a restore is required, a third party can recover it from tape and return the required files.
   
   
3. Retain the entire legacy environment until all data within it expires. This is a good option if the backup image retentions are short (<12 months) and hardware isn’t going to be reused. The new environment can be configured for client workload creation. After backups start going to the new environment and the data in the old environment has expired, the new environment can be decommissioned.
   
   
4. Manually recover and re-backup data to move it from the legacy environment to the new one. This is time-consuming, and you lose the historical trail that’s often needed for audit purposes and compliance.
   
   
5. Use a data management and migration tool. Most require third-party professional services to set them up and run, along with a separate engine to index the legacy backups. Some don’t need legacy backup software to read data, so you need to find out if the legacy product can be decommissioned. Most use their own interface for restores – if you have to carry out a restore, you’ll have to work out if data is old or new, and which interface to use. Most can script/automate image duplication to fully migrate them into the new backup environment, but this requires original media to be recalled and read before the new backup environment can re-backup the data. Until this process is complete, you will still use multiple catalogs.
   
   
6. Use the Tranzman backup transition manager appliance. It’s a best-of-breed option that fully automates and manages the transition from the legacy backup to the new backup product. Legacy catalog data is automatically merged into the new environment, so all restores are performed using the native interfaces. You choose whether you want to automate client workload creation based on those (policies, jobs etc.) from the legacy environment. Tranzman converts images on demand, when you want to restore, and also schedules the duplication of all data and images into the new environment. Tranzman has its own image readers, so you can decommission the legacy backup software but still restore data when you need it.