What do we have here Holmes? cloud migration is tricky!

Migrating one or two applications into the public cloud or simply creating new digital application is not difficult! Ok so it is hard but it’s not that HARD! but taking a legacy portfolio of 100+ applications into the cloud, that is HARD! Having led a number of these types of projects and seeing a lack of good content out there around large-scale cloud migration I thought I would talk a little bit about the initial challenges I have seen and the approaches I have used to overcome them. Let’s start with some assumptions: -

• you know less about your application estate than you think!
• you will have a lot of messy integration between applications that you never thought you had!
• your developers don't have the time or knowledge to change their applications into all singing and dancing "cloud native apps"
• you will have some strong technical, procedural or commercial dependencies on traditional enterprise vendors such as IBM, oracle, SAP etc.
• your business units (BU) that own the applications will think infrastructure is free
• your users of the applications will not care about moving or being in the cloud they will simply be concerned about security, performance and any interruption to their services
• • You can rationalise your estate and move to Software as a Service

In every cloud migration I been involved in these assumptions have always proved to be, on the whole, true. So, let’s look at each one in turn and see how we can manage them.

You know less about your application estate than you think!

Take a start-up or a company that has been around for a few months/years and you see some nice example of well-designed and documented application estates. Look at a large enterprise that has been around for 5+ years and I will show you managed chaos! A slight exaggeration maybe but factor in any large packaged solution shifts for example SAP to Oracle or vice versa, any mergers or acquisitions, any new CTO's/CIO's wanting to make things better, consultants (hello) telling you how to do things better, new technology adoption such as IoT or NoSQL...and while everyone has a vague understanding of how things work nobody is 100% sure.

When you want to migrate you need to be 100% certain what servers make up a specific application and which environment (dev, test or prod) they sit in. What applications talk to each other over what type of interfaces. Where are your application databases or web proxies. What server Operating Systems you have. Pretty much all of this can be discovered using technical discovery tools but what about business criticality? What about any change freezes or critical business milestones that prevent moves or changes? This stuff needs to come from interviewing the BU's (CTO, product manager, application owner, Dev and Ops, end users). So, here's a couple of suggestions: -

DO - get the BU's involved in the migration planning and draw up a list of applications that are in scope before you start, agree that changes can be made but you need a starting point, and this will be a long running program. Agree some change windows in your migration program where you can adjust the list.

DON'T - start migrating applications without considering the entire landscape

DO - perform a technical discovery and an application discovery to make sure you understand both the technical and application context and make sure they correlate

DON'T - just considers servers and begin migrating them 

You will have a lot of messy integration between applications that you never thought you had!

Integration is a key aspect of an enterprise application portfolio and one that is often un-examined. Consider deploying large amounts of applications into an AWS environment, do you deploy them into separate accounts, VPC's, subnets ? now all of those application need to communicate with each other, some use nice well-formed web API's and other use shared file systems! how is that going to influence the design of your AWS environment? not all applications will move (at once) so your likely to have a "hybrid" on premise/cloud for a period of time so how does that impact your cloud connectivity (private/public). Integration can have a big impact on your overall cloud landing zone/scaffolding design and not having a good strategy in place and a full understating of your integration requirements can derail the whole migration plan. So, here's a couple of suggestions: -

DO - map interface types and complexity when mapping application dependencies

DON'T - focus on the simple intra-interfaces such as the application to database and ignore the inter-interfaces

DO - consider integration requirements when designing your base cloud environment

DON'T - just assume everything will magically be able to talk to everything else without good design

DO - try and simplify your integration interfaces, moving away from file and proprietary transports

DON'T - assume your horrible interfaces that just work in your datacentre will work in the cloud

DO – consider new integration approaches such as iPaaS (Apigee, Mulesoft etc.) or platform native’s solutions such as Azure API apps or AWS private link

DON’T – try and move your existing ESB or Brokers as is

Your developers don't have the time or knowledge to change their applications into all singing and dancing "cloud native apps" so you’re going to have to move some difficult stuff.

This one comes in two parts, the 1st part being how do you help your developers get better "at cloud" so you can scale and the second one is how do you move the none "cloud native" stuff as you can’t transform everything in one go!

Making sure you have some cloud specialists in the organisation (from leaders down to technical specialists) is a must and using a cloud readiness assessment (CRA) will help you quantify where you are in driving out those skills to the rest of the organisation. Normally this cloud specialism takes the form of a Centre or Excellence (CoE) or Community of Practice (CoP) but the goal is always the same, provide a initial focal point for any cloud projects that can provide technical and commercial guidance and skills (please note commercial is highlighted here and will be discussed later) so your developers don't need to be cloud experts all at once. This approach will work in the short term but the CoE soon become a bottleneck so a key goal for any CoE should be to dissolve itself into the overall organisation.

Thinking about the technology adoption life cycle , you will always get developers, application owners or BU's that innovate or are early adopters of cloud and cloud native approaches but they don't tend to be the majority. Those people need to be involved early and become advocates for the cloud and the point of contact for their peers allowing the CoE to scale and focus on more advanced technology as they evolve and ultimately disappear. So, here's a couple of suggestions: -

DO - spend some time doing an organisational cloud readiness assessment that looks at everything from current business case and organisational structure to technical capability

DON"T - assume that as you or your team know about cloud that's good enough and everyone else will 

DO - create a centre of excellence but expect it to be integrated in the BU's at some point

DON'T - build a new silo

DO - involve enthusiastic developers, operators and leaders irrespective of their skill level

DON'T - build a new silo

DO - Democratise learning, using your cloud provider, a cloud learning platforms and/or in-house material, making it available to all

DON'T - build a new silo

DON'T - build a new silo 😊 

The 2nd part of this assumption is that you will need to make some sub-optimal decisions regarding application performance, resilience and/or functionality to get you into the cloud. So, it’s critical you understand what the driver into cloud is. If it is a financial incentive for moving into the cloud, then it’s a trade-off decision, money saved vs constraint imposed. If it is about agility or simply because you have a cloud 1st strategy it’s a lot harder to justify the potential benefits so a stronger hand, Program Management Office (PMO), may be needed to be the final decision maker.

At the end of the day nobody wants to provide a worse service but there are times when it can't be helped if you look at the end goal, all of which is good consultant speak but it doesn’t help the end user, developer or operations person that is at the sharp end of the decisions. So make sure there is some budget allocated to provide extra staff to support, provide extra coders to build a fix or simply buy everyone working hard a pizza (or two pizza's if it’s a Devops team). So, here's a couple of suggestions: -

DO - make sure you have some budget allocated for tactical "fixes" to allow applications to be lifted into the cloud and alleviate some of the sub optimal decisions, see if the cloud provider or consulting partner can help or has any programs running to make it easier

DON'T - expect to move everything and have no issues

DO - have a strong PMO that can mandate application moves if necessary and has the backing of the board

DON'T - rely on good will and favours

DO - make sure you have cloud migration, COTS and traditional application experience in your CoE

DON'T - staff your CoE with it with Devops/Cloud Native folks only and build a new silo 

You will have some strong technical, procedural or commercial dependencies on traditional enterprise vendors such as IBM, oracle, SAP etc.

Guaranteed if you are an enterprise you will have some packages/commercial of the shelf (COTS) products from a big vendor. Understanding your licensing and support positions from day 1 is critical. You may find that out-of-support products need to be brought back into support to move them which means you have to pay for the years since the support lapsed! you may find that moving software to the cloud may double your license costs! Unpicking your enterprise license agreement (EULA) is an art and it’s no wonder companies have sprung up around this! So, here's a couple of suggestions: -

DO - look to understand your licensing and support positions early and if necessary engage your cloud provider or a specialist company to help you unpick your EULA

DON'T - move what you have and worry about licensing and support after

DO - ask the big question, do we really need these vendors? ?or can we get by with open source or newer technology

DON'T - simply move what you have 

DO - try to make some small technology changes that leverage opensource and/or PaaS services to test and trial these services, ask your cloud provider for help

DON'T - Think of it as a massive transformation project where everything needs to change 

Your business units (BU) that own the applications will think infrastructure is free

Most business units will not pay directly for the Datacentre space and support, they may pay for projects but a lot of that is done through central budgets and/or the equipment costs have depreciated a long time ago. The net result is that current IT costs nothing or at least that's the perception so when you start saying “we can move your applications to the cloud by the end of march” you will see a lot of developers nodding their heads but when you say “…and you will begin paying for it in April” there is suddenly a look of incomprehension.. "sorry... pay for what exactly...?". 

It’s very important that any CoE is built with a cost management/ optimization function in mind that can not only proactively manage costs but can actively help BU's understand what they will be paying as the migrate. Any large cloud migration plan should also make sure they have some budget available to incentive BU's to move their applications, for example, the first 20 applications to move get funded for 6 months the rest must pay their own way. It's massively important to include some education and examples of cloud costs with all CTO’s, product managers, application owners and tech leads so they fully understand they will need to pay for literally every CPU cycle, egress packet and Kilobyte stored as this will be alien to them. So, here's a couple of suggestions: -

DO - spend time educating all the senior application folks on cost calculation, cost management and optimization, ask your cloud provider for help

DON'T- ignore this till you start migrating things

DO - deploy or build cost visualization tools and optionally make that visible across the entire organisations (this is a risky strategy but illustrating who spending the most or least can often have positive results)

DON'T - send a bill at the end of the month to the BU

Your users of the applications will not care about moving or being in the cloud they will simply be concerned about security, performance and interruption to services

I've left the hardest to near the end, the users, particularly if they outside your organisation, will not care about the cloud, the cost savings or the enhanced agility. They will simply care about access to their application and/or data and if you make it worse or interrupt it your will be in trouble, maybe contractually. Not many organisations hold production performance baselines so trying to gauge current performance and then replicate it in cloud is hard as you just have people’s perception rather than hard data. The migration teams that hard data to understand if an application is performing as expected.

Infrastructure in your own datacentre tends to build to withstand a direct assault by a zombie army and the same can be said for Amazon, Microsoft and Google infrastructure however they won’t offer you a 99.999 availability Service Level Agreement (SLA) so if you currently offer a stringent SLA for a service or application and it’s not backed up by you cloud provider you are opening a whole can of risk worms. Starting to think about application resilience and fail-over and not infrastructure reliability is one of the 1st steps in building a truly cloud native application, but this needs specific distributed system knowledge, software and approaches which is not necessarily in the comfort zone for a lot of developers.

Disaster recovery (DR) is one aspect of an application that can be leveraged to minimize disruption and interruption during the actual migration. Solutions with high recovery time or point objectives tend to be easy to move particularly if you can adopt Database PaaS services or you can migrate standby instances 1st and then migrate the primary. Solutions with a low recovery time or point objective (RTO/RPO) will tend to need specific real-time migration tools or proprietary hardware/software combinations that may not be supported in the cloud so you they may need re-architecting! So, here's a couple of suggestions: -

DO - engage your end users early, communicate regularly (using a communications plan) and make sure they are aware of what you are doing, why you are doing it and the potential impacts on them 

DON"T - ignore them until you actually start migrating things

DO - build a business change plan the identifies the impact on different user groups, their SLA's and contractual requirements and details the potential impact to the business or revenue streams

DON'T - group applications for migration without understanding what the business impact will be for a successful or unsuccessful migration

DO - build a migration plan that considers any internal or external change freezes, blackout dates or national/public events 

DON'T - build an unrealistic migration plan that has no business context and simply a technical implementation plan 

DO – Fully investigate and understand all the nuances of application DR in your environment 

DON’T – ignore what DR can do during migration

DO - invest in skills and training around building distributed, cloud native, systems

DON'T - just expect your developers to pick it up

You can rationalise your estate and move to SaaS

Any large application estate is organic, it’s a living, breathing thing and like all of us it gains possessions it doesn't really need. Some of this is technical debt and some of it is just legacy requirements. The problem is nobody wants to fund removal of this stuff, just new features and capabilities but in cloud this approach will cost you more money. The less optimised your application is the more “real” money it will cost, if it doesn’t auto-scale, money! If it depends on a COTS product, money! If you can’t automate the deployment or rollback, money! 

If you look at the traditional enterprise software vendors, they are all being challenged by Software as a Service (SaaS) vendors, from CRM to service desk to enterprise monitoring. As I sit in my global start-up office (thankfully a nice office in Hammersmith thanks to CYLON rather than my bedroom) I’m considering what CRM and development collaboration toolsets to use @latticesecurity and not once has the idea of installing them crossed my mind. It should be one of the 1st things you think about especially for those big unwieldy enterprise solutions, BUT SaaS comes at a price, those highly customised platforms supporting highly customised business processes will be a nightmare to move and support and will be difficult to implement in a SaaS solution. Working out what is core vs context (here's a nice article from Ian Munro on it) and moving everything that is context to SaaS should be goal! ! So, here's a couple of suggestions: -

DO – Get the BU to evaluate if they really need an application and if they need to develope or customsie it, keep challenging them as any application lost is a dollar saved

DON’T – move what you have 

DO – Provide some budget in the migration plan to help remove technical debt and legacy ways of working, ask your cloud provider or consulting partner to help fund it 

DON’T – expect the BU to change by themselves

DO – Spend time looking at your business processes and systems and see where you have some functional overlap that offer rationalisation or simplification opportunities

DON’T – move what you have

DO – Decommission and remove assets

DON’T - leave them where they are because you never know right?

DO – consider a SaaS 1st strategy

DON’T – think of cloud as just IaaS or PaaS

I'm sure I've missed some things and you may disagree with me, but this has been my experience to date and I hope it’s been useful. Please reach out to me or comment directly in the article if you want to add something.

Here are the top 6 things I recommend you consider as you start on your cloud migration: -

1. Don’t move what you have.
2. Don’t build a new silo, called Cloud Centre of Excellence
3. Do perform some sort of Cloud Readiness Assessment to understand where you are prior to migrating
4. Do a top down (application) and bottom up (server) discovery and make sure they correlate
5. Do have a strong PMO with board level sponsorship 
6. Do ask you cloud provider to help financially or technically after all they have everything to gain if your successful

Malcolm is currently the CTO of Lattice Security, a start-up focusing on Cyber Security in the cloud. He previously worked as the cloud advisory practice lead in Capgemini, a Technology Strategist at Rackspace and a cloud architect at Colt Telecom and Cisco