introduction

In this blog we will look at the different types of business applications in the wild, and how-to migrate them to the cloud. We aren’t looking at the benefits of the cloud vs other types of hosting, we’ll assume if you’re reading this you’ve already decided that the cloud is for you.

Just a word though about migrating applications to the cloud … you can migrate *almost* all applications to run from cloud services BUT … that does not mean you should. … we will explain more when we get into the details.

We are going to cover several different scenarios covering different application types and application origination.

Type of Application: Web, Desktop, Server (Background Process)

Commercial Off-The-Shelf (COTS): Yes or No

Bespoke or Custom Software (with source code available): Yes or No

NOTE: Usually COTS and Bespoke or Custom Software are mutually exclusive e.g.it is very rare that source code is available to you the end-user for a COTS based product, so let’s focus on whether you have access to the source code or not.

background: which cloud service should I use?

One of the common misconceptions about the cloud is that it is a single thing. It is not.

In the context of public cloud is 100’s of services bundled together (often achieving the same objectives in different ways).

Cloud services can be sub-divided into following categories:

Depending on the requirements (or limitations) of the application workload you are migrating to the cloud will depend in which tier that application can operate in.

You want to be as far to the right as possible if minimising management and costs are your primary goals.

Most often we find our client’s prime motivation for moving to the cloud is to reduce the management burden on their teams, or seeking a more flexible cost model for hosting their application workloads.

There is a trade-off – for the cloud vendor to provide saving at scale the requirements for your application workload get more restrictive the further to the right you go and can prevent an application not designed to operate in that tier from functioning without modifications.

See the table below with our types of applications over-layed:

Takeaway: If you have access to the source code for application then there more potential solutions available to explore.

how-to migrate to cloud

1. Create or update your application register.
2. Perform migration critical path analysis.
3. For each application in your register that you want to migrate:
4. Select the right cloud service type of your application type.
5. Create a test environment for your application type.
6. Deploy your application.
7. Validate your application by:
8. Smoke Test
9. Scale Test
10. Penetration Test
11. Plan your migration.
12. Create your production environment.
13. Deploy your application.
14. Go live.

create or update your application register

Critical to successful migration of applications to the cloud is understanding the current application environment.

Keeping an up-to-date application register helps you, other team members and external parties build a common understanding of what needs to migrate and the order in which to do so.

The register should include key information such as:

• Application Version
• Minimum Requirements (Normally Operating System, Runtime, Installed Dependencies)
• Connected Dependencies (Databases, Messages Queues, SMTP Gateways, SMS Gateways, 3^Rd party Application Integrations)

The format of the application register isn’t important – use whatever feels best for you, but Excel or Visio type diagrams work well in our experience.

perform migration critical path analysis

CPA allows for each application and its dependencies to be mapped out and helps form the roadmap for migration to the cloud. Many factors can influence the order of the migration but often these include:

• Criticality of application to business
• Number of dependencies on or to the application
• Technical difficulty in achieving the migration
• Challenges or Issues with current application hosting environment

Recommendation:
With any new migration we would look for an initial “easy-win” such as an application with minimal dependencies and marginal technical difficulty to help build confidence in the team during the initial stages and demonstrate early value to the business.

select the right cloud service type for your application type

Desktop Applications

Web Applications

Server Applications

create a test environment for your application type

Once the blueprint for the environment has been designed then an environment for testing should be created to give the migration team a safe place to try out the migration without interrupting the business.

Recommendation:
We recommend that a scripted (also known as Infrastructure As Code) approach to creating the environment is used. For a team new to cloud this will seem like a lot of effort to create the environment compared to clicking around in the UI, but we promise you that you will get faster at scripting and the payback is worth the effort.

Having repeatable, reliable, self-documenting asset(s) which describe the environment will pay dividends over the lifecycle of the migration project and beyond.

deploy your application

Once the test environment is operational then the application should be deployed to the environment.

Recommendation:
We recommend that the deployment process should be automated using a deployment automation tool, this will provide an automatic, repeatable, and consistent way to deploy applications to the hosted environment.

validate your application

With the application deployed then validation of the application can begin, we follow these test and validation steps:

1. Smoke Testing
2. Scale Testing
3. UAT Testing
4. Penetration Testing

We always start with a preliminary test to reveal the simple failures called a smoke test.

After smoke testing the application we perform a scale test, this test looks for any performance issues which might have become apparent when moving from on-premise to the cloud. This is not to say that the cloud is slower, but it does tend to highlight code which consumes a lot of resources more acutely than on-premise environments such as SQL query efficiency.

User Acceptance testing comes next. This is a more formal test of system behaviour against user requirements.  In the context of the migration to the cloud this could be more accurately considered as a regression test, since it likely to be a comparison between the behaviour of the platform on-premise compared to the installation under test in the cloud.

If the application is available via the public internet, we complete the testing phase with a penetration test conducted by an approved independent 3^rd party to check that the new cloud environment meets all the security requirements.

plan your migration

Planning the actual migration of the application is going to be unique to each business; but here are some important considerations when putting together the plan.

Migration Timings & Approach:
During the Testing Phase accurate timing of the process of migrating the application should have been captured. If you’re lucky, the time taken to migrate the application will fit inside a suitable window for the business so the application can be taken offline without causing any downtime.

Increasingly, this is becoming more difficult so other techniques and technology may need to be employed in order to smooth the transition, such as data replication between on-premise and cloud in order to shorten the time required for the switch over to occur.

Rollback Planning:
Always, always have a rollback plan! There is no shame in rollback to a previous known “good state” it allows time to then improve the migration plan and trying again. The business won’t thank you for a one-way, no way back approach to cloud migration if something goes wrong.

User Communication and Training:
Keeping the community of users up to date with the migration plan is critical. Do this several weeks and days before the actual migration takes place, think of the plan as a marketing campaign, where little and often message re-enforcement is more effective.

If required make sure that users are given training, make the Test / UAT environment available to them so that they can experience the migrated application before they have to use it in anger.

Enhanced Post-Migration Support:
Reserve some bandwidth for migration team members to help deal with post-migration technical support issues. Reserve this capacity until support calls return to normal pre-migration levels.

Plan to have support staff “walk the floors” physically or virtually to enable on the spot support of any issues.

create your production environment

This is where the benefit of having a scripted approach begins to pay dividends – creating the production environment should be quick and pain-free.

Recommendation:
If not already in place and appropriate, consider using aliases to direct users to the new production environment (for example aliased DNS entries), this will not be the last time you migrate this platform so having a static name for this application (and going through the pain of people remembering / bookmarking) it’s happening anyway, due to the cloud migration.

This will allow you to migrate the application in future without having to re-train staff to go to a new address for the application each time, saving on training and initial support costs.

deploy your application

Having an automated deployment tool in place should allow you to deploy the application to the new production environment in a quick and reliable manner.

go live

If you have followed the steps described here, then go-live should be a breeze! We all know that there is likely to be some issues along the way, but by planning in advanced and testing and validating the application being migrated will ensure any disruption to the business will be short lived and quickly return to business as usual.

In the case of sever disruption or unplanned events then invoking the rollback plan and returning to pre-cloud migrated state is an option always available.

‍