The case for a private cloud pitstop

By Linda Sterling, Director & Principal Technologist, Cloud Design Architect, Sustaining Engineering, Ensono Adding a step in the on-prem-to-public-cloud journey can help you avoid migration messes and prepare your legacy apps to thrive in their ultimate destination

While migrations are rarely seamless and not always easy, there are a few considerations that can significantly smooth the process. First among these is the Cardinal Rule of a migration: Try to change as little as possible.

The move from on-prem hosting to public cloud is, almost by definition, a violation of this rule. With its lower upfront costs and the general push to jump on the “cloud train”, it can be quite tempting to migrate your entire infrastructure thinking you’ll save not only a ton of money but also time, by no longer having to worry about aging infrastructure or maintaining an entire building and its circuits, HVAC, power, redundancy, etc.

However, those costs are soon replaced by hosting and data egress fees, and a slew of new requirements as the products you used on-prem do not translate nor migrate as-is to the new environment. You no longer have control over how you want certain things configured at the platform layer, which means the security appliance you’ve been using that requires promiscuous mode to be enabled is no longer compatible. You also have the dubious pleasure of starting that effort all over again to identify a reasonably priced and compatible replacement. Remember that Windows 2003 FTP server with all the various security and firewall rules to protect against malicious access and still allow the application to function? That will require a reconfiguration, and if you can’t get it to work in your public cloud tenant, you’d better hope your Google Fu is strong because there’s no support and you’re on your own.

The lift-and-shift fallacy

I have seen many clients fail when they assume they can lift and shift their application stack from their on-prem environment directly into a public cloud environment. They honestly thought it would just work. They didn’t realize all the fine tuning and tweaking—what one of my colleagues likes to call turning the “nerd knobs”—that occurred while the systems were on-prem and made the application fast and seemingly robust. The more you turn those knobs, the more complex your solution has become and the less compatible it will be in a different environment.

Where I have seen clients running on-prem environments be most successful is when they transitioned from on-prem to a hosting provider—whether IaaS or a fully managed solution—before moving their systems to public cloud. This alleviates the financial burden of maintaining an on-prem environment while allowing for a proper transformation of legacy applications to get them closer to being cloud compatible or cloud ready.

If you’re still running operating systems that are in or out of extended support, public cloud may not be where you want to go right away. You need to find a safe place to uplift or refresh your aging application stack, test all the functionality and make sure all the necessary code and dependencies are working as expected. Then you can entertain the idea of moving into public cloud.

Navigating the path to private cloud: Two stories from the trenches

My recommended first step in this process is to conduct a discovery and assessment of your current on-prem environment. This allows the in-scope application stack targeted for migration to be mapped out and dependencies identified and can reveal bloat and remnants of applications from days past that are still running out there in your environment. It also enables identification of communication that occurs between all the various systems, which then results in a base firewall ruleset that can be implemented to facilitate a more seamless transition. This helps with migrating a server to a new platform within a new IP address range and ensures you will be able to reach it as well as authenticate.

There are quite a few technical options for achieving the end goal of migrating out of on-prem. The migrations I have been involved in have leveraged several technologies, each with their own strengths and challenges. I have used VMware’s Stand Alone Converter, Acronis, PlateSpin, Zerto, VCDA, NetBackup and Commvault. All of these achieved the result we were looking for. I have my favorites; you choose what works for you.

How the migration unfolds from there is unique to each circumstance. Here are two real-world examples from my own experience that highlight the different twists and turns the journey can take:

Smooth sailing with simplicity

A few years ago, we migrated a client from their on-prem environment to Ensono’s VMware-based private cloud. The goal was to exit both on-prem data centers by the new year, changing their IP address range and improving security. By the time I was engaged, it was August. Fortunately, this client agreed to a discovery and assessment. One challenge was their recent migration from VMware to Nutanix, which converted their VMDK format to Nutanix AHV format, making it hard to revert without running CLI commands and causing an outage. Thankfully, Commvault’s 1-Touch restore feature allowed us to back up a system and restore it to a different platform.

Phase one involved backing up systems in the Nutanix environment and restoring them to a smaller on-prem VMware environment without changing the IP address, just the underlying platform.

Phase one involved backing up systems in the Nutanix environment and restoring them to a smaller on-prem VMware environment without changing the IP address, just the underlying platform. This phase required systems to run for at least a week before migrating to our private cloud. Phase two added VCDA replication, migrating systems, and changing IP addresses in flight. Our base firewall ruleset, prepared from the discovery and assessment, allowed workloads to work as expected upon arrival. Any issues were quickly resolved since the only change was the IP address.

Choppier waters with complexity

Now for an example of what can happen when the cardinal migration rule is broken, and too many changes are made at once. This client needed to migrate from their on-prem data center to Ensono’s private cloud while simultaneously changing IP addresses, security posture (i.e., firewall stack, NSX micro-segmentation, route advertisements, etc.), and underlying platform architecture—all while maintaining a dependency on IBMi LPARs. Additionally, they were transitioning their end users to a different domain, different IP address scheme, and introducing Zscaler and proxies due to a spinoff from their parent company. Despite these complexities, the client opted not to have discovery and assessment completed.

Issues abounded, necessitating daily troubleshooting calls and a prioritized list of problems. The end user experience suffered. Slow web server response times, initially blamed on network and platform changes, were eventually traced to the new Zscaler deployment, which was inadvertently routing users from the U.S. to Asia and back to the U.S. web server. Once this routing issue was resolved, performance improved. We spent over a month together, methodically listing and narrowing down changes to identify focal points. Ultimately, we resolved all problems and achieved the desired outcome, but not without a considerable investment of time and effort.

Despite the different approaches and varying degrees of challenge, each of these engagements resulted in a successful migration from an on-prem to a private cloud environment that set the clients up for future public cloud migration success. The complications that cropped up along the way underscore the value of a private cloud pitstop. If you have a bumpy ride just going to a hosting provider, imagine what the experience would be like when attempting to directly migrate to public cloud. The architectural differences can be vast and wide, and you lose the ability to force compatibility for those older workloads.

There is no one solution in the distributed world that works for all.

One size doesn’t fit all

While these strategies can be considered best practices, they can’t ensure a perfect experience. There is no one solution in the distributed world that works for all. It’s also true that some applications just run better when you’re able to turn those “nerd knobs”. Susan in Finance with the Windows XP desktop that runs a special script written by someone 20 years ago who has since retired will be very upset when she can’t get her report to work. You’re going to need time to figure out what that script was doing and whether you want to spend the resources to modernize and potentially move it to public cloud which could take a year or more. Maybe it just needs to stick around for another three years and retire with Susan.

Whichever path you choose, I highly recommend that you take advantage of the many service offerings and resources out there to help you be successful. Get an assessment of your environment; listen to your engineers who are on the front line and know their estate; make sure you have a plan as well as a backup plan and, of course, a backup plan for the backup plan.

Most importantly, follow the Cardinal Rule of a migration: keep changes limited and closely aligned with your business and operational goals. Through that focused lens, you’ll be better able to scan the migration horizon and see which cloud is the right one for you to land on, right now.

Pose a question to our Mavens today!

Submitting a question is quick and easy. Just send us an email at askamaven@themavenreport.com. Include your question and let us know how you’d like to be identified (provide your name, company and/or industry) or if you’d prefer to remain anonymous.

Our Mavens personally review and consider each reader submission. If yours is featured in an upcoming issue, you’ll receive a special Maven gift—our way of saying thanks for asking a Maven.