> For the complete documentation index, see [llms.txt](https://docs.plenit.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.plenit.com/docs-en/productos/migrations/quickstart.md).

# Quick Start

Migrations is the tool that uploads, converts, and deploys virtual machines and other cloud services in a guided way.&#x20;

With it, you take your **Servers** and Remote Desktop **Remote Desktop** to Plenit through a guided process that reduces time and risk.&#x20;

This guide gives you the big picture: where the tool lives, the three-step wizard to launch a migration, the transfer formats and modes it supports, how you follow the process from its details, and how the final adjustments are closed.

> #### 👍 What you get
>
> An overview of Migrations so you can choose the right source format and transfer mode before launching your first migration, and know how to read the status of each process as it progresses.

### Where the tool lives

Access **Migrations** from **Cloud Services**. The tool has two tabs:

* **Migrations**: your migration processes and the wizard to launch new ones.
* **Assisted migration**: the migration accompanied by our team, for when the scenario is complex or you prefer to delegate it.

When you don't have any migrations yet, the tab **Migrations** welcomes you with an overview of what you can do: a **assisted migration wizard** that guides you from start to finish, **multiple transfer formats and methods** to fit your environment, and **connectors for any source** (AWS, Microsoft Azure, OVHcloud and other cloud providers, plus on-premise environments).&#x20;

From here you launch your first migration with **New migration**.

<figure><img src="/files/e3c7229b29565f7287b3a31b11b8e3e3ddb485e2" alt=""><figcaption><p>Migrations</p></figcaption></figure>

Once you have migrations running, the tab **Migrations** shows the **list** of all the processes launched from your organization, for each client. This lets you have several migrations at once and track them from a single place. Each row gives you, at a glance:

* **ID** of the process and its **status** (for example, **Pending adjustments** in orange, **Completed** in green or **Cancelled** in red).
* **Server** and **Disks**, with a **progress bar** and its percentage.
* **Organization**, **Subscription** and **Date**.
* The **Actions** menu (⋮) to operate on each process.

At the top right you have **Request assistance** (takes you to the assisted migration) and **New migration** (opens the wizard). The button **Filter** helps you narrow the list when you have many processes.

<figure><img src="/files/198f63dce710ae597afc326c63b25131984831f0" alt=""><figcaption></figcaption></figure>

### The 3-step wizard

Press **New migration** (New migration) in **Cloud Services → Migrations** to launch the wizard, which automates upload, conversion, and deployment. There are three steps: **Service**, **Source** and **Destination**.

> #### 🚧 The Source Step determines everything else
>
> The source format and transfer mode you choose determine the rest of the process. Take your time with this step: changing it later means relaunching the migration.

#### Step 1 · Service

You choose **which service to migrate**. Right now the wizard offers **Servers** and **Remote Desktop** (Remote Desktop); **File storage** and **DNS** appear as *Coming soon*. Each card has a **Learn more** with the service details.

<figure><img src="/files/8a818b27dcea8e3eae03ed6a97c5ea12ca2ca64b" alt=""><figcaption></figcaption></figure>

#### Step 2 · Source

You define where your data comes from. Here you decide:

* Whether the source server is **physical or virtual**.
* The **format of the server to migrate**: **VHD – Disk conversion** or **Acronis Agent**.
* The **transfer mode**: **FTP client** or **Download from URL**.
* The **disks to import**: file name, partition (for example, System) and disk name. You add each disk with **Create**.

Keep in mind the limit: only disks up to **1 TB**, and the supported extensions are those of the VHD path (VMDK, VHD, VHDX, QCOW2, VDI, RAW). You have the details in Disk Formats and Transfer Modes.

> #### 📘 DHCP on all adapters
>
> All network interfaces on the machine must have DHCP enabled to operate correctly in Plenit's infrastructure.

<figure><img src="/files/1493ac0432bdf92e28294f99cb0fe4472eb733c4" alt=""><figcaption></figcaption></figure>

> #### 🚧 Transfer modes in the wizard
>
> The documentation describes four paths (SFTP, download by URL, web upload, and Acronis Agent), but the screenshot wizard only shows **FTP client** and **Download from URL** (Acronis Agent appears as *format*, not as a mode).&#x20;

#### Step 3 · Destination

You define where the migration arrives:

* **Organization** and **subscription** destination. If you're missing one, create it on the fly with **New organization** or **New subscription**.
* **Location**: the **region** (for example, Madrid or Paris) and its **availability zone**. The region applies to all servers created in that subscription.
* **Do you want to deploy a new server with the imported disks?** With **Yes**, in addition to migrating the disks we deploy a new server with them. With **No**, we only migrate the disks.

If you choose **Yes**, the wizard asks you to configure the server: **name**, **offering** (CPU and RAM), **operating system**, **network type** (Standard Network or VPC Network) and, in **Advanced options**, the manual network configuration (network, subnet mask, gateway, IP and MAC) and opening a TCP port for SSH access.

<figure><img src="/files/74727ba3e4faef8bf6490163d9a0ecba77aa961b" alt=""><figcaption></figcaption></figure>

> #### 🚧 Operating system catalog and step schema
>
> The deployment OS catalog (AlmaLinux, Rocky Linux, CentOS, Oracle Linux, Ubuntu, Windows, 3CX and versions) is still to be confirmed against the current panel.&#x20;
>
> And an old mockup labels the organization/location step as "Step 2 · Where you want to migrate": the current wizard treats it as **Step 3 · Destination**.&#x20;

### Special case: migrating Remote Desktop

When the service to migrate is **Remote Desktop**, the flow has a nuance: first you migrate the **server** that hosts the remote desktop and then you deploy a **new remote desktop service** pointing to that server. The wizard summarizes it in four steps:

1. Migrate the disks and the server that host the remote desktop service.
2. Deploy a new remote desktop service.
3. In the wizard for the new remote desktop, select the server you migrated.
4. Complete the required information and perform the final validations.

If you still haven't migrated the server, the wizard itself links you to **Server migrations** so you can start there.

<figure><img src="/files/1677c31c4c7bbc3fb70c45ad6f77a3d76dafb688" alt=""><figcaption></figcaption></figure>

### Following the process: migration details

Each process has its **details**, where you see the **phase** the migration is in, the data at each moment, and the actions you need to take to unblock it. The number of phases depends on whether you asked to deploy a server or only migrate disks.

#### With server deployment (5 phases)

The detail goes through **Source → Disks → Server → Adjustments → Completed**. When the migration reaches **Adjustments** (status **Pending adjustments**), the planned phases have been completed and only the final adjustments remain so the machine is 100% operational. From this same detail:

* **Access the server** via VNC console.
* **Install the Cloud Migrations Tool** (you download it or run it from the path indicated on the screen itself on the migrated server).
* **Validate the installed components** with the **Validate**button: the tool checks the monitoring software, virtualization drivers, and initialization software. If any check fails, it tells you what to fix.

> #### ⚠️ Uninstall VMware or AWS tools
>
> If the source server has VMware or AWS tools installed, uninstall them before continuing with the adjustments.

> #### ℹ️ Restart and password
>
> When the migration is validated, we restart the server and set the password for the administrator user (if it doesn't exist, we create it). When it's ready, we send you a notification with the password.

In the details you also have the blocks for **Server** (name, status, operating system, location, resources, network type and disks), **Disks** (with disk-by-disk progress) and **Source** (connection status and the **transfer mode**, with its host, user, and password).

<figure><img src="/files/be60d6b25c1b5b7c38c263fc27362ba9bedfda6c" alt=""><figcaption></figcaption></figure>

#### Disks only (3 phases)

If you chose **No** deploy server, the detail is shorter: **Source → Disks → Completed**. When it finishes, the screen itself confirms it. Here there is no Server or Adjustments block: the migration closes with the imported disks.

<figure><img src="/files/26c14f90f33b4668a803bfb3d93e2ea8805002b8" alt=""><figcaption></figcaption></figure>

### Supported disk formats

There are two paths depending on the origin of your data: the **Acronis Agent**Acronis Agent **VHD – Disk conversion**VHD path

### Transfer modes

Four paths depending on your infrastructure: **SFTP** (encrypted, the general mode), **download by URL** (from S3, Azure or compatible source), **web upload** and **Acronis Agent**. In the URL download, the link must stay alive while the transfer lasts, because Plenit is the one downloading the disk. You have the table with when each mode is convenient in Transfer Modes.

### Final adjustments and validation

Once launched, the migration doesn't always flow the same way: it depends on the type and the chosen options. Sometimes it goes automatically to the end; other times, the tool asks you for specific actions through alerts in the details so you can unblock it.

When you see the status **Pending adjustments**, the planned phases have been completed and only the final adjustments remain:

* In **Windows**, you usually download an application and run it on the migrated server.
* In **GNU/Linux**, you download and run an application and some additional commands on the migrated server.

Once that's done, validate from the tool itself: you'll see a series of verification checks. If any fails, validation tells you the error and what to fix.

### Assisted migration (Assistance)

If the scenario is complex or you prefer to delegate it, you have the assisted migration by our team. You enter through the tab **Assisted migration** or with **Request assistance** from the list. We move your disks or servers from any provider or local environment through the same three-step wizard, with you in each decision. You also have it in Assisted migration with Partner Success.

<figure><img src="/files/295180919bb57b4ba5368ea4a41947544f2ee14d" alt=""><figcaption></figcaption></figure>

### Conclusion

Migrations exists to remove complexity from a process that usually has a lot of it: it automates upload, conversion, and deployment, and makes visible what you actually need to decide.&#x20;

The key lies in the step of **Source**, because the format and transfer mode determine everything that comes after.&#x20;

Once you've chosen correctly, you follow the process from its details (5 phases if you deploy a server, 3 if you only migrate disks) and the check validation confirms that the machine has been made operational before considering it migrated.


---

# 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.plenit.com/docs-en/productos/migrations/quickstart.md?ask=<question>&goal=<endgoal>
```

`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.
