Skip to content
Kite Hosting

Hosting migration planner

Plan a server move that survives contact with the calendar: enter the sites, the method and the hours you can give, and get the effort band, the working days, the cutover freezes, and a calendar with the DNS lead and the propagation tail built in.

A migration fails on the calendar, not the copy: the DNS record nobody lowered, the tail where both servers had to stay paid, the set of sites planned at zero hours a day. Enter the sites and your daily hours, and the planner returns the effort band, the working days, the cutover freeze and the order of work.

A floor plan with furniture sliding along dotted arrows into a smaller room, the leading arrow in vermilion.

By Sam Moreton

Researched

Calculator

Every site that has to move, including the quiet ones.

Everyone helping, combined. Four hands for three hours is six.

Migrate one site first, time it end to end, and enter the number: your measurement replaces every planning band below.

Assumptions

  • Automated plugin migration: 0.5-1.5 working hours per site, covering setup, the run and the checks afterwards.
  • Manual migration: 2-5 working hours per site, covering files, database, URL search-replace and checks.
  • Standard complexity (media-heavy sites, busier databases, routine plugins) adds 0.5-1.5 working hours per site.
  • Complex migrations (multi-GB databases, email still on the old server, cron jobs, staging sites, WooCommerce order history) add 2-6 working hours per site.
  • Cutover: 15-60 minutes of content freeze per site, scheduled when the fewest people are editing.
  • The DNS TTL on every domain is lowered to 300 seconds at least 24 hours before the first cutover, so the switch is not stuck behind an old record.
  • Both servers stay live and paid for 24-48 hours after the last cutover while DNS tails off; roll back means pointing DNS back.

Formula vv0.1 / last reviewed 2026-10-10

Migrations are planned in hours and lost in calendars. The copy is the easy part. The failures are scheduling failures: the DNS record nobody lowered until the night before, the fortnight where both servers had to stay live and paid, the old plan cancelled while cached records were still sending visitors to it. This planner takes the sites and the hours you can actually give and returns a calendar with those days already in it.

Who this is for

Anyone moving a set of WordPress sites between servers: an agency relocating a client roster, a developer consolidating scattered hosting onto one platform, a site owner escaping a renewal price. The more sites in the set, the more the calendar part matters.

How to read the result

The planner prices each site from the band for your chosen method, plugin or manual, adds the complexity adder, and divides the total by the hours per day you can give it. Working days round up, because a plan rounded down is a plan that quietly drops work. On top of the working days comes the calendar: lower every domain's DNS TTL the day before the first cutover, and keep both servers live for a day or two after the last while records finish propagating. The result names the freeze window per cutover and the order of work, so batch the freezes outside editing hours and nobody loses an afternoon's edits.

The one input worth earning

Bands are guesses; a timed site is data. Migrate the smallest site first, time it end to end, and enter the figure as the measured hours per site. Your number replaces every planning band wholesale, because a real timed site already carries its own complexity. That is the difference between an estimate you can defend in a meeting and one you are still hoping holds.

When to trust it, and when to get help

Trust the schedule for ordinary WordPress sites moving to a platform with a working migrator. Get a human involved when the set includes WooCommerce with live order history, email still hosted on the old server, or multi-gigabyte databases; that is what the complex setting prices. If the destination is Cloudways, their engineers migrate the first site free, which is worth knowing before you plan a week of manual copying.

Where to go next

The step-by-step guide to migrating WordPress to Cloudways covers the doing: plugin settings and the checks per site. Once the sites have landed, the WordPress capacity estimator says how many more the new box can take, and the Cloudways review describes what living on the destination platform is like.

FAQ

Where do the hour figures come from?

They are planning bands, stated on the page and in the result, and no figure here pretends to have been timed on your sites. That is why the planner accepts a measured input: migrate one site, time it end to end, enter the number, and the bands are replaced wholesale by your own data.

Why does the calendar include days when nothing is being copied?

Because migrations fail on the calendar more often than on the copy. The DNS lead exists so the switch is not stuck behind an old TTL, and the tail exists because cached records keep sending visitors to the old server for up to two days after the last cutover. Both servers stay live and paid through that window, and roll back means pointing DNS back.

What sets the freeze window?

The cutover freeze is the window where the site stops accepting edits while the final data is synced and DNS is switched: 15-60 minutes per site in the plan. Batch cutovers outside editing hours and the freeze costs nobody their work.