Private and Hybrid cloud are an exciting topic but you've got to do it right! In this presentation, you'll learn the 10 Best Practices for Migrating Applications to the Public, Private or Hybrid Cloud

1. 10 Best Practices for Migrating
Applications to the Public, Private or
Hybrid Cloud

2. #1 Determine any changing OS or app
licensing provisions
Depending on where you are migrating your application to,
you may need to reassess the licensing requirements for both
your operating system and your application. This will apply
when you are migrating the entire stack, the OS and/or the
app. Make sure the location that you are migrating to
supports running what you have. Bigger cloud providers may
require different or special licensing according to their model.
Take a look at your end-user license agreement to confirm any
special scenarios or circumstances.

3. #2 Asses your application’s Data
Gravity
Data gravity will apply regardless of whether you are migrating the
whole stack or just part of it. To assess the data gravity of your
application, calculate the rate of change. As a general rule, if your rate
of change is greater than of equal to your bandwidth, your migration
will likely fail. That’s because the rate of change refers to everything
coming in to the app, it’s gaining gravity as the rate comes in. The
bandwidth is like the escape velocity it requires to get off the
ground, or migrate. You need a high enough bandwidth to “overtake”
that rate of change.

4. #3 Understand how your application
is connected to other applications
Few apps are an island. Before you choose the application to
migrate, check the coupling and connectivity of your
application to other applications. Migrating “App A” may
require migrating closely coupled “App B” and “App C” as well
if they won’t be able to handle the increased latency from
being pulled apart. There’s no magic formula for assessing
this checkbox, just knowing your architecture, how everything
connects and how closely those apps need to be coupled to
run efficiently is key to a successful migration, though.

5. #4 Do judge an app by its Disk Format
When migrating entire VMs, your disk format may
need to be converted as you move from one cloud
(or system) to another. AWS uses AMI, which is
different from VMware VMDK, which is different
from Microsoft VHD. Be sure you have converter
tools and know how to do the conversion if you’re
migrating entire virtual disks.

6. #5 Network Services: Firewalls, Load
Balancers and IPS
Whether it’s compliance or app scalability, moving to
cloud means you’ll have to use whatever network
services that your cloud provider has available. If you’re
required to have an Intrusion Prevention System
(IPS), make sure that your security vendor or your cloud
provider has something for you to use. And, be sure you
are able to convert the data that you already have to the
cloud provider’s format.

7. #6 Software services updates
required
This includes OS/app patching and antivirus. However
you’re doing these currently will likely need to be
revisited for how you will check these off in the future.
The tools and procedures you currently use and have
documented will need to be updated. That’s true not
only if you’re migrating to a new cloud, but your software
services still need to be reassessed going from private
physical to private cloud, cloud-to-cloud or physical-tovirtual.

8. #7 Backups are an app’s best friend
Enterprises are used to a certain level or grade of
backup policy. Those policies will be different in the
cloud, so before migrating you will need to be sure
to update your procedures and be ready for change.
Your provider may have recommended best
practices and/or unique options available based on
the location to which you are migrating.

9. #8 Prevent lock–in before it’s too late
The general rule of thumb is to make sure that if you put
your data somewhere that you still own the data. And,
that place should be somewhere that you are able to exit
at any time with your data. More than just the data, this
should also apply to things like configurations,
performance statistics and other metadata that could be
useful if and when you leave the provider. Always have an
exit strategy because you never know when you will need
it.

10. #9 Connectivity is important
Like we mentioned before, few apps are an island. It’s
rare for enterprises not to have some sort of private
connectivity to their cloud provider. Different cloud
providers may have different connectivity options and
restrictions available. Make sure that your new provider
has the level of connectivity that you require. If the
connectivity is particularly important, make sure it’s part
of the SLA.

11. #10 Do your P2V homework
When moving specifically from a physical system to a
virtual system or a physical system to the cloud, you
should always follow P2V best practices. This means
reading up on any software tuning that needs to be done
and removing any legacy software that pertains to the
physical world. Don’t forget things like battery back-up
software for your physical system. This should be done
BEFORE the migration.