The One Thing CIOs Might Be Missing: A Cloud Computing Exit Strategy

In Cloud by Shelly Kramer4 Comments

The One Thing CIOs Might Be Missing: A Cloud Computing Exit Strategy

As Neil Sedaka crooned in 1975, breaking up is hard to do. (If you were born after 1990, you’ll probably have to Google that.) What none of us need Google to tell us, however, is that a lot has changed in the 41 years since that song was released, especially in the tech space.

What has remained the same is our desire to innovate and leverage the technologies available to both businesses and consumers. But when it comes to technology and its myriad benefits, sometimes breakups have to happen. And if you’re a busy CIO, breaking up is especially hard to do—and it can be even messier if it involves your cloud computing partnerships.

Did your business deal go sour? Need to terminate a cloud partner in favor of a better option? Has your cloud company gone out of business, or do you want out of cloud computing altogether? These situations aren’t pretty, but they do happen. As CIO, you’re tasked with forming relationships with well-vetted cloud vendors that mesh with your business needs. If it all goes south, you need to have a well-defined cloud computing exit strategy in place to avoid downtime disasters and other major company disruptions. Let’s dig into that idea a little more.

Cloud Computing Exit Strategies Defined

Some call it “reverse migration” or “unclouding.” Put simply, a cloud exit strategy is exactly as it sounds—a plan to ensure the cloud services that support your business activities can be replaced efficiently and without disruption. This includes internal and external service provider relationships falling into any category (i.e., IaaS, PaaS, or SaaS).

It does seem like a lot of work for something you can’t guarantee you’ll even need. But it is—and you might. Of course, none of us move forward in a business relationship that we don’t initially think is going to be a beneficial one, but relationships fail all the time.

In our family of companies, we’ve had several relationships with cloud service providers that we thought were going to be awesome, but which turned out to not deliver on what we expected and have the business results we anticipated. As a result, we had to “consciously uncouple” — extra bonus points if you know what dumb phrase is a reference to—which resulted in some internal upheaval and change as we explored replacements. If you’re a small business, that can be a lot to wrestle with. If you’re an enterprise business, it can be an enormous undertaking resulting in not only major headaches, but also potentially financial losses.

Now is the time, more than ever before, to be a business realist. Chances are good you’ll have to shift your cloud loyalty at some point in the lifecycle of your business. When that time arrives, you’ll be glad you had a cloud computing exit strategy in place.

How to Build a Cloud Computing Exit Strategy

So maybe we agree that a cloud computing exit strategy is important, let’s talk about what you need to know to get started building your exit strategy:

Take inventory. Look long and hard at what assets you have in the cloud and create a comprehensive inventory that includes both applications and infrastructure elements. This is a critical step—missing the boat here can mean your whole plan will have holes and eventually sink. So don’t spot-check old inventory lists! Take the time to make new ones, maybe every six months or so.

Build a foundation through mapping. To build your foundation for uncoupling (there’s that word again), thoroughly map all your dependencies. Then, focus on untangling your webs of applications and realigning them back to their home infrastructure elements.

Examine (and reexamine) Service-Level Agreements (SLAs). Now that you’ve got the fundamentals—that is, a comprehensive asset inventory and a map of how everything is aligned—you’ll need to take a step back to examine those SLAs. This is important because whether you’re unclouding altogether or shifting provider loyalties, organizations must continue to meet the contractual obligations outlined in SLA documents until the process is complete.

Uncloud applications first, not systems. If you’re going the full unclouding route, make sure to hone in on applications first. If you start with entire systems, it leaves far too much room for error. Migrations that are application-centric may take longer, but they come with a reduced risk.

Test (and test again). Whether you’re joining the cloud in general or aligning with another cloud service provider as part of your overall strategy, odds are you’re going to spend quite a bit of time testing potential outcomes and weighing options. Why would that process be any different for switching providers or removing your business from cloud? (Answer: It’s not.) Test your solutions now, when it’s noncritical, so a failure later won’t signal a critical company disruption.

Thoughtfully reallocate your resources. Just like the possibilities for the cloud are seemingly endless, so are the ways in which our business relationships in that space can fall apart. Don’t get ahead of yourself as you choose a replacement vendor or alternative “unclouded” method of meeting your business objectives. Focus on the security, operational viability, and potential longevity of each proposed solution, and take care to compare your ideas to your asset inventory list. Is everything covered? This is a good time to pause and see if any realignment or asset consolidation is in order—both can help streamline your future endeavors as CIO.

The Takeaway

Think for a moment about your relationships with your cloud vendors. Are your cost/benefit ratios evergreen? How about organizational maturity and speed of service—are they on point? If there’s any reason your business and your cloud vendors just aren’t meshing well—and, perhaps the whole point of this post, even if they are—it’s a proactive and protective business step to go ahead and get an exit strategy on paper.

As a CIO or IT leader, have you ever been part of a cloud breakup? Was your exit strategy helpful in terms of damage control? If you didn’t have one, what may have gone differently if you had? Specifically, how important do you think exit strategies are at the contractual outset of cloud partnerships—does the timing particularly matter to you? What would be your suggested approach? I’d love to hear your thoughts.

Additional Resources on this Topic:

Build a Cloud Exit Strategy in Three Steps
Gov Execs: ‘Exit strategy’ Critical in Federal Cloud Computing Contracts
Why You Need a Cloud Exit Strategy

Photo Credit: Compu-Net Systems, LLC Flickr via Compfight cc

Shelly Kramer is a Principal Analyst and Founding Partner at Futurum Research. A serial entrepreneur with a technology centric focus, she has worked alongside some of the world’s largest brands to embrace disruption and spur innovation, understand and address the realities of the connected customer, and help navigate the process of digital transformation. She brings 20 years' experience as a brand strategist to her work at Futurum, and has deep experience helping global companies with marketing challenges, GTM strategies, messaging development, and driving strategy and digital transformation for B2B brands across multiple verticals. Shelly's coverage areas include Collaboration/CX/SaaS, platforms, ESG, and Cybersecurity, as well as topics and trends related to the Future of Work, the transformation of the workplace and how people and technology are driving that transformation. A transplanted New Yorker, she has learned to love life in the Midwest, and has firsthand experience that some of the most innovative minds and most successful companies in the world also happen to live in “flyover country.”


    1. Thanks Sledge … but I’ve gotta admit, I grew up during this time frame, and do my homework before I write/publish. Here’s the deets on Neil’s song:
      “*Breaking Up Is Hard to Do*” is a song recorded by Neil Sedaka <>, and co-written by Sedaka and Howard
      Greenfield <>. Sedaka recorded this song twice, in 1962 and 1975, in two significantly different arrangements, and it is considered to be his signature song <>.[1] <>

      The version I’m referring to is the 1975 one. But I always appreciate anyone keeping me on my toes!

Leave a Comment