In the world of IT infrastructure, "retiring in place" refers to the phasing out of older, less efficient technologies and techniques as organizations move to more modern approaches. This concept has become increasingly relevant in the context of cloud migration, as many small to medium-sized businesses (SMBs) and mid-market companies look to move their applications and data from on-premises servers to cloud-based environments like Microsoft Azure. In this article, we'll explore some of the key migration techniques that are being retired or phased out in favor of newer, cloud-native approaches.

Retiring On-Premises Migration Techniques

The Drawbacks of Manual Server Migration

One of the most basic approaches to cloud migration is manual server migration, which involves manually configuring and moving each on-premises server to a cloud environment. While this approach can work for very small-scale migrations, it quickly becomes impractical for larger projects. Manual migrations are extremely time-consuming, often requiring weeks or even months of IT staff time.

For example, consider a mid-market company with 50 Microsoft SQL Servers. If each server takes an average of 20 hours to manually configure and migrate to Azure SQL Database, the total staff time required would be 1,000 hours, or about 6 months of full-time work for one employee. This assumes no errors or complications, which is unrealistic. Manual migrations are also highly error-prone, as administrators must meticulously recreate server configurations in the cloud. A single mistake can lead to application downtime or data loss.

You may also like: Azure Migration Techniques: What is Retaining

```sql 

-- Manual SQL Server migration 

-- Step 1: Backup the on-premises database 

BACKUP DATABASE [MyDatabase]  

TO DISK = 'C:\Backups\MyDatabase.bak'; 

 

-- Step 2: Copy the backup file to Azure Blob Storage 

-- Step 3: Restore the database on Azure SQL Database 

RESTORE DATABASE [MyDatabase]  

FROM URL = 'https://myblobstorage.blob.core.windows.net/backups/MyDatabase.bak' 

``` 

Due to these significant drawbacks, manual server migration is rapidly being phased out in favor of more automated, reliable approaches.

The Risks of Physical Server Shipping

In the early days of cloud computing, some organizations attempted to migrate to the cloud by physically shipping their on-premises servers to a cloud provider's data center. The servers would then be racked and connected by the provider. However, this approach had numerous drawbacks. Shipping servers was costly and risky, with hardware often being damaged in transit.

An SMB manufacturing company attempted this approach to migrate their 10 on-premises servers to Azure. Despite careful packaging, 2 of the servers were damaged in transit, causing significant project delays and additional costs. The company estimated that the physical shipping process added nearly $15,000 to the total cost of their migration.

The process was also slow, with extensive downtime during the shipping and setup process. There were additional security concerns about sending physical servers containing sensitive business data offsite. With the maturation of cloud migration tools and processes, physical server shipping has become largely obsolete. Today, SMBs can use secure, high-speed network connections to migrate data to Azure without the risks and costs of physical shipping.

Retiring Lift-and-Shift Cloud Migration

Why Lift-and-Shift Falls Short

Lift-and-shift, also known as rehosting, is a cloud migration approach that involves moving an application to the cloud with minimal changes to its architecture or codebase. Essentially, the application is "lifted" from on-premises and "shifted" to a cloud environment. While lift-and-shift can seem like an attractive option due to its perceived simplicity, it often fails to deliver the full benefits of the cloud.

Lifted-and-shifted applications are not optimized for cloud scalability, elasticity, or resilience. They often carry forward inefficiencies from their on-premises roots and can't take advantage of cloud-native services and architectures.

For instance, a mid-market retailer that lift-and-shifts their monolithic ASP.NET web application to Azure App Service may find that it cannot automatically scale to meet demand spikes during sales events, or that they are paying for idle compute resources during low-traffic periods. The application may also not be architected to leverage Azure services like Azure Cache for Redis, Azure Cosmos DB, or Azure Functions, which could improve its performance and reduce operational overhead.

```csharp 

// Lift-and-shift migration of an ASP.NET application 

// Step 1: Provision an Azure App Service plan 

// Step 2: Create an Azure Web App 

// Step 3: Deploy the application to the Azure Web App 

// Step 4: Update connection strings to point to Azure SQL Database 

string connectionString = "Server=tcp:myazureserver.database.windows.net,1433;Database=MyDatabase;User ID=myuser;Password=mypassword;"; 

``` 

As a result, many SMBs and mid-market companies are retiring pure lift-and-shift in favor of migration strategies that involve some degree of refactoring for the cloud.

The Move Toward Cloud-Native Architectures

Containers: A Key Enabler for Cloud-Native

As organizations migrate to the cloud, there is a growing recognition that the greatest benefits come from adopting cloud-native application architectures. One key enabler of cloud-native is containerization, which involves packaging an application with all its dependencies in a standardized unit for deployment. Containerized applications are highly portable and can be efficiently deployed and scaled in the cloud.

You may also like: 7 Common Cloud Migration Pitfalls to Avoid

Tools like Docker and Azure Kubernetes Service (AKS) have made containerization mainstream and accessible to SMBs. A mid-sized financial services company used Docker and AKS to containerize and migrate their 15 .NET microservices to Azure. By leveraging these technologies, they were able to significantly reduce their time-to-market for new features and improve the scalability and resilience of their applications.

```dockerfile 

# Dockerfile for a .NET application 

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build 

WORKDIR /src 

COPY ["MyApp.csproj", "./"] 

RUN dotnet restore "MyApp.csproj" 

COPY . . 

RUN dotnet publish "MyApp.csproj" -c Release -o /app/publish 

 

FROM mcr.microsoft.com/dotnet/aspnet:6.0 

WORKDIR /app 

COPY --from=build /app/publish . 

ENTRYPOINT ["dotnet", "MyApp.dll"] 

``` 

Serverless: The Next Stage of Cloud Migration

Serverless computing is another cloud-native approach that is gaining traction as organizations retire older migration techniques. In a serverless model, the cloud provider dynamically manages the allocation and provisioning of servers. Developers simply package their code in functions, which are executed in response to triggers or events.

This model removes the burden of server management and enables true pay-per-use pricing, as resources are only consumed when a function is running. A small software development company migrated their image processing service to a serverless architecture using Azure Functions. By refactoring the service into a set of functions triggered by Azure Blob Storage events, they were able to significantly reduce operational costs while improving scalability and agility.

```csharp 

// Azure Function for processing uploaded images 

[FunctionName("ResizeImage")] 

public static async Task<IActionResult> Run( 

    [BlobTrigger("images/{name}", Connection = "AzureWebJobsStorage")] Stream imageBlob, string name, 

    [Blob("thumbnails/{name}", FileAccess.Write, Connection = "AzureWebJobsStorage")] Stream thumbnailBlob) 

{ 

    await imageBlob.CopyToAsync(thumbnailBlob); 

    return new OkResult(); 

} 

``` 

The growing adoption of containers and serverless represents a significant shift away from the retired migration techniques covered earlier. Rather than simply rehosting applications in the cloud, SMBs and mid-market companies are refactoring and rearchitecting them to be truly cloud-native. This approach enables them to fully exploit the scalability, flexibility, and cost-efficiency of Azure.

Optimizing Cloud Migrations with Redgate Software

While the move to cloud-native architectures is promising, the migration process itself can still be complex and challenging, especially for SMBs with limited IT resources. This is where tools from Redgate Software can help. Redgate provides a suite of tools specifically designed to simplify and optimize migrations to Microsoft Azure.

For example, Redgate's SQL Data Compare tool can automatically compare and synchronize SQL Server databases between on-premises and Azure environments. This can significantly reduce the time and effort required for data migration.

```powershell 

# Using Redgate SQL Data Compare to synchronize data 

$dataSyncParams = @{ 

    SourceServerInstance = "MyOnPremServer" 

    SourceDatabase = "MyDatabase" 

    TargetServerInstance = "tcp:myazureserver.database.windows.net,1433" 

    TargetDatabase = "MyDatabase" 

    TargetUser = "myuser" 

    TargetPassword = "mypassword" 

    TransactionIsolationLevel = "Serializable" 

    Validation = "Full" 

} 

Sync-RedgateSqlData @dataSyncParams 

``` 

Similarly, Redgate's SQL Provision tool can automate the provisioning of SQL Server databases in Azure, ensuring consistency and reducing manual effort.

By leveraging tools like these, SMBs and mid-market companies can streamline their migrations to Azure and start realizing the benefits of cloud-native architectures more quickly.

Conclusion

In the cloud migration landscape, we are seeing a clear trend away from older, less efficient migration techniques toward modern, cloud-native approaches. On-premises techniques like manual server migration and physical server shipping are being rapidly phased out due to their time-consuming, error-prone, and costly nature. Pure lift-and-shift migrations are also being retired as organizations recognize that they do not deliver the full benefits of the cloud.

In their place, we are seeing a growing adoption of cloud-native architectures enabled by containerization and serverless computing. These approaches allow SMBs and mid-market companies to refactor and rebuild their applications to be truly optimized for Azure, delivering maximum scalability, resilience, and agility. Industry trends and forecasts clearly indicate that these are the migration techniques of the future.

Frequently Asked Questions

What are the 7 common migration strategies?

The 7 common migration strategies are rehosting, replatforming, repurchasing, refactoring, retiring, retaining, and relocating.

What is the difference between Rehosting and refactoring?

Rehosting involves moving applications to the cloud with minimal changes, while refactoring involves modifying the application architecture to take full advantage of cloud-native features and services.

What is refactoring in cloud migration?

Refactoring in cloud migration is the process of restructuring an existing application to optimize it for the cloud environment without changing its external behavior.

What are the five migration steps?

The five migration steps are assessment, planning, design, migration, and optimization.