4 ms·

There is no such thing as "lift and shift". It is something Azure account reps like to say to make it sound like moving is easy. It sounds like you're picking u

by mdeeks 3y ago

There is no such thing as "lift and shift". It is something Azure account reps like to say to make it sound like moving is easy. It sounds like you're picking up some boxes from one side of the room and moving them to the other. When in reality you're rewriting your infra code mostly from scratch. When we were acquired by MSFT we had the same project. We had to move from AWS to Azure. I made them all stop saying "lift and shift" because in reality it is "throw away all of your provisioning code and rewrite it using Azure primitives which don't work the same way as AWS ones". It is more akin to writing an iOS app to work on Android.

axus 3y ago
I'm gonna bet that many Azure customers had no such thing as "provisioning code".
_cenw 3y ago
To be fair, AWS also used the exact term when we moved a project out of a tiny expensive to operate (though lack of scale) datacenter that only hadn't been retired because we had a 30+ year old COBOL app suite on a z system.
arielcostas 3y ago
But lift and shift is not that, is it? It's having applications running directly on OSs (without containerisation or separation of dependencies like the database or physical disks) and moving it to "the cloud" to be ran on a VM in the same fashion. I mean, if you're already with AWS using their services (besides EC2 for hosting) such as RDS or S3; moving to Azure SQL (or DB for MySQL or whatever) and Blob Storage is not just lift-and-shift anymore, since you are actually changing from a cloud provider to a different one. AFAIK an actual migration to the cloud would involve rewriting some parts of the application to be cloud-native, such as using Service Bus for queues instead of a local Redis/RabbitMQ instance, using GCS instead of local disks, and using RDS instead of hosting your own single MySQL server.
- oasisbob 3y ago
  There's no formal definition of "lift and shift", certainly nothing that would dictate specific virtualization strategies. I've always read it as being roughly analogous to "like for like," and dependent on the specific circumstances and status quo.
oasisbob 3y ago
"Lift and shift" isn't just an Azure-specific phrase. Many people use it pejoratively, and point to it as an anti-pattern, and something to avoid. Similar terminology is "forklift"... been hearing that one for well over a decade. Migrations are oftentimes an opportunity to revisit scaling, configuration, build and deployment pipelines, platform primitives, etc. Every migration I've been involved in has a (probably necessary) tension between getting the job done efficiently, while not repeating all the mistakes of the past.
- hinkley 3y ago
  “Lift and shift” came into the conversation once we started talking about how we were paying too much for AWS. The obvious stuff was things like less bin packing, and bandwidth for third party services, like telemetry dashboards. And it’s not just the service fees. I blanche to think of the opportunity costs we accrued by focusing for that long on infrastructure to the exclusion of new product and features. It’s truly breathtaking. And then there’s the burnout, and the ruffled feathers.
  - oasisbob 3y ago
    I've become convinced that most migrations are absolute losers in terms of opportunity costs. Even if done skillfully with valid rationale, they don't show any value until you come out the other side successfully.
    - hinkley 3y ago
      Definitely. We migrated to a new telemetry vendor and I'm pretty sure it'll take 10 years for us to recoup the cost savings in man power and opportunity cost. They were worried the old vendor might go under. My own track record with predicting company failures is pretty bad, so I suspect they'll still be around ten years from now.
icedchai 3y ago
The IaC has to be rewritten, but often the application itself needs major modifications due to pervasive use of proprietary managed services. Vendor lock in is a major problem. It's almost never simple unless an app is entirely running on a standalone VM. And if it is, you're probably wasting money running it in the cloud anyway...

by mdeeks 3y ago

axus 3y ago

I'm gonna bet that many Azure customers had no such thing as "provisioning code".

_cenw 3y ago

To be fair, AWS also used the exact term when we moved a project out of a tiny expensive to operate (though lack of scale) datacenter that only hadn't been retired because we had a 30+ year old COBOL app suite on a z system.

arielcostas 3y ago

But lift and shift is not that, is it? It's having applications running directly on OSs (without containerisation or separation of dependencies like the database or physical disks) and moving it to "the cloud" to be ran on a VM in the same fashion. I mean, if you're already with AWS using their services (besides EC2 for hosting) such as RDS or S3; moving to Azure SQL (or DB for MySQL or whatever) and Blob Storage is not just lift-and-shift anymore, since you are actually changing from a cloud provider to a different one. AFAIK an actual migration to the cloud would involve rewriting some parts of the application to be cloud-native, such as using Service Bus for queues instead of a local Redis/RabbitMQ instance, using GCS instead of local disks, and using RDS instead of hosting your own single MySQL server.

oasisbob 3y ago
There's no formal definition of "lift and shift", certainly nothing that would dictate specific virtualization strategies. I've always read it as being roughly analogous to "like for like," and dependent on the specific circumstances and status quo.

oasisbob 3y ago

"Lift and shift" isn't just an Azure-specific phrase. Many people use it pejoratively, and point to it as an anti-pattern, and something to avoid. Similar terminology is "forklift"... been hearing that one for well over a decade. Migrations are oftentimes an opportunity to revisit scaling, configuration, build and deployment pipelines, platform primitives, etc. Every migration I've been involved in has a (probably necessary) tension between getting the job done efficiently, while not repeating all the mistakes of the past.

hinkley 3y ago
“Lift and shift” came into the conversation once we started talking about how we were paying too much for AWS. The obvious stuff was things like less bin packing, and bandwidth for third party services, like telemetry dashboards. And it’s not just the service fees. I blanche to think of the opportunity costs we accrued by focusing for that long on infrastructure to the exclusion of new product and features. It’s truly breathtaking. And then there’s the burnout, and the ruffled feathers.
- oasisbob 3y ago
  I've become convinced that most migrations are absolute losers in terms of opportunity costs. Even if done skillfully with valid rationale, they don't show any value until you come out the other side successfully.
  - hinkley 3y ago
    Definitely. We migrated to a new telemetry vendor and I'm pretty sure it'll take 10 years for us to recoup the cost savings in man power and opportunity cost. They were worried the old vendor might go under. My own track record with predicting company failures is pretty bad, so I suspect they'll still be around ten years from now.

icedchai 3y ago

The IaC has to be rewritten, but often the application itself needs major modifications due to pervasive use of proprietary managed services. Vendor lock in is a major problem. It's almost never simple unless an app is entirely running on a standalone VM. And if it is, you're probably wasting money running it in the cloud anyway...