Sixty-three percent (63%) of enterprises on the cloud plan to migrate more workloads to the cloud. But many enterprises struggle with how do you get from one or two apps on AWS to a mature, governable AWS environment at scale.

This week we sat down with Irina Reznik, Logicworks’ Operations Project Manager, who oversees large-scale AWS migration projects and has helped dozens of organizations move to AWS. Irina has seen it all: different workloads, from SAP to Microsoft, different teams, different industries and end goals. Below are her recommendations for how to accelerate AWS adoption sustainably.

What is the biggest challenge for enterprises migrating to AWS?

Expertise. It sounds obvious, but a successful migration is really all about having the right people with the right skills. Every workload is different. Every migration is different. There is a lot of AWS documentation and online help, but the chance of you finding a blog post or white paper that solves your specific migration use case is close to zero.

So the first way to accelerate AWS migration is to find a team that has migrated a workload like yours before. If you find a handful of DevOps engineers, you will be very lucky. Most organizations choose to hire a migration/DevOps partner (like Logicworks) because a: finding DevOps engineers is incredibly difficult, and b: even if they do find those engineers, it makes sense to multiply those engineers’ power with automation and an outsourced DevOps team.

How important is the project manager role in cloud adoption?

Honestly, I cannot imagine a migration project without a focused project manager that is also trained on AWS. On a daily basis, I schedule engineering resources, email the engineers at AWS for special requests, attend daily standups, troubleshoot access issues, train our clients’ engineers, field questions about new AWS products — things that no engineer should do, and no project lead or business manager has time to do either.

I have worked with AWS for about three years and started as a NOC engineer. I think it is crucial that the project manager is not just someone who creates GANTT charts, but is on the ground, looking out for future pitfalls, and understands what it takes to do an AWS migration or improve an existing AWS environment. A central project manager is especially useful in complex migrations where multiple project teams are involved; they can also serve as a hub of shared knowledge about all cross-team migration initiatives.

Sometimes, the single most important thing I can do is answer a question. Often clients we work with have relatively complex questions, and if they tried to find an answer alone, it could take hours or even days of trial and error. My job is to prioritize that question, either with our own engineers or with AWS, and get an answer quickly so that their migration timetable stays on track.

What workloads are growing in popularity for AWS migration?

There is a lot more interest in the last year in enterprise applications like SAP HANA and Business Suite and Microsoft Exchange, SQL and Sharepoint. This just reflects the maturity of public cloud solutions: more enterprises are focusing on the “harder” applications using AWS’ latest services, like the X1 instance.

The organizations that are successfully migrating these business-critical applications already have mature cloud governance and management policies, or are relying on a partner to manage these workloads. Usually these applications require 100% SLAs, which is beyond what AWS will offer, meaning that the organization either must be willing adopt some risk or will outsource that liability to a partner.

What is the most common misconception about large-scale AWS adoption?

To support large, mission-critical applications in AWS, you need to have automation in place. You cannot possibly catch every configuration error, or every about-to-expire SSL cert, or manually reboot individual instances.

The most common misconception is that AWS is already automated, that Auto Scaling is easy to set up, or that some third party software will fill in the gaps. The truth is that off-the-shelf orchestration products are only for relatively simple workloads; the automation you really need is customized per-application and per-environment. And “automation” means not just Auto Scaling, but an entire orchestration and monitoring layer that proactively corrects misconfigurations (usually in a configuration management tool like Puppet) and spins up new AWS resources without human intervention (a combination of AWS CloudFormation, configuration management, and a secure deployment pipeline).

Automation not only improves and protects current workloads, but by building out standard templates and scripts, it significantly accelerates the buildout of future environments.

Organizations do not have to go from zero to fully-automated overnight; we talk here about the steps from NoOps to DevOps. But again, having a partner that already has the configuration management and templating skills to help you automate can actually reduce your ongoing management costs, make your workloads more reliable, and can even educate your internal teams about the value of automation. Every week, I see organizations avoid disaster because one of our automated tools caught something and alerted our NOC, and every day, thousands of Auto Scaling events happen with zero downtime or human intervention across our client base. It is very cool to watch automation “work” in real time.