IncidentMonitor Service Desk Software In Azure

We recently decided to move our corporate SaaS IncidentMonitor environment to Microsoft’s Azure platform. In doing so we thought it may prove beneficial to others to recount our experience moving IncidentMonitor to Azure. Although we moved a large number of VMs to Azure the process is the same for a single client, just repeated many times.

We won’t cover the licensing program for running in Azure but suffice it to say there are a number of different options and which you choose to use is based on your organization needs.

In our existing SaaS model a client’s system was comprised of their VMware VM (web/application server) that connected to a dedicated database on a shared SQL Server cluster. We’ve used this model for many years as it allows us to easily move a client’s system from our SaaS environment to their site of vice versa.

There were a few main goals that we were trying to achieve by doing this:

• Flexibility in sizing VMs based on the client’s needs.
• Geographic localization of VM for high speed access.
• Geographic redundancy of VM and storage accounts.
• Eliminate resources to manage our server infrastructure.
• Reduce the cost and management for hardware and software maintenance.
• Eliminate cyclic hardware and software refresh costs.

Basic items to set up in Azure:

• VMs
• DNS – or you may already have an existing DNS registrar for this
• Public IP address for this system
• Backup Vault to store backups of VMs
• Storage Account for any kind of attachments or database backups

Active Directory (AD) / Authentication

Depending on your situation there are options to use Azure Active Directory AD which can leverage an on premise server to provide authentication in Azure. If you are simply going to use the IncidentMonitor authentication e.g. E-mail address and password, then nothing is required.

Choosing VM

Our model of a client’s system would be similar to yours and lends itself very well to the Azure world. You need to decide what you need to run your system in Azure. If your system is smaller you may run as a single VM with SQL Server Express. Meaning the whole IncidentMonitor system is contained in the VM. This model is very simple as you can run the VM pretty much anywhere in the world from the list of Azure data centers. Believe it or not this may fit a large number of client’s situations. You can also choose to use a SQL Server VM and a web/application server VM. This closely models our SaaS environment so it is pretty straight forward.

Choosing DR Model

For disaster recovery (DR) there are many options and it really comes down to what downtime you are willing to live with versus the cost of the solution. If you determine that you need to be up 100% of the time and don’t want to have any outages then you would go to a web/application availability set and a SQL Server availability set both of which can be done across data centers. The more elaborate option isn’t cheap but if that is what you need, then you have to pay for it.

You may decide that your DR requirements are a little more reasonable and you may get by with having your VMs backed up in a Backup Vault. Meaning, the system takes a VM snapshot and stores the VM in the vault. If for any reason the VM is damaged, you simply restore the VM from the Backup Vault.

Another option around DR is that you may take disk snapshots periodically. The VM has to be shut down for this approach but it often only takes a few minutes to perform so some prefer this method. These disk snapshots can be used to recreate the VM to a point in time. If the disk snapshots are stored in a storage account that is geo-redundant (replicates the contents to the sister data center over 100 miles away), it means you can easily recreate the VM in another data center within minutes of a catastrophic failure at the main data center.

At the end of the day the two most important items to backup are the database itself and the file attachments (any files associated with a request, reports etc) as this is where most of the changes are taking place. Everything else is pretty static. In addition to the VM backups noted above you would want to back up your database or transaction log to a geo-redundant storage account. As far as the attachments we found the best way to may DR copies of these files is to use the Windows RoboCopy utility to copy all new attachments based on a date range (within the last day). RoboCopy is very efficient and storage account aware so you can easily copy the attachments added in the last day or so in a matter of minutes.

Choosing Data Center

There are a number of data centers around the world that you can use. For example, if you are in Europe then choose one of the data centers in Europe for local high speed access to your clients.

Sizing VM

One of the best features of Azure is that you can size your VM very easily. By sizing we mean the VM size in terms of vCPUs, memory and disk IOs. If you find your system is getting pushed very hard you can change the VM size to acquire more CPU, memory or disk. The concept here is to be able to scale as your business scales but also only pay for what you use or need. The cost of the VM is related to the VM size so don’t use a VM that is oversized if a smaller one will do.

Planning

If you plan to move to Azure our recommendation is to setup Azure and the items you need and then do a test migration. Verify the new system in Azure. When you are ready it is a matter of getting a copy of your database and file attachments and moving them to the Azure VM. Then change your DNS to point to the Azure VM and you are running.

As far as planning you must plan on getting a copy of your database files and file attachments up to your Azure VMs. This can take a considerable amount of time and has to be figured into your migration time window. One strategy that we employed is that we would take a copy of all the file attachments before the migration and note the date. Then when the actual migration is performed we are just copying up any new attachments since we first took the snapshot of attachments. This will significantly reduce the amount of time to FTP the attachments up to the Azure VM. Ultimately this means the most time consuming task is detaching your database and FTPing it up to the Azure VM.

We used this approach for migrating all of our SaaS clients and even our corporate IncidentMonitor system to Azure and not one took longer than 4 hours to migrate when cutting over the production system. It allowed each client to experience the IncidentMonitor Azure environment as a system test before actually doing the production migration.

Summary

After assessing the Azure migrations we found:

• More flexibility in VM sizing to address client needs.
• Reduced or eliminated all hardware/software management.
• Better throughput for clients.
• Greater geographic redundancy and better DR.
• Eliminated hardware/software cyclic refreshes.
• Eliminated all hardware/software maintenance contracts and management.

We have proven through the many Azure migrations we’ve done that it is a pretty straight forward migration. If the appropriate planning is done to size the VM and define your DR plan, you should have a reliable service that is pretty easy to manage. The process we went through would be the exact same process we would go through for a client that wants to migrate their on premise IncidentMonitor system to Azure.