Finding All of Your Assets After a Cloud Migration

by Oct 15, 2019

If your company is like the majority of others out there, they are likely to be interested in taking advantage of the cloud for at least some of their computing requirements. They might just want to add some extra storage capacity without the capital investment involved with purchasing equipment. It could be that the goal is to eliminate an in-house data center or to maintain a hybrid environment that encompasses on-premises and cloud resources. Businesses can flexibly deploy the cloud in whatever way makes the most sense from an organizational and financial perspective.

As a DBA responsible for your company’s SQL Server environment, there’s a good chance that the majority of migration decisions are being made outside your scope of influence. You may have some say about the order in which your systems are re-hosted, but where and when they are moving is something you may just have to accept. Of course, it’s up to you to make sure all the databases are all up and running on both sides of the move.

Migrating SQL Server to Microsoft Azure

There are several new neighborhoods that your databases can end up in when moving to the cloud. As the developers and driving force behind SQL Server, the team in Redmond has designed a robust environment with several different hosting options. One is to migrate SQL Server instances to Azure SQL Database. For the sake of simplicity, we will focus this discussion on the migration of SQL Server instances from an on-premises data center to Microsoft Azure virtual machines.

Multiple migration methods are available when moving to Azure VMs. These techniques are also applicable when moving SQL Server databases between SQL Server VMs in Azure. Your organization should choose its migration method during pre-migration planning. The main migration methods include:

  • Creating compressed backups of the SQL Servers on-premises and manually copying the backup into an Azure VM.
  • Using a URL to store a backup and restoring it to the virtual machine.
  • Physically shipping a hard drive using the Windows Import/Export Service.
  • Detaching and copying data and log files to Azure blob storage and attaching it to SQL Server in an Azure VM.
  • Use the Add Azure Replica Wizard from within an AlwaysOn Availability Group deployment.

It’s common for migrations to be conducted over a pre-defined timeframe during which a subset of systems will be moved at a time. This fact introduces the chance that a system can get lost in the shuffle. Perhaps a server migration was unsuccessful and needed to be rescheduled. In a large-scale migration, keeping track of your environment while it is in flux poses a serious challenge that will overwhelm manual efforts.

Catching Your Breath After the Move

Before undertaking any steps toward a migration you should have conducted a thorough inventory of your SQL Servers that identifies all instances and helps in understanding their current usage. The information obtained in the inventory may help develop the migration strategy by identifying which SQL Servers are best suited to be moved first.

IDERA’s SQL Inventory Manager can be indispensable when reconciling your SQL Server environment before, during and after a migration to the cloud. It helps your organization deal with the server sprawl inherent in cloud migration. Automatic discovery and a global dashboard result in visibility into your complete SQL Server inventory. On-premises and cloud instances can be organized with custom tags for operational efficiency.

Health checks can help you find servers that need to be patched or backed up. Availability alerts can be generated to address servers that are down or running low on storage capacity. SQL Inventory Manager is a valuable tool for the database team even if there are no plans for migration in your company’s future. It can help you locate and understand your SQL Server assets no matter where they call home.