Migrate Compute Engine Types

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.

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: An active IONOS Backup Service Backup Unit with the Acronis agent installed on the source VM.

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.

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.

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.

DCD workspace showing the expand arrow on the source server to reveal attached storage volumes

1. 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.
2. 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.

Inspector pane showing the Storage tab with the re-attached volume set as Boot Device

1. Add a network connection: Drag a connection line from the new server to the appropriate LAN element.
2. Provision: Delete the now-empty source server object and select Provision Changes.

Result: Your storage volume is now attached to the target server and ready for use.

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.

DCD Inspector pane showing the Create Snapshot option in the storage volume drop-down menu

1. Deploy the target server: Drag the new target element (vCPU Server, Dedicated Core Server, or Cube) into the workspace.
2. 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.

Inspector pane showing the Image dropdown with the Snapshots section and a snapshot selected

1. Add a network connection: Drag a connection line from the new server to the appropriate LAN element.
2. Provision: Select Provision Changes. Once the new server is confirmed as functional, delete the original source instance and the temporary snapshot.

Result: Your workload is now running on the target Compute Engine type from a restored snapshot.

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.

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 and Install Acronis Backup Agent on Windows.

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 Restoreor manually attaching the VirtIO ISO to the VM through the DCD.

1. Clean up: Once the new server boots successfully and network connectivity is verified, delete the old source instance.

Result: Your workload is now running on the target Compute Engine type with adapted drivers and boot configuration.

Architecture and firmware considerations

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.

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 or Method 2 (snapshot) 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).

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.

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 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 2 (snapshot)	Method 3: IONOS CLOUD Backup Service (Acronis)
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

Note: For Method 1: Storage re-attachment and Method 2 (snapshot) 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

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
• Set up a vCPU Server
• IONOS CLOUD Backup Service