Migrating a Microsoft Stack from a local VM to Microsoft Azure (Part I)

Hepta Analytics recently completed a successful migration project of a Microsoft application stack to Microsoft Azure. By “Microsoft application stack”, I am referring to ASP.NET and Classic ASP applications running on Microsoft IIS which connect to a Microsoft SQL database all on top of a Windows Server operating system. In this three-part series, Benson and I will share our experience of working on this project, detail how we set up a CI/CD pipeline on Azure and discuss challenges faced together with their resolutions.

For context: were operating within strict timelines (less than one calendar month) with the primary goal being to move away from the old provider and shut down that service by the end of the month. Further, although the dozen applications and almost as many databases were generating low traffic through the migration period, downtime was still unacceptable as content was being uploaded to the interactive platform.

And so we began this migration project by revisiting our plan. Step one was to migrate the databases, check their integrity and, if okay, document that process together with time taken to execute it. Next was to migrate the applications and check that they were running fine. The third step was connecting the applications to the databases on Azure and continue extensive testing. The fourth step was setting up the CI/CD pipeline with Github integration and staging the client’s development applications accordingly. The final step was to go live: Synchronizing the latest database changes followed by an immediate shutdown of the old site while simultaneously changing the DNS records to point to the new site.

Microsoft offers a tool for database migration known as “Data Migration Assistant”. This tool was very useful in letting us know how sensitive the databases were. But because we were dealing with an old database version that supported some legacy functions and code, this tool was not able to meet our migration needs beyond providing information. Most unfortunately, the tool did not allow for migration to the same database version and forced us to move to the next one which was going to break a lot things. Given the strict timelines, we had to find other means to migrate the data and ended up resorting to age-old backup and restore method.

Next, we migrated the applications. Again, Microsoft provided a handy tool for this known as “Azure App Service Migration Assistant”. This brilliant tool connects to the local IIS server, extracts each application with some of its settings and migrates the entire package onto an Azure App Service. Azure App Service is a Platform as a Service (Paas) solution that is a brilliant way to host either Linux or Windows based applications without having to manage an entire operating system. Unlike the DB tool, this one worked well for us, save for some minor tweaking.

Connecting the applications to our databases was rather straightforward as most application credentials were in the infamous Web.Config file for ASP.NET applications and global.asa for Classic ASP applications. The credentials that were not in there, however, had to be fished out and this proved quite challenging but was completed nonetheless.

Next, we set up the CI/CD pipeline with Github which will be covered extensively by Benson in the next post.

Finally, we synchronized the latest changes on the databases then proceeded to change the DNS records to point to the new site. Fortunately, Azure had one IP address for all “A records” so this was a relatively quick and easy task. For CNAME records used by subdomains, we benefited from having used a standard naming convention for the app services which meant we could quickly change the CNAME records without having to refer to anything. The last and final step was to configure the SSL certificates which is a point and click affair on Azure once the certificate is uploaded.

Overall, the migration was completed successfully save for the fact that our extensive testing was hampered by the client’s use of domain redirection – especially when logged in. This severely affected our ability to conduct conclusive tests on all applications especially given the brief timeline. In the end, the errors were aptly resolved once we went live.

After completion, we continued to support the client and performed extensive training – especially on the CI/CD pipeline – to ensure that they were well versed with the new way of doing things and provided documentation to that effect.

In the next blogpost in this series, Benson will elaborate further how we set up the pipeline on Azure. I will then return to touch on some of the benefits and challenges of using Microsoft Azure as opposed to AWS which we are well versed in. Until then, kwaherini!

Also published on Medium.