Modernising Legacy Organisations by Embracing the Cloud

There are many reasons why organisations are choosing to embrace the Cloud (in one of the many guises we discussed in a previous blog post) but, once the decision is made, how do you go about making sure your new environment will be an optimised success providing a healthy return on investment?  The answer, as with many things, is planning. 

I’d like to preface the following with the clarification that no matter how much planning you do, you will always experience things that are unexpected – no one can plan for every eventuality and things will always crop up that will come as a surprise.  However, the process of planning makes us aware, in broad strokes, of what we need to consider and, by thinking about the bigger picture makes us consider things that we may not have done at first glance. 

A typical Cloud Transformation project will follow multiple phases, all of these are carried out with the aim of surfacing as much information as possible and making the migration a success.  There is often trepidation amongst traditional IT teams that the Cloud is something to be feared or hated, however, if we treat it like a tool to be used in the correct job, it definitely has a place in everyone’s toolbox. 

Phase 1: Portfolio discovery and initial planning 

This phase could also be called “You don’t know what you don’t know”.  The focus here is to understand the current organisation and the associated portfolio of processes and applications. 

The duration of time spent on each phase will vary based on the complexity of the organisation and what they’re trying to achieve (move one application vs. their entire estate for example) however, this phase would typically last 4 – 5 weeks.  The reason for this is that a lot of things in businesses happen at specific times of the month (i.e. a payroll run at the end of the month), by running an assessment that extends beyond a month, we have a much greater chance of catching these one off tasks than if we just run an assessment for a day or two. 

This phase will often involve the use of automated discovery tooling.  This will scan your network(s) and discover applications. Depending on the exact tooling used, it can also identify application dependencies and links between different elements.   

By the end of Phase 1, we should have identified our initial list of migration candidates and decided how our application base can be rationalised to a set of core, must have applications; due to the way Cloud resources are metered, you want to move only what is required and decommission anything that is not. 

Phase 2: Prioritised application assessment 

In phase 2 we look at what will give the business the most benefit for the least amount of effort.  We focus on these “low hanging fruit” in order to deliver a faster time-to-value. 

We use the data collected during Phase 1 to identify the important applications and do a detailed assessment of those that are the most critical.  This will then inform our decisions as we begin our initial design of the target architecture. 

One of the most important aspects of moving the initial applications is that it gives IT teams Cloud Migration experience that they may not have had before.  It also gives the opportunity to interact with the environment and to establish a common set of services that will span the entire architecture – things like Jump Boxes, ExpressRoutes/Direct Connect etc. 

This phase will likely last a couple of weeks, although again, it all depends on the size of the organisation and what they’re trying to achieve. 

Phase 3: Portfolio analysis and migration planning 

Phase 3 is where the real design decisions are made.  At this stage, we’re concentrating on getting as much insight into the application portfolio as possible.  We’ll use this information to design how we move functions to the cloud and when we’ll do it. 

When looking at an application in this phase, there are four broad categories we would generally consider when looking at dependencies. 

• What infrastructure is the application dependent on? 

We’re aiming to document any link between software and hardware. 

• What are the component parts of an application and where do they run? 

If you’re running, for example, a three tier web-app you may have your front end running on one set of virtual machines, your application layer in another and your databases running in a separate cluster.  Each part is intrinsic to the whole so we need to be aware of it. 

• Is the application reliant on any other applications? 

An example of this would be if you have separate Project Management and Customer Billing systems and you have it so once a project is signed off as complete, it automatically outputs to the billing system that will generate the invoice and send it to the customer.  We need to map that dependency and then make sure we carry out a full assessment of that application as well. 

• Is the application reliant on any infrastructure services? 

There are lots of things that sit in the background and are common to lots of different applications.  For example, in a traditional Microsoft Windows domain, Active Directory underpins all of the Authentication, Authorisation and Account (AAA) and when migrating an application to the cloud, we need to make sure that we take care of those elements in the new environment. 

This phase can be very time and resource intensive, especially on large and complex environments that have grown organically over many years in order to satisfy the needs of a business.  For that reason, we normally rely on the discovery tooling we implement in Phase 1 to provide as much of the data as possible.  This includes performance baselines for the applications so that we have a baseline to compare to post-migration. 

This information is also used to decide on the migration strategy for each application.  Different cloud vendors refer to these as the R’s of customer migration.  Azure has 5 and AWS has 7 but they amount to the same thing.  There’s enough there to make a blog post of its own, so keep checking out the website to see when that becomes available. 

The information collected will then be used to come up with a Migration Wave plan.  This will allow us to define what aspects of the environment are moved and when, based on what interacts with what and how moving it will affect the rest of the environment. 

Phase 4: Continuous assessment and improvement 

As I mentioned at the start of this post, a plan will never manage to cover all eventualities.  However, in order to mitigate that risk, we need to ensure that we’re continuously assessing our plans and making sure that we’re flexible and willing to adapt as issues arise. 

In order to do that, we need to make sure that we’re constantly assessing the migration plan for each wave and making sure we’re happy with the dependencies, the proposed design and the migration strategy we’ve decided upon.  We also need to make sure we look at previous waves to identify what has gone well, what went to plan and what was unexpected so we can try and anticipate it going forward.  We may also find that as a migration wave is carried out, we end up having to move a service dependency that we hadn’t anticipated and this will then change the plan for the next wave.  These plans aren’t just a tick box exercise to do once, they’re a living document that will change over time in order to guarantee us the greatest level of success. 

We also need to make sure we’ve documented all of the requirements and any cut-over considerations and liaised with the relevant departments/users/stakeholders to ensure everything will proceed as smoothly as possible. 

The last element of this is Improvement.  The Cloud is not just somewhere you can throw all your stuff and hope for the best.  It is something that needs to be monitored and optimised on an ongoing basis in order to make sure that you’re getting the best ROI on your solution.  All of the big players offer tooling to do this (AWS Cost Optimization, AWS Compute Optimizer, Microsoft Cost Management, Azure Advisor Best Practices) and we can also offer the same service within our ACS platform (based on the vRealize product line from VMWare). 

Phase 5: Consolidation and decommission 

The final phase here is actually independent of the Cloud migration but is just as important.  If you’re going to realise the benefits of the new environment in the cloud, you need to make sure that you properly decommission your legacy infrastructure. 

As part of each migration wave, you will have moved away from legacy infrastructure but if you leave the hardware running it still needs to be powered, cooled and collocated somewhere, all of which comes at a cost.  It also offers attack surfaces and ingress points to your network which, as these systems are no longer going to be maintained, is a massive security risk. 

Once a platform is thought to be no longer in use, we would normally raise a Change (if required), ensure sufficient monitoring is in-place, and then power down the infrastructure.  This will be left in a powered off state for a pre-agreed length of time before being backed up and permanently decommissioned. 

Conclusion 

The above outline is a high level overview of how to start your Cloud migration journey to take you from legacy applications in your datacentre/server room to being natively in the cloud. 

There’s obviously a lot more to it, so if you’d like to hear more then reach out to our Sales Team who will be able to go through our offerings with you and see how we can help. You can get in touch with our team here.