A Practical Cloud Migration Checklist: Lift-and-Shift vs Re-Platforming

Moving applications to the cloud is rarely a single event. It is a programme of work that touches infrastructure, security, budgets and the day-to-day experience of the people who rely on those systems. Two approaches dominate most small and mid-sized migrations: lift-and-shift, where servers are moved largely as they are, and re-platforming, where applications are adjusted to take advantage of managed cloud services. This article explains the trade-offs between the two and provides a practical checklist you can adapt for your own project.

Understanding the two approaches

Lift-and-shift (rehosting)

Lift-and-shift means taking existing virtual or physical servers and recreating them as virtual machines in the cloud with minimal change. The operating system, application and configuration remain broadly the same. Migration tools from the major providers can replicate disks continuously and allow a relatively short cut-over window.

Advantages: fast to execute, low application risk, little need for developer involvement, and a good way to exit a data centre or replace ageing hardware on a deadline.

Disadvantages: you carry over existing inefficiencies, you still patch and manage operating systems, and virtual machines that are sized like old physical servers are often more expensive than necessary in the cloud.

Re-platforming (lift, tinker and shift)

Re-platforming makes targeted changes during the move without rewriting the application. Typical examples include moving a self-managed database to a managed database service, replacing a file server with cloud file storage, or running a web application on a managed app hosting platform instead of a self-built virtual machine.

Advantages: reduced operational overhead, built-in high availability and backup on many managed services, and better cost alignment with actual usage.

Disadvantages: more testing is required, some application changes may be needed, and the team must learn the managed services involved.

How to choose for each workload

You do not have to choose one approach for your entire estate. Most successful migrations apply different strategies to different workloads. Consider these questions for each application:

• Is there a hard deadline? If a hardware lease or data centre contract ends soon, lift-and-shift reduces schedule risk. You can modernise later.
• Is the database a standard engine? Common engines such as SQL Server, PostgreSQL and MySQL usually have managed equivalents, making re-platforming straightforward.
• Is the application supported by its vendor in the cloud? Some commercial software has specific support conditions. Check before changing the underlying platform.
• How much operational effort does it consume today? Workloads that generate frequent patching, backup or capacity issues benefit most from managed services.
• Is the application due for replacement? If it will be retired or replaced by a software-as-a-service product within a year or two, the simplest move is usually best, or it may not need migrating at all.

Phase one: discovery and assessment checklist

1. Create a complete inventory of servers, applications, databases, file shares and scheduled tasks.
2. Record resource usage over a representative period, including peak times such as month-end processing.
3. Map dependencies between systems: which applications call which databases, APIs and file locations.
4. Identify hard-coded IP addresses, host names and certificates that may break after migration.
5. Note licensing terms for operating systems, databases and third-party software.
6. Classify data by sensitivity and record any residency or retention requirements.
7. Assign an owner to each application who can approve testing and cut-over.
8. Choose a strategy for each workload: retire, retain, rehost, re-platform, or replace.

Phase two: foundation and landing zone checklist

Before migrating any workload, build the foundations that everything else will rely on. Skipping this step is one of the most common causes of security and cost problems later.

• Set up the account, subscription or project structure, separating production from non-production.
• Integrate identity with your existing directory and enforce multi-factor authentication for all administrators.
• Design the network: address ranges that do not overlap with on-premises networks, VPN or private connectivity, and firewall rules.
• Enable central logging and retain audit logs in a location that ordinary administrators cannot delete.
• Define tagging standards for owner, environment, application and cost centre.
• Configure budgets and cost alerts.
• Agree a backup policy and test that it applies automatically to new resources.
• Document a naming convention and use infrastructure as code where practical.

Phase three: migration and testing checklist

1. Start with a low-risk pilot. Choose an application that is useful but not business-critical, so the team learns the process safely.
2. Right-size as you go. Use the utilisation data from discovery rather than copying the specifications of old hardware.
3. Replicate data early. For larger datasets, begin replication well in advance so the final synchronisation is small.
4. Test functionality and performance. Have the application owner run agreed test scripts covering normal use, reports and integrations.
5. Test failure scenarios. Confirm that backups restore correctly and that monitoring raises alerts as expected.
6. Prepare a rollback plan. Define the point at which you would abandon the cut-over and how you would return to the original system.
7. Communicate the cut-over window. Tell users what to expect, when, and who to contact if something looks wrong.
8. Update DNS and integrations. Lower DNS time-to-live values in advance so changes take effect quickly.

Phase four: post-migration checklist

A migration is not finished when the application is running in the cloud. The weeks after cut-over are when you capture most of the value.

• Monitor performance and user feedback closely for the first few weeks.
• Review utilisation and resize or schedule resources that are over-provisioned or idle out of hours.
• Decommission the original servers once you are confident, and remove any temporary network rules.
• Consider commitment-based discounts once usage has stabilised.
• Update documentation, runbooks and disaster recovery plans to reflect the new environment.
• Revisit lift-and-shift workloads and plan re-platforming where it now makes sense.

Comparing the approaches at a glance

When summarising the decision for stakeholders, it helps to frame the two approaches in simple terms. Lift-and-shift optimises for speed and low change; re-platforming optimises for long-term efficiency and reduced management. Lift-and-shift typically demands more ongoing infrastructure administration but less up-front testing. Re-platforming typically demands more up-front engineering and testing but can lower day-to-day effort once complete. Neither is inherently superior, and a phased plan that rehosts first and re-platforms later is a perfectly respectable outcome.

Conclusion

The success of a cloud migration depends less on the approach you choose than on the discipline with which you plan and execute it. Thorough discovery, a well-built landing zone, realistic testing and a deliberate post-migration review will prevent the majority of problems. Use lift-and-shift where time is short or applications are fragile, and re-platform where managed services can genuinely remove operational burden. Treat the checklists above as a starting point, adapt them to your environment, and make sure every application has an owner who signs off each stage.