In a recent entry, I discussed how many backup software providers are trying to integrate their core backup application with other components of the data protection and data management process to attract users to switch to their application. What is getting lost in the discussion is that while new features are nice, the biggest problem lies in converting from one backup application to another -- and it just shouldn't be so hard.
Converting from one backup application to another always makes me think of jumping out of the frying pan and into the fire. Conversion elsewhere is not so hard. For example, if you use Microsoft and for some reason decide to switch to OpenOffice, its fairly simple; OpenOffice can read and write most Microsoft office formats. As an IT example, there are tools available now that will allow you to migrate virtual machines from VMware to Hyper-V to Xen seamlessly. Why is this not the case with backup applications?
In backup software the need is probably greater than anywhere else. Not only do you have the data format to worry about (i.e. how will you read those old tapes?), you also have the conversion of all the backup jobs and policies, not to mention any special scripts that you have designed for that special application.
The typical backup software vendors response? First, keep your old application running for "a while" so you can read the old data. Second, recreate all your backup jobs and policies and, third, re-write all your scripts to work with your application. Anyone that has run a backup process will tell you that those are three big requests and moving them over can be a time consuming process.
Keeping the old application running so you can get to old backups is an ugly alternative; because of today's retention and compliance issues that could mean years if not decades of running at least one copy of the old application. That means paying software maintenance on that one instance and at least one person in the organization staying up to speed on the product.