“That’s the Cloud sorted then: let’s talk about Blockchain…” Part 3: Transition & Migration
3 min read
In and out of the Cloud
In my previous blog Enablers of Industrialisation, I itemised the key (primarily non-technical) capabilities to invest in if you are to drive Cloud-appropriate adoption at scale.
This blog considers Transition & Migration – that is, the business of moving anything into and taking anything out of the cloud. Key objectives here are to de-risk the migration, avoid lock-in and fully exploit the opportunities.
In a Cisco Global Cloud Networking Survey of 1300 senior professionals, almost 40% said they “would rather get a root canal, dig a ditch, do their own taxes” than orchestrate a cloud migration.
This view has probably changed a little, with the emergence of tool sets and specialist consulting services to facilitate migration. The Cloud providers have also made it easier by automating some elements of the discovery, re-design, re-build and deploy processes.
That said, the problems arising from migration are still the most quoted ‘drag anchors’, slowing down adoption and tempering ambition.
One recent survey of 200 UK CIOs and senior IT decision makers from large enterprises with over 1,000 employees indicated that on average, they’re planning to move around half of their on-premise apps into the cloud by 2022. Delivering on this aspiration will be… ‘challenging’, especially given that the average time to migrate a system is, apparently, around six months.
Let’s be more precise: according to AWS, there are four ways that migrating your existing workload can go between the IaaS and PaaS categories:
– Rehost
– Replatform
– Refactor and:
– Rebuild.
With IaaS you can rehost (“lift and shift”) or replatform (“lift, tinker, and shift”) and with PaaS you can refactor or rebuild. AWS spins the process in a very palatable way – suggesting you can “retire your technical debt”, although “pay off” may be more appropriate, as it involves major cost.
Transition and Migration Challenges
- Discovery: discovering which apps, platform or infrastructure components and services make up the system to be migrated is a monumental task. Missing out a critical component which then becomes ‘unavailable’ to the Cloud-resident incarnation would at best degrade and at worst make the whole system ‘unavailable’. Again, specialised static analysis tools can provide some automation of the discovery involved but should not be 100% relied upon for ensuring complete coverage – especially when you include the usual ‘Dev’, ‘Test’ and ‘Ref’ environments as well as ‘Prod’ for each system.
- Service Level and Quality Requirements: most service level and quality requirements and agreements such as availability, throughput and latency are implicit. Even if they were once, in the mists of time, specified when the system was first implemented, they will now have changed. The business will have become accustomed to ‘emergent’ qualities and levels. Migration to Cloud forces the explicit articulation of implicit attributes as they need to drive commercial contracts and product/service selection. Cloud vendors help here as there are a finite set of quality/level options available – typically ‘T-Shirt sizes’ (e.g. XS/S/M/L/XL).
- Functional Capability Requirements: other than the most recently implemented systems, these will likely be implicit as updating the requirements spec is the very lowest priority for funding, always losing out to new features. The relevance of this is…testing. ‘Sample’ testing will not be enough on the new Cloud installation – a full regression test will be needed.
- Execution: some practical considerations here. The most often encountered is the time and temporary resources it takes to cleanse, extract, move and install data in the target environment. As a matter of principle, unless it is trivial, only look to migrate what is necessary – the risk of problems is directly proportional to the amount of data involved.
- Security during Migration: data ‘at rest’ and ‘in motion’ needs additional (and resource-hungry) security measures, e.g. encryption.
- Migration Capability: that is, people, skills, knowledge, process, tooling, resources. As migration of any one system is a one-off activity, it looks hard to justify any user organisation investing in the capability to do it. However, it shouldn’t be. By the time a pipeline of multiple system has been identified, the beneficial side-effects of documenting and re-factoring the systems recognised and the need to provide ongoing governance to ensure smooth exit migration in the future…you get the picture.
- Certification: most Cloud providers will require the new tenant to demonstrate compatibility and compliance with the provider environment. Typically, this requires varying degrees of refactoring and re-engineering of system components to address the issues covered in Portability above.
You might even argue that by the time you’ve prepared for the Cloud, your system estate is better documented and re-engineered. It is already in much better shape than it was before, and you may well have delivered many of the proposed and unplanned benefits.
Next up in Mar 2019, this blog stream considers the sibling to migration – Portability or How to make the next migration off or between clouds easier.
Hope to see you there.
Meantime, as ever, any thoughts, observations, critique, suggestions – anything at all really, please get in touch with me.
Authors