The 6R Strategy in Cloud Migration: Not Every Server Should Move

Rehost, replatform, refactor, repurchase, retire and retain; a sample mix for 120 servers and a five-year TCO comparison.

The most common mistake in cloud migration projects is moving all servers to the cloud as they are. This "lift and shift" approach is sometimes a quick fix but often leads to a cloud bill higher than running on-premises. The 6R framework lets you choose the right strategy for each application.

What are the 6Rs?

Rehost: the application is moved to the cloud as is. It is quick and needs the least change.
Replatform: moved with small improvements; for example the database switches to a managed service.
Refactor: the application is rewritten for a cloud-native architecture. It is costly but gives the biggest long-term gain.
Repurchase: a ready SaaS solution replaces the application (for example email or CRM).
Retire: unused or duplicate applications are switched off.
Retain: latency-sensitive, regulated or legacy-hardware-dependent applications stay on-premises.

Example mix: a company with 120 servers

Strategy	Servers	Note
Rehost	55	A fast wave, in three months
Replatform	25	Databases to a managed service
Refactor	6	Critical customer-facing applications
Repurchase	10	Email, file sharing, HR
Retire	14	Unused test and legacy systems
Retain	10	Production line and customs systems

In the inventory stage alone, 14 servers were found to be unnecessary; that by itself means a yearly saving of about 11 percent.

Cost comparison

In five-year total cost of ownership (TCO): on-premises operation 18 million TRY; moving everything as is 17.2 million TRY (limited gain); a 6R strategy with FinOps 13 million TRY. The difference comes from right-sizing, reserved capacity and the systems retired. The figures are examples.

Tips for success

Cloud governance (tagging, budget alerts, identity) should be in place before the migration.
Migration should be done in waves, measuring cost and performance at the end of each wave.
Data residency should be addressed at the start because of KVKK and sector regulation.

Omurga starts with a readiness assessment and ends with a business case report that can be presented to the board.

A security and compliance note

Identity, encryption and logging decisions should be made at the very start of the architecture during migration. The shared responsibility between cloud provider and customer should be made clear in writing; the location and backups of workloads containing personal data should be documented under KVKK.