Migrate the company’s SaaS platform from a co-located data center to a public cloud within six months. This was my first task upon joining Shiftgig last year. It made total business sense: improve failover across regions, lower the total cost of ownership, and greater flexibility to scale and experiment with new technologies. It sounded great and I was ready to tackle this project until I learned about Shiftgig’s “lift and shift” plan.
A lift and shift plan means moving applications and data with minimal or no changes, typically to a new cloud-based location. While this strategy does allow organizations to move applications quickly and easily, it’s not always the best fit for custom or more complex programs. As I listened to horror stories of previous attempts I wondered how much faith the team had left in the cloud migration (and I wondered what I had gotten myself into.)
After spending a couple of weeks getting to know the technology stack and the team, I decided the only way forward was to embrace a cloud-native migration and ditch the lift and shift plan. We had little time and very few hands left, so we needed to leverage all the services we could and avoid building from scratch. And here came the first win and success factor: the leadership team said yes to my proposal. In fact, they were thrilled to embrace the cloud-native approach. It was a great vote of confidence and motivator.
I also had my own personal goal: Could I complete the whole migration without spinning a single virtual machine (VM)? (I’d give myself bonus points if I never had to open port 22 again!)
Here is how we did our migration and what we learned:
Front-end Applications: Originally served from Nginx servers, the content was moved to a private bucket and served with the cloud provider’s CDN service. It was also the first thing to be migrated because it was the easiest! It was also a strategic move to build trust in the migration and gave me time to get to know the tech and the people in the organization. I know the next moves were going to be harder.
Databases: We had Postgres, Redis, MongoDB, and Couchbase to deal with. All were moved to cloud-based services except for Couchbase. This was the only case in which I had to spin up VMs, but thanks to the cloud provider features, I did not have to open port 22 to log in! Also, we took the time to decide what data needed to be moved, and we learned that some old legacy data could be left behind which reduced our capacity needs. Database upgrades are now just a config change once the apps are ready.
Messaging Broker: We needed RabbitMq, and thankfully we were able to rely on a cloud provider for this service as well. We leveraged private network peering to keep all of our traffic private and secured across the two providers.
Back-end Applications: All of the back-end applications got packaged into docker images. We leveraged the cloud provider’s container orchestrator service to run them, no servers needed. This has opened the door to multiple release strategies like blue-green deployments, canaries, etc. Rollbacks as a brief when needed.
Ditching the lift and shift was a great decision for us. We are now fully migrated and enjoying the benefits: improved performance, better security, ease of scaling up and down, and maintenance is painless. Our energy now is devoted to optimizing the Deploy platform to deliver outstanding service levels and building new products for our growing user base. Of course, every project and company is different, but I encourage you to consider ditching your lift and shift plan too. Bring a fresh pair of eyes, preferably someone who has worked with cloud infrastructure before. Maybe you will be left with just a handful of virtual machines and no port 22 to worry about too!
Are you an engineer interested in tackling technical challenges like this? We’re hiring! Check out our open roles and apply today.