Within Akamai Cloud, Linodes can be migrated from one physical host machine to another (either within the same region or between regions). These migrations typically occur for one of the following reasons:

User-initiated migration to a different region: Migrations between regions can be configured by customers in Cloud Manager or initiated by our team when a region is decommissioned. For customer-initiated cross-region migrations, see Migrate to a new data center.
User-initiated plan change (resize): When a Linode plan is changed, it migrates to a new host so that it can be resized to the new plan. See Resize a Linode.
Host maintenance event: It's often necessary to perform planned (or unplanned) maintenance on host hardware. When this occurs, the affected Linodes are either migrated to a new host or an in-place upgrade is performed.

Migration methods

There are three types of migrations that can occur: live migrations, warm migrations, and cold migrations. Migrations within the same region can be performed using any method, depending on host availability, plan type, and other details. Migrations between regions can only be performed using cold migrations.

Live migrations — Linode remains operation while it migrates to another host, though there is some performance impact during the migration. No reboot is required.
Warm migrations — Linode remains operation while it migrates to another host, though there is limited performance impact during the migration. A reboot is performed after the migration finishes.
Cold migrations — Linode is gracefully shut down and migrated to another host. Downtime is 20 minutes to multiple hours and depends on plan size.

While customers are not able to select which migration method is performed for a particular migration, a live migration method is prioritized whenever possible.

Live migrations

A live migration moves a Linode to a new host while it is still running. During the migration, the instance will be fully operational, though there is a temporary performance impact to disk I/O and system memory. When the migration finishes, no reboot is required, though there are a few seconds of downtime while network traffic is rerouted. In some cases, such as for large Linode plan sizes or GPU plans, a live migration might not be available. When this occurs, the system will fall back to another migration method. Live migrations are not supported for Linodes in distributed compute regions.

Live migrations are the default option and are preferred for most use cases. Consider other migration types if individual system downtime is preferable to reduced system performance (such as applications configured for high availability).

Warm migrations

A warm migration is similar to a live migration from a user's perspective. The Linode is moved to another host and most of the migration occurs while the Linode is powered on and operational. There is still a small performance impact during the migration, but only disk I/O is affected. When the migration is complete, the Linode is rebooted. This means any applications running on the Linode will experience downtime while the Linode reboots. In most cases, a properly configured system will fully recover after a reboot and all services that were running prior to the reboot event will be restored. If your system is not able to recover from a reboot, your applications may remain down until you correct the issue. See the Reboot Survival Guide for tips on recovering from reboots.

Cold migrations

As part of a cold migration, the Linode is gracefully shut down and remains powered off during the entire migration process. After the migration finishes, the Linode boots back up. Just like for warm migrations, properly configured systems will automatically restore full functionality after a system reboot. If your system is not able to recover from a reboot, your applications may remain down until you correct the issue.

Cold migrations may be preferred for applications that can handle individual system downtime, such as those configured for high availability. In these cases, application traffic can be routed to fully functional Linodes while the impacted Linode is powered off.

Troubleshooting migrations and FAQs

What if my cold migration fails?

Should a cold migration fail for any reason, the Support team is notified and will configure a new cold migration.

Why would a live migration not be available?

In order for a live migration to occur, a host compatible with the host your Linode currently resides on must be available. Not all host hardware is alike or available to accept a live migration, so live migrations are not always a viable option.

What could cause a warm migration to fail?

Your Linode is not configured to respect ACPI shutdowns:
- This applies to warm migrations initiated by customers, including warm migrations taking place during the warm resize process.
- This also applies if you are running a custom distribution (i.e. Windows) or unsupported disk image that is not configured for ACPI shutdowns.
If a Akamai Cloud administrator cancels the warm migration.
If the sources Linode stops responding, is shut down before the cross-host sync, or if the process is disturbed in any way.

What should I do if my warm migration fails?

If your warm migration fails to complete after an early initiation is triggered via Cloud Manager, the Support team is notified. There are two options that are used at the discretion of the Support team.
- A new warm migration can be configured to be performed at a scheduled time.
- A cold migration can be configured. You can then initiate the cold migration via Cloud Manager or allow it to proceed as otherwise scheduled.

What should I do if my warm resize fails?

If a warm resize fails, you can either proceed with a cold resize (recommended) or troubleshoot your Linode's configuration to respect ACPI shutdowns.

What if my cross data center migration fails?

Should a cross data center migration fail, you may reattempt the migration. If it fails again, open a Support ticket for further assistance.