Everyone who embarks on a cloud project wants it to succeed, but data suggests there's a real risk success may not happen -- even with careful planning. Statistical modeling suggests that every company will have at least one failed cloud endeavor because of overrun costs, outages or unsuitable application choices; when that happens, the best option may be a graceful retreat, moving application back on-premises. The retreat won't be easy, but with carefully planning it's survivable and preserves your cloud reputation for future projects.
A retreat from a cloud project is likely to be a three-step process: preparing a line of withdrawal in your cloud plan; "retro cloud movement" (my term for going back to your IT environment before cloud); and considering a re-launch.
Virtually every user who reports a retreat from a cloud commitment indicated they would have had fewer problems if they structured their cloud projects to anticipate at least a risk of failure. Some surveys show as few as one cloud project in 10 has a viable retreat plan included, often because users don't understand how to create one.
A cloud that can sustain a retreat should include an early warning indicator of failure that keeps the project from advancing when it's not working, a contractual process of withdrawal from public cloud commitments and fallback options until the risk period has passed. Of these, the critical foundation of retreats is most likely to depend on that early warning indicator.
Testing in the early stages of a cloud project
The business case for a cloud migration is determined by balancing expected benefits and the technical risks that must be offset. In most cases, companies will extensively test cloud applications in a performance sense, but they will likely do this with test volumes of information and not in a production setting. Furthermore, they rarely validate the cost assumptions.
A cloud retreat consists of:
- Early warning indicator of failure;
- Contractual process of withdrawal from public cloud commitments; and
- Fallback options until risk period has passed.
To avoid problems with a cloud retreat, perform both a functionality test and a business pilot test. The former should focus on application integrity, performance and manageability; the latter should focus on testing cloud pricing assumptions.
It's necessary to conduct an extensive review of what variables might influence a cloud's price to determine accurate cloud pricing. In most cases, the potential variables relate to data storage, data access, cloud performance and availability. Many companies find, for example, "basic" cloud services don't meet user Quality of Experience (QoE) expectations and they are forced to move to dedicated instances, clustering and other more effective services. These variables should be spotted in the functionality test, but some may appear only in full production.
Not all companies agree on how long these two test should run to effectively expose any cost risks; most cloud admins say at least a month, but some say as long as a quarter. In the case of a longer testing period, companies can encounter contractual issues with the cloud vendor and issues maintaining a fallback system. Most cloud providers accept a one-time contract bailout, and virtually all will convert month-to-month services to a long-term contract by crediting a company for the original monthly payments. However, users report that test periods that last longer than three months become difficult to negotiate. In most cases, it's also necessary to maintain an on-premises fallback system if a retreat is needed. The longer the test period, the more costly the retreat will be.
Entering the "retro cloud movement" phase
If early warning indicators in a testing process show that the cloud project won't meet its objectives, then you must enter the "retro cloud movement" phase. First, notify the cloud provider that you are exercising your option to drop the service for failure to meet the business case. The cloud provider may suggest remediation, which you can accept if it's financially feasible. However, most cloud project failures cannot be fixed unless you notify a provider at the first sign of trouble.
Next, prepare an on-premises application platform. If the early warning indicator showed problems in the test phase, the only requirement is to discontinue the test and eliminate any processes that were designed to keep the application updated during the test. If problems didn't occur until production use, it's necessary to check the application to ensure it's up-to-date with all transactional data and platform or software changes before bringing the applications back on-premises. This requires a validation test on the in-house system before the "retro cloud movement" begins. In many cases, application lifecycle management practices developed for the in-house application can be used as a guide to moving back from the cloud if necessary.
Considering a second cloud attempt
The final point is to recognize many cloud failures are recoverable. Some cases in which cloud costs or performance have failed to meet project needs can be remedied by changing providers or renegotiating contracts.
If internal project measures help ensure success of a cloud migration, then failing may point out new measures to preserve success. Every cloud project failure should be subject to a post-mortem to determine whether a relaunch under different conditions will better serve your company's interests.
About the author
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.