Migration team hosting built for the week you move fifty sites.
Managing sites steadily and onboarding forty of them in a fortnight are different problems. This page is about the second one.
What a migration week actually needs.
Not more dashboard features. Somewhere to put sites before they go live, and a way to hand them over afterwards.
Sites live before DNS does
Each migrated site runs on its own free address, so it can be tested properly while the customer's domain still points at the old host.
Cutovers on your schedule
DNS moves when you say, not when the copy finishes. A batch of migrations can be staged over days and switched over in whatever order suits the clients.
Handover without a second migration
A finished site transfers to the client's own account with its files, database and domains intact, so the last step is not repeating the first.
Clone to try the risky one twice
A migration that goes wrong is cheaper to redo than to debug. Cloning a site gives you a second attempt without touching the first.
Per-site resources, not a shared pool
Twenty migrations running at once do not compete for one account's limits, because each site has its own container and its own ceiling.
Verify first, switch second, hand over third.
Every painful migration week has the same shape: sites going live before anyone checked them, because the DNS change and the copy happened at the same moment.
- Every site reachable and testable before DNS moves
- Cutovers scheduled per client, not per batch
- Failed attempts retried on a clone
- Finished sites transferred to the client's account
The bottleneck is review, not copying.
Moving files is the fast part. What sets the pace of a migration week is how quickly each site can be checked, and that depends on being able to see it before it is live.
What we set up for teams onboarding in bulk
These are the things that decide whether a migration week is calm or not.
| Setting | What we do | Why |
|---|---|---|
| Pre-DNS addresses | Every site reachable on its own free domain before any record changes | Testing a migration only after DNS has moved means the first person to find a problem is the client, and rolling back is a DNS change with its own propagation delay. |
| Cutover scheduling | DNS moved per site, at a time each client agrees to | A batch cutover picks one moment for everybody, which is fine for the team and wrong for the client whose busiest hours it lands in. |
| Retry strategy | A clone for a second attempt rather than repairing a half-finished migration | Debugging a partial import usually costs more than redoing it cleanly, and a clone means the failed attempt can be kept for comparison rather than overwritten. |
| Ownership handover | Sites transferred to the client's own account with files, database and domains intact | The alternative is migrating each site twice — once to onboard it and again to move it out of the agency's account — which doubles the risk for no benefit. |
| Resource isolation | Per-site containers rather than one shared account pool | Bulk onboarding runs many imports at once, and on a shared pool those compete with the live sites already on it. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Can I test a migrated site before moving DNS?
Do all the sites have to go live at once?
What happens when a migration goes wrong?
Can I hand a finished site to the client afterwards?
Will twenty migrations at once slow down the live sites?
Onboard the batch without the bad week.
Free migrations, every site testable before DNS moves, and a clean handover when it is done.