Cloud Migration Step by Step — Practical Guide for SMEs 2026

In 2026, a cloud migration is rarely a purely infrastructural exercise — it is a multi-year undertaking with immediate impact on costs, delivery capability, compliance and headcount. In the German SME market, two parallel movements are currently underway: companies that have hesitated so far are being pushed into a migration obligation by expiring hardware contracts, energy costs and a shortage of skilled IT staff. Companies that already have workloads in the cloud must modernize their first-generation architectures, because the lift-and-shift wave of 2019 to 2022 is now generating costs that are no longer sustainable. Both groups need a clear, methodical roadmap — not a consulting slide deck, but a plan that concretely addresses assessment, tooling, data migration, cutover and rollback. This guide summarizes how such a project can be delivered with realistic effort, which tools are available on AWS, Azure and GCP, what strategies the 6-Rs matrix provides, and what cost ranges you should expect. For the broader strategic context, see our Cloud & DevOps Guide for SMEs.

Why Migration in 2026 Looks Different — Fines, Liability, Costs

The cloud migration of 2026 differs fundamentally from the first wave six years ago. The driving factors are no longer innovation and scalability alone, but a combination of regulatory pressure, business necessity and talent scarcity. The EU Data Act, NIS2, DORA for financial services providers and German KRITIS regulation now require documented resilience, auditability and sovereign data storage — requirements that are achievable in classic on-premise data centers but expensive and labor-intensive. At the same time, electricity prices and hardware lead times have noticeably increased the TCO of in-house data centers.

Three observations from current projects in the German SME market shape the migration reality of 2026. First: pure lift-and-shift migrations are out of fashion — the cost trap of "on-premise with a cloud surcharge" is now well understood, and companies are demanding a replatform component from the outset. Second: sovereignty requirements are no longer a niche topic — even mid-sized customers are asking about EU regions, sovereign cloud offerings and encryption options with customer-managed keys. Third: the talent shortage is driving a shift toward more managed services — an SME that can no longer fill database administration roles switches to RDS, Azure SQL or Cloud SQL out of necessity.

These three drivers change the order of migration decisions. The question is less often "What do we migrate first?" and more frequently "Which workloads do we retain at which level of self-responsibility?" This makes the 6-Rs model and a thorough assessment more important than ever.

Assessment Phase: Application Discovery, Dependency Mapping, Compliance Check

Every cloud migration stands or falls with the assessment. In our projects we spend 15 to 25 percent of the total project time in this phase — and save many times that in rework later. A reliable assessment consists of three building blocks that should run in parallel:

• Application DiscoveryInventory of all running applications, their version levels, operating systems, databases, middleware and licensing models. Tools such as AWS Application Discovery Service, Azure Migrate Discovery or GCP Migration Center automatically collect technical metrics — CPU, RAM, IOPS, network — over 30 to 60 days. This data forms the basis for right-sizing and cost calculation.
• Dependency MappingCapturing the dependencies between applications, databases, interfaces and external services. Often the most important and most underestimated task — virtually no SME has a complete map of its integrations. Tools such as ServiceNow Discovery, Device42 or the mapping functions of Azure Migrate provide a baseline that must be supplemented by interviews with business units.
• Compliance CheckEvaluation of each application against legal and contractual requirements: GDPR data categories, sector-specific regulations (BAIT, VAIT, KRITIS), customer contract clauses on data localization, software licenses with cloud restrictions. The result is a matrix that specifies for each application in which region and on which service model it may be operated.

A common mistake: the assessment is conducted purely on a technical level, without involving business units and procurement. An application may be technically perfect for migration, but if a software vendor's license imposes a surcharge or prohibits cloud operation, the migration is economically dead. Such findings must surface during the assessment, not at cutover.

The 6 Rs — Decision Matrix for Every Application

The 6-Rs model, established by AWS and Gartner, remains the standard in 2026 for selecting the right migration strategy for each application. The key insight: every strategy has its legitimate place — a portfolio of 100 percent refactor is just as wrong as one of 100 percent rehost.

Strategy	What happens	Effort	When it makes sense
Rehost (Lift & Shift)	VM moved 1:1 to the cloud, no code changes	Low	Fast data center evacuation, stable legacy applications with no scaling requirements
Replatform	Minor adjustments, e.g. moving to a managed database or containers	Medium	When staff effort for DB administration or OS patching should be eliminated
Repurchase	Switch to a SaaS solution, old stack is decommissioned	Medium–High	CRM, HR, accounting, email — wherever standard SaaS works
Refactor / Re-architect	Application is decomposed and rebuilt cloud-natively (microservices, serverless)	High	Business-critical proprietary applications with long-term scaling requirements
Retire	Application is shut down, not migrated	Low	End-of-life applications, redundant tools, "dead apps" with only 1–2 users
Retain	Application stays on-premise or in the existing data center	Low	OT systems, licensing restrictions, very data-intensive batch jobs

A proven distribution for SME portfolios typically looks as follows: 35 to 50 percent rehost, 20 to 30 percent replatform, 10 to 15 percent repurchase, 5 to 10 percent refactor, 5 to 10 percent retire, 5 to 10 percent retain. The exact distribution depends on application age, the degree of standardization and the availability of internal development capacity.

Tool Stack — AWS MGN, Azure Migrate, GCP Migrate, CloudEndure

For operational execution, the three hyperscalers provide mature, cost-effective migration tools. They are considerably more capable today than three years ago and are generally sufficient for SME projects without requiring specialized third-party tools.

• AWS Application Migration Service (MGN) — the successor to CloudEndure, continuously replicates running servers into an AWS region and enables cutover within minutes. The de facto standard for rehost migrations to AWS, with German-language support and low per-server-per-hour costs.
• Azure Migrate — an integrated suite covering discovery, assessment, server and database migration. Particularly strong for Windows and SQL Server workloads, with native integration with Azure Arc for hybrid setups.
• Google Cloud Migration Center and Migrate to Virtual Machines — a leaner solution than the AWS and Azure equivalents, less commonly used in DACH SME projects but a serious option for container-centric migrations.
• CloudEndure — the original engine, now part of AWS MGN and Disaster Recovery — still relevant for cross-cloud migrations or as a DR service.
• Carbonite Migrate, Zerto, Veeam — third-party tools, useful for very heterogeneous environments or when a license already exists from a DR context.

Practical recommendation: for an SME project with a clear hyperscaler choice, the target provider's native tools are almost always sufficient. Third-party tools only become worthwhile when there are multiple parallel targets, exotic sources (AS/400, mainframe), or when disaster recovery needs to be solved in the same step.

Data Migration — Storage Gateway, DataSync, Database Migration Service

Data migration is the most delicate part of any cloud move. It determines the cutover window, consistency and rollback capability. Different tool classes apply to structured and unstructured data.

Unstructured data (file shares, archives, backups). Synchronizing tools dominate here. AWS DataSync and Azure File Sync transfer continuously, with bandwidth throttling, encryption and delta synchronization. AWS Storage Gateway and Azure StorSimple additionally offer an on-premise cache layer, useful when cutover is to be carried out in stages. For very large volumes (more than 50 TB), physical transport devices (AWS Snowball, Azure Data Box) are cheaper than pure network transfer.

Structured data (databases). Here the hyperscalers' migration services are the first choice. AWS Database Migration Service (DMS), Azure Database Migration Service and GCP Database Migration Service support heterogeneous migrations — for example Oracle to PostgreSQL or SQL Server to Aurora — and offer change data capture for near-zero-downtime cutovers. For homogeneous migrations (SQL Server to Azure SQL, MySQL to RDS MySQL), the combination of DMS and native replication mechanisms is the most robust approach.

Three practical recommendations: first, always start with a data trial run in a test environment that covers at least 7 days of change data capture, because many conflicts only become visible over time. Second, verify network bandwidth for the initial transfer early — a 10 TB database initial load over a 100 Mbit connection physically takes several days. Third, always agree the cutover window with the business unit rather than setting it from an IT perspective — accounting period-end closings or quarterly close periods are hard no-go zones.

Network Setup — VPC, Hybrid Connectivity, Direct Connect, ExpressRoute

The network is the skeleton of every cloud migration, and it must be in place before the first server cutover. Three layers need to be planned.

Cloud-internal segmentation. AWS VPC, Azure VNet or GCP VPC are the base containers for all cloud resources. A sensible segmentation separates production, test and development into dedicated VPCs or subscription structures, with dedicated subnets for public, private and database tiers. Transit Gateway (AWS), Virtual WAN (Azure) or Network Connectivity Center (GCP) consolidate routing between multiple VPCs and the outside world.

Hybrid connectivity during the migration phase. During migration, on-premise and cloud run in parallel — and need a reliable connection. Site-to-site VPN is the fast, low-cost entry point (typically 100 to 500 Mbit) but rarely sufficient for large data migration volumes. Dedicated lines such as AWS Direct Connect, Azure ExpressRoute or GCP Partner Interconnect offer 1 to 10 Gbit, lower latency and more stable SLAs — at monthly costs of between 500 and 3,000 euros depending on bandwidth and carrier.

DNS, identity, certificates. A consistent DNS structure across cloud and on-premise (Route 53 Resolver, Azure Private DNS Zones), the integration of existing identity (AD Connect, Azure AD DS, IAM Identity Center) and a unified certificate management all belong in the same planning effort. These three topics are frequently underestimated in migration planning and generate friction later.

Cutover Strategies — Big Bang, Wave, Strangler

Three cutover patterns have established themselves. The choice depends on risk tolerance, application coupling and the available maintenance window.

• Big-bang cutover — the entire landscape is switched over in a defined weekend window. Simple to plan, high in risk. Only suitable for very small environments (fewer than 10 applications) or when an imminent data center deadline dictates the schedule.
• Wave migration — applications are migrated in waves of 5 to 20 units each, with their own cutover weekend. The standard for SME projects because the risk per wave remains manageable and lessons learned feed into subsequent waves. Typical wave duration: 4 to 8 weeks.
• Strangler pattern — the old application continues to run in parallel, while the new cloud application gradually takes over functionality until the old one is fully replaced. Suitable for large proprietary applications being refactored as part of the migration. More effort, but low risk.

Recommendation: an SME with 40 to 80 applications is safest with a wave migration across 4 to 6 waves. The first wave should deliberately contain small, non-critical applications in order to test the process and tooling before the business-critical workloads are tackled.

Risks and Rollback Plan

The most common risks in cloud migration projects are not technical but organizational in nature. Five recurring patterns:

• Incomplete DiscoveryForgotten interfaces or shadow IT surfaces only at cutover. Countermeasure: run discovery for at least 60 days, plus workshops with all business units.
• Skill and Staffing GapThe migration team has insufficient cloud experience. Countermeasure: external support during the first 2 waves, with parallel training of internal staff through hyperscaler certifications.
• Unclear ResponsibilitiesBusiness units do not know when they need to test. Countermeasure: a named business owner per application with a clear testing task before every cutover.
• Missing Cost GovernanceBills spiral because right-sizing was skipped. Countermeasure: FinOps owner from day 1 and monthly cost reviews. More on this in our article Cloud Costs and FinOps.
• No Viable Rollback PlanWhen something goes wrong, there is no way back. Countermeasure: documented rollback plan per wave, tested at least once in the test environment.

A realistic rollback plan has three pillars: first, the source system runs in read-only mode for 7 to 14 days after cutover. Second, the DNS switch is prepared with short TTL values (60 seconds) so that a switchback is possible within minutes. Third, a tested database resynchronization exists that has been run through at least once in the test environment. A rollback plan that does not meet these three points is a document, not a plan.

Cost Examples for SMEs

The question "What does a cloud migration cost?" can only be answered responsibly in ranges. Three typical profiles illustrate the order of magnitude — the figures are intended as orientation for SME projects in Germany.

Profile	Apps / Servers	Project Duration	External Costs	Internal Effort
Small project (rehost-heavy)	15–30 apps / 40–80 servers	6–9 months	€80,000–180,000	1–2 FTE equivalents
Standard SME (mixed)	30–80 apps / 100–250 servers	9–15 months	€200,000–500,000	2–4 FTE equivalents
Larger SME (with refactor)	80–200 apps / 250–600 servers	15–24 months	€500,000–1,500,000	4–8 FTE equivalents

On top of this come the ongoing cloud costs after cutover — for a standard SME typically €8,000 to €25,000 per month in the first 12 months, reducible by 25 to 40 percent thereafter through right-sizing and reserved instances. The business case rarely comes from pure infrastructure savings but from eliminated staff effort, faster provisioning of new environments and reduced downtime.

Reepa Migration Approach

We guide SME cloud migrations through four defined stages that have proven themselves in practice. Stage 1 is a four-week assessment with a discovery tool, dependency workshops and compliance mapping — the output is a 6-Rs portfolio, a wave plan and a realistic cost framework. Stage 2 is the landing zone: VPC, identity, network connectivity, logging, FinOps tagging and an infrastructure-as-code foundation are built out over 4 to 8 weeks. Those who have not yet adopted infrastructure-as-code will find introductory guidance in our article Terraform IaC Best Practices. Stage 3 is the actual wave migration, typically spanning 6 to 18 months, with a dedicated migration factory of internal and external staff. Stage 4 is stabilization and optimization during the first 6 months after cutover — right-sizing, reserved instances, a modernization backlog and knowledge transfer to the internal team.

A characteristic of our approach: at every step we argue against lock-in by consistently using infrastructure-as-code, container orchestration and open data formats. We accept hyperscaler-specific services where they save staff effort (managed databases, object storage, identity), but we avoid deep dependency on proprietary platform services where they would prevent a future multi-cloud or exit strategy. Which hyperscaler fits in a given case depends on the existing Microsoft, Linux or data landscape — a detailed comparison is available in AWS vs Azure vs GCP.

Frequently Asked Questions