You’ve already made the decision to embrace Azure? Congratulations, great decision.
Now then, if you’ve read the previous three blogs in this series, you may have noticed that we’ve been developing a theme. Each blog has become more focused and detailed as the series has progressed. This blog – Turbocharge your Enterprise Applications with Azure – looks at where to start. But, before diving in, let’s revisit where we’ve got to so far…
The first blog explained why Azure is the future and was designed to make the case for Azure over other hyper-scale cloud providers. The second one suggested four low-commitment ways for companies to start with Azure; backups, domain controllers, test and dev servers and SQL server. The third blog developed the theme of migrating Line of Business applications to Azure, because that’s how you turbocharge your enterprise. This blog explores the most commonly asked question we encounter with Azure migrations; “How should we decide which systems or applications to migrate to Azure first?”
This may seem a little obvious, but a good starting point to explaining which applications come first is to define which ones are being considered.
In this blog, we’re talking primarily about line-of-business applications that are either hosted on your servers on-premises or in a local hosting facility. So, we’re talking about things like accounting software as well as CRM, MRP, ERP and bespoke applications – basically, the tools you use to do your work.
You may have applications hosted in another hyper-scale cloud platform like Amazon Web Services (AWS) too, and if you want to migrate them to Azure, then the comments in this blog apply to those as well.
Back to line-of-business applications, it’s very likely you could technically migrate all or almost all your systems to Azure. Even so, it’s highly unlikely and highly inadvisable to consider migrating everything in one go. You may have no choice, of course, if all your systems are highly integrated, but for now, let’s assume they’re not.
So… how do you decide where to start? The slightly unhelpful answer is “that depends on the needs of your business”.
Services and line-of-business systems that have the following requirements are excellent candidates to be deployed in Azure. The flip side of that argument is these requirements also make them poor candidates for on-premise hosting.
Other reasons for selecting candidate system to migrate are:
Users are very quick to point out systems that are slowing up, unreliable or even unworkable. These are very good indicators that you might need to migrate an application. What’s the root of the problem?
Your on-premises hardware may be coming to the end of its life or be obsolete. Rather than go to the expense of replacing a server, you should consider migrating the application to Azure. Your users will get a faster, more reliable and consistent experience and you’ll eliminate the capital expenditure related to buying and commissioning a new server.
Your hardware might be in-life, but simply unreliable. Hardware does fail and it’s much easier and better value to migrate than mend.
Your systems could be slowing up because your servers lack the processing power to drive your applications, particularly if upgraded versions are more resource hungry or you’ve been adding users. One of the single biggest benefits of cloud-based architectures is on-demand scalability. Server performance never needs to be an issue again.
Your users may be operating an application that you want to update to the latest version, but it requires a version update for the supporting SQL Server. We encountered exactly this situation at Caligor Coughlan and you can read the full story in the published case study and download a PDF copy. Caligor Coghlan wanted to upgrade Sage 200 but couldn’t without an updated SQL Server. This was a pressing issue and became the catalyst to start their Azure migration. It was quicker, simpler and lower cost to migrate Sage to Azure than to replace the hardware and upgrade SQL on their on-premise servers.
If your systems are coming up for license renewal – like a SQL Server License – and you want to avoid the cost, it might just be the imperative you need to consider migrating. With Azure IaaS, PaaS and SaaS options, your SQL Server Licenses are built-in to your usage price, so they become an operating expense rather than a capital expense. And of course, you never need to worry about whether your license is live or not – with Azure, you’re always licensed.
A very common driver for migrating applications to Azure is to modernise them to make them more scalable, resilient and easily accessible. We covered the main methods of modernisation in our last blog (re-host, replace, refactor, rearchitect and rebuild). All methods allow you to add capability. For example, if your company is acquisitive, growing rapidly or expanding into new territories, hosting your line-of-business in the cloud allows you to scale your applications instantly.
If you’re innovating and need to commission new test or development servers, Azure also offers a very simple and cost-effective route.
Whatever your drivers are for migrating your applications to Azure, you’ll need to think about how your network includes the workloads running in Azure. The usual method is to add a Domain Controller in Azure and set up a site-to-site VPN from your on-premises network to your virtual network in Azure. This allows you to extend your network to seamlessly include the workloads running in Azure, provide additional resilience for your on-premises Domain Controllers and provide Active Directory local to the line-of-business workloads in Azure.
This hybrid on-premises / Azure environment allows you easily to migrate further workloads as and when the timing is right. The drivers for such decisions are exactly those already described above.
Operating a hybrid environment also means that, if you need to add any new systems, you have the choice of adding them in Azure or adding them on-premises.
If you are operating a hybrid environment, you have choices to make about which applications get hosted where. All of the above advice still applies and, as far as we’re concerned, once you’ve started the Azure journey, there aren’t many reasons for hosting new applications locally. Where you host is a strategic choice and your strategy is *your* strategy. We’re here to support it.
In our next blog, we’re going to explore how to optimise your Azure usage. The premise? All companies should seek to optimise the balance between the services their IT environment delivers to the business and what they pay for it.