About a week ago I was reading an article on the Tech Target site about cloud repatriation – to begin with the title confused me a little as I’d never heard the term “repatriation” applied to cloud. Its normally used in relation to getting people back home when an airline collapses or war breaks out somewhere, or more recently when COVID-19 causes a country to shut its borders.
In this context though it related to bringing “workflows” that had been moved to cloud back on-premise because cloud was not working properly for the “workflow”. The article was commenting on the costs associated with successfully bringing an application back on-premise after a failed cloud migration.
I don’t believe that the article meant immediately after the application had been migrated – it wasn’t that an application (work flow) had migrated and hadn’t worked but the organisation had left it there anyway… but rather than over a period of time using the application in cloud (be that delivered on IaaS, PaaS or SaaS) it hadn’t delivered the performance or functionality required by the organisation and thus the decision had been made to bring the application home.
What I found interesting in this article was that to reach this situation organisations must be moving to cloud in a very “gung-ho” fashion… the article noted
It’s also possible the move to the cloud was poorly thought out. Ninety-two percent of IT organizations that repatriated applications had originally moved them without any rearchitecture or modification. Furthermore, 68% of organizations said the decision to move to the cloud was made by a business group outside of IT, according to Scott Sinclair, senior analyst at Enterprise Strategy Group (ESG).
92% of organisations that brought applications back on-premise moved them without any rearchitecture or modification? Wow.
The importance of preparation
In my opinion there are a few items any organisation planning a cloud migration ought to know before they move the application
1. Can you measure performance and user experience for the application before and after the move? If you can’t then how would you know if the application was working properly before or after? I accept you could do a series of tests to prove functionality before signing off the changes associated with the move but if the application runs fractionally slower for 1 user in commissioning tests this might not be noticeable but if this poor performance escalates as the user count increases and if it runs pathetically for 1000 users you want to know this… plus, you want to know which bits of the application run slowly. To know this you need a user experience tool and a performance management tool.
2. Do you know how much the application costs to run before and after the move? Do you know what the software license costs are, the OS costs, the hardware replacement costs, the storage costs, backup costs, etc do you know the internal support costs, the vendor support costs? Do you know how many service desk tickets the application generates and the cost of resolving these?
3. Do you have adequate test plans for the application? Do you have exhaustive test plans and know the expected results of these tests? Have you run the tests on the existing system before completing the migration? – there is no sense in migrating a broken application because you didn’t test it… Have you run your tests from somewhere other than the data centre?
4. Do you know how significant the application is? How many users use it? Who are those users? What happens if the application fails? Does the application have a business continuity plan? A disaster recovery plan? Does it fulfil a legal obligation? A contractual obligation? Are the users internal or external?
5. What are the allowed destination architectures? Where can the application go to and what constraints exist? More on this below.
The importance of understanding your options
My five point in the above list of five is so important that I think it should be brought out separately. Take a step back for a moment and look at the reason why you are considering a move to cloud in the first place – you probably want to move applications to cloud because of:
A desire to reduce on-premise infrastructure / support
A desire to become more flexible
A desire to make use of new tech
A desire to “be seen” doing cloud
A desire to leverage some particular cloud feature
A desire to reduce costs
But there are a number of different ways of achieving this end and they don’t necessarily involve a move to cloud…
When I do gardening the bits I enjoy the most are the bits where I get to remove a plant that’s in the wrong place and bin it. This makes my garden look neater and for some reason I find it deeply rewarding. I think in a sense that when looking at application portfolios and considering cloud we should feel much the same – we should be looking always for opportunities to merge or retire applications. If no one is using it or it presents a risk to the business it should be removed. Similarly applications that have few users but cost a lot should be carefully considered and if possible removed or replaced.
If we have to keep an application then when considering alternative delivery models we ought to know the cost of the alternatives and the cost of getting to them – and be pretty sure they will work before we spend that money.
Keeping an application on premise but upgrading the version of the application, replacing its underlying hardware – particularly its storage – can lead to massive improvements in the application performance and potentially at a lower cost to the business. After all new hardware typically has improved performance, a smaller footprint, lower energy consumption, and costs less to support that older hardware.
So how do I decide where my application goes?
Assuming for a moment that you have completed my list of 5 things – so you know who uses the applications, you know how much the application costs and the costs of the allowable new delivery model options, you have well written test plans and know the results of the tests from running them against the production system, you know the significance of the application, and you know the benefits and disadvantages of each possible new delivery model – how do you decide which option to choose?
I think by the point you get to this stage you will probably have eliminated at least half of the service delivery options I’ve listed above. Your choice from the remainder should probably be influenced by:
Strategy: Where do you want to go and why? Which option aligns best with the business objectives? Which one fits best with the available skills? Not just ICT strategy but business strategy, Etc
Budget: Which options can you afford, which options fit best with your mix of / or preference for capex and opex spend? Which options cost the least to support?
Functionality & Features: If you want to retain the existing functionality and features of the application then you are probably stuck with the existing software vendor – you only have a choice of where to host that application and who will manage it. Most of the so called “digital opportunity” however comes from switching delivery model and switching vendor. If you can find a different vendor who offers a solution with a feature set that matches what you want at a cost you can afford this can often be a winner.
So will all of this stop me from needing to repatriate an application I’ve moved to cloud?
No. Rather it suggests that applications should ideally be chosen that are easy to move between delivery models if those models don’t deliver the required performance and/or user experience.
For many years in other parts of ICT it has been key to avoid tie-in. Outsourced contracts (e.g. WAN delivery) have included novation clauses in an attempt to ensure the supplier is helpful when you are exiting the contract. I think its key when planning a cloud migration to understand what you are entering into and how you get out of the chosen solution if it doesn’t work along with the likely cost of that exit.
Contact us to find out more about planning a cloud migration