When Lift & Shift Isn’t the Best Solution: Lessons Learned from Platform Migrations

When it comes to platform migrations, there’s a common trap: replicating everything from the source system exactly as it was, without exploring how to fully leverage the destination’s capabilities. I get it—it’s tempting to stick with what’s familiar because it feels safer and faster. But is it really the best approach?

Recently, I encountered a scenario that reminded me why it often isn’t. A team was migrating from SAP HANA to Snowflake. In HANA, Calculation Views allow you to enforce mandatory filters, requiring users to narrow down data before querying. It’s a logical feature, especially for an in-memory database like HANA, where controlling what gets loaded into memory is critical for performance.

The challenge came when the team tried to replicate this functionality in Snowflake by creating UDFs (User-Defined Functions) and UDTFs (User-Defined Table Functions) to enforce the same behavior. Technically, it worked, but the approach introduced unnecessary complexity. More importantly, it missed the point of Snowflake’s design. Snowflake is built to efficiently handle large-scale queries without the need for rigid filtering mechanisms. Well-designed views or materialized views would have achieved the same outcome more effectively, with lower cost and better alignment to Snowflake's architecture.

This reminded me of a similar situation I faced a few years ago, migrating from SQL Server to Snowflake. The client’s mindset was to treat Snowflake like a cloud-based SQL Server. They attempted to carry over everything—from indexes that weren’t applicable to stored procedures that weren’t needed—overlooking the strengths of Snowflake as a platform designed for massive data analysis, not transactional operations.

Here’s the takeaway: “Lift & Shift” isn’t always the best solution. Migrating to a new platform isn’t just about moving data; it’s about understanding the strengths of the destination system and redesigning when necessary. Every platform has its unique advantages, and part of our job as data and solution architects is to identify how to best use them.

Lessons I’ve Learned (and You Should Too):

1. Understand the destination’s architecture: Snowflake isn’t HANA, SQL Server, or Oracle. Leverage its elasticity, scalability, and distributed processing instead of forcing legacy behaviors.
2. Redesign with purpose: Migration isn’t just copying what works—it’s about optimizing for the new system. Don’t shy away from rethinking designs if it means better performance or cost efficiency.
3. Avoid unnecessary complexity: Objects like UDFs and UDTFs have their place, but don’t overcomplicate if a well-crafted view can achieve the same result.
4. Shift your mindset: Don’t treat the new platform as a replica of the old one. Each technology has unique strengths, and understanding them is key to unlocking their full potential.

Migrating isn’t just a technical challenge—it’s an opportunity to learn, adapt, and evolve. These experiences have taught me that every platform migration is a chance to rethink, optimize, and grow.

Have you faced something similar? I’d love to hear your thoughts. Did “Lift & Shift” create more challenges than it solved in your migration? Let’s share experiences.