> For the complete documentation index, see [llms.txt](https://docs.ionos.com/cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ionos.com/cloud/compute-services/compute-engine/how-tos/migrate-compute-engine-types.md).
# Migrate Compute Engine Types
Migrate between vCPU Servers, Dedicated Core Server, and Cube Compute Engine types in IONOS CLOUD DCD.
Compute Engine types are fundamental architectural choices in the Data Center Designer (DCD) and cannot be toggled directly. To migrate between **vCPU Server**, **Dedicated Core Server**, and **Cube**, you must move your storage from the source instance to a new target instance using one of the following methods.
{% hint style="info" %}
**Prerequisites:**
* An active IONOS CLOUD account with DCD access.
* The source VM is identified and its boot firmware (BIOS or UEFI) is known.
* For [Method 3: IONOS CLOUD Backup Service](#method-3-ionos-cloud-backup-service): An active IONOS Backup Service Backup Unit with the Acronis agent installed on the source VM.
{% endhint %}
## Method 1: Storage re-attachment
This is the most efficient method for moving between **vCPU Server** and **Dedicated Core Server**. It involves moving the virtual storage volume from one server instance to another within the DCD workspace.
### Limitations
* The source and destination must be in the same Virtual Data Center (VDC).
* **Firmware match required:** The source and target CPU architectures must support the same boot firmware (for example, both BIOS or both UEFI).
* **Cube boot volumes are locked:** This method cannot be used for the primary boot volume of a Cube, as Cube base storage uses direct-attached local NVMe and cannot be detached.
{% hint style="info" %}
**Note:** Secondary Block Storage volumes (HDD/SSD) can be detached and moved from a Cube to another server using this method. You can also drag a standard volume from another server onto a Cube as secondary storage.
{% endhint %}
### Steps
1. **Power off the source VM:** Shut down your VM gracefully through the Operating System (OS) to ensure data consistency.
2. **Create the target server:** Drag a **Dedicated Core** or **vCPU Server** element from the Palette into the workspace. Configure the CPU family, cores, and RAM as required. At this stage, the new server shows 0 MB of storage.
3. **Expand the storage view:** On the source server object, select the **down arrow icon** to reveal the storage volumes currently attached to the VM.
4. **Move the storage volume:** Select and hold the specific **Storage Volume** block (excluding Cube NVMe drives) and drag it onto the new target server object.
5. **Configure the boot sequence:** Select the new server, navigate to the **Storage** tab in the Inspector pane, and ensure the re-attached volume is set as the **Boot Device** when multiple volumes are present.
6. **Add a network connection:** Drag a connection line from the new server to the appropriate **LAN** element.
7. **Provision:** Delete the now-empty source server object and select **Provision Changes**.
{% hint style="success" %}
**Result:** Your storage volume is now attached to the target server and ready for use.
{% endhint %}
## Method 2: Snapshot migration
This method supports any Compute Engine type (**Cube**, **vCPU Server**, or **Dedicated Core Server**). You must use this method to migrate from a Cube or between different Virtual Data Centers.
### Limitations
* **Firmware match required:** The target CPU must support the boot firmware of the snapshot.
* **Cube storage size constraint:** If migrating to a Cube, the snapshot size must be smaller than or equal to the fixed storage capacity of the target Cube tier. Cubes use pre-sized, direct-attached storage and cannot restore a snapshot that exceeds the storage capacity of the target Cube tier.
### Steps
1. **Create a snapshot:** Use one of these options in the DCD:
* **Option A:** Expand the source server in the workspace, select the specific storage volume block, and select **Create Snapshot** in the Inspector pane.
* **Option B:** Select the source server, navigate to the **Storage** tab in the Inspector pane, open the drop-down menu next to the storage volume, and select **Create Snapshot**.
2. **Deploy the target server:** Drag the new target element (**vCPU Server**, **Dedicated Core Server**, or **Cube**) into the workspace.
3. **Initialize storage from snapshot:** Drag a new Storage element onto the new target server. In the Inspector pane, select the **Image** dropdown, navigate to **Snapshots**, and select the snapshot you created in step 1.
4. **Add a network connection:** Drag a connection line from the new server to the appropriate **LAN** element.
5. **Provision:** Select **Provision Changes**. Once the new server is confirmed as functional, delete the original source instance and the temporary snapshot.
{% hint style="success" %}
**Result:** Your workload is now running on the target Compute Engine type from a restored snapshot.
{% endhint %}
## Method 3: IONOS CLOUD Backup Service
This method is recommended for moving between **any** Compute Engine types across different regions, resizing file systems, or **migrating across incompatible CPU architectures (BIOS to UEFI)**. Because you cannot detach storage from Cubes or move volumes across incompatible hardware, this method treats the migration as a standard Bare-Metal Recovery (BMR): back up the source server and restore it onto a newly provisioned, blank target server.
{% hint style="info" %}
**Prerequisites:**
* An active Backup Service with a configured Backup Unit.
* The Acronis Backup Agent installed and registered on the source machine. For more information, see [Install Acronis Backup Agent on Linux](https://docs.ionos.com/cloud/backup-and-storage/backup-service/how-tos/install-acronis-backup-agent) and [Install Acronis Backup Agent on Windows](https://docs.ionos.com/cloud/backup-and-storage/backup-service/how-tos/install-acronis-backup-agent-windows).
{% endhint %}
### Steps
1. **Back up the source VM:** Perform a Full Machine backup of your source instance via the Backup Service Console.
2. **Provision the target server:** Deploy your new Compute Engine (**vCPU Server**, **Dedicated Core Server**, or **Cube**) in the DCD with a blank storage volume.
3. **Add a network connection:** Drag a connection line from the new server to the appropriate **LAN** element.
4. **Restore to the target server:** Perform a full machine recovery to the new target server. You can do this by booting the new server with the Acronis Rescue Media ISO via the KVM console, or by installing a temporary OS and triggering the recovery from the Acronis web console.
5. **Adapt hardware and drivers:**
* **For BIOS/UEFI changes:** Acronis automatically adapts the boot partition for the new hardware during recovery.
* **For Windows:** Inject the new VirtIO storage drivers by running Acronis **Universal Restore**or manually attaching the VirtIO ISO to the VM through the DCD.
6. **Clean up:** Once the new server boots successfully and network connectivity is verified, delete the old source instance.
{% hint style="success" %}
**Result:** Your workload is now running on the target Compute Engine type with adapted drivers and boot configuration.
{% endhint %}
## Architecture and firmware considerations
{% hint style="warning" %}
**Important:** Before choosing a migration method, evaluate the boot firmware and CPU architecture of your source VM. Moving a virtual hard drive directly (by re-attaching storage or restoring a snapshot) only works if the source and target hardware are compatible.
{% endhint %}
Consider the following factors:
* **ISO type and age:** Modern IONOS CLOUD images typically use UEFI. Older or self-managed ISOs may use Legacy BIOS.
* **Boot path requirements for custom UEFI images:** Even if a custom or self-managed ISO supports UEFI, a direct disk migration [**Method 1: Storage re-attachment**](#method-1-storage-re-attachment) or [**Method 2 (snapshot)**](#method-2-snapshot-migration) may fail to start. Some operating systems register exact boot loader file paths inside the original VM's system memory (NVRAM). A newly created server starts with empty system memory and does not automatically detect the boot path unless the operating system is configured to use the standard removable fallback path (`\EFI\BOOT\BOOTX64.EFI`).
* **Cross-architecture boot failure risk:** Moving an existing boot volume between different CPU generations may cause the operating system to fail to start due to missing kernel drivers, instruction set mismatches, or firmware conflicts (Legacy BIOS vs. UEFI enforcement).
{% hint style="info" %}
**Note:** Explicit CPU architecture selection is only available when deploying **Dedicated Core Servers**. Standard vCPU instances use a generalized hardware pool and do not allow manual architecture customization. The available CPU families for Dedicated Cores are region-dependent.
{% endhint %}
If you are unsure of your architecture, or if you know you are crossing CPU generations or dealing with a complex self-managed UEFI installation, [**Method 3: IONOS CLOUD Backup Service**](#method-3-ionos-cloud-backup-service) is the recommended option. Acronis handles the migration and conversion of the BIOS/boot partition and injects the necessary hardware drivers for the new CPU.
## Migration compatibility matrix
| **From** | **To** | [**Method 1: Storage re-attachment**](#method-1-storage-re-attachment) | [**Method 2 (snapshot)**](#method-2-snapshot-migration) | [**Method 3: IONOS CLOUD Backup Service (Acronis)**](#method-3-ionos-cloud-backup-service) |
| -------------------------------------------- | -------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **vCPU Server** | **Dedicated Core Server** | Supported\* | Supported\* | Supported |
| **Dedicated Core Server** | **vCPU Server** | Supported\* | Supported\* | Supported |
| **Cube** | **vCPU Server** or **Dedicated Core Server** | Secondary volumes only (boot volume locked) | Supported\* | Supported |
| **vCPU Server** or **Dedicated Core Server** | **Cube** | Secondary volumes only (boot volume locked) | Supported (check size limits)\* | Supported |
{% hint style="info" %}
**Note:** For [**Method 1: Storage re-attachment**](#method-1-storage-re-attachment) and [**Method 2 (snapshot)**](#method-2-snapshot-migration) indicated with \*, you require the source and target CPU to support the same boot firmware (BIOS/UEFI). If there is a mismatch, use [Method 3: IONOS CLOUD Backup Service](#method-3-ionos-cloud-backup-service)
{% endhint %}
## Result
Your workload is now running on the target Compute Engine type. The new server is provisioned and available in the DCD. You can delete the original source instance once functionality is verified.
## Next steps
* [Set up a Dedicated Core Server](/cloud/compute-services/compute-engine/how-tos/set-up-dedicated-core.md)
* [Set up a vCPU Server](/cloud/compute-services/compute-engine/how-tos/set-up-vcpu.md)
* [IONOS CLOUD Backup Service](/cloud/backup-and-storage/backup-service.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.ionos.com/cloud/compute-services/compute-engine/how-tos/migrate-compute-engine-types.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.