How to Migrate Your Data Center to Azure

It’s time to move to the cloud, something you probably already know. In this way, you pay for whatever computing resources you need, no more no less. And when you do need more resources, they are automatically provided.

Your only decision, at this point, is whether to use a public, private, or hybrid cloud service. The case for public clouds is strong – full elasticity, affordable pricing and the latest security technology. Best of all, it gets your enterprise out of the data center business.

What Makes Microsoft Azure a Strong Candidate

There are a number of reasons to migrate your data center to Azure, including the following:

• If you access the Azure website, you will see a directory of services and tools – hundreds of them – including virtual machines, databases, file storage, backups, even mobile and web apps services. It’s a versatile solution.
• The previous name, “Windows Azure,” was changed to “Microsoft Azure,” because the platform now handles much more than Windows. You can, for example, run Windows or Linux virtual machines.
• Microsoft has also expanded its Windows through Azure Active Directory. Now, instead of having to run your own Active Directory software, you can use the one provided by Azure. All of the administrative features of an in-house directory are now available – the complicated infrastructure which you have to maintain, and the access permissions you have to set up to allow it to work remotely. If you currently use Windows 10, you can easily join an Azure AD through its “Work Access” feature.
• Azure is easily scalable. As you grow, your IT platforms must as well. Azure allows you to build clusters of apps that can be distributed across multiple servers. Server capacity will never run out.
• Azure has global data centers in over 50 regions, more than any other cloud provider, and is adding more. This speeds up time.
• Enterprises can choose a hybrid environment so that on-site resources can be leveraged and combined with the cloud services.
• Azure provides 24/7/365 tech support and health monitoring, and in many languages.

Migration to Azure – General Considerations and Methods

Migrating live databases to the cloud is not as straightforward as one might think. Some general pre-planning will be needed.

During the migration process, no matter which method you use, you will have to plan for some co-existence of your in-house and new cloud-based systems.

• Many organizations choose to migrate in chunks, through an iterative process, test each migration thoroughly, and then decommission the in-house chunk. This is a slower process but may result in fewer issues over the long haul.
• You may have to increase local bandwidth temporarily, so that both systems can communicate with one another during the process.
• You have to plan for the sequence of the migration. Microsoft recommends migrating core services first – your active directory domain controllers, distributed file service nodes, remote desktop services, etc. – and then those services that are dependent upon the core ones. You will want to minimize this as much as possible, because charges are incurred, even if core services are not yet being used in Azure.

There are many methods of migration, and you will need to study each one, its pros and cons, and choose the method, or combination of methods, that will best suit your needs.

Before you make a final decision, your very first step will be to download the Microsoft Assessment and Planning Toolkit. This will give you detailed readiness assessment reports based upon your current in-house system and make recommendations for the process. Based upon that assessment and your own needs, you can then move forward and establish the optimal migration method.

Copying the Database Files

At first glance, this seems like a “no-brainer” and the most straightforward method. But, depending on the database type, it can result in loss of data or, in some instances, database corruption. Remember, your databases contain complicated in-memory states, and if you copy files that the database uses externally, you will not get data that is currently in-memory. The other issue is that files will be copied one at a time and will thus represent different times in your database – additional corruption is a possibility.

Copying the Disks of the Entire Machine

This is a tempting solution too. It avoids such things as installations, setup time, and mistakes. But copying to new hardware does not guarantee that your system will boot. The additional issue is that licensed software may be tied to specific in-house machines, and they may have different licenses for usage in the cloud.

Cold Export

If you have a database management system that allows export of a database while it is not running, it means that you can copy the whole thing and create a new working copy elsewhere. But there are trade-offs. This method will ensure data integrity but there will be downtime during the export and import process. This means loss of access to the systems, and that must be factored in.

Hot Export

There are database systems that allow export while a database is in use (e.g. Oracle RDBMS and Microsoft SQL). This takes longer than the cold export, but it does keep your databases accessible throughout the process. The tradeoff is that this method takes more time, and transactions that occur on your in-house database will not be migrated. There may then be consistency issues.

Continuous Replication

If you choose this method, your migration will be smooth and result in no downtime. You will also avoid consistency issues. Basically, you are going to continuously replicate the in-house system in the cloud-based one, and both become usable during the process. The big plus to this is that you can test the new system until you are ready to fully changeover, and you also have a fallback should anything go wrong with the cloud-based system.

These five methods are often dubbed “direct migration” or “re-homing,” because you’re not changing or adding to your architecture, and you are not re-developing any parts of your current system.

When You May Need New Architecture and/or Development

If you current system is rather ancient and you have been considering updating architecture or re-development, now is the time to do it. And, some ancient systems just will not migrate well, whether it’s Azure or any of the other “biggies” in the cloud service business. You have some options here, the biggest one being to re-architecture and/or re-develop your current system before using one of the direct methods, or to complete these tasks in the cloud once you have migrated your current system.

Either one of these options will result in downtime – it’s a matter of how much. But you can minimize it, if you use a direct migration method first, keep your current system running, and complete the re-architecture or re-development in the cloud.

Once you have made this decision, the changes you are making will involve only in-house decisions. Will you take a waterfall or an iterative approach? Either one will work, and the financial commitment you have made with Azure will provide you with the support you need as you accomplish this.

The Four Main Phases of Cloud Migration

No matter what method or combination of methods you choose, there will be four key phases of your migration:

• Extend your services into Azure. This simply means that you find the subscription that will meet your current needs and that will scale as your business does.
• Redirect your published URLs to Azure.
• Migrate your data, using your chosen process.
• De-commission your on-site services, either in a planned sequence or as a whole, depending on the migration process you have chosen.

Azure Migration Best Practices

While migration process differs from case to case, there are certain universal best practices worth adhering to during the active stage. As you migrate, consider these points:

Why are You Moving to the Cloud?

You need to ask this question. It may seem ridiculous, given the huge benefits of Azure, but still you have to have it clear in your mind. What is it you want out of the technology? Remember, you have to “sell” this migration to everyone in the organization and build a strong business case for it. If you don’t have a clear understanding of the business value, the migration may not turn out to be as successful as anticipated.

Identify the Assets that Will Be Migrating

This may not be an all-or-nothing endeavor. There may be assets that are better kept in-house. This will take lots of discussion of stakeholders and a firm understanding of what Azure offers. These decisions will make the migration much smoother once the process begins.

Orienting and Training Staff

The fallback position of humans is often to keep doing things the way they have been done. After all, they are working. A workforce has to be prepared for the shift. Who will do this, when, and how?

Plan for the impact that migration will have on the business

The whole point of moving to the cloud is to make your organization run more smoothly, efficiently, and profitably. But the migration itself will bring inconvenience – to your workforce and to your customers. Plan in advance for this, make sure that everyone understands the temporary negative impacts (e.g. outages), and the time period of these impacts.

Post-Migration Testing

This goes without saying. Whether you select a full fast migration or an incremental one, everything must be tested. Plan in advance how you will be testing your applications and document the testing process, so that you have a record and can refer to it if something does go awry.

This is by no means an exhaustive list of best practices, but it provides the key elements you have to put into place.

Nothing really worthwhile is easy to accomplish. And so it is when a decision is made to migrate a system to the cloud. Infopulse team has a wealth of expertise and experience with cloud migration and has executed a series of successful projects for multinational companies and smaller startups.

Contact us now to discuss your Azure migration project.