Migrating to Azure

Overview

So, you’ve decided that you want to migrate to the Cloud.  Moving to a cloud service provider such as Azure is not something that should be taken lightly.  However, it’s reasonable to plan and execute while keeping downtime to a minimum.  The topics to be discussed in this article are going to focus on Azure but keep in mind that most of them also apply when moving to all cloud service providers.

At JBS, we offer services to lift & shift clients out to the cloud provider that best suits their needs.  Lift & shift is a term used to describe the process of taking an on-premise environment and migrating it to a cloud provider such as Azure while changing as little of the infrastructure as possible.  Doing a lift & shift operation is often the most pragmatic way to get to the cloud instead of attempting to migrate while also taking advantage of Platform as a Service (PaaS) options given the complexity of all the moving parts.  Based on our experiences with doing cloud migrations, we will outline the good, the bad, and the ugly of doing so.

Why?

When working in an on-premise environment, there are many hurdles that businesses run into especially as they continue to grow.  Within a physical data center, you need to size your hardware needs for worst-case scenario.  In addition to hardware considerations, your data pipe needs to be set up for worst-case scenario as well.  Thus, you will likely need to oversize your environment when much of the time, you don’t need that.  Aside from paying for more than you need, you may also need to manage, update, and oversee all the extra infrastructure necessary to support worst case scenario.

Within a cloud offering such as Azure, your business can size its infrastructure for its needs today and can scale up & out to support your growing needs.  You can also leverage Azure to be able to compress your existing environment to save on operating costs.  Your infrastructure can also be set up so that it can automatically scale in accordance with the needs of your applications to avoid unnecessary end-user impact.

Focus on core business

Azure also allows you to focus on your core business needs instead of managing the supporting infrastructure which can help to make your offerings more efficient by reducing your time to market.  Azure also allows you to be more agile with your business by removing the pain of acquiring and setting up hardware to support your applications.

Reduced complexity

Another benefit of relocating to the cloud is that it simplifies your infrastructure management needs by reducing several areas that no longer need to be managed.  While it’s not a silver bullet and there are still going to be components that need to be managed, there are quite a few burdensome infrastructure responsibilities that can be eliminated.

Cost savings

With reduced complexity and reduced infrastructure responsibilities, your operating costs can also be reduced.  Several large cost areas we often find with clients are licensing, warranty, hardware, and bandwidth.

When using Azure, you still have the option to bring your own licensing however in all the cases we have seen, it is easier (and cheaper) to leverage either Platform as a Service (PaaS) or to use Marketplace images with the licensing costs baked into the instance.  The reason for this is that it gives a realistic picture of the costs and fewer things to manage.  Additionally, when using a service provider like Azure, dealing with warranty and hardware support is a thing of the past as well.  When hosting on-premise, you are also likely to be subject to bandwidth constraints and audits from your provider to ensure you are able to support your highest-traffic times whereas, with Azure, you are able to keep costs lower by tailoring your offering to only what is necessary.

When setting up the target environment in Azure, one area where we have found for clients to reduce costs is to reduce the number and size of the servers within the environment.  By scaling back, the environment to only what is needed, clients can reduce their monthly spending by only paying for what they truly require on a day to day basis.

How to get buy-in from the business

The idea of moving to the cloud will sometimes come from the business or in other cases it will come from groups within the organization such as IT.  If the push to migrate comes from the business side, getting the project off the ground is easier.  However, that is not always the case and you will need to convince the business to gain buy-in.

Cost

Cost is the number one question that we receive when giving talks about cloud migration.  Because the costs are right there in front of you for what a deployment will cost, it can at first be off-putting to the business.  The reason for this is because on-premise installations have many hidden costs that make it appear like it’s cheaper to host.  The hidden costs I’m referring to are things like:

• Power audits
• Licensing audits & costs
• Warranty support
• Hardware installation costs
• Hardware procurement costs
• Cabling costs

These areas all add up to time and money but when you are looking at the cost of a server, these costs don’t typically get discussed.  When working with a cloud provider like Azure, the cost is shown upfront so that’s why it’s important to think about the hidden costs that you get to alleviate by using an offering like Azure.  It is often difficult to quantify the hidden costs of hosting on-premise though so it will take some time to get together an accurate assessment of current costs.

Security

Aside from the cost, security is the second biggest concern that businesses have for migrating to the cloud.  And with PaaS offerings, it becomes an even bigger concern because now you may be talking about having a service that is going to live outside of your protected VLAN.  However more recently Azure started offering PaaS offerings like App Services which can live within your protected VLAN with a premium subscription.  While you aren’t forced to use PaaS, there are some useful scenarios where it can make sense for you to entertain using it.

Microsoft has all its security-related documentation for Azure available through its website (link) and their offering is compliant with all the major compliance organizations.  One topic that our team has heard come up again and again with Azure security is that by moving to Azure, you are perhaps making your business a bigger target for hackers and attacks.  That can be true however if the only way that your application is secure is through security by obscurity, then you are unfortunately begging for trouble.

The Azure platform itself is made secure from hackers and attacks but it is still up to you and your business to leverage the tools and best practices they make available to ensure your security is still a top priority.  Azure also leverages Artificial Intelligence (AI) to identify potential attacks which is something that would be very costly to do on-premise.

Agility

Cloud providers provide a unique way to right-size your environment for your current needs.  And since the needs of the business are always changing, the footprint of the environment can change with it.  For example, in the eCommerce space, the holidays provide special challenges when it comes to supporting a great user experience and maintaining uptime.  With a typical on-premise scenario, you would size up your hardware needs so that you can support the massive influx of traffic during the holiday season but you don’t need that hardware for the rest of the year.  With a platform like Azure, you can set up your environment to automatically scale out & up based on performance metrics, timing, or manually.  This allows for you to scale out the environment for Black Friday through Cyber Monday or for the back to school rush then scale it back to avoid paying for more than you need to use.  All the while, maintaining at least 99.95% uptime.

What are you going to run into?

So now the business is on board and you are planning your migration.  What issues are you going to encounter?

Data migrations

It’s been our experience that getting your data out to Azure is going to be the longest part of the actual migration process itself.  Focusing on SQL Server specifically, some of the big topics you will hit will be version and edition changes.  This is especially true if you are on an older version of SQL Server if you are looking to upgrade during the migration.

To see what you’re in for, we suggest downloading the Data Migration Assistant (DMA) tool and running it against your current source database servers.  The DMA tool will analyze your source databases and determine what portions (if any) will be issues for the migration.  It will not find all the issues but it will find a vast majority of them.  Once all the upgrade issues are identified & deployed to the source system, then any lingering issues can be resolved while testing your applications in Azure before the actual migration.

If you are considering moving to the SQL Azure PaaS offering, you will have more upgrade considerations that will need to be dealt with prior to migration.  Additionally, the export & import process currently takes significantly longer than a backup & restore for the same size database.  That may be something to consider if downtime needs to be minimized.  We’d suggest that if your goal is to migrate to SQL Azure then you consider first moving to a full-blown SQL installation for the purposes of moving to Azure.  Then once you have finished the migration, you schedule out a separate migration just to move to SQL Azure.  The migration times will be reduced significantly and it reduces the number of moving parts during the initial migration.

Security

Security is of course a big concern on everyone’s mind when it comes to cloud platforms like Azure.  Specifically, our team often hears from clients looking to move that by moving to Azure, they are becoming a bigger target for hackers since the Azure platform itself is much more well-known than their on-premise environment.  Clients feel a certain degree of safety as a result of hosting on-premise because they would need to be specifically targeted.

That is one reason why Microsoft has focused so heavily on security in its platform.  A security breach of any scale would ruin a cloud provider so Microsoft has made it a top priority to ensure that Azure is a platform that can be trusted.  Because of that, they have focused on ensuring their platform conforms to various compliance regulatory committees to gain the trust of their user base.  We suggest reviewing the documentation within their Trust Center for details on the various compliance that Azure holds.

Documentation

A double-edged sword with Azure is that they are constantly adding new features and while that is great, it does have the downside of the documentation not being up to date with the current Azure offering.

What we have found is that the documentation is accurate however the examples are sometimes out of date.  Most of the time this is simply because there have been upgrades that now make things simpler to do and the documentation has a hard time keeping up.  It’s not a huge deal, but it is something to be aware of.

Load balancers

Azure load balancers are a little different from what you are likely used to as an IT professional.  With most on-premise load balancers, you get nearly full control of all the aspects of the way the traffic is routed.  With Azure, most of the nitty-gritty is abstracted from you so it will take a little getting used to.  However, you can tap into diagnostics data to get more feedback from the load balancer should you need it.  There are also some nice benefits from the Azure load balancer that you don’t get from many on-premise load balancers as well like the ability to automatically reconfigure itself and direct integration with virtual machines & cloud services.  And more features are always being added to Azure so the load balancers will continue to get better as well.

How much is it really going to cost?

Before jumping into any new platform, it’s always good to know what your consumption and associated costs will be.  This is a key reason why it’s one of the top questions we get from people looking to migrate.

Before knowing what the costs are going to be, you need to ensure you have a good handle on what your current environment is made up of.  Knowing all the details of your existing environment is crucial to being able to accurately forecast and we cannot stress that enough.

To accurately project your hardware spend, you need to ensure that you are changing things at a known rate.  What we mean is that if you are continuing to change the environment by adding, removing, or scaling components within it, you will have a hard time accurately gauging your projected spend unless it’s done in a repeatable way that can be projected.

Azure calculator

Your first stop should be to the Azure Calculator and plug in all the facets of your environment to get a baseline of what your current footprint would cost.  It is honestly going to be staggering… however, you will not need to exactly replicate your existing on-premise environment out on Azure so that should not deter you.  In fact, with all the clients we have migrated, we are consistently surprised that we can use smaller instance sizes on the Azure side versus on-premise and still maintain the same (or better) level of service.

Scaling

When talking about scaling with an environment like Azure, there are less logistical nightmares to deal with in doing so.  You need to determine if you are going to scale up or out and by how much you are going to scale up or out.  Then you need to determine how to trigger the environment to shrink back down to normal size.  I’m oversimplifying a little but the point is that once you know what target you are trying to hit, you can have the environment scale to meet the goal.  It also gives options to alter the way the scale process takes place as well.  Going back to the eCommerce example from before… if you are planning for the holidays and Black Friday traffic, you need to ensure your site stays online and responsive so that sales are not lost.  The way to do so would be to run load tests on your site ahead of time, then you can determine how far you must scale to meet the demands and then determine trigger points so that you can scale things back once the load has dropped back to normal levels.

The process

So, what are the steps to perform the actual migration to Azure?

Planning

Planning is going to be the biggest part of the migration.  It can truly make or break a migration though so it’s worth investing the time up front to avoid headaches later.  We suggest going through the following steps with your planning efforts:

• Audit and document all the components that need to be migrated to Azure
  • Additionally, you will want to rate them in terms of how difficult you feel they will be to move and which components are business-critical. Now is a great time to identify old components that could be pruned and skipped during the migration.
• Identify migration blockers and create mitigation plans
  • It is rare to find something that cannot be migrated to a cloud provider but there are rare circumstances where it does come up so you want to find out about those upfront and work to try to mitigate them at all costs.
  • One reason that people typically say they are blocked from migrating is that they have clients of their own that are afraid of the cloud or “will never go for it”. We highly recommend having a conversation with them and go over the reasons for the migration and help to alleviate any concerns they have.  Communication is key for migrations like this.
• Identify legacy applications that need to be upgraded to migrate
  • Keep in mind that many older systems are still supported on Azure. If possible and if it makes sense, upgrading can be the path of least resistance.  However in cases where those legacy applications need to continue running on older versions of Windows or Linux for whatever reason we recommend checking over the Site Recovery tools available from Azure to aid you in the migration process.
  • You may need to make some alterations to the source environment and systems to prepare for the upgrade so keep that in mind while you are in the planning phase. When moving to Azure, you will want to ensure that your applications can be load balanced and with some legacy applications that may require changes to the source system to support that.  Additionally, our teams have seen cases where legacy SQL Server installations will require updates at the source to be able to migrate without issue.
• Identify applications that are resource-intensive and ones that can be downsized
  • To ensure that you are right-sizing your environment, you will want to identify where you can scale machines back or reduce nodes. You won’t be able to do this everywhere but there are always places where you can trim an on-premise environment that is migrating to Azure.  After you’ve gone through the machines and you’ve identified places where you can trim, look at components where you can leverage Azure alternatives.  Examples of those types of components would be Activity Directory, Exchange, Load Balancers, Monitoring, Databases, etc.
• Identify networking components
  • While you will not have to cable the environment in Azure, you still need to set up the environment in such a way that it meets the requirements of your systems. Another consideration you will need to make is that while the Azure platform itself is compliant with several regulating bodies like being PCI compliant, you still need to ensure that your applications are also compliant.
• Document the environment, the steps and the plan of attack
  • No one likes creating documentation so it’s often something we leave until the end. That is a big mistake especially for a migration like this.  By skipping the documentation, there are bound to be issues during the migration or afterward where they can have catastrophic effects.

Testing

Testing is integral to success with these migrations.  We recommend that you get started on testing on both the actual migration itself as well as testing the applications in Azure as soon as you can.  And as you are testing, make sure you are updating the documentation components.

When testing the migration, we recommend using your documentation as your guide.  This will force you to find issues along the way before you get to the migration day.  If you continue to run the migration plan, again and again, it will become second nature until there are no hiccups during the final migration.

While the migration testing is happening, you will want to test out the applications migrated to Azure during testing.  This is going to let you fine-tune the size of the target machines and weed out issues before the actual migration takes place.  Just be careful with any components that have external dependencies so that you aren’t impacting any downstream components.

To perform the testing, we have found that the Azure Site Recovery tool is invaluable.  You can leverage the tool to set up your migration effort and have it set up to be repeatable.  It allows for you to set it up to synchronize from the source system to Azure so as things change in the source system, there is no loss once the migration needs to happen.

Migration

Believe it or not, the actual migration is the easy part… by far the most stressful, but it’s easier.  Depending on the size and complexity of your environment, the actual migration process can range in time but we have found that it usually only lasts a few hours for a production environment.

Prior to the production migration, we find it’s easiest to migrate the other environments of your application first (i.e. Development, then Acceptance, Staging, etc.).  This process gives everyone a chance to start using the new environment before everything is out on production.  The downside of this is that you are more likely to have some overlap in the environments so your internal staff may have to use two VPN connections or things of that nature as a temporary measure until everything is migrated.

Again, we recommend using the Site Recovery tool for the actual migration because it helps to limit the downtime since the environments are already synchronized so it reduces the cut over time.

More Testing

Once the migration is over and you’ve done the initial round of testing, you will want to make sure you run through a full regression test to cover your bases.  Prior to the actual migration, you should have already run a load test to size the environment effectively so that shouldn’t be required at this point.  But you will want to analyze the users on your application to ensure that there are no new issues that are lurking that aren’t immediately apparent.  For eCommerce sites, you would look at your site metrics to verify that your conversion rate, average user timespan, etc. are all coming back as expected.  Other platforms should use their typical metrics to validate the overall health of the applications.

Cost Analysis & Reduction

The first month out on Azure usually is a little more than what you determined in your planning phase so not to worry.  It shouldn’t be grossly out of line with your estimates but we just want to bring it up that it is more than likely going to be a little higher than you anticipated for a monthly charge due to the migration itself, altering the sizes of virtual machines, etc.

After things are out on Azure and you have let them settle, you want to come back around for a self-evaluation of the environment and look for ways to trim and reorganize so that you can save on your monthly consumption.  For example, you may want to do some testing with using smaller instance sizes but perhaps more of them.  In some cases, the initial virtual machines that you’ve migrated over can be cheaper to scale down and set up more instances that are smaller and use less consumption.  Also, consider looking at PaaS offerings which would let you remove virtual machines in lieu of using that type of platform as a service offering.

Looking back / Debrief

It’s likely going to take longer than you anticipate at first to plan and execute your migration.  Once you map out all the pieces and determine your plan of attack, you are going to have a much better idea of what it will take.  Unfortunately, since all businesses and setups are different, there isn’t a clear cut answer for how long it should take for your migration.

While the process to migrate may seem daunting at first, with the right people and the right steps to plan and test out the migration, it is reasonable to do and can offer significant cost savings to your business in the long run while also setting up your business to be more competitive in your space.