Your New Backup Software Just Arrived. Now What?

Now what?

It sounded so good when you spoke with the sales team...

You’ve just purchased a new data protection (backup) software application and realize you aren’t sure what to do next. This may help.


Backup migration overview

A trapeze artist shouldn’t perform without a net and neither should your organization.

Your backup is your safety net.

As such, you need to ensure that your organization will not be put into a position where you are forced to operate without recoverable backups during transition from one product to another. And to be sure, there will be times when data will need to be restored from the previous backup application. This might occur due to normal user operations (i.e., accidental file deletion), hardware failure (i.e., disk crash) or even for discovery requirements (i.e., government regulations).

As you move to your new backup application, it is imperative to address both these situations. This is a big project and needs to be handled accordingly. You have made a decision to move to a new platform (and it probably wasn’t an easy decision), so first and foremost…breathe.  

These recommendations may make your life just a bit easier during this migration.

Pre-transition – before you migrate

As with many projects, it is a good idea to evaluate your overall environment to determine the “who, what, where, when, why and how” questions. When you know the answers to those, you can focus on creating a solid implementation baseline while eliminating all those old “work-arounds” that have crept into your environment over time. You know the ones, like your DBA’s secret SQL backup that no one else knows about.   

Understand what you are doing now.

Prior to transitioning, you should have a comprehensive understanding and inventory of your existing backup environment. Key points to understand include, but are not necessarily limited to:

  • What is currently being protected across the organization
    • Servers, operating systems and versions, applications, databases, etc.
  • How it is being protected
    • Full, incremental, differential, snapshots, deduplicated, encrypted, etc.
    • D2T, D2D, D2D2T
    • Retention cycles
  • When it is being backed up
    • Schedules, backup windows, etc. 
  • To where is it being backed up
    • On-premises, secondary site, cloud, etc. 
  • How long the data needs to be available
    • Government regulated, company policies 

This inventory will likely vary by company, department and application. While gathering this data may seem like an arduous task, it will pay off in the long run. It is critical for ensuring your new backup application continues to protect the data being protected with the old application AND it will help you determine what migration methodology will be best for you.

Understand what you want to do with the new application.

While developing your inventory, it’s a great time to consider whether any changes to the existing policies and procedures are merited. Engage individual stakeholders to review existing data protection policies and determine if these still meet their business requirements. Some topics to review and modify include but, again, are not limited to:

  • Recovery point objectives
    • How much data can they afford to lose? 
  • Recovery time objectives
    • How much downtime can they afford before coming back “live”?
  • Version retention objectives
    • How many copies of a given version of a file/application data set will be maintained and how long will that copy be maintained?
  • Geographic redundancy objectives
    • What data needs to be replicated offsite, how often should replication occur and what is the distance required between sites?
  • Data encryption requirements
    • At rest, in-flight
    • Key management
  • Data deduplication requirements
    • Client-side, in-line, post-process, etc.

To see how the Quest Data Protection Suite of products stacks up against your business requirements, take a look at our data protection products overview and as you review and modify your processes, don’t forget to document, document and then document those changes.  

Application coexistence: Can’t we all just get along?

One of the most important factors during the transition process is ensuring that you continue to back up your data. You don’t want to work without that safety net! 

To that end, it’s time to determine how the transition process will take place. Typically, the transition involves migrating specific server(s) based on application, virtual architecture or some other characteristic as defined by your infrastructure. Once successful migration of the first group is complete, the next group is migrated, and so on. This means that both backup applications will be used for some period of time.

Many backup applications depend on agents (client software), and you may find that you are unable to deploy both backup applications’ agents to the same server at the same time.

Prior to transitioning, a good recommendation would be to create a test environment with at least two test servers. Back up those servers using your old backup application and then install the new backup agent and, if successful, attempt a backup using the new software. The ideal environment would allow backups/restores from either application (though not at the same time). You should also verify that your current and newly created storage repositories are supported on both backup software applications and can be shared during transition. You may need to dedicate individual backup targets for each backup application if this isn't the case.

If you cannot install the agent or generate a successful backup, ensure that the server remains stable if you uninstall the old backup application.

Educate yourself.

Training is a critical component for a successful transition. Even if you choose no formal training, you should, at a minimum, set up that test lab and experiment with the new backup application. Understand how the application works and what resources (network, CPU, storage, etc.) are needed prior to installing into a production environment. For example, identify whether the new application protects applications agentlessly, what granularity of restoration is available, how encryption key management works and how data is transferred from server to backup target.


Remember your long-term retention requirements.

It is likely that you may have data that was backed up using the old software that will need to be restored at some point after the transition. You need a solid understanding of how that data is stored, as this varies across vendors. In short, your new application isn't going to be able to restore those old backups should the need arise. Therefore, it is strongly recommended to keep an instance of your previous backup application available until there is no longer any chance that the old backups will need to be restored (all data sets have expired).

For data that cannot or does not expire, a process for data migration to your new backup application should be implemented, unless you want to keep that annoying instance of your old backup around (and hope that you won’t need support). This process would involve restoring data from the old application to a server outside of your production environment and then creating a backup of this data using the new software application. Time consuming? Heck yeah! Necessary? Only you can decide that! But don’t make that decision without buy-in from the business owners of the data. It may be a career-limiting move if you don’t.

There are a few tools “out there” that migrate data between backup software packages, but they are VERY limited in their interoperability. As an example, different versions of the same backup software may have different backend databases, deduplication and encryption algorithms, etc., which may not be included in the migration tool. What we want for data migration is simple in theory; what we have is a tangled web of interoperability that (arguably) no one can address. And this problem leads us, of course, to the issue of support. Should a tool migrate data incorrectly, then what? Who ya gonna call? Your old vendor won’t be too excited to assist. Your new vendor would love to help but doesn’t have a migration tool, nor an understanding of the tool you used. All this, I believe, is why we have never seen the “Swiss Army Knife” backup data migration application.

It boils down to two options to ensure your existing backup data is protected:

  • Keep an instance of the old software around for restores, assuming your retention policies are reasonable.
  • Migrate old backups to new backups, assuming your existing retention policies are too long to reasonably keep that instance of the old software around.

One thing to take into account during your planning process is that if you are forced to install your old backup application onto a different server, your recovery service-level objectives may be impacted. First, environmental components may have changed (CPU, memory, internal storage, networking, etc.), which we know can dramatically impact performance. Secondly, removing your backup application from the original backup server could destroy your backup indexes. This shouldn’t preclude you from restoring data, but it does mean that the restoration may take longer because the data may need to be re-indexed. Neither one of these situations is optimal. You should, therefore, plan to keep your old backup application installed on its original server or ensure that end users understand that restoring data may take longer than normal and could impact existing service level objectives.

Be patient/breathe.

It is critical that you perform the transition in such a way to ensure resources (servers, applications, etc.) will not be left vulnerable to data loss during the process. To that end, create a plan to achieve success, perform a walk through or table-top exercise to ensure all aspects have been addressed, and follow that plan accordingly.

In my younger days, I was assigned to a project that was immense in nature and I was, to be blunt, freaking out. The project manager (a much smarter fellow than I) asked me, “How do you eat an elephant?” I answered with a fresh-off-the-farm, smart-aleck reply of, “With a knife and a fork.” He looked at me with pity, shook his head and dryly responded, “No, you eat it one bite at a time.” 

He was so right.  I now live by that advice every time I come up against overwhelming projects. Your backup migration may fall into this category, so take his advice: Take it one piece at a time. 

If you feel you need assistance through this process, have no fear; Quest provides professional services to assist you with your backup migration.


Adapt and adjust

It's good practice to return to the business stakeholders and solicit input on success (or failure) and modify your backup infrastructure and policies as needed. In fact, this is also a good practice to perform regularly outside of your migration project. When we engage the stakeholders, we are significantly less likely to get hit upside the head when something goes wrong. Proactively identifying potential issues and adapting our processes prevents future headaches, long sleepless nights and helps ensure our success.

As with every completed project, requirements change after the fact and are due to a variety of reasons. As you encounter these changes:

  • Make corrections to your backup plan accordingly.
  • Document, document, document.
    • A plan is only as good as its documentation.
  • Test, test and, oh, yeah…test again.
    • Test both backups AND restores using the new plan requirements. I have heard many times in my career that it’s ALL about the restores. I respectfully disagree with this notion. For me, it’s ALL about the backups AND the restores. I suppose one could argue that the restores are effectively testing the backup. I cannot disagree with that, but a restore only validates the data residing in that specific data set. We need to make sure that our backups are protecting everything we want them to protect. A restore might prove that the data was good but it won’t verify that we have all the required data. A nit perhaps, but backups and restores must play nice together and, therefore, deserve equal importance.
  • Solicit feedback from your stakeholders.
  • Repeat!

Once you’ve successfully transitioned to your new backup application, another good practice is to adapt and adjust on a regular basis. This ensures your backup strategy will be current with the ever-changing environments you are tasked to protect. I know I mentioned this already, but because of its importance, it warrants repetition.

Most of all, don’t forget to breathe.

Remember, transitioning from one backup application to another is a process, and with every process, you will find challenges along the way. But if you’ve done your homework upfront and created a solid plan, you will be able to address those challenges head on while ensuring a successful migration! For more information about Quest's data protection and backup portfolio, take a stroll to our website dedicated to backup and recovery.