Linux sysadmins: What is your cloud migration strategy?

Where are you in your cloud migration strategy? Are you just starting out, or are you well on your way? Are you pausing at a hybrid solution, or are you going all-in on a public cloud provider? Have you chosen to keep things in-house in a private cloud, or are you still plugging along with your own individual servers running workloads? Inquiring minds want to know.

A few short years ago, almost no one was interested in migrating to the cloud, stating security as the number one reason why not. However, today, in 2020, companies are now loosening their grip on in-house infrastructure and opting for something a bit more resilient, less expensive, and more accessible. There are always security concerns, but who's better equipped to handle security—you and your support staff or the watchful eyes of a cloud provider? Well, the answer wasn't so simple even five years ago, but now, it's undoubtedly the cloud providers that have the necessary tools and expertise to handle security.

Most small and medium-sized businesses, which are really the majority of all businesses, don't have the staff or in-house expertise to manage today's global security threats. Trust me. I have firsthand experience with a major security breach perpetrated by a foreign Advanced Persistent Threat (APT) group. 

[ You might also like: Getting started with software-defined networking ]

I've participated in and performed cloud migrations myself. I can tell you that good planning in the early stages can make the process go much more smoothly. Having a migration plan is the best thing I ever did.  My "big picture" plan looked something like this:

1. Assess and inventory all systems to be migrated—functions, resources, and workloads.
2. Consolidate and eliminate workloads.
3. Create a parallel cloud environment—mirror production.
4. Restore daily backups to the cloud environment from production.
5. Prepare email, DNS, and internet-facing services (NATs, PATs, forwards).
6. Engage alpha and beta test groups.
7. Enable new services and disable old ones.
8. Prevent access to old services.
9. Take the final backup.
10. Restore to the cloud.

Running a parallel environment is essential to your migration's success. For a really smooth transition, treat your new cloud environment as a disaster recovery (DR) site and perform a practice failover, with testers at the ready, a week or two before the official changeover. If your test fails, you can mitigate your issues and then repeat the test. Failures after you've migrated won't be taken well by management and staff. Plan ahead and test multiple times.

[ A free course for you: Virtualization and Infrastructure Migration Technical Overview. ] 

We'd love to hear your thoughts! Please participate in the poll regarding your cloud migration strategy.