Lessons from real-world Azure migrations on how to move beyond lift-and-shift and unlock more value

Cloud migration projects often have very tight timelines, budget constraints, and the need to show some level of results quickly. When you encounter these pressures, it’s easy to see why many organisations opt for the simplest approach: lift and shift… 

At first, this strategy seems logical. Moving existing workloads to the cloud with minimal changes cuts down on complexity and speeds up delivery and gives confidence that systems will continue to operate as expected. The issue is that while lift and shift can simplify migration in the short run, it often brings existing problems into the new environment and limits a huge amount of the cloud-native benefits you get from adopting the cloud. 

However, lift and shift isn’t always the wrong choice. In some cases, it can be a useful first step, or you may be limited to ageing application types or architectures that are still required for a business to operate. Still, relying on it as the default approach can result in higher costs, more operational overhead, and missed chances to modernise or transform. 

Here are three common situations where organisations can benefit from challenging their assumptions before migrating. 

When planning a migration, it’s important to work backwards from the business goals and make sure those outcomes remain central throughout. The migration itself should not become the objective – it should be the means of delivering the right business value. 

Traditional file servers are probably the most commonly migrated workloads to the cloud. Most organisations have grown up with typical mapped drives and some form of DFS namespace. The easiest option is typically to just set up a virtual machine, copy the data (manually or with tooling like robocopy), and keep running as before. 

This style of migration is very straightforward, and users notice little to no change, which making the project seem like a success. 

However, the organisation still has to manage the virtual machine, apply patches, maintain backups, monitor performance, and plan for future storage capacity needs. In many cases, a cloud-hosted file server ends up resembling the on-premises server it replaced. 

However, before making the decision to take that route, think about whether other cloud-native options such as Azure Files or Managed File Solutions might offer a more successful end result.  

For example, I have seen finance shares that have been around for years, still accessed through familiar DFS paths such as \\company.local\shares\finance. 

In that situation, the obvious option is often to move the data onto a file server VM in Azure and keep things running as they are. It works, but it also means you have effectively carried the same operational overhead into the cloud. 

A better approach can be to move the share fully into Azure Files, giving users the same mapped drive experience without having to manage and patch another file server. Where a site still needs local performance, Azure File Sync gives you a more gradual path. The local server can remain in place as a cache, while cloud tiering keeps less-used files in Azure and only the active data on-site. 

DFS Namespaces can still sit in front of this, so users do not need to learn new paths or change how they work. It gives IT a cleaner way forward, either moving fully to Azure Files where it makes sense or keeping a hybrid model for locations and workloads that still need it. 

The aim shouldn’t just be to move data. It should be to determine whether the current architecture is still the best fit for the future. 

Database migrations often follow a similar trend…

Organisations tend to go with a cloud virtual machine running SQL Server because it feels comfortable and requires minimal change to existing processes. There is little disruption to how teams operate, and they retain full control over the environment.

Although this reduces perceived risk, it also keeps the company responsible for all of the necessary tasks including updating, backing up, ensuring availability, performance management, and ongoing maintenance.

There is a wide range of managed database services available across cloud platforms, which can help reduce this burden. By delegating routine tasks, teams can spend more time delivering applications rather than maintaining infrastructure.

For example, I have seen SQL Server databases moved into Azure by placing them on a virtual machine. It is familiar, low disruption, and sometimes the right choice where legacy dependencies or full control are still required.

The issue is that the operating model barely changes. The database is now in Azure, but the team still owns patching, backups, availability, performance, monitoring, and capacity planning.

Before taking that route, it is worth considering whether a managed option would be a better fit. Azure SQL Managed Instance can provide a more familiar SQL Server experience with less operational overhead, while Azure SQL Database, Azure Database for PostgreSQL, or Cosmos DB may suit more modern or cloud-native applications.

The aim is not to force every database into a managed service, but to avoid rebuilding the same database server in a different datacentre without questioning whether there is a better option.

There are other factors influencing this decision – licensing terms, dependency of applications on the current architecture and others. What really matters here is that alternative solutions are actively considered.

A migration project is always a great opportunity to rethink existing approaches. Organisations should take advantage of this opportunity to make their environment easier to manage and more resilient.

There are many areas where organisations miss opportunities during migration.

One of those areas is security, where outdated access mechanisms, permissions, and other processes are simply replicated in cloud-based services. This includes legacy user groups, old permission sets, and wide administrative access being carried forward unchanged.

However, it’s easy to carry over all kinds of technical debt accumulated over years.

When considering migration to cloud, this is the perfect opportunity to eliminate that technical debt and start afresh. Think of it this way: would you rather paint a white wall with green paint or try to paint green over a red wall?

It’s important to reassess who needs access to resources, apply RBAC (role-based access control) techniques, remove unnecessary permissions, and adopt a least-privilege approach.

Instead of asking, “How do we replicate our existing security policies and settings in the cloud?”, a better question is: “How should we be building our security architecture, whilst still meeting existing compliance or governance requirements?”.

Taking the time to plan cloud-based security architecture will help improve governance, mitigate risks, and make future scaling much easier.

A common misconception with cloud migrations is that success is defined by how quickly workloads are moved.

In reality, a successful migration should focus on achieving better business results – whether that’s lowering operational costs, improving resilience, enhancing security, or creating a foundation for future innovation.

Lift and shift does have its place, and in some situations speed or simplicity might be the right priority. However, it can pose a risk if it becomes the default solution for every workload.

Before migrating, take a moment to ask a simple question:

“If I we were building this today, would we really design it the same way?”

If the answer is no, migration is the perfect opportunity to make a better choice.

The fastest route to the cloud isn’t always the most effective or even cost-effective for that matter. Sometimes, investing extra time to question assumptions can lead to much greater value in the long run.

If you’re planning a cloud migration and want to explore the best approach, get in touch with our team to see where you could unlock more value.