> 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/how-to/como-migrar-servidores-gnulinux-desde-on-premise-a-cloud.md).
# How to Migrate GNU/Linux Servers from On-premise to Cloud
Migrating a GNU/Linux server from on-premise to Plenit comes down to three blocks: you prepare the import from the platform, generate an image of the source disk, and upload it to the migration SFTP server.
The flow is designed for on-premise Linux servers, but it works just as well for other sources if you can obtain the disk image in the required format.
> 👍 What you get
>
> The import prepared in Plenit and the image `.raw` of your disk uploaded to the migration environment, ready for the platform to deploy the target server.
### Before you start
* Log in to the Plenit platform.
* Have access to the section **Migrations** within **Cloud Services**.
* Have the source GNU/Linux server ready from which you will generate the image.
### Step 1. Start the migration from the wizard
In **Cloud Services → Migrations**, click **New migration** to open the wizard. If you have already migrated before, this screen also shows the history.
#### 1.1 Service and source type
Select **Servers** as the service to migrate and, as the server type, **Virtual** to import the disk.
{/\* 📸 CAPTURE 1 · wizard · Servers service and Virtual type \*/}
#### 1.2 Disk format and delivery method
Select **Compatible Virtual Disks** as the format and **FTP** as the delivery method. Then fill in the disk data:
* **Name of the file to import**: with extension `.raw` (a raw disk is uploaded, copied bit by bit).
* **Partition**: whether it is a system or data disk.
* **Display name**: the name by which the disk will be identified in the console.
Click **Create** and then **Next**.
{/\* 📸 CAPTURE 2 · wizard · Compatible Virtual Disks format, FTP and .raw disk data \*/}
#### 1.3 Organization, subscription and deployment
Indicate the **organization**, the **subscription** and the **availability zone** where to upload the disk. To the question **Do you want to deploy a new server with the imported disks?**, the usual thing is **Yes**, to continue with the deployment in the same flow.
{/\* 📸 CAPTURE 3 · wizard · organization, subscription, zone and deploy option \*/}
#### 1.4 Destination server
If you chose to deploy, indicate the **name**, the **operating system**, the **size** and the **network type** (standard or VPC). Click **Finish**.
{/\* 📸 CAPTURE 4 · wizard · destination server configuration \*/}
#### 1.5 SFTP connection data
When it finishes, Plenit leaves the import prepared and shows the **SFTP connection details**: server, user, and password. Save them: these are the ones you will use to upload the image.
{/\* 📸 CAPTURE 5 · final screen with the SFTP connection details \*/}
### Step 2. Generate the disk image and upload it
Before you begin, delete unnecessary files or data from the source server: the image `.raw` takes up the **full disk size**, not just the used portion, so cleaning reduces what you are going to upload.
> ❗️ Clone the disk cold so the image is consistent
>
> Copying a system disk while it is mounted and services are writing to it can capture an incomplete state. For a reliable image, clone it with the machine stopped, from a live environment, or with the services stopped and the file system at rest.
#### 2.1 Identify the source disk
Check the machine's disks. If there are several, repeat the process for each one, distinguishing the system disk from the data disks.
```shell
lsblk # or: fdisk -l
```
Clone the **disk** entire one (for example `/dev/sda`), not the partition (`/dev/sda1`).
{/\* 📸 CAPTURE 6 · output of lsblk/fdisk -l identifying the source disk \*/}
#### 2.2 Generate the .raw image
Create the bit-by-bit copy with `dd`. A large block and the progress indicator make it faster and more visible than the classic example with `bs=1024`:
```shell
dd if=/dev/sda of=/media/backups/server.raw bs=4M status=progress
```
Verify that the file has been generated and its size:
```shell
ls -lah /media/backups/server.raw
df -lh
```
{/\* 📸 CAPTURE 7 · generation of the image with dd and size verification \*/}
#### 2.3 Upload the image to the SFTP
With the image ready, upload it to Plenit's SFTP using the wizard data, with a graphical client or from the command line:
```shell
sftp -P 22 @
put /media/backups/server.raw
```
(`-P 22` is the port; `` and `` are the ones the wizard gave you; `put` uploads the local file.)
{/\* 📸 CAPTURE 8 · SFTP connection and upload of the .raw file \*/}
When the upload finishes, the import continues on the platform. After a while, you will see in the migration console the messages to complete the configuration and start the server.
### Conclusion
The migration of an on-premise Linux lives in two places at once: the Plenit wizard, which prepares the import and gives you the SFTP, and your source server, where you generate and upload the image.
The point that decides whether the migration succeeds is not the `dd` image itself, but the state of the disk when you clone it: a cold image boots cleanly; a hot one, taken on a system that is writing, may boot with the file system damaged. If you take care of that and clean the disk first so you do not upload more than necessary, the rest is just following the wizard.
---
# 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/how-to/como-migrar-servidores-gnulinux-desde-on-premise-a-cloud.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.