<img src="https://secure.seem3pick.com/198073.png" style="display:none;">

Series 2 - Three Options for Migrating to the Cloud

Posted by Ben Olcott on Fri, Jul 25, 2014

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.


pavis cloud

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.

cloud lingo

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

cloud office

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

    • A transfer of your current server exactly as it is to a cloud platform
    • You have a stable data environment
    • You run unsupported software you do not want to pay to upgrade
    • Few compatibility issues – you know it works
    • Easiest  and quickest migration type
    • Short testing phase – you know it works
    • It’s a direct copy – any errors will be copied over
    • Once you switch you’re stuck – upgrades can be an issue

2. Component-Level Migration

    • Updating, reinstalling, or replacing outdated, non-functioning software as you migrate
    • You don’t want to pay for a data service, but your current server isn’t working at the level you need it to, or your software sources are unstable
    • Replaced parts are easy to update
    • Newer, better software injects performance into your server
    • Difficult to get all components working together, and thus time-consuming
    • With so many different compatibilities, there will be errors – test cycles will be long
    • Scattered upgrade schedules can be confusing

3. Data-Level Migration

    • Complete replacement of your current server with a company’s build and services
    • Your server components are outdated or beyond repair
    • You need to migrate a database – large companies can handle the load
    • When you’re looking to simplify your server
    • Straightforward and easy to use
    • Upgrading is simple and happens often
    • Environments are always state-of-the-art
    • Monthly, per-user rates, most often
    • Potential configuration issues
    • Expense – monthly, per-user rates might not make the right price sense
    • Incompatibilities might occur when using extra-company software

 cloud security







Ladies and Gentlemen:

Microsoft Office 365 Part 1

Microsoft Office 365 Part 2

Microsoft Office 365 Part 3


Office 365   Upgrade your Business

Tags: Cloud Computing, Microsoft, Managed Services

Subscribe to our BLOG

Recent Posts