In search of everything from cost savings to faster releases and more innovation, modern enterprise software shops are busy working to migrate their on-premise applications and other workloads to the public cloud. From the New Relic blog to Amazon Web Services and beyond, many experts are doing their best to help in this epic movement.

Amidst all the excitement, though, it’s easy for essential points to get lost, so we asked New Relic’s cloud experts (from product folks to cloud evangelists) for their thoughts on the overlooked essentials of an enterprise cloud migration. Here are their insights:

1. Cloud migration is easy; digital transformation is hard

At the most basic level, cloud migration is all about getting things out of bare-metal virtual machines and into cloud instances. There may be some immediate cost benefits to that, but the realjourney toward modern software efficiency doesn’t even begin until you get to the cloud. The real goal is to adopt cloud services to speed development, enable teams to manage infrastructure more autonomously, and ultimately improve your customer experience. Early, comprehensive monitoring is essential to that digital transformation, which is when you actually reap the full benefits of moving to the cloud.

Don’t miss:

2. Cloud migration is also cultural move

For many companies, a successful cloud migration requires a cultural shift even more profound than the technology changes. If after your migration you’re still doing your same dev methology, but just doing it “in the cloud,” you aren’t going to get the great leaps in productivity you’re looking for. According to AWS principal John Enoch, as quoted in Forbes, “those organizations that have a business plan and can communicate together as teams get really good results and those that can’t don’t.”

Don’t miss: DevOps and Culture Change Cut Time-to-Market for KPMG

3. Cloud and DevOps, or the chicken and the egg

One of the most common reasons why companies move to the cloud is to help implement DevOps practices. And one of the most common reasons why companies implement DevOps practices is to help them move to the cloud. Chicken, meet egg. Or maybe, chocolate, meet peanut butter.

Don’t miss: New Relic Cloud Survey Reveals Key to DevOps Success

4. Speed vs. stability can be a complicated equation

cloudsOne of the cloud’s big advantages is the opportunity it offers to provision resources faster and more dynamically to meet real-time demands. That can help save money on unused infrastructure and alleviate the short-term pain of frustrated developers waiting for servers. Properly managed, smaller, less comprehensive, more frequent deploys can actually be more stable. But a cascade of poorly managed deploys with short lead times can result in chaos. Companies need to institute processes to manage and optimize the tension between speed and stability in cloud environments. That means ensuring parity between staging and production environments, properly validating all changes, incorporating modern deployment approaches such as blue/green and canary deployments, and—of course—advanced monitoring techniques.

5. Code-level visibility is essential to monitoring cloud applications

When selecting a vendor to help you monitor cloud applications, you have to ensure it offers code-level visibility. Why? Because public cloud vendors are driving customers to embed “infrastructure as code” into their applications. So deep visibility into applications is becoming a critical component of understanding infrastructure health and cost. Infrastructure metrics alone are critical, but not enough for the future.

6. You need to understand the six Rs of cloud migration

How do you decide whether to lift-and-shift an application into the cloud, or refactor it to take better advantage of capabilities available only in the cloud. The answer? It depends. Consider each of the six Rs of cloud migration strategy (rehost, replatform, repurchase, refactor, retire, and retain) on a case-by-case basis. For instance, if your team is struggling to maintain its database servers, you might want to consider refactoring to use a cloud database as a service offering. That can help reduce the need to for database server maintenance, patching, and so on.

Don’t miss:

7. There are many great cloud migration tools

Your cloud migration doesn’t have to be a blind leap.  There are many tools to help you with planning, discovery, and tracking each step of your migration. Use these tools to take inventory, build a pre-migration business case, perform migration readiness, plan the actual migration of workloads and data, and validate that your migration was successful.

Don’t miss: Migration Tools—A Puzzle or Lego Blocks (AWS re:Invent 2017)

8. Consumption metrics are not enough

Many times when companies migrate applications to the cloud, they look only at infrastructure consumption metrics (CPU usage, disk I/O, etc.) but never at end-user experience metrics (response time, error rate, etc.) that show how the application is actually performing. That makes it hard to answer questions about whether the migration was “successful” or not. To truly understand the results of a migration, you mustlook at app performance in depth in addition to cloud infrastructure health.

Don’t miss:

9. Proper pre-migration instrumentation can save you big $$$

For a cost-effective cloud migration, it’s critical to include instrumentation as early as possible in the process. For example, New Relic research has shown that implementing proper instrumentation before you begin your migration can save you from 16% to 25% of your total migration costs. Without pre-migration benchmarking, it’s difficult to determine operational parity post migration, so cloud migrations can end up running parallel environments far longer than expected.

Put simply, spending 48 hours instrumenting your systems before a cloud migration can save 3 months or more of migration time.

Don’t miss:

10. CapEx vs. OpEx

An often under-appreciated element of moving from on-premise applications to cloud-based applications is not technical, but financial. The two approaches use radically different expense models. On-premise infrastructure costs are usually considered capital expenses (CapEx) while cloud service costs are typically accounted for as operating expenses (OpEx). That difference doesn’t usually affect the overall impact on the bottom line, but it can be a big deal to the CFO and the accountants who have to make the numbers come out right.

 

Big thanks to the experts who contributed their insights to this post: Henry Shapiro, Lee Atchison, Rob Peterson, Chhavi Nijhawan, Tori Wieldt, and Ravi Tharisayi.

fredric@newrelic.com'

Fredric Paul (aka The Freditor) is Editor in Chief for New Relic. He's an award-winning writer, editor, and content strategist who has held senior editorial positions at ReadWrite, AllBusiness.com, InformationWeek, CNET, Electronic Entertainment, PC World, and PC|Computing. His writing has appeared in MIT Technology Review, Omni, Conde Nast Traveler, and Newsweek, among other places. View posts by .

Interested in writing for New Relic Blog? Send us a pitch!