Line-of-Business (LOB) servers and databases
Most customer environments include one or more line-of-business (LOB) applications. These could be an accounting system like QuickBooks, Peachtree or Sage Accounting, ERP applications, CRM applications, design applications, proprietary databases, and more.
These LOB applications have a few things in common (unless they are fully cloud-hosted like QuickBooks Online). There is typically a database backend such as SQL Server, MySQL, Access, or a similar technology. A client application that accesses the database can be browser-based with the web app running on another server or the database server itself. In many cases, the client application is installed on a user’s desktop with the desktop version of QuickBooks being a prime example. Sometimes there is also an application server that sits between the client app and the database backend.
When planning to migrate a LOB application, these three tiers should be considered individually: database tier, application mid-tier, and client. Let’s look at the considerations for each.
Azure offers many platform-as-a-service (PaaS) database options, especially for SQL Server. You can run SQL Server on a VM in Azure that you manage, one that Microsoft manages, or use the Azure SQL database-as-a-service product. Take a look at this comprehensive overview of the various SQL Server options in Azure, including cost analysis.
If the database backend of the LOB application is not SQL Server - or even if it is, and you want to maintain full administrative control of the database - you will likely want to migrate it to a VM in Azure.
This can be done by creating a new, clean VM in Azure, reinstalling the appropriate version of the database engine, and manually moving the database.
The advantage of this “fresh start” approach is that you’ll have an up-to-date, clean database environment on the latest version of Windows Server. The disadvantage is the migration complexity and the need to reconfigure security.
We typically see MSPs start fresh when the database tier is simple and can be easily re-installed and data transferred. Also, if the existing database engine version is badly out-of-date and needs to be upgraded as part of the Azure migration, the “fresh start” approach is best.
Often the existing database tier will be complex and difficult to recreate in a new VM environment. In such a case, a “lift-and-shift” approach is best. It is possible to use Azure Site Recovery (ASR) to replicate the database VM(s) from on-premises to a staging area in Azure and put it into production at the right time.
This approach requires no changes to the VM itself other than the IP address. AD domain membership, DNS name, OS configuration, and all settings remain intact. It also involves deploying an Azure environment to land the database workloads, creating site-to-site VPN connectivity between the two environments, extending on-premises Active Directory to the Azure environment, setting up ASR to replicate the database servers, and failing over when ready.
We've created this guide that outlines what needs to be done and how to migrate a server from on-premises to Azure in a single afternoon.
For LOB applications that have application mid-tier between the client and database, the migration approach is similar to the database tier. If the application tier can be easily re-installed on a clean, new VM, that’s the preferred option. However, if the application is complex and re-installing the mid-tier isn’t an option, then performing a “lift-and-shift” migration of the mid-tier servers to Azure is the way to go.
This would follow the same set of steps outlined above for a database migration using ASR. Typically, a lift-and-shift database migration strategy would apply to the application mid-tier and a fresh re-install migration strategy for the database would also apply to the mid-tier.
The client application could be installed on each user’s desktop or be browser-based. If browser-based, then there is likely a web server (e.g. IIS or Apache) running the front-end. Migrating the web server is no different than migrating the database or mid-tier. Either reinstall it on a new VM, or use ASR to lift-and-shift the existing web server to Azure.
If the client application is installed on users’ desktops, then things get a bit more complicated. Many installed client apps are “chatty” and when separated from the database by a WAN, they do not perform well. This is something that you should test before finalizing your application migration strategy. The question is: can the client application remain installed on users’ local desktops, while the database and mid-tier are moved to Azure?
For example, if your end users already use a VPN when outside of the office to access LAN-hosted applications, then performance after the migration won’t be any worse than when used with VPN today. However, if the client application must be on the same LAN as the database and separating the two across the internet will degrade performance, then desktop or application-streaming technology must be used.
Desktop-installed applications can be easily deployed in Azure with Nerdio and published as either full desktops or individual RemoteApps using RDS or WVD technology. The client app will run on the same LAN as the database and mid-tier to ensure optimal performance. When deploying desktop or app virtualization, you’ll also need to consider printing, scanning, data transfer, and other variables. See the Desktops and Applications section of this article for more.
Application Migration Timing
By now you’ve identified the components of your LOB application and decided on a lift-and-shift or fresh re-install approach.
If a desktop-installed client app is involved, you’ve also evaluated application performance across the WAN and decided on either separating your non-“chatty” desktop app from the data in Azure or publishing the “chatty” app. Now the question is how you perform the migration minimal user disruption.
With the fresh re-install approach, a cutover migration will be necessary, and some user downtime should be scheduled to complete the application migration.
Here are 10 steps that will help you ensure a successful migration outcome:
- Create a new Azure environment with the necessary VM and infrastructure
- Connect the new Azure environment to the on-premises environment with site-to-site VPN
- Perform a fresh install of database and mid-tier components
- Take a snapshot of the data on the source system (e.g. SQL backup), transfer it to Azure, and restore on the new system (e.g. SQL backup restore)
- Use a web-based front-end or installed client on local desktop or virtual desktop to test the application with a point-in-time snapshot
- Select a group of test users to connect to the database and test, test, test
- Once user testing is complete and application deployment is validated and accepted, schedule a go-live cutover
- Make a final copy of the data from the source system and transfer it to Azure
- Make the source environment inaccessible to users so no changes can be made to the data
- Reconfigure users’ devices to point at the new application location in Azure. This could be done on each device or if the application is accessed via a DNS host name, change the DNS A record to point at the new IP address of the application in Azure.
If you’ve elected to go the lift-and-shift route, then the cutover time can be reduced even further, although it is more challenging to test the application prior to cutover.
Here are the 10 steps to ensure success:
- Create a new Azure environment for the LOB application workloads to land in
- Connect the new Azure environment to the on-premises environment with site-to-site VPN
- Extend Active Directory from on-premises into the new Azure environment
- Configure ASR to replicate database, mid-tier and front-end web servers to a staging area in Azure
- Ensure that all application components are configured to talk to each other by DNS name and not IP address since those will change. If the application is configured to use hard-coded IP addresses, be sure to identify all areas of the application where changes will need to be made when cutting over.
- Select a group of test users and an after-hours cutover time
- Use ASR to perform a test cutover in Azure. This will spin up the application server VMs and optionally shut down the source servers to avoid any conflicts.
- Make any necessary IP address changes, if needed. If only DNS names are in use, then no changes should be necessary other than ensuring the new Azure VMs properly registered their IP addresses in the primary DNS server.
- Ensure that user testing is successful.
- Complete the ASR migration. This will make the Azure VMs permanently available and stop replication from the source since Azure will not be the production environment.
Line-of-business applications are critical to most businesses, and their architectures varies widely. Consider the various available migration options before formulating a strategy, and test all technologies that will be used in a real-life migration in advance.
Performance considerations are also very important when it comes to migrating applications. If you’re not fully satisfied with the performance of a desktop client application after its data is moved to Azure, consider using desktop or application virtualization. If it’s not fast enough during your testing, it’s likely to be even slower under real-world loads in production.
(By the way, if you'd like to get our expert advice on other topics, you can check out the rest of our Academy, or sign up for our newsletter and get new guides, white papers, videos and more delivered straight to your inbox once they're available!)
Get the latest insider updates from Nerdio
We still need to determine where we'll be moving the customer's files, so let's address that on the next page.