Skip to content
Knowledge Hub/Article
Article

What Is Cloud Migration? Strategies, Steps and Risks

Cloud migration moves systems from a data center to the cloud. The 7 R strategies, the steps, downtime and cost questions, and the rules that apply in Türkiye.

Oğuzhan Gerçek··8 min read
What Is Cloud Migration? Strategies, Steps and Risks

Short answer: Cloud migration is moving an organization's servers, data and applications from its own data center to the cloud, or from one cloud to another. A good migration is not a single big day but a program that runs in waves: first an inventory and a dependency map, then a migration strategy per application, a pilot, a cutover driven by replication, validation and cost correction. In Türkiye, where the data will reside is a regulatory question for banks, capital market institutions and the public sector that has to be settled before anything moves.

What is cloud migration?

The scope is usually wider than assumed. What moves is not only virtual machines: databases and file servers, the identity infrastructure (Active Directory), network and firewall rules, the backup regime, monitoring and licenses all change places too. The target can be a public cloud, the organization's own private cloud or a hybrid cloud that mixes the two; the path from source to target is chosen separately for every application being moved.

Migration strategies: the 7 Rs

AWS's large migration guide lists seven strategies:

  • Retire: Shut down an application that no longer has business value instead of moving it. AWS calls applications whose average CPU and memory usage stays below 5 percent over 90 days "zombie" and those between 5 and 20 percent "idle"; both are retirement candidates.
  • Retain: Keep in place, for now, what cannot move because of data residency requirements, dependencies on special hardware, or a recent investment.
  • Rehost (lift and shift): Move the virtual machine to the cloud without changing the application; the fastest and least risky path.
  • Relocate: Move the virtualization platform as is to its cloud version; the application architecture is untouched.
  • Repurchase: Replace the existing software with its SaaS or cloud version.
  • Replatform: Make limited changes while moving: put the database on a managed service, upgrade the operating system, put the virtual machine into a container.
  • Refactor: Redesign the application with a cloud-native architecture.

The same guide carries an important warning: the common strategies in large migrations are rehost, replatform, relocate and retire; refactor is the most complex and costly, so the advice is to migrate first and modernize after the migration is complete. In practice the right answer is mixed: non-critical workloads move as they are, expensive ones go to cloud-native services, aging ones are retired.

The steps of a cloud migration

  1. Discovery and inventory: Which servers, which applications, which data, together with real usage measurements.
  2. Dependency map: Which application talks to which. The place projects most often get stuck is the invisible dependencies that surface after the move.
  3. Strategy and placement decision: One of the 7 Rs and a target (public cloud, private cloud, on premises) for each workload.
  4. Landing zone: Account structure, network, identity, encryption, logging and tagging standards; security is written into the architecture from day one, not added later.
  5. Wave plan: Systems that must move together are grouped, the order is set by risk, and the rollback point of every wave is written down.
  6. Pilot: A low-risk wave tests the method, the tools and the team.
  7. Replication and cutover: The target environment is synchronized in advance by continuous replication; at cutover only the final delta is transferred and traffic is switched to the target.
  8. Validation and hypercare: Application tests, performance and cost monitoring; intensive support in the first days.
  9. Optimization: Right-sizing to actual usage, reservations, shutting down unused resources.

How long is the outage, and can data be lost?

On systems that can be synchronized in advance by replication, the cutover is measured in minutes; where hardware has to be moved physically, the window is measured in hours. With the right method there is no data loss: the target is synchronized beforehand, validation is done before the cutover and the rollback path is kept in writing for every wave. The logic is the same as in disaster recovery; how to set the acceptable outage and data-loss targets in advance is in the RPO and RTO article.

Regulation in Türkiye

Where the data will reside is the question to answer before migrating:

  • Banks: The BDDK regulation requires primary and secondary systems to be inside Türkiye; cloud services count as outsourcing, and only the private cloud and community cloud models are possible. Details are in our BDDK article.
  • Capital market institutions: The SPK's Communiqué VII-128.10 (Official Gazette, 13 March 2025) makes it mandatory to keep primary and secondary systems inside Türkiye.
  • Personal data: Moving data abroad is subject to a separate regime under KVKK; the conditions are in the cross-border transfer article.
  • Public sector and critical infrastructure: Presidential Circular 2019/12 on information and communication security requires critical data to be stored inside Türkiye (in Turkish).

These conditions do not block a cloud migration; they set its target. A cloud with a region in Türkiye, a private cloud or a mixed placement is the answer in most cases, and the location of the backups is part of the same rule.

Does the cloud cut costs?

Not automatically. Over-sized servers moved one to one can cost more in the cloud; the advantage comes from right-sizing to actual usage and shutting down unused resources. According to Flexera's 2026 report, 85 percent of organizations name managing cloud spend as a top challenge, and the share of spend respondents estimate as wasted rose for the first time in five years, to 29 percent. Three items to know before moving: data egress fees, software licenses that work differently in the cloud, and the cost of running two environments at once during the migration. How to bring spending under discipline is in the FinOps article; what the shift from capital to operating expense means is in the CapEx and OpEx article.

The most common mistakes

  • Planning waves before the dependency map exists.
  • Leaving the identity and network layer to the last wave; the servers move, the users cannot log in.
  • Not writing down the rollback path; the decision is left to the moment of cutover.
  • Setting up backup and monitoring after the move.
  • Migrating a system that is about to be retired; the money is spent twice.
  • Forgetting optimization as soon as the migration ends; the bill shows it in the first month.
  • Not deciding at the start who will run the environment afterwards.

Managed migration: Eclit's approach

In our cloud migration service the work starts with an assessment: a strategy and a target are chosen for each workload, the migration runs in risk-driven waves, every wave has its rollback point and tests, and hypercare support follows the cutover; data center exit, the landing zone and cost optimization are part of the same program. If you wish, the team that migrates also runs the environment afterwards. For the readiness assessment and the workload placement decision, see the cloud adoption and platform migration page.

Frequently asked questions

What does migration mean? Moving a system, data or application to another environment. Cloud migration is moving to the cloud, data migration is moving data, platform migration is changing the platform.

How long does a cloud migration take? It depends on dependency complexity, not on the number of systems: twenty independent servers can take weeks, twenty interdependent servers months. A realistic timeline is given once the dependency map exists.

What does lift and shift mean? The other name of the rehost strategy: moving the virtual machine to the cloud as it is, without changing the application. The fastest path; the cost advantage needs right-sizing after the move.

Which systems should not move to the cloud? Those that are highly sensitive to latency, those with a data residency constraint, those whose license model does not allow third-party infrastructure, and those close to retirement.

Can data be lost during a cloud migration? Not with the right method: the target environment is synchronized in advance by continuous replication, only the final delta is transferred at cutover, and validation before cutover and the rollback path are written down for every wave.

Hybrid or full migration? For most organizations the answer is mixed: variable loads and new applications in the cloud, systems with a data residency requirement or latency sensitivity on premises or in a private cloud. Deciding per workload is safer than moving everything at once.

Sources