Series 2 - Three Options for Migrating to the Cloud

First: if you haven’t already done so, we highly recommend reading our blog post on Cloud Lingo before continuing. Things get hooey if you don't have the cloud-vocabulary nailed down.

Otherwise...

So you’re beginning to formulate some ideas for your new cloud-based services. Perhaps you already have a plan. You’ve identified your system’s clients, considered which services make the most sense for your company, and scoped out some vendors. You’ve envisioned a beautifully efficient cloud-based future, and it works, it makes sense, hypothetically. But you’ve looked only ahead. Unfortunately, moving to the cloud involves just that, some actual moving, what’s called “migration”; it involves looking backwards at your current infrastructure and figuring out from there how you’re going to move (migrate) its valuable data to the confines of your new cloud-infrastructure. This requires a plan and a good sense of your Business & IT Objectives. You’re looking for a thought-out strategy coherent with your company’s status. It is a complicated step.

We’re here to make IT work, so we’re breaking this down into three general migration options:

1. Server-Level Migration

2. Component-Level Migration

3. Data-Level Migration, so to a Saas or IaaS or PaaS

Let’s take a look at each.

1. Server-Level Migration

This is a basic migration, one that avoids some of the learning curves and headaches associated with our other, more elaborate options (Options 2 and 3 on our list). The concept of this migration-type is simple: take whatever you have right now exactly as it is and put it on the cloud. It will look and act exactly the same as it has; only its location is different. There are a number of instances where this makes sense. Most obviously, if your server environment is stable and you’re largely content with your server’s organization as it is now, there’s no need to change it. If you’re migrating software that is without proper support, often the case with boutique products, or software lacking install disks, exactly replicating your server allows you to continue to use this software and circumvent a slew of new software purchases. The dark side of replication is that errors are copied along with it, and if upgrades are needed, you can get stuck with compatibility issues. The initial migration, however, often minimizes incompatibilities, and again: if your environment is stable, discombobulating upgrades may not be necessary for some time. It’s generally the simplest and quickest option, and since the replicated server has been your working server, there is rarely a need for rigorous testing. You know how it works and that it works.

2. Component-Level Migration

This migration-type responds directly to some of the issues that might arise when considering Option 1. If you foresee components of your server’s software needing comprehensive upgrades, or if your server environment is too unstable to host them, or will become too unstable, you might need to replace them as you migrate. In other words: bring along everything that works and replace whatever doesn’t or won’t. The obvious advantages of this are these new components will be perfectly able to update for a long time, and the newer, better software will inject high performance into your system. However, as anyone who has replaced car parts in a similar fashion will know, it can be difficult to get outdated parts to function efficiently, or at all, with newer parts. It can be difficult to even install the parts in the outdated shell, and compatibility can be a total guessing game; you might have to swallow some errors before getting the balance functional. Naturally, testing for Component-Level migrations can be extensive. The cost of components and time-consuming installs needs to be weighed carefully against Option 1 and, in particular, Option 3.

3. Data-Level Migration

A Data-Level Migration completely replaces your server’s image, or its organization and structure, with a standardized cloud service. In essence, it’s your data in their build, which they host, where “they” is a company, like Microsoft, that sells builds or services. This is a good option if you have too many faulty components to replace in a budget-responsible manner, if you just want to standardize your varied software and cut out compatibility issues, or you have a big database that needs a big data migration to the cloud: providers of cloud platforms typically have the infrastructure and scalability to handle your database’s needs. And yes, this is where PaaS, SaaS, and DaaS come in: depending on what YOUR need is, these companies will give you their various form of service. Microsoft’s Office 365, for example, is a SaaS—you pay for access to cloud software Microsoft hosts on its own servers. The advantages are easy to see. You don’t have to worry about scattered component upgrade schedules, an out-of-date server, or, mostly, compatibility. Often, you have to pay for these data services, usually at a monthly rate.

These are the three migration options. In review:

1. Server-Level Migration