DEV Community

Cover image for AWS Migration: Lessons from the trenches
David Colebatch for AWS Community Builders

Posted on

AWS Migration: Lessons from the trenches

It’s been over 12 years that I’ve been on AWS and I’ve seen a lot of cloud adoption initiatives since 2008, lately there’s been an accelerating number of cloud migration projects to AWS, Azure and Google Cloud. It seems only fitting that I share with you a run-down of the top three lessons I’ve learned in this time I’d be interested in hearing yours too.


1. Analysis Paralysis

Usually seen when more traditional IT departments take the lead on a cloud migration, analysis paralysis is the problem of spending months and years in abstract architectural planning meetings trying to solve all the problems of the universe. Generally, this comes from a lack of understanding in the new paradigm that AWS provides and trying to shoe-horn existing ITSM process as well as their datacenter architectures into the cloud-box.

If you find yourself in endless discussions around the perfect landing zone design and playing “what if?” whack-a-mole with your security team, do yourself a favour and spend a few dollars hiring someone who has done it before. Then, start small.

2. Too Big to (not) Fail

On the other side of the spectrum from #1 is when companies jump in without any thought given to the organizational change that is required to support a technology transformation. This results in customers adopting only EC2 and treating AWS as a giant virtualization provider. Yikes — didn’t that strategy ever miss the point — we’ve just moved our same operational problems elsewhere.

Thankfully there are now enough case studies of these lift-and-shift mass-migrations which have resulted in sticker shock, and in some cases, reverse migrations, that our current customers aren’t considering the outsourced “migration factory” approach.

Top trigger term here: “Flash-cut the DC to the cloud.” Yeah, not anymore.

3. Start small, migrate with purpose

The most successful cloud deployments we have seen start with an application portfolio assessment, to identify the low-hanging fruit of applications that are (a) easiest from a technology perspective and (b) valuable enough to the business that the applications migration yields tangible results for the business.

Leveraging out-of-the box landing zone automation and reference architectures gets customers a long way in terms of adopting best practices. Having the organization recognize that these architectures will continue to evolve over time through small incremental changes, will remove the need to wait until every man and his dog has “signed off” on the designs.

It’s a novel approach for most teams, and one that goes against the grain of traditional enterprise architecture gating processes. But it is one that has served us very well in the past, with the right executive leadership to support it.


Lesson learned: Start small, don’t over-complicate things, and build momentum for your organization. Each migration can feel slow to get going, be it from naysayers, server huggers or lack of confidence from your team itself. If you follow these 3 steps, your migration will snowball and your project sponsor will look like a visionary genius, while your name lives forever as a migration hero.

It’s that easy. :)

-David Colebatch
Chief Migration Hacker, Tidal Migrations

Top comments (1)

lotushunter profile image

Well written blog. Good points.