Category Archives: Strategy
(Confused by the title of this post? Read this brief anecdote.)
The myth of cloud repatriation refuses to die, and a good chunk of the problem is that users (and poll respondents) use “repatriation” is a wild array of ways, but non-cloud vendors want you to believe that “repatriation” means enterprises packing up all their stuff in the cloud and moving it back into their internal data centers — which occurs so infrequently that it’s like a sasquatch sighting.
A non-comprehensive list of the ways that clients use the term “repatriation” that have little to nothing to do with what non-cloud vendors (or “hybrid”) would like you to believe:
Outsourcing takeback. The origin of the term comes from orgs that are coming back from traditional IT outsourcing. However, we also hear cloud architects say they are “repatriating” when they gradually take back management of cloud workloads from a cloud MSP; the workloads stay in the cloud, though.
Migration pause. Some migrations to IaaS/IaaS+PaaS do not go well. This is often the result of choosing a low-quality MSP for migration assistance, or rethinking the wisdom of a lift-and-shift. Orgs will pause, switch MSPs and/or switch migration approaches (usually to lift-and-optimize), and then resume. Some workloads might be temporarily returned on-premise while this occurs.
SaaS portfolio rationalization. Sprawling adoption of SaaS, at the individual, team, department or business-unit level, can result in one or more SaaS applications being replaced with other, official, corporate SaaS (for instance, replacing individual use of Dropbox with an org-wide Google Drive implementation as part of G-Suite). Sometimes, the org might choose to build on-premises functionality instead (for instance, replacing ad-hoc SaaS analytics with an on-prem data warehouse and enterprise BI solution). This is overwhelmingly the most common form of “cloud repatriation”.
Development in the cloud, production on premises. While the dev/prod split of environments is much less common than it used to be, some organizations still develop in cloud IaaS and then run the app in an on-prem data center in production. Orgs like this will sometimes say they “repatriate” the apps for production.
The Oops. Sometimes organizations attempt to put an application in the cloud and it Just Doesn’t Go Well. Sometimes the workload isn’t a good match for cloud services in general. Sometimes the workload is just a bad match for the particular provider chosen. Sometimes they make a bad integrator choice, or their internal cloud skills are inadequate to the task. Whatever it is, people might hit the “abort” button and either rethink and retry in the cloud, or give up and put it on premises (either until they can put together a better plan, or for the long term).
Of course, there are the sasquatch sightings, too, like the Dropbox migration from AWS (also see the five-year followup), but those stories rarely represent enterprise-comparable use cases. If you’re one of the largest purchasers of storage on the planet, and you want custom hardware, absolutely, DIY makes sense. (And Dropbox continues to do some things on AWS.)
Customers also engage in broader strategic application portfolio rationalizations that sometimes result in groups of applications being shifted around, based on changing needs. While the broader movement is towards the cloud, applications do sometimes come back on-premises, often to align to data gravity considerations for application and data integration.
None of these things are in any way equivalent to the notion that there’s a broad or even common movement of workloads from the cloud back on-premises, though, especially for those customers who have migrated entire data centers or the vast majority of their IT estate to the cloud.
(In my soon-to-be published note, “Moving Beyond the Myth of Repatriation: How to Handle Cloud Projects Failures”, I provide detailed guidance on why cloud projects fail, how to reduce the risks of such projects, and how — or if — to rescue troubled cloud projects.)
Note: It’s been a while since I blogged actively, and I’m attempting to return to writing short-form posts on a regular basis.
In my current role within Gartner for Technical Professionals, I talk to a lot of cloud architects, engineers, and other technical individual contributors who are concerned that seeking outside assistance for cloud implementations will lead to long-term outsourcing, lack of self-sufficiency, lack of internal cloud skills, and loss of control. (The CIOs I talk to may have similar concerns, although typically more related to CIO-level concerns about outsourcing.)
Those concerns are real, but getting expert outside assistance — from a cloud managed service provider (MSP), consultancy / professional services provider / systems integrator, or even an individual contractor — doesn’t have to mean a sliding down a slippery slope into cloud helplessness.
Things I’ve learned over the past 5+ years of client conversations:
- Use of expert external assistance accelerates and improves cloud adoption. Organizations can strongly benefit from expert assistance. Such assistance reduces implementation times, raises implementation quality, lowers implementation costs as well as long-term total cost of ownership, and provides a better foundation for the organization to enhance its cloud usage in the future.
- Low-quality external assistance can have a devastating impact on cloud outcomes. Choosing the wrong vendor can be highly damaging, resulting in wasted resources, and failure to achieve either the expected business or technical outcomes.
- There must be a skills transition plan in place. Unless the organization expects to outsource cloud operations or application development over the long term, the MSP or consultancy must be contractually obligated to transfer knowledge and skills to the organization’s internal employees. This transfer must occur gradually, over a multi-month or even multi-year period. It is insufficient to do a “handoff” at the end of the contract. The organization needs to shift into a new mode of working as well as gain cloud competence, and this is best done collaboratively, with the external experts handing over responsibilities on a gradual basis.
- The organization needs to retain responsibility for cloud strategy and governance. It is dangerous for organizations to hand over strategic planning to an external vendor, as it is unlikely that plans produced by an external party will be optimally aligned to the organization’s business needs. For similar reasons, the organization also needs to retain responsibility for governance, including the creation of policy. An external party may be able to provide useful advice and implementation assistance, but should not be allowed to make strategy or policy decisions
You can cut years off your migration efforts, and significantly accelerate getting your foundations laid (building a Cloud Center of Excellence, etc.) by getting the right entity to do at least some of it with you, rather than doing all of it for you.