Common Migration Strategies

As part of the cloud adoption journey, companies around the world may need to decide on the strategy to get their IaaS workloads migrated to Azure. Some of the common strategies are covered in this blog:

Parallel Migration

There will be times when there would be a push from application or business teams to migrate their application to Azure without touching their existing environment. Or there could be a technical reason as well to do so. Hence, during these scenarios migrating using migration tool-sets such as Azure Migrate or any 3rd party tool wouldn’t be an option.

This would then lead to building of a parallel environment in Azure, by basically cloning the application and/or web server(s) to Azure and taking database copies of the application to a SQL server in Azure. Make the necessary changes from infra and application end on all the three tiers to ensure that they can speak to each other in this new target environment (Azure in this case). Now the application can be tested whether it is working as expected and make the necessary corrections to fix any issues.

Finally, once the business and application teams are satisfied, perform the cut-over by copying across the delta changes mostly on the DB tier. It is probably the safest approach to perform migration of applications that call for this approach, as this would almost eliminate the need to roll back the migration.

Apart from the parallel build requirement for individual applications there was a classic case to cutover an entire customer environment to Azure. These included Active Directory Domain Controllers, File Servers (using DFSR), SQL Servers, Customer LOB App servers, Citrix Servers. This was achieved by understanding the application architecture, dependencies and the components which are static/dynamic. Finally these were recreated as a parallel build in Azure. Then the static components were simply recreated using copies of those server images. Dynamic ones, like the File servers were synced using robocopy to an Azure counterpart server and then post cutover the DFSR replication was re-enabled with another instance of a file server running in Azure. SQL cluster was built afresh. However, for the application server architecture I had to dig out the config files to understand the post-cutover config changes required. Finally, a temporary application endpoint (a website on the load balancer with a temp URL) was setup for this application. Once all concerned parties tested this parallel environment using this temp URL, we were good to cutover the entire environment to Azure. So a downtime was sought for this work and during cutover - delta file sync was carried out, Restoration of DB’s from backups was done and finally the switch to this new Azure hosted application endpoint was made at the DNS level. Although I’ve made it look quite simple, which it is, it needed some planning and needless to say the beast that DFSR is to ensure replication works (as that was the only thing I was worried about and it worked as a charm though).

Infrastructure application migration

Most of the infra applications such as AD, DNS, File Server, etc. have got various articles covering their migration strategy to any public cloud. So, we aren’t going to discuss these infra apps here, just sighting one such common infrastructure service which generally most companies use, i.e. a print service. There are newer print management solutions available in the market such as Equitrac, but here we are going to focus on companies which are still using Windows Print server as their print solution.

Ideally applications such as a print server, is generally best hosted at on-premises, as it ensures that this service is closer to its consumers. Otherwise, if it is hosted in Azure then this would mean the print request from the client machine will be sent to the Print Server in Azure and then the print request will be directed to the printer, so the traffic is traversing twice through Azure for a single print request. However, if the business decision is to move almost all services possible to Azure, then this can be done too without any issues, as long as the necessary ports are allowed on the firewall side in Azure as well as any network devices controlling traffic to the printers at customer site locations.

There is a new feature recently released in private preview (as of May 2020) called “Universal Print” which is in private preview and could provide this capability in Azure without the need to host IaaS based print servers in Azure, probably it might be good to evaluate whether that meets your requirements once it is GA.

Database Server Migration

Most common scenario we come across is when the databases for applications are spread across various central database servers (taking SQL servers as an example here). And also, there might be cases wherein databases of different applications are running on the central database server. So that would mean it would be difficult to move the application to Azure, if the migration is focused on an App level approach.

One of the available solutions is to create a highly available target database environment in Azure and then migrate the database(s) specific to the application being migrated individually. This way there is a better control over the migration and helps avoid a big bang migration approach which may not be technically feasible. This solution can be utilized for large and complex environments.

However, if the environment is smaller then a big bang cut-over of the applications along with standalone database server(s) might need to be evaluated accordingly.

Migration Challenges

Every large-scale and complex migration has some or the other issue(s), no matter how much you plan. Certain things would be out of your control. I’ve mentioned few such interesting issue(s) that I came across while migrating servers to Azure.

• Migrating an application that uses an outdated SMB Protocol – An old application that was running on a Win2008R2 based server was using an outdated SMB protocol (v1), because this application is susceptible to corruption if “Opportunistic File Locking” feature is enabled, which was only possible to be turned off in SMBv1 earlier. Now the challenge was that Microsoft doesn’t recommend using SMBv1 and it was a strict no from a security point of view. Hence, we needed to ensure that the application’s requirement as well as the security constraint is addressed at the same time in order to migrate this application to Azure. Hence, it was decided to clone the application server VM and perform an in-place upgrade of the cloned VM to Win2012 and above OS (that was compatible with the application) as the SMBv3 allows to disable “Opportunistic File Locking / File Leasing” feature in SMBv3. This approach helped us to disable SMBv1 and utilize the supported version of the SMB protocol and eventually led to us to successfully migrate this application to Azure.
• FTPS issue related to SAP – One of the issues we encountered was when we were migrating an application using IIS based FTPS to import/export files to SAP. Now as this application required a parallel environment build, the copy of the server in Azure had a new name and also had its FTPS site made to use the updated certificate based on the new server name. However, the SAP FTPS jobs were failing, after lots of troubleshooting it was identified to be an issue at the SAP end and it was being caused by the optional feature called, “Strict Hostname Checking” as part of the SSL handshake. After this feature was disabled the SAP transfers started working as expected.
• IIS based website migration issue – Another issue was encountered when one of the websites within an IIS server was cut-over to Azure and the load-balancer in this case Citrix Netscaler was throwing a Service Unavailable error. After some troubleshooting it was identified as an issue related to the “Negotiate Client Certificate” being in disabled state for this site in IIS. So, after enabling the same it resolved this issue and the website was accessible.