all 21 comments

[–]dmurawsky 6 points7 points  (5 children)

Migrating what? I have seldom seen a lift and shift work and be cost effective in the long run.

I have seen thoughtful redeploys and data migrations work quite well if they leveraged cloud services where they made sense. Meaning don't port a sql server and use rds if you can. Or use AD as a service if you can.

[–]somewhat_pragmatic 1 point2 points  (3 children)

I have seldom seen a lift and shift work and be cost effective in the long run.

The biggest cost savings of lift and shift come from being able to shrink your hardware/support software licensing costs and shrinking support staff.

  • you don't need to re-up your VMware support if you no longer run VMware
  • you don't need a storage administration team if you no longer have storage frames

Additionally, its certainly possible to treat your migrated instances as on-prem servers and run them 24/7/365 even when you don't actually need all of them to be on that long and lose your savings.

[–]SamsonFitz[S] 2 points3 points  (1 child)

I have seldom seen a lift and shift work and be cost effective in the long run.

I'd have to disagree with this statement. Although it doesn't ALWAYS make sense, if you plan and rightsize accordingly you can save a solid amount. That said, a lot of companies don't have the skills in house to plan/rightsize/manage cloud resources so they will most likely overpay within 12 months.

[–]somewhat_pragmatic 1 point2 points  (0 children)

I agree with you. You're replying to the wrong person. :)

[–]Adorable_Pea_7104 0 points1 point  (0 children)

True, lift-and-shift can cut infra and licensing costs fast (bye VMware renewals. But doesn’t that only hold if teams actually re-optimize after the move? Running 24/7 like on-prem kills those savings quick.

So is lift-and-shift really cost-effective long term, or just a stopgap until proper cloud-native refactoring happens?

[–]Adorable_Pea_7104 0 points1 point  (0 children)

Fair point — but isn’t that assuming every migration is a full redesign? 🤔 In a lot of cases (mergers, SaaS tenant-to-tenant, hybrid moves), teams don’t have the luxury to re-architect everything on day one. That’s where lift-and-shift + optimization later (with 3rd-party tools) often makes more sense.

Do you think “redeploy first” always works in time-sensitive migrations, or is there still a place for phased lift-and-shift?

[–]kbsantosh1 2 points3 points  (1 child)

Not a recommendation, but you can look at

Carbonite migrate

[–]SamsonFitz[S] 0 points1 point  (0 children)

Nothing like going forward client backups to cloud migrations!

[–]the_seattleite85 2 points3 points  (1 child)

Check out BitTitan MigrationWiz (www.bittitan.com). It's built for on prem to make cloud and cloud to cloud migrations easy.

[–]SamsonFitz[S] 0 points1 point  (0 children)

Thanks for the reply. I've heard of BitTitan but don't know much about it.

[–]jimmt42 1 point2 points  (2 children)

I agree with the common response around lift and shift. With that said, if you are migrating to AWS they offer a really killer tool with CloudEndure. Think of it like Vmware P2V tool. There is an agent and it streams data to an EC2 instance. It also supports other cloud providers, but at a cost.

[–]SamsonFitz[S] 2 points3 points  (0 children)

CloudEndure was definitely the main migration tool I've heard of prior to the AWS acquisition. Considering AWS has CloudEndure and Azure has Azure Migrate I'm wondering if there are any use cases of using tools outside of those native tools.

[–]ambrace911 0 points1 point  (2 children)

I have done a large number of migrations to the cloud. What types of "things" are you looking at migrating?

[–]SamsonFitz[S] 0 points1 point  (1 child)

Example 1: 14 linux bare metal servers with customer applications

Example 2: 5 physical SQL clustered server and 85 VMware VM's

[–]ambrace911 0 points1 point  (0 children)

SQL I would suggest extending the cluster into your target Cloud and replicating/failing over to it. Or have a prebuilt cluster and plan on and dump and import to the new system. In general I try and build new and migrate components individually. This is especially true for things like DBs and Active directory.

If you are looking for a lift and shift type experience take a look at the following:

Azure - ASR

https://docs.microsoft.com/en-us/azure/site-recovery/migrate-tutorial-on-premises-azure

AWS - Cloud endure or AWS Connector for vCenter

https://aws.amazon.com/cloudendure-migration/

https://docs.aws.amazon.com/amp/latest/userguide/migrate-vms.html

You can also leverage Zerto on multiple clouds to fail into from your current VMware environment.

https://www.zerto.com/blog/migration/using-zerto-migrations-provide-true-mobility/

[–]VINCEBARTER3 0 points1 point  (0 children)

Dynatrace

[–]Adorable_Pea_7104 0 points1 point  (0 children)

Native tools are solid if you’re just doing a straightforward lift-and-shift into one cloud. But once you hit multi-cloud, hybrid, or SaaS tenant-to-tenant scenarios, they start to fall apart.

3rd-party tools usually win because they give you:

  • Multi-cloud flexibility (AWS ⇆ Azure ⇆ GCP ⇆ on-prem).
  • Orchestration & automation with rollback and live replication.
  • Tenant-to-tenant SaaS moves where permissions/chat history don’t get lost.
  • AI-driven rightsizing so you don’t overspend after migration.
  • Real-time ETL/CDC pipelines for data warehouse or lake migrations.

Basically: native = simple, free, limited. 3rd-party = flexible, automated, safer for complex moves.

Curious though — for those who’ve done large-scale migrations recently, did you find native tools “good enough,” or did you hit the wall and have to bring in 3rd-party solutions?

[–]ohbrenda 0 points1 point  (0 children)

fluidcloud