Every cloud migration conversation eventually arrives at the same fork in the road: do you move what you have, or do you rebuild it? The short answer is that both strategies are valid — and most organisations end up using both at different points in their cloud journey. The mistake is applying one strategy everywhere without understanding what each actually costs you in time, money, and complexity.
This guide walks through how each approach works, when it makes sense, and how to make the decision for your specific workloads. We will also cover the data residency requirements that matter specifically for businesses operating under German and EU law — because where your data lives is not just a technical question here.
What Lift & Shift Actually Means in Practice
Lift and shift — also called rehosting — means taking a virtual machine or server workload and moving it to the cloud with minimal changes. You are not rewriting the application. You are not changing how it stores data. You are not rethinking the architecture. You are essentially picking up the server and putting it in a different building, except the building is a Microsoft or AWS datacentre.
Azure Migrate is the primary tool for this in the Microsoft ecosystem. It discovers your on-premise servers, assesses their compatibility, and handles the replication of virtual machine disks to Azure. A migration that would have taken weeks of manual work is compressed into days.
The business case is speed and risk reduction. If your company is approaching a hardware refresh cycle and the existing servers are ageing, lift and shift lets you exit the physical infrastructure entirely without rewriting a single line of application code. For a German Mittelstand company running DATEV, a bespoke ERP, and various legacy Windows Server workloads, this is often the only realistic path in a 12-month window.
The Hidden Costs
Lift and shift is fast to start but often expensive to run. A virtual machine that was sized for peak load on a physical server runs 24 hours a day in the cloud and bills accordingly. An on-premise SQL Server that was purchased once now costs money every month. Many organisations that lift and shift without optimising find their cloud bill is higher than expected within the first six months, which creates pressure to rightsize and start the modernisation work anyway.
What Refactoring Means — and Why It Is Worth It
Refactoring means modifying your application to take advantage of cloud-native services. Instead of running a SQL Server virtual machine, you migrate to Azure SQL Database. Instead of hosting a file server VM, you move documents to SharePoint or Azure Blob Storage. Instead of a dedicated application server, you consider Azure App Service or containers.
The difference in running costs is significant. Azure SQL Database scales automatically, you only pay for the compute you use, and high availability is built in. A SQL Server VM running 24/7 to serve moderate traffic is almost always more expensive than a well-configured managed database service at equivalent performance.
The drawback is time and risk. Refactoring requires development work, thorough testing, and careful cutover planning. For a line-of-business application that is mission-critical and has limited internal documentation, this work can be substantial.
A Decision Framework: Which Workloads Go Where
Rather than choosing one strategy for everything, the practical approach is to categorise each workload. Here is a framework that works well in the DACH context:
| Workload Type |
Recommended Strategy |
Reason |
| Legacy ERP (DATEV, SAP Business One) |
Lift & Shift |
Vendor-managed, limited refactoring options |
| Internal file server |
Refactor to SharePoint/OneDrive |
Immediate cost savings, no VM required |
| Custom web application |
Refactor to Azure App Service |
Auto-scaling, managed runtime, lower TCO |
| SQL Server database |
Refactor to Azure SQL or keep VM short-term |
Depends on customisation level |
| Development/test environments |
Lift & Shift first, refactor later |
Low risk, good learning environment |
Data Residency: The DSGVO Factor
For businesses in Germany, Austria, and Switzerland, cloud migration is not purely a cost and performance decision. The question of where your data is physically stored matters under the DSGVO, the Swiss DSG, and the Austrian DSG. Customer personal data, employee records, and financial information all fall under strict requirements.
Microsoft Azure offers dedicated German datacentre regions — Germany West Central (Frankfurt) and Germany North (Berlin). Choosing these regions for workloads that process personal data ensures your data remains within the EU and is subject to EU data protection law without relying on transfer mechanisms like Standard Contractual Clauses.
The BSI (Bundesamt für Sicherheit in der Informationstechnik) has published cloud computing guidance under C5 (Cloud Computing Compliance Criteria Catalogue). Microsoft Azure holds a C5 attestation, which means independent auditors have verified that Azure's security controls meet BSI standards. This attestation is increasingly relevant when negotiating cyber insurance or when customers in regulated industries ask about your cloud security posture.
One practical note: data residency is not the same as data sovereignty. Residency means the data is stored in Germany. Sovereignty means no entity outside Germany can compel access to it. Microsoft's EU Data Boundary commitment addresses the former but not the latter in all circumstances. Organisations handling particularly sensitive data — legal firms, healthcare, financial services — should evaluate this distinction carefully before migration.
The Migration Timeline: What to Expect
A realistic migration for a 20–50 person company typically runs across four phases:
- Discovery and Assessment (2–3 weeks): Inventory every server, application, and dependency. Azure Migrate generates a readiness report and a cost estimate. This phase often uncovers forgotten servers and applications that nobody has touched in years.
- Proof of Concept (1–2 weeks): Migrate one low-criticality workload — usually a development server or internal tool — to validate connectivity, security, and performance. Resolve any issues in a low-stakes environment.
- Wave Migration (4–12 weeks depending on complexity): Migrate workloads in batches grouped by dependency. Email and collaboration tools go first if they are on-premise. Line-of-business applications follow. Data migration runs in parallel where possible.
- Optimisation (Ongoing): Rightsize VMs, implement Azure Cost Management alerts, decommission on-premise hardware. Most cloud cost savings are not realised at migration but in the months afterwards.
How IDE Solutions Can Help
We have run migrations for companies ranging from 10-person professional services firms to 200-person manufacturers. The starting point is always a Cloud Readiness Assessment — a structured review of your current infrastructure that produces a prioritised migration plan, a realistic cost model, and a clear recommendation on which workloads to lift and shift versus refactor.
We work with Azure exclusively for the DACH market, which means we configure your environment specifically for German datacentre regions, BSI C5 alignment, and DSGVO compliance documentation from the start.
Further reading: Azure Migration Documentation