Cloud Migration Services

How to plan a server and cloud migration

A successful server migration depends more on preparation than on the technical transfer itself. Cloud migration projects typically follow these steps:

1. Inventory and discovery: servers, applications, databases, licenses and resource usage are documented.
2. Dependency map: which application depends on which database, service or network resource is identified; interdependent systems move in the same wave.
3. Target architecture and sizing: vCPU, RAM, disk, network and security rules are designed in the cloud.
4. Pilot migration: the method and timings are validated with a non-critical system.
5. Replication and testing: data is copied to the target while the live system keeps running, and acceptance tests are run with application owners.
6. Cutover: the final delta is synchronized in the planned window, and DNS and connections are pointed to the new environment.
7. Rollback plan and closure: a path back to the old system is kept ready in case of issues; the old environment is decommissioned after a set period.

Responsibilities are defined in advance for each of these steps: the infrastructure side sits with the migration team, while confirming that the application works correctly is usually the job of the application owner or software vendor. Putting acceptance criteria in writing before the migration prevents uncertainty on cutover night. A migration is also a good opportunity to revisit your backup and disaster recovery setup; our how to create a disaster recovery plan guide can help.

Service assurance: Requests raised during and after the migration are handled by the priority levels in the service level agreement; for a critical issue on cutover night, the first-response target is 15 minutes. Migration projects are planned with MAV Cloud’s ISO/IEC 20000 certified IT service management and ISO/IEC 27001 certified information security processes (see our certifications).

Migration methods: which one for which system?

Method	What happens?	Best suited for
Rehosting (lift and shift)	The server is moved as-is as a virtual machine	Fast migration, applications that should not be changed
Replatforming	The operating system or database version is upgraded during the move	Systems running on end-of-support versions
Data-focused migration	The application is installed on a new server and only the data is transferred	Old servers with complex installations

Using more than one method in a single project is common. For example, the file server and Active Directory may be moved as-is, while a database server running on an end-of-support operating system is upgraded to a current version during the move. The method is chosen by weighing the downtime the application owner can accept, the age of the system and how much longer it will be used after the migration. With large data volumes, transferring the initial copy in advance and synchronizing only the changes at cutover significantly shortens the planned downtime window.

Which infrastructure the migrated systems will run on in the cloud is also part of the migration plan; for most enterprise workloads, a cloud server is used as the target platform.

For example, Erler Otomotiv’s systems running on local servers and Lets Club’s systems were each moved to the cloud over a single weekend so that business operations were not disrupted.

Common cloud migration mistakes

• Moving systems one by one without mapping dependencies between applications.
• Not checking license terms (especially core-based licenses) before the migration.
• Copying resources one-to-one from existing hardware; sizing by guesswork instead of measurement.
• Taking the final step on migration day without a backup and rollback plan.
• Postponing post-migration monitoring and backup setup.
• Not informing users and application owners in advance about the migration schedule, possible brief outages and new access addresses.
• Forgetting to lower DNS record time-to-live (TTL) values before the migration; otherwise, the redirect reaches some users late.

To see how ready your current infrastructure is for migration, you can request a free infrastructure assessment.

To score pre-migration readiness across 11 items and estimate data transfer time, use the cloud migration readiness assessment.

Physical server to cloud migration: how it works

A physical server to cloud migration turns a machine that runs on its own hardware into a virtual machine on cloud infrastructure, or rebuilds its workload on a new virtual server. Most of the effort goes into measuring the old server correctly and removing its ties to the hardware.

When a company decides to move a server to the cloud, the first question is not “how big is the old box” but “how much of it is really used”. A physical server bought five years ago is often oversized in some areas and short in others. Before any data is copied, CPU, memory, disk growth and disk activity are measured over a normal working period, including month-end or payroll peaks. The target virtual machine is then sized from these measurements, with headroom that can be added later instead of paid for on day one. For reference, an entry-level cloud server with 4 vCPU, 8 GB RAM and 100 GB SSD costs roughly USD 60–100 per month at MAV Cloud, and resources can be increased after the move if monitoring shows the need.

Physical servers also carry hardware dependencies that a virtual machine does not have. Typical examples are USB license dongles, serial or PCI cards, RAID controller drivers, software licensed to a specific hardware ID, and local tape or disk backup jobs. Each of these is listed and given a solution before cutover: a network-based license, a vendor-issued license transfer, a different backup method or, in rare cases, keeping that single component on-premises.

On the target side, migrated servers run on VMware-based infrastructure in Equinix Istanbul, where each virtual machine has isolated resources and sits on high-availability hosts with central storage. That means a single host failure does not take the server down with it, which is a practical difference from a stand-alone physical machine with one power supply and one set of disks.

Application dependencies to map before migrating from on-premises

Before migrating from on-premises, every connection an application makes to something outside itself needs to be written down, because a server that starts fine in the cloud can still fail when it cannot reach a database, a license server or a file share. Dependencies that are missed are the most common reason a server migration to cloud is rolled back on cutover night.

The dependency map is built from network connection data, configuration files and interviews with application owners. The items that most often come up are:

• Database connections: connection strings that point to an IP address or a local server name rather than a DNS name.
• Directory and name services: Active Directory authentication, internal DNS zones and group policies the server relies on.
• License servers: applications that check a license service on another machine at start-up.
• File shares and scanned folders: mapped drives, export folders and devices such as scanners or printers that write to a share.
• Scheduled jobs and integrations: nightly transfers, e-invoice or bank integrations, SMTP relays and APIs that whitelist a fixed public IP.
• Latency-sensitive pairs: an ERP client and its database that must stay close to each other and move in the same wave.

Each dependency is marked as “moves with this server”, “already in the cloud” or “stays on-premises”. The last group determines whether a site-to-site VPN or a dedicated connection is needed during the transition period.

Who can move our servers to the cloud? What a migration service includes

A cloud server migration can be carried out by an in-house IT team, by the software vendor or by a cloud provider’s migration team; the right choice depends on who owns the risk on cutover day. With a migration service, the provider takes responsibility for the infrastructure side of moving servers to the cloud, while the application owner confirms that the software works as expected.

Area	Migration team	Customer / software vendor
Inventory, sizing, dependency map	Prepares and documents	Reviews and confirms
Target servers, network, firewall	Builds and configures	Approves access rules
Data copy, sync and cutover	Runs the process	Agrees the downtime window
Application acceptance tests	Supports	Signs off
Monitoring and backup after go-live	Sets up	Defines retention needs

After go-live, support requests follow the SLA priority levels: first-response targets are 15 minutes for critical, 1 hour for high, 4 hours for medium and 1 business day for low priority issues, with a 99.9% monthly availability target for cloud servers. Migrated systems can be added to 24/7 system monitoring and to Veeam-based cloud backup with storage located in Türkiye, so protection starts on the first day in the new environment rather than weeks later.

For the step-by-step technical process, see the guide on migrating servers to the cloud; to score current readiness, use the cloud migration readiness assessment.