As with any emerging technology, early adopters of the cloud had quite a few surprises in store for them. Still, it’s easy to understand what their thought process was: if moving to the cloud really could reduce your infrastructure costs by as much as it was promised to, and if being in the cloud really could make your business as agile and as mobile as it was supposed to, then getting there first would be like giving yourself a head start in a footrace. You would be way out ahead, enjoying the benefits of early adoption, while everyone else struggled to catch up.
Of course, it was only a matter of time before we all started hearing the disaster stories.
There were obviously some success stories too, but feel-good rumors tend not to get as much traction as the other variety. All the while, there was the other, probably even more common line of thinking about the cloud: Move all my files and applications into someone else’s datacenter? How could that possibly be secure? When you add these knee-jerk misgivings into the mix with all the horror stories floating around, you have a recipe for some potentially costly misconceptions. To balance out the apprehensiveness, though, you have all the marketing hype about how the cloud is sure to revolutionize business computing. The combined effect: lots of confusion.
If there’s one key to avoiding the most common pitfalls associated with cloud migrations, it would be, first, to make decisions and formulate plans on a workload-by-workload basis instead of on an organization-wide basis, and, second, to base your planning on actual business use-cases to set meaningful, and measurable, goals. Your specific goals for each workload or use-case will help you determine what your best options are for infrastructure, whether you’re choosing between on-premises or cloud, private or public cloud, Amazon Web Services or Microsoft Azure, or Infrastructure vs. Platform as a Service.
When cloud migration projects fail, it’s most commonly because the business made one or more of the following mistakes in the planning stage:
1. Treating Cloud Migration as an All-or-Nothing Proposition
Some of your legacy applications may need to be re-architected before they’ll function properly in the cloud. On the other hand, some apps may actually get a performance boost after the move. Obviously, viability in a cloud environment is an important factor in any cost-benefit analysis, but before deciding where to host a given app—or whether to re-architect it—you should weigh other considerations as well. What are the regulatory requirements for the data? Azure is much better about HIPAA compliance than Amazon, for instance. Do you need consistently high performance for, say, reliable and high-quality Voiceover IP for client calls? Then you may want to look into private cloud options. Or are you hosting a website that experiences periodic spikes in traffic? In that case, you may opt for the auto-scaling capabilities of pubic cloud services.
The important point here is that you shouldn’t treat the cloud as a monolithic solution but rather as a collection of services, each suited to meeting a specific business challenge. Depending on your available resources and your business priorities, your best move may not be to go to the cloud at all. But whether you should keep your entire company operating with an on-site datacenter or move everything to the cloud isn’t the right question to ask. You may, for instance, want to host your website on Azure for scalability, while continuing to run SharePoint on your own servers to avoid issues with regulatory requirements. Your strategizing needs to be far more granular than all cloud vs. all on-prem.
2. Assuming that All Workloads Are Created Equal
One of the common misconceptions informing decisions about the cloud is that you need to keep your business’s most critical workloads running in on-site infrastructure. Really, though, mission-critical doesn’t necessarily mean staying on-premises is the best option, but it does obviously mean interruptions will be more detrimental, which in turn means more planning is required. Despite all the horror stories, total uptime for most cloud services beats total uptime for most on-prem environments by a significant margin. And, if bandwidth is an issue, the best course of action is usually not to stay out of the cloud, but to simply get more bandwidth.
Outside of the mistaken assumption that business-critical means on-prem, however, the tendency for many business leaders is to think that what applies to one workload must apply to all the others. For migration projects, this misconception probably causes the most trouble when it comes to schedules and deadlines. Switching from on-site environments to Office 365 or Google Apps for email and document management can be relatively quick and painless, but that doesn’t mean migrating line-of-business apps will go as smoothly. For both technological and business reasons, every app will likely have to be evaluated and planned for separately.
3. Overlooking the Need for Pre-Deployment Testing
If something is going to go wrong with your app in the cloud, you want to find out about it long before you start deploying it to users. Performance issues can arise for any number of reasons, from cross-wired integrations to buggy legacy code. Since you can’t know for certain how well a given app will perform post-migration, the best policy is one where you test as you go. Some refactoring tasks will be more difficult and take more time than others, but either way you’ll want to discover whatever issues there are while there’s still time to fix them. The test-as-you-go policy obviously requires some extra budgeted time, as well as the resources for setting up a testing environment.
Unfortunately, there’s no switch you can flip that will simply transfer all your workloads into the cloud. As with most other IT projects, cloud migrations demand a sort of matching between business goals on the one hand and the capabilities of the tools on the other. It takes a lot of analysis, planning, and a deep understanding of the technologies involved. The good news is that there’s no reason to set company-wide migration to the cloud as an overarching goal, either in the short-term or the longer-term. The fact that migration planning needs to be done on a workload-by-workload basis means you can set your own priorities on your own timeline, and then decide to move or not a piece at a time. Of course, you are still in a race with your competitors, but the prize won’t necessarily go to the one who gets to the cloud fastest.
Popular posts like this: