So, you want to move to the cloud. You know where you want to be, and where you are now. Before you start planning your migration, give some thought these three key commercial considerations; existing contractual obligations, the financial impact associated with the move from capex to opex, and, finally, the cost of the transformation journey.
What are my contractual obligations to existing third-party providers?
And, what financial penalties exist that may prevent me moving? In other words, am I going to end up paying for data centres that are empty because I’ve moved to the cloud and not ‘sweated’ the existing data centre contract? Are my existing suppliers able to support the new technology and/or way of working? In fact, do I need my existing suppliers?
What are the financial implications of any company-owned hardware, software, etc.?
In the world of capex, investment in hardware and software was depreciated over a number of years. In other words, will I be paying twice for the same kit because I’ve moved to a cloud opex model and the existing kit still figures on my balance sheet?
Clearly, there is an opportunity to write down capex based hardware and software that may still be on the depreciation curve, but you need to review the potential booking implications and possible tax benefits of this with your tax and accounts department.
What effort, time and cost is associated with making existing databases, applications, etc. cloud-ready?
And what is the cost benefit associated with each service and asset? Don’t forget that the cost benefit may change over time and when using different performance/volume models. Some applications may need a significant amount of refactoring before they are cloud-ready.
If you choose to change database technology as a result of your move to the cloud, not only do you need to allow for migrating the data, but also any refactoring of existing applications, platforms, tools, etc. And, don’t ignore that some assets may not be suitable for the cloud, either as a result of their design or the associated negative cost benefit.
And, then there is the important technical question, how do I interact with legacy assets that may be deemed out of scope for migration? This is important because you need to manage interoperability challenges and may need to build anti-corruption layers to decouple services that need to communicate between cloud services and the existing legacy environment.
For each asset you need to ask yourself if you really need to migrate it or if there is an opportunity to either archive it or kill it altogether. Migrating to the cloud is an excellent opportunity to cull all unused or unnecessary applications, databases, environments, etc.
There is no right or wrong answer
It’s simply a case of committing to your journey aware of all the facts and making informed risk-based and financially-aware decisions.
It’s worth remembering that your move to the cloud, in the short term, may mean you change the way you utilise your existing assets. Not all cloud is public. If you’re tied in to your existing data centre for several years, your first steps to the cloud could mean changing the way you pool and provision your data centre assets. You can use automation and orchestration to make better use of your existing data centre assets, by doing this, you are readying yourself to use public cloud when the time is right.
It may be that the effort, time and cost, the complexity and associated cost benefit of refactoring an existing legacy application means you run a hybrid of old-world data centre and new-world cloud services whilst you strangle your legacy estate or it reaches end of life.
How we can help?
- Optimisation of the existing legacy estate and, in doing so, sweating existing infrastructure, licenses, etc.
- Contractual and financial implications with existing third-party providers
- The time, effort and cost associated with making existing assets cloud-ready. For example, migration to a new database technology or strangling a legacy in-house application over many months Migration to new technology, i.e. change of database
