Cloud & DevOps
Server migration: move your services to a new machine without losing anything
A server migration means transferring every service hosted on a machine (websites, databases, email, scheduled tasks, certificates, configuration) to a new dedicated server or VPS. It is usually triggered by an end-of-life OS, an undersized machine, a change of provider or a security requirement.
This service is for SMEs, agencies and software publishers running one or more servers, with or without a control panel (Plesk, cPanel, ISPConfig), who lack the in-house resources to carry out the operation safely. A server accumulates years of implicit settings, which is exactly what makes the exercise delicate.
We inventory every service, rebuild the target environment on a supported OS version, transfer data using rsync and consistent dumps, then switch traffic after full testing. The old server stays available until everything is confirmed working.
When do we step in?
End-of-life operating system
Your server runs an end-of-life Debian, Ubuntu or CentOS release and no longer receives security patches. Since an in-place upgrade is risky, migrating to a fresh machine on a supported OS is often the safest route.
Saturated or ageing server
Constant CPU load, full disks, insufficient memory or old hardware: the server can no longer keep up with the growth of the sites and applications it hosts.
Changing provider
You are leaving a host for OVH, Hetzner, Scaleway, AWS or another provider, for reasons of cost, data location or service quality.
Plesk or cPanel migration
Your sites are managed through a control panel. Subscriptions, domains, mailboxes, databases and certificates must be transferred using the native migration tools, or rebuilt manually when versions are incompatible.
Consolidation or split
Consolidating several small servers onto one more powerful machine, or conversely isolating a database or a critical application on its own dedicated server.
How we work
- 1
Source server inventory
Listing sites, databases, PHP, Node.js or Java versions, cron jobs, system services, open ports, certificates, firewall rules and external dependencies. We also document the implicit settings that appear in no documentation.
- 2
Target server design
Choosing the OS and sizing, installing the same software versions or newer compatible ones, baseline hardening (key-based SSH, fail2ban, firewall), and setting up backups from day one.
- 3
Initial data transfer
Copying files with rsync, exporting databases with consistent dumps or temporary replication, transferring mailboxes with imapsync where needed. This first pass has no impact on production.
- 4
Full acceptance testing
Every site and service is tested on the target server through the hosts file: pages, forms, checkout, email sending, scheduled tasks, performance. Any discrepancies are fixed before cutover.
- 5
Controlled cutover
DNS TTLs lowered in advance, write freeze, final delta sync with rsync and a last dump, DNS records or failover IP switched, then log monitoring during the first hours.
- 6
Decommissioning
The old server is kept read-only during a safety period, then its data is archived and the machine cancelled. We deliver up-to-date documentation of the new setup.
Technologies we use
- Debian and Ubuntu
- rsync and SSH
- Plesk and cPanel
- Nginx and Apache
- MySQL, MariaDB and PostgreSQL
- imapsync
- Let's Encrypt
- OVH, Hetzner, Scaleway and AWS
- fail2ban and nftables
- Docker
Related expertise
Why choose Agencei?
Exhaustive inventory before any action
Most failed migrations fail because of a forgotten service: a cron job, a certificate, a webhook. We start from the processes actually running on the machine, not just the documentation.
Reversible cutover
The old server remains intact and reachable until the migration is validated. If anything goes wrong, rolling back simply means pointing DNS or the failover IP back to the original machine.
Upgrade rather than identical copy
We use the migration as an opportunity to move to supported versions of PHP, Node.js or the database, after testing application compatibility beforehand.
Secured from installation
The target server is delivered hardened: key-based authentication, restrictive firewall, automatic security updates and off-site backups configured.
In brief
- What is this service?
- Server migration is the complete transfer of websites, databases, email, scheduled tasks and configuration from a dedicated server or VPS to a new machine, with or without a Plesk or cPanel control panel.
- Who is it for?
- SMEs, agencies and software publishers running a server that is end-of-life, saturated or hosted with a provider they want to leave, without an in-house systems team.
- What problem does it solve?
- Preventing data loss, forgotten services, extended outages and application regressions when changing server or upgrading the OS.
- How long does it usually take?
- Typically a few days for a simple VPS, several weeks for a server hosting many sites, mailboxes and heterogeneous applications. The final cutover often takes only a few minutes.
- What factors influence the price?
- The number of sites and services, data and email volume, the presence of a control panel, the version gap between source and target, and availability requirements.
- How does the engagement run?
- Exhaustive inventory, building and hardening the target server, initial transfer with rsync and dumps, full testing via the hosts file, DNS cutover after a delta sync, then decommissioning.
- What are the risks?
- A forgotten service or cron job, PHP or database version incompatibility, DNS or SPF records not updated, and data written to the old server after cutover if writes are not frozen.
- What alternatives exist?
- In-place OS upgrade, progressive containerisation of applications on the existing server, or migration to a managed platform that removes server management altogether.
Frequently asked questions
Should I migrate or upgrade the OS in place?
In-place upgrades are possible on some distributions, but they can leave obsolete packages behind and make rollback difficult. Migrating to a fresh machine on a supported OS gives you a clean environment and a simple fallback: the old server stays available.
How long does a server migration take?
It depends on the number of services and the data volume. A VPS hosting a few sites is usually migrated within days, while a Plesk server with dozens of subscriptions and email can require several weeks of preparation. The cutover itself is often a matter of minutes.
Are mailboxes transferred?
Yes. We transfer accounts and their contents using Plesk or cPanel native tools, or imapsync when migrating between different systems. MX, SPF, DKIM and DMARC records are reproduced or updated.
Can the IP address change without impact?
Yes, provided DNS TTLs are lowered a few days ahead and every reference to the old IP is updated (A records, SPF, partner allowlists). With some providers, a failover IP even lets you keep the same address.
What if an application is not compatible with the new versions?
We detect this during acceptance testing, before cutover. Depending on the case, we fix the application, install the required software version alongside, or isolate the application in a Docker container with its own version.
Related services
Website Migration
We move your website (host, domain, HTTPS, CMS) with no downtime and no lost Google rankings.
See this serviceCloud Migration
Migration of applications and infrastructure to the public cloud, from lift-and-shift to re-architecture.
See this serviceIT Maintenance
Monitoring, updates, backups and continuous improvement of your applications in production.
See this serviceSecurity
Hacked site cleanup, hardening, vulnerability assessment, WAF, backups and access management.
See this serviceData migration
Migration between databases, engines, versions or systems, with ETL, validation and zero-downtime cutover.
See this serviceCommon problems
Tell us about your project
Describe your need in a few lines: we come back to you with a first analysis and the next steps.