Our Technical Architect, Tom, talks us through some of the main issues to watch for if you’re thinking of migrating to Microsoft Azure and how, despite teething issues, he’s now a fan.

In a recent article, my colleague Mike talked about why you need to break up with legacy tech. As he put it, “No matter how complex it seems, breaking up will always be a step in the right direction”. Having recently migrated a large on-premise system to Microsoft Azure, I completely agree.

A few sleepless nights were had, but we overcame the hurdles we faced to deliver a future-proofed system. Having always been a big Google fan, I’ve been pleasantly surprised with the product, tools, and service. They’ve made a big effort towards becoming more open and appealing to developers over the past few years – and it really shows. If you’re looking to migrate to a modern, flexible, cloud-based service, I’d highly recommend it.

In this article, I’ll run you through some of the main issues we encountered and the workarounds we found, so if you opt for Azure, you can plan for them ahead of time.


1. Plan to deploy

Whenever you move an application somewhere new, you're likely to have teething issues and you're going to need to change things. Even if, by some miracle, everything goes exactly as planned, development never stands still. This means there are always new features to deploy or bug fixes to be grappling with.

You're going to want to just keep up your normal pace of development as soon as you’ve finished your migration. So you need to know how you're going to get your software to where it needs to sit and hit the ground running. Build pipelines can often be a primary focus – especially as deadlines approach – so you may need to find workarounds.

Our workaround?

Whilst we plan to re-engineer our existing pipeline, we have been able to make use of Azure's handy AZ Command-Line Tool that has helped us create and manage resources. One of the commands allows us to import from an existing repository to our new repo in Azure (ACR) ready for deployment. This is just one of the features we’ve found invaluable.

2. The hidden surprises in legacy code

As Mike highlighted in his article, one of the big issues with legacy systems is that they often contain hidden secrets in the form of super old code. This can cause issues even when you’re just planning for a ‘lift and shift’ migration.

One of the most worrying things we discovered was single page load making upwards of 30 requests to the database and generating a new connection for each of them. Coupled with an additional security requirement – imposed as part of the migration – this led to an unacceptable level of overhead and was affecting the performance.

The fact is, there will be unknowns, if you try and preempt everything you’re going to be stuck. It’s always better to bite the bullet and just start.

Our workaround?

Quite simply, our workaround for this was to do the best we could to modernise the database connection code. We were able to switch the connection implementation to use a singleton, which meant that the database could actually reuse a connection for the process of a request. We also leant quite heavily on the use of caching. All of which helped reduce the page load time.

3. Monitoring and optimising

We expected teething issues and wanted to fix them as soon as they emerged. The metrics and logging functionality that comes almost out of the box with most Azure components has been really useful for this.

For example, we discovered we had a URL that was leading to a 404 page and receiving tens of thousands of requests within the space of half an hour. Before we were on Azure that would have caused us a lot of problems. We wouldn't have known where to find it, how to go about understanding the source or tracking it across our different regions. But the in-built tools are excellent, and it only took us a few minutes to identify the issue.

Our workaround?

Rather than block the IP, which could have blocked some legitimate requests, we were able to use a dynamic block in the firewall to only block high numbers of requests from the same IP in a short timeframe.

4. Maintaining performance

Overall, performance hasn’t suffered. However, in some areas we've had to put in stop gaps solutions. One particular area is our API log search applications, where we are currently using Azure files for data storage, and finding it tricky to search over data efficiently.

Following the migration we found that the existing application was taking up to 7 minutes to return a result when it worked. Sometimes we got nothing at all.

Our workaround? 

We've now moved to a premium share and we're seeing requests move from roughly 7 minutes to 1.5 minutes. We’re looking at ways to improve this further, for example using Microsoft Cognitive Search, which looks highly promising.

Use your migration as an opportunity

Migrating to Microsoft Azure – or any cloud system – is never going to be 100% straightforward. Teething problems are unavoidable, no matter how well you plan or how powerful the technology is. However, the key is to use these issues as an opportunity to improve your processes and problem points. For example, we’ve started using infrastructure as code via Terraform. We also moved away from YAML files to Helm charts, which make running the software far leaner.

The end result is that we’ve ended up with a superior system all round, with a migration that was much easier than expected. You never know, Microsoft might make a fanboy of me yet.