“The server contract is up for renewal,” “the site is slow,” “support is ending”—the triggers for considering a server migration vary, but the migration work itself is a task that will reliably turn into an incident if you get the steps wrong. This article explains the standard migration steps, typical costs, and the planning that minimizes downtime.
The standard migration procedure (6 steps)
- Survey the current state — Inventory the current server’s PHP/DB versions, disk usage, and the sites, email, cron jobs, and SSL certificates that are running. Gaps here are the single biggest cause of incidents
- Choose the destination — Based on the current load and future growth, decide whether to stay on shared hosting or move to a VPS/cloud
- Build the new environment and copy the data — Move files and the database to the new server. At this point the old server is still live in production
- Verify operation — Validate the new environment against the production domain, for example by editing the hosts file. Always test form submission, payments, and email delivery
- Switch DNS — Shorten the TTL in advance to speed up propagation after cutover
- Parallel monitoring and decommissioning the old environment — Keep the old server for one to two weeks after cutover, and cancel it once you confirm there are no problems
Typical costs
| Case | Typical cost (labor) |
|---|---|
| Migrating a single WordPress site between servers of the same type | ¥50,000–150,000 |
| Multiple sites plus email migration | ¥150,000–400,000 |
| Shared hosting → cloud such as AWS (including architecture design) | ¥300,000–1,000,000 |
| Server migration of a business system (including DB migration and a staging environment) | ¥500,000+ |
The range in price is determined almost entirely by “whether email is involved,” “the scope of verification,” and “whether a rollback plan is designed.” For a cheap estimate, check whether one of these has been left out.
Three ways to minimize downtime
- Shorten the DNS TTL one week before cutover — If the TTL is left at one day, traffic can keep flowing to the old server for up to a day after cutover
- Handle the database in two stages: a pre-copy plus a last-minute diff — Copying the entire dataset on cutover day means updates are frozen for the whole duration
- Write the rollback procedure first — “Point DNS back if there’s a problem” alone loses any data written after cutover. Decide in advance up to which point you can safely roll back
Points where it tends to go wrong
Overlooking email
Absorbed in the website migration, you find the email addresses that were running on the same server go dead on cutover day—the most common incident. Always plan the migration of MX records and mailboxes as a separate task.
The SSL certificate gap
In some cases a certificate can only be issued on the new server after the DNS switch, which can produce a warning display lasting anywhere from a few minutes to several tens of minutes. Using a method that allows pre-issuance (DNS validation) eliminates the gap.
Display breakage from PHP/DB version differences
If the old server’s PHP is old, plugins and themes may throw errors on the new server’s newer PHP. Plan a version upgrade that coincides with the migration with the verification effort built in.
Summary | A migration is not “work,” it’s “planning”
The technical work of a server migration is fairly routine, but what decides success or failure is the inventory and the cutover design. At SHANNON, we take on the whole flow from the initial survey through migration planning, execution, and post-cutover monitoring under one roof. A good place to start is our free server assessment, which makes your current configuration and the difficulty of the migration visible.