УКР Choose a server

Choosing a server and migrating

Checklist for moving from a Ukrainian data centre or office to Europe

Updated 12 min read Читати українською

Contents

For administrators and managers of companies moving accounting, files, mail or websites from a Ukrainian data centre or office server room to rented dedicated servers in Europe. The result is a two-week plan: what to do beforehand, on moving day, and how to go back if something goes wrong.

Who this is for and why#

We rent out servers and do not house customers’ equipment, so a move means copying data over the network, not transporting servers. Software licences are not covered here.

Our own data centre in Ukraine was destroyed by a strike on 23 September 2026 (our story). Our advice from experience: do not put it off. A planned move can be spread over two weeks and checked step by step; an emergency one is done from whatever survived in backups.

What you need#

  • Administrator rights on the old servers and access to your domain’s DNS zone.
  • A person in charge of the move and an agreed downtime window — an evening or a day off.
  • A fresh backup of the old site, already test-restored.

Migration schedule#

WhenWhat to doOutcome
Two weeks beforeInventory; choice of line, configuration and country; request for serversTable of systems, invoice, window date
One week beforeServer setup and hardening, VPN; lower TTL; new addresses to banks and partners; preliminary sync; backups; trial loginNew servers with a copy of the data, checked by users
Moving dayServices stopped on the old site; final delta of files and databases; checks; DNS switch; “stay or roll back” decisionWork on the new servers
AfterwardsA week or two of observation; usual TTL restored; trial restore from the new backup; data wiped from the old disksOld site decommissioned

Steps#

1. Inventory of systems and dependencies#

Record every system in a table: server, OS and software versions, data volume, who uses it, what it exchanges data with. The servers show what listens on the network and what runs on a schedule:

# Linux
sudo ss -tulpn
systemctl list-units --type=service --state=running
systemctl list-timers
sudo ls -R /etc/cron.d /var/spool/cron
# Windows Server (PowerShell)
Get-NetTCPConnection -State Listen
Get-ScheduledTask | Where-Object State -ne 'Disabled'
Get-SmbShare

List separately what people remember last: TLS certificates, electronic signature keys, USB keys in the old server, printers and scanners, exchange with the bank and cash registers.

2. Servers, country, order#

From the inventory, choose the line and configuration and the country. For production systems we recommend the Standard or Business lines.

Apply at least a week before the window: we get in touch within a working day and invoice in hryvnia (payment); a server from stock is delivered within 12 or within 72 hours of payment, and login details go to the contacts in the request. State the OS in the request comment (it is installed before delivery) and, for Linux, your public SSH key: it is added to the sudo user at once. More: from request to access.

3. Network plan: the addresses will change#

The new servers will have different addresses: IPv4 and an IPv6 /64 block (/56 on Power and Ultra, a single address on Lite). Additional IPv4 addresses are ordered through support: up to 256 per server, 128 on Lite. Find everything that refers to the old ones in advance.

  • DNS. Lower the TTL of the records you will change (A, AAAA, MX) to 300 seconds — then the change spreads within minutes. Do it at least one old TTL before the switch: if it was 86400 seconds, a day before.
  • Allowlists. Banks (online banking, APIs), payment services and partners that accept connections only from known addresses. Send them the new addresses and ask them to keep both during the move.
  • VPN and settings. Peer addresses in tunnels, rules on the office router, users’ .rdp files, database connection strings, the hosts file.
  • Mail. If mail is sent from your server, update the SPF record (ip4:203.0.113.10 is an example) and the reverse DNS record: it must match the mail server’s name. Support sets the reverse record on request once the name’s forward record points to the new address.

Current records and TTL (the second field in the answer line, in seconds):

dig +short NS example.com
dig +noall +answer @ns1.example.com example.com A
dig +noall +answer example.com MX
dig +noall +answer example.com TXT
dig +short -x 203.0.113.10

Replace ns1.example.com with a name server from the first command: it shows the full TTL, not what is left in a cache.

4. VPN and private network#

Do not open RDP, SMB or database ports to the internet even “just for the move”: shared folders are copied and users work through a VPN — see WireGuard between office and server and secure RDP. Link several servers with a private network: it is a separate interface without a public address, support joins the servers into it (ask in the request comment), and you choose the private addresses. The Lite and Turbo lines have no private network.

5. Data transfer: preliminary sync and final delta#

Copy the bulk of the data beforehand, while everyone is working; in the window transfer only what has changed.

Warning. The --delete (rsync) and /MIR (robocopy) options delete everything at the destination that is absent from the source: a wrong direction or path destroys data. First run the same command with -n -i (rsync) or /L (robocopy) added — it only shows what would be done. Deleted data comes back only from a backup.

Linux: rsync

The rsync package is needed on both servers. rsync preserves file owners only when it runs as root on the new server. That takes the --rsync-path option and a temporary rule there: the line admin ALL=(root) NOPASSWD: /usr/bin/rsync, added with sudo visudo -f /etc/sudoers.d/migration, where admin is your sudo user. The rule in effect gives that user root rights, so delete the file after the move. The SSH key must belong to the user who runs the command — here, root.

# on the old server; preliminary sync: can be repeated
sudo rsync -aHAX --numeric-ids --partial --info=progress2 \
  --rsync-path="sudo rsync" /srv/data/ admin@203.0.113.10:/srv/data/

# final delta after the services are stopped
sudo rsync -aHAX --numeric-ids --partial --info=progress2 --delete \
  --rsync-path="sudo rsync" /srv/data/ admin@203.0.113.10:/srv/data/

A trailing slash on the source path means “the contents of the directory”. Run a long copy inside tmux.

Windows: robocopy

robocopy D:\Shares \\10.10.0.2\Shares /E /SEC /DCOPY:DAT /Z /R:2 /W:5 /MT:16 /XJ /NP /LOG:C:\Logs\presync.log
robocopy D:\Shares \\10.10.0.2\Shares /MIR /SEC /DCOPY:DAT /Z /R:2 /W:5 /MT:16 /XJ /NP /LOG:C:\Logs\final.log

Run both commands as administrator: the first beforehand, the second in the window. 10.10.0.2 is an example address of the new server in the VPN, Shares is a shared folder on it; the C:\Logs directory must exist. An exit code below 8 means no failures. Copying access rights (/SEC) makes sense if both servers are in the same domain.

Databases

The files of a running DBMS are not copied “as is”: a database is moved as a dump or a backup. The DBMS version on the new server must not be lower than on the old one.

# PostgreSQL, old server (as the postgres user)
pg_dumpall --globals-only -f globals.sql
pg_dump -Fc -f appdb.dump appdb

# PostgreSQL, new server, after both files are copied
psql -d postgres -f globals.sql
pg_restore -C -d postgres -j 4 appdb.dump

globals.sql holds the roles’ password hashes — do not leave the file in a world-readable directory.

-- MS SQL Server, old server
BACKUP DATABASE [AppDB] TO DISK = N'D:\Backup\AppDB_move.bak'
  WITH COPY_ONLY, CHECKSUM, STATS = 10;
RESTORE VERIFYONLY FROM DISK = N'D:\Backup\AppDB_move.bak' WITH CHECKSUM;

For restoring MS SQL Server and moving BAS databases, see database backups and moving an accounting database.

6. How long the data transfer will take#

Estimate: hours ≈ volume in GB × 2.22 ÷ speed in Mbit/s. Take the speed from a trial copy of a large file: usually the old site’s uplink limits it. Example: 500 GB at 70 Mbit/s takes about 16 hours; 5 GB of daily changes, about 10 minutes. Small files copy more slowly.

7. Cutover and rollback plan#

  1. Warn the users, end their sessions, stop application and database services on the old site. Do not delete anything there.
  2. Transfer the final delta of files and the database dumps, restore the databases on the new servers.
  3. Check the new servers against the list in “How to check the result” — before changing DNS, through the VPN.
  4. Change the DNS records, the addresses in the VPN and in users’ shortcuts.
  5. Let the test group in, then everyone.

Write down the rollback plan before you start: who decides whether to go back and by what hour, and what it takes — reverting the DNS records and starting the services on the old site. A lossless rollback is possible until data entry begins on the new servers, so decide before you let everyone in.

8. Backups from day one#

Backups must be running before the users arrive. A server comes with backup space on separate storage: 500 GB on the Standard, Business, Power and Ultra lines, 100 GB on Classic, none on Lite; for Turbo see the server card. You set up the copying; support sends the connection parameters and opens access from your servers’ addresses. Keep one more copy outside the server and the storage, following the 3-2-1 rule. Keep the old backups until you have restored something from the new ones.

9. Decommissioning the old site#

For a week or two keep the old servers closed to users but intact, in case you need to roll back. Then wipe the data from the disks: ordinary file deletion and quick formatting do not destroy it.

Warning. The commands below irreversibly destroy all data on a disk. Check the disk name twice and make sure the new servers work and the backups restore.

lsblk -o NAME,SIZE,TYPE,MODEL,SERIAL,MOUNTPOINT
# HDD: one pass of random data, then zeros
sudo shred -v -n 1 -z /dev/sdX
# NVMe: built-in erase (the nvme-cli package)
sudo nvme format /dev/nvmeXn1 --ses=1

On Windows, a non-system disk is wiped with diskpart: list disk, select disk N, clean all. Wipe the system disk after booting from external media. On an SSD, overwriting does not reach every cell — use the drive’s built-in erase. Wipe disks behind a RAID controller with its own tools, and physically destroy faulty ones.

How to check the result#

  • DNS returns the new addresses and the new reverse record.
  • Running rsync with -n -i or robocopy with /L again shows no differences.
  • The accounting system has the last documents entered before the stop, and a control report matches the old one.
  • Users log in through the VPN from the office and from home; the response time is as expected (how to measure it).
  • Exchange with the bank and printing work; a message to an external mailbox does not land in spam.
  • A backup exists at the new location, and a file and a database were restored from it.

Common mistakes#

  • The TTL was lowered on moving day: some users reach the old address for another day.
  • Allowlists were forgotten: online banking or a partner’s API refuses connections from the new address.
  • The final delta was run without stopping the services: some changes stayed on the old server.

What next#