2018: The year you migrate to the cloud?

Welcome to 2018, where the rush to the cloud shows no sign of slowing down.  New Azure features are being released so quickly that the Azure marketplace seems to show new services every day.  I sometimes see new features arrive between button clicks!  It is probably safe to say that we are in the “majority adopters” phase of the traditional technology adoption curve for the cloud.

The big question for you is whether this is the year to migrate your data center assets to the cloud.

Lift and Shift vs. Application Modernization

The first thing you need to consider is whether you want to “lift and shift” your infrastructure or start an application modernization project to move your digital assets to the cloud.

Lift and Shift Methodology — This method consists of cloning your server infrastructure to the cloud and transferring the data to the new servers.  The new servers are cloned as virtual machines (VMs) operating as they did in your on-premises infrastructure.  The plan detailed below is going to focus on this methodology.

Application Modernization Methodology — This method requires you to refactor your applications for the cloud.  There are significant cost savings available long term using this method; however, the conversion cost will be much higher than a straight “lift and shift” to the cloud.

The “Lift and Shift” Plan

Azure provides several tools including Azure Migrate (public preview) and Azure Site Recovery (ASR) to execute the migration to the cloud, but you need to understand what you are trying to accomplish.  The following is a typical plan for one of these projects:

  • Assessment – Use tools to collect data in manual or automatic ways to perform a documented analysis.  Data that should be collected and analyzed include the server function, operating system, cores (or CPUs), memory, disk sizes, and network performance.
  • Selection and Planning – Once the assessment is complete, you can then select the servers or workloads that are good candidates for migration.  You should also identify any server issues such as unsupported operating systems, large disk sizes, or incompatible disk technologies.  For example, disk sizes over 4TB cannot be cloned using ASR as of this writing.  Items like available network bandwidth, maintenance windows, and business objectives need to be considered before publishing your plan.
  • Environment Preparation – With any on-premises migration to the cloud, network constraints may need to be implemented (such as QoS and firewall changes for future replication). The target also needs to be created in Azure consisting of the new network, storage, and virtual private networks.  If you are using ASR, an on-premises process server needs rollout.  In this stage, I also recommend implementing a monitoring solution where you can watch the process server health and network bandwidth.
  • Replication – This is probably the longest and most tedious part of this entire project.  At this stage, the data is replicated using the selected migration tool.  Like any backup or disaster recovery solution, the longest part of synchronization is the initial data replication.  You do not merely want to replicate all the servers at once because you could significantly affect your available network bandwidth and that could make you unpopular.  When your end users come to find you with their torches and pitchforks, that’s very bad.  I have seen in the migrations that I have managed that doing more than 2-3 initial replications at a time is the limit.  Once a server has completed the initial replication, then you can add others because the completed servers need incremental changes over time.
  • Cutover – You are almost there!  Now comes the maintenance windows where you can migrate to Azure and then disable the original server.  Depending on your project and business needs, you can either do it all at once, or break up the list based on workloads and other factors.  Doing the migrations in multiple, distinct sets reduces stress.

Here at Coretek we do many of these projects every year.  We can definitely help you with your migration to the Azure cloud!  Just give us a call.

2018-01-23T23:52:54+00:00 January 24th, 2018|Azure, blog, Cloud, Disaster Recovery|

About the Author:

Richard is an architect in the Coretek Services' Cloud Practice. He has over 20 years' experience and is a veteran in cloud, software development, and infrastructure. He has served as a director and software architect at Tyco Telecommunications, Boeing, NYSE, Vonage, Savvis, and PEER 1 Hosting. He earned his MBA and a BS in Computer Science from the University of Maryland, University College. He lives in San Antonio, Texas with his wife and daughters.

Fatal error: Uncaught exception 'GuzzleHttp\Exception\ClientException' with message 'Client error: `POST https://dc.services.visualstudio.com/v2/track` resulted in a `400 Invalid instrumentation key` response: {"itemsReceived":1,"itemsAccepted":0,"errors":[{"index":0,"statusCode":400,"message":"Invalid instrumentation key"}]} ' in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113 Stack trace: #0 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Middleware.php(66): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response)) #1 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(203): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response)) #2 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(156): GuzzleHttp\Promi in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php on line 113