What are the primary approaches to database migration, and how do you decide between lift-and-shift, re-platforming, and refactoring? What factors influence the decision for each approach?

Question

Accepted Answer

Database migration approaches range from simple moves to complete redesigns, and choosing the right approach depends on balancing business goals, technical requirements, timeline, and available resources. Understanding the spectrum of options helps ensure you invest the right level of effort for each migration.

Lift-and-shift, also called rehosting, moves the database to a new environment with minimal changes. You take the existing database and move it to new hardware, a different data center, or a cloud-hosted virtual machine running the same database engine. The schema, data, stored procedures, and configurations remain essentially identical. This is the fastest and lowest-risk approach. I recommend it when the primary goal is leaving an aging data center, when the database platform is remaining the same, or when the application is near end-of-life and does not warrant optimization investment. The limitation is that you do not gain any benefits from platform-specific features or managed services.

Re-platforming involves moving to a different but compatible platform with moderate modifications. An example is moving from a self-managed PostgreSQL instance to Amazon Aurora PostgreSQL or from on-premises SQL Server to Azure SQL Managed Instance. The core database engine is similar, but you adapt configurations, backup procedures, and high-availability mechanisms to use the managed service capabilities. This approach captures cloud benefits like automated backups, automatic failover, and elastic scaling with moderate effort. It is my default recommendation for production databases moving to the cloud.

Refactoring, or re-architecting, involves significant redesign of the database layer. This might mean migrating from Oracle to PostgreSQL with stored procedure rewrites, moving from a monolithic database to microservices with database-per-service, or replacing a relational database with a purpose-built alternative. Refactoring offers the greatest long-term benefits in cost, performance, and architectural fitness but carries the highest risk, longest timeline, and greatest resource requirements.

The decision factors I evaluate include the business timeline and urgency. If the data center lease expires in six months, lift-and-shift is the pragmatic choice. If this is a multi-year modernization initiative, refactoring can be planned. Technical debt in the current system matters because a database riddled with Oracle-specific PL/SQL packages is expensive to refactor, while a database using standard SQL is easier to re-platform. Cost analysis comparing the total cost of ownership for each approach over a three to five year horizon, including license savings from moving off commercial databases, helps justify the investment. Team capabilities determine what is feasible without excessive external hiring or consulting costs.

I often recommend a staged approach that combines methods. Start with lift-and-shift to move to cloud infrastructure quickly, then re-platform to managed services as the team gains cloud familiarity, and finally refactor specific components that would benefit most from architectural improvement. This approach delivers value incrementally while managing risk at each stage.