It wasn’t too long ago that the idea of migrating an infrastructure to the cloud was seen as a gamble. Cloud technology was still in its infancy as recently as 2009, and companies that made the jump from on-premise data centers to the cloud were either pioneers of brand new tech or suckers buying into the hype, depending on who you talked to.
Nowadays, cloud-based applications are the norm for startups and newer SMBs. It’s a low-cost, flexible, and scalable alternative to a personal data center, a solution that lets companies adapt to changing needs on a dime without worrying about the upkeep and maintenance of on-premise hardware.
But just because it’s extremely popular doesn’t make cloud migration any less overwhelming. For older companies, ones that have relied on on-premise servers for years, the move can feel like a total upheaval. Maximizing your migration to the Cloud can mean re-thinking the way your business operates and organizes.
So to ease some of your concerns, Codal’s cloud engineers put together a few key things to keep in mind when undergoing migration. Think of it as a travel guide, a handy reference before making the switch to the cloud.
CRAWL BEFORE YOU RUN
One of the most difficult aspects of cloud migration—especially for older, companies—is that their current legacy tech is part of a monolithic system. Its elements are tightly interwoven, which makes it hard to swap out components without disrupting the entire machine.
Imagine two cubes, one made out of concrete and one made out of Legos. Say you wanted to reshape those cubes into a pyramid, or a rectangular prism, or some other form. Which cube is going to be easier? For the Lego cube, you’ll be able to quickly disassemble it and rebuild it into your desired mold. The concrete cube…well, I hope you’ve got a jackhammer handy.
That’s the difference between cloud applications and monolithic, legacy ones. The Lego cube represents cloud services like AWS, and the concrete one is the legacy tech.
So before you move an entire monolith application the cloud, start small. Migrate comparatively isolated applications—a landing page, for instance—that isn’t dependent on a host of other technologies. Migrate, test, and then apply what you learn to the next migration phase.
It’s tempting to dive right in to the big stuff, but even enterprise cloud migrations began with simple, basic applications. Even Netflix, one of the most notable examples of a company pivoting to the cloud, began by moving over just a single page onto Amazon Web Services, in order to validate their decision.
CHOOSE A MIGRATION PHILOSOPHY
No two cloud migrations are alike, which means no two cloud migration strategies are alike. They differ by specific use cases, timelines, budgets, technologies, and a litany of other factors. It’s near impossible to take one cloud migration and duplicate it exactly for another company—the digital landscape is just too fractured, too diverse.
But while you can’t copy-and-paste a cloud migration strategy, there are a few different overarching philosophies that many of these migration plans subscribe to. For companies saddled with legacy technology, these essentially boil down to two options: the ‘lift-and-shift’ or the ‘fix-and-shift’.
‘Lift-and-shift’ describes the simple transition from data center to cloud, with little to no changes in how the application works or runs. It may not be optimized for the cloud, or leveraging the cloud to its maximum potential, but that’s fine for now. Lift-and-shift is quicker, easier, and ideal for simpler applications (where there aren’t too many major differences in how it runs between the cloud and on-premise).
Fix-and-shift essentially drags and drops your application from the server to the cloud (Source)
‘Fix-and-shift’, on the other hand, takes the time to optimize and reorganize the application (and its workflows) before it’s deployed. This doesn’t just mean re-developing either—it can extend to re-structuring entire teams.
In his piece on cloud migration case studies, Increment’s Chris Stokel-Walker describes the fix-and-shift method as “buying into the concept of moving to the cloud, fixing your culture along the way, and making it more adaptable to the new norm.” It’s more resources doing more work upfront, but the long-term benefits can outweigh the price of extending the migration’s timeline.
TEST, AND TEST AGAIN
One of the cloud’s biggest draws is its scalability, the way companies can effortlessly optimize their usage by paying for only what they need. But the feature asks a thorny question: how much do you need?
While you won’t truly know until you launch your application, you can get a fairly accurate estimate by simulating the workload it a test environment. By running the application on a staging platform, you can better clock the bandwidth and usage requirements you’ll need for the real launch.
Which metrics you’ll actually be monitoring, and the fidelity of your simulation, will depend on the specific type of cloud application and its use case. But as a rule of thumb, the more you can match the final environment, the smoother your launch will be. Better to just tweak to the resources you need than to go-live with a rough estimate that turns out to be more wrong than right.
IT’S EASIER THAN YOU THINK
When I wrote this blog post, my goal was to shed some light on the intimidating process of cloud migration. What I didn’t want to do was add to your cloud migration to-do list, overwhelming you even further. So my last piece of advice: don’t sweat cloud migration too much.
It’s not 2009 anymore. There are endless resources out there, from how-to guides and user-friendly documentation, to digital agencies that can perform the migration for you. Cloud migration is easier and much less stressful than you think! As a software development company, Codal has migrated companies of all sizes and sectors to the cloud. If you’re looking for further guidance, don’t hesitate to reach out and contact us.
