Migration Process - Public Cloud [EN]

Q1. What do I need to do for the migration? Is it automatic?

There's no fully automatic "one-click migration" - the service architecture and the underlying platform are both changing, which makes that impossible.

The amount of work on your end depends on how your project is set up:

• One or more independent VMs - we handle the migration with minimal involvement from you, preserving your IP address and data. All you need to do is choose a migration method, confirm you're ready, and verify that everything is working after the move.

• Multiple interconnected VMs - we'll go over your project details in a ticket and plan the migration together.

• Kubernetes cluster - we'll set up a project on the new platform where you can deploy an equivalent cluster and migrate your data from Websa Cloud. Our team will help you plan the move and guide you through every step.

Q2. How does migration executed by the Advanced Hosting tech team go?

Our team can carry out migration in one of two ways:

Option 1 (Recommended): Shutdown and transfer with IP preservation. We shut down the VM, copy all data to a new VM on the new platform, and bring the new VM online once the copy is complete.

1. Pros: Full data consistency - the new VM reflects the exact state of the old one at shutdown.
   Cons: Downtime equal to the disk copy time (typically 20 to 60 minutes, depending on volume size).

2. Option 2: Migration via backup. We create a backup of the VM on Websa, restore it on the new platform to spin up a new VM, and only then transfer the IP address.

1. Pros: Short downtime - only the time needed to transfer the IP (typically up to 5 minutes).
   Cons: Data state might be out of sync between the old and new server during the backup window (up to 2 hours).
   Any changes made on the old server during that window might not be reflected on the new one.

Q3. Will all servers be migrated at the same time?

Migration is carried out in phases, starting with the European location (Amsterdam, Netherlands).
If you have servers in the US (Ashburn), we will reach out separately to align on the transfer - timelines and options for the US location will be agreed upon with you individually.

If all your servers are in the same location, their migration will not be spread across different days or weeks unless you specifically request it.

Q4. Is migration free, or will there be extra charges?

If it's critical for you to perform the migration outside business hours or on weekends, that can be discussed with our team. Depending on complexity, such work can be offered as a paid extended support service.

Q5. When exactly will my migration take place?

The specific date and estimated time will be agreed upon with you individually in a ticket once you've confirmed you're ready to proceed. The order depends on your preferences and our team's availability.

Migrations are typically performed during business hours (10:00–18:00 UTC+3). You can specify a preferred day of the week and time of day - we'll do our best to accommodate. If it's essential to migrate outside business hours or on weekends, that's handled separately and could be available as a paid extended support service.

Q6. What happens to my data during migration?

Your server's data is not deleted or erased during migration.

If you choose the shutdown-based migration (20 to 60 minutes of downtime), the server state is captured at the moment the old VM is stopped, and that's exactly what gets moved to the new server.

With the backup-based migration ("Migration via backup"), there can occur a small amount of data divergence - for example, changes written to a database in the 1–2 hours before the cutover might not make it to the new server. This risk is specifically discussed with you when you select the migration method.

Q7. Should I make a backup before migration?

Snapshot billing will be disabled for the entire migration period - you can create backups free of charge during this time.

If our team is performing the migration, we create a backup before starting work. You're also welcome to make your own additional copy and store it somewhere safe - consider it extra insurance.

Q8. Will my IP address change after migration?

We take care of the necessary network-side configurations to minimize any impact on your websites and services.

If you'd actually prefer to change your IP address, just let us know in the ticket beforehand.

Q9. What happens if something goes wrong during migration?

If any technical issues arise during the migration, our top priority is to keep your project up and running.

In that case, we roll back to a stable state on the old platform, then work through next steps together with you and our technical team - whether that means adjustments, a different migration scenario, or additional preparation on either side.

Q10. How long will my VM migration take?

Migration time depends on the data volume, project architecture, and chosen transfer scenario - typically between 30 minutes and 2 hours.

Before work begins, our team will assess your setup during the ticket coordination phase and give you an estimated timeframe.

Things may shift slightly in either direction, but we'll keep you informed throughout the process.

Q11. Can I test the new platform before migrating?

Contact support and request a free trial period: we'll set up a temporary project where you can build and test the infrastructure you need.