Skip to content
CTP is part of HPE Pointnext Services.   Explore our new services here →
  • The Doppler Report
Cloud TP Logo
  • Thought Leadership
  • Clients
  • Services
  • Careers
  • Contact Us

Cloud Technology Partners

CLOUD SERVICES

  • The Cloud Adoption Program
  • Application Migration
  • Software Development
  • Infrastructure Modernization
  • DevOps & Continuous Delivery
  • Cloud Security & Governance
  • Cloud Strategy Consulting

TECH DOMAIN

  • Amazon Web Services
  • Google Cloud Platform

ABOUT US

  • Company Overview
  • Leadership Team
  • Partners
  • News & Recognition
  • Announcements
  • Weekly Cloud Report
  • Client Case Studies
  • Events

CAREERS

  • Join Us
  • Job Opportunities
 Cloud Technology Partners
  • Doppler Home
  • Client Case Studies
  • Podcasts
  • Videos
  • White Papers
  • Quarterly
  • Events
  • Subscribe

What Is So Complicated About Lift-and-Shift Cloud Migrations?

John Cronkite Cloud Architect
October 8, 2019 THE DOPPLER
Share this 
doppler_mail1

For more content like this, Get THE DOPPLER
email every Friday.
 
Subscribe here  chevron_right

Has this ever happened to your organization? You have just gone through a seven-hour cloud migration, something goes wrong and the IT team has to stop the process and roll the project back. Later, you relate the experience to an engineer outside the team, and the person responds in a confused manner. “That should have been easy. It was just a lift and shift.”

Of all the cloud migration options, the lift-and-shift approach is probably the least intensive and least risky to pull off. You pick up bundles of small, less critical, on-premises apps, and move them to the cloud. This means you can capture the cloud’s benefits without having to painstakingly rearchitect existing apps or integrate new ones into your organizational processes.

Lift and shift is efficient. It is straightforward. But that does not mean it is easy.

There are complexities hidden under the surface, which organizations may not fully understand. Any one of these wild cards can trip up a project and force team members to start over. Things go wrong, deadlines are missed, costs rise and outside stakeholders unfamiliar with the process begin hurling questions at the project owners. Why is this taking so long? Why did you not catch these issues in QA? Why am I seeing POs to vendors? Why is this so hard?

Lift-and-shift projects are harder than they look, but they can be successfully managed if they are approached the right way. Organizations can pull off these so-called “rehosting” projects efficiently, perhaps even seamlessly, if they know where the problems can come from, and take steps to keep them from getting in the way.

Here are some common lift-and-shift missteps and some tips for avoiding trouble.

Misstep #1: IP address changes can cause ripple effects

Changing an IP address is a small thing, right? Actually, this process can wreak havoc. When you move to the cloud, most likely you will get new IP and MAC addresses. This gets complicated when vendors tie licenses to a specific system profile. To keep the whole application from breaking, you will want to check the status of support contracts and update any lapsed licenses. You will also need to make sure that all connected applications are leveraging DNS and not hard-coded IPs for communication. Application configurations based on hard-coded IPs will need to be updated when the app is migrated.

Misstep #2: You did not account for application dependencies

Very few apps these days operate independent of other systems. To start with, your two-tier application consists of an application server and a database. Is the application server configured to pull data from any other internal systems or third-party vendors? Does the database have DB links to other internal systems? If you do not review the spider of dependencies before migrating an application, a web of issues can unravel as testing continues.

Misstep #3: Did you allow for an outage window?

Moving an app is not like sending an email. It takes time to get from place to place. You will need to set aside an outage window to allow enough time to accomplish a series of maneuvers: migrating the technical server, reconfiguring the application and doing business testing/signoff. You will also want to build in time to roll back systems in the event the migration is unsuccessful. Yes, this means always having a rollback plan ready for each migration.

Misstep #4: Features were not tested in all environments

The standard mitigation approach is to migrate application environments starting with the lowest environment levels, and then make your way up to Production. This allows you to catch any issues and have an expected timeline for the Production migration prior to the migration event. But what if your different environments – Development, Quality Control and Production – are built on their own independent server stacks? All the features may not have been fully tested. You need to work with the application team to develop a prescribed plan to have testing across each environment, so you can work through problems as they come up.

Misstep #5: If you need vendor help, lock it in

If you do encounter a problem, you are going to want to correct it right away. But that may not be possible if you need vendor support and the vendor is not available. If your SLA stipulates that the vendor will call back within, say, four hours, your migration will have to wait. It is best to anticipate potential issues and reach out to vendors ahead, to time to make sure they will offer the support you need and will be around to walk you through a solution.

Misstep #6: Do not sneak in any last-minute changes

Doing a domain change while moving the server may seem like a great idea – kind of like making two improvements at once. This is actually a bad idea. When you change components midstream, you no longer have a steady point to look back on, to make sure the app works the same way. It can confuse the system and force you to roll back much farther than you would have during a normal process.

Misstep #7: Did the application even work before the migration?

This may seem obvious. But if a cloud service does not work correctly after a lift and shift is done, find out if it was actually working before the migration. Problems will not magically fix themselves on the app’s journey to the cloud. Setting proper expectations about app performance before migrations can eliminate finger pointing afterward.

Misstep #8: Check the network ahead of time

Networking controls in the cloud are more restrictive than comparable controls on premises. In the cloud, the firewall policy has to be programmed to determine what connections the networking controls can communicate on. Leveraging a tool to understand what ports and protocols are being used between servers in an application stack will help prevent most migration bridge network troubleshooting issues. Doing a networking analysis ahead of time often reveals dependencies that would cause a required rollback if they had not been previously identified.

Misstep #9: Commit to the cause

To make migrations successful, organizations need to have buy-in not only from IT but also from the business stakeholders themselves. For the first few weeks of an initiative you will probably have everyone’s full attention. Then, as the date approaches, both IT and business units tend to start shifting to other priorities, assuming that all the facets of the migration process are in place. This leads to migrations where critical resources are “unavailable” during the process. Organizations need to keep the pressure on, to make sure that everyone is focused, and the right resources are being allocated.

Conclusion

Bottom line: Migration projects may be complicated, but they can be handled – with the right focus and preparation. Organizations have to commit to the process. They have to identify what can go wrong, head off problems before they appear and then follow through on their plans.

After all, it is not just a lift and shift. It is a vitally important move for the success of your business.

Share this


Related articles

 

5 Steps to Building a Cloud-Ready Application Architecture

 

All in on AWS

 

Putting Ourselves Out of Business: How Kronos Reinvented Itself to Change the Future of Workforce Management

By Bill Bartow

Related tags

Cloud Strategy   CloudOps   mig   Software & Technology

John Cronkite

John Cronkite is a Cloud Architect at Cloud Technology Partners, a Hewlett Packard Enterprise company.

Full bio and recent posts »



Find what you're looking for.

Visit The Doppler topic pages through the links below.

PLATFORMS

AWS
CTP
Docker
Google
IBM
Kubernetes
Microsoft Azure
OpenStack
Oracle
Rackspace

BEST PRACTICES

App Dev
App Migration
Disaster Recovery
Change Management
Cloud Adoption
Cloud Economics
Cloud Strategy
Containers
Data Integration
DevOps
Digital Innovation
Hybrid Cloud
Managed Services
Security & Governance

SUBJECTS

Big Data
Blockchain
Cloud Careers
CloudOps
Drones
HPC
IoT
Machine Learning
Market Trends
Mobile
Predictive Maintenance
Private Cloud
Serverless Computing
Sustainable Computing
TCO / ROI
Technical "How To" Vendor Lock-In

INDUSTRIES

Agriculture
Energy & Utilities
Financial Services
Government
Healthcare
Manufacturing
Media & Publishing
Software & Technology
Telecom

EVENTS

CES
DockerCon
Google NEXT
Jenkins
re:Invent


 

Get The Doppler

Join 5,000+ IT professionals who get The Doppler for cloud computing news and best practices every week.

Subscribe here


Services

Cloud Adoption
Application Migration
Digital Innovation
Compliance
Cost Control
DevOps
IoT

Company

Overview
Leadership
Why CTP?
News
Events
Careers
Contact Us

The Doppler

Top Posts
White Papers
Podcasts
Videos
Case Studies
Quarterly
Subscribe

Connect

LinkedIn
Twitter
Google +
Facebook
Sound Cloud

CTP is hiring.

Cloud Technology Partners, a Hewlett Packard Enterprise company, is the premier cloud services and software company for enterprises moving to AWS, Google, Microsoft and other leading cloud platforms. We are hiring in sales, engineering, delivery and more. Visit our careers page to learn more.

CWC-blue-01

© 2010 - 2019 Cloud Technology Partners, Inc., a Hewlett Packard Enterprise company. All rights reserved. Here is our privacy policy CTP, CloudTP and Cloud with Confidence are registered trademarks of Cloud Technology Partners, Inc., or its subsidiaries in the United States and elsewhere.

Do Not Sell My Personal Information

  • Home
  • Cloud Adoption
  • Digital Innovation
  • Managed Cloud Controls
  • The Doppler Report
  • Clients
  • Partners
  • About CTP
  • Careers
  • Contact Us
  • Most Recent Posts
  • All Topics
  • Podcasts
  • Case Studies
  • Videos
  • Contact
Our privacy statement has been changed to provide you with additional information on how we use personal data and ensure compliance with new privacy and data protection laws.  
Please take time to read our new Privacy Statement.
Continue