The honest answer is: it depends on how much data you have. A small brochure site migrates in minutes; a multi-gigabyte store with large databases takes longer. This article gives realistic expectations and explains what drives the timing.
The stages that take time
Two stages dominate the clock: building the backup on your old host, and transferring it to iWebVault. The restore and verification steps are usually quick by comparison.
Rough estimates by size
- Small site (under 500 MB): a few minutes
- Medium site (500 MB – 2 GB): roughly 10–20 minutes
- Large site (2 GB – 10 GB): 20–60 minutes
- Very large account (10 GB+): an hour or more, sometimes several
Why big accounts take their time
The system waits for your backup to be genuinely complete before transferring it — it checks that the backup file has reached a sensible size and stopped growing. This deliberate patience is what prevents half-finished backups from being restored, which would corrupt your site. For a large account, that waiting is normal and healthy.
Bulk reseller jobs
A reseller migration moves accounts one at a time, so total time is the sum of each account’s migration. Dozens of accounts can take several hours overall — by design, so neither server is overloaded.
What actually drives the speed
Three things determine how long your migration takes. First, the total size of your account — more data means a longer backup and transfer. Second, your old host’s performance — a busy or throttled server builds backups slowly. Third, the network path between the two servers — this affects transfer speed. iWebVault’s side is fast; the variable is usually the old host.
Why the backup stage dominates
For most migrations, building the backup on the old host is the longest single stage. The system deliberately waits for that backup to be fully written and to stop growing before it transfers anything — this is what guarantees you never restore a half-finished, corrupt backup. On a large account, a long pause at this stage is the system being careful, not stuck.
Planning around the estimate
If you have a small site, you can comfortably migrate and cut over in a single sitting. For a large account, plan for the migration to run in the background while you do other things, and schedule your DNS cutover for after it completes. Never feel you have to watch the progress bar — it advances on its own and notifies you when done.
Setting expectations with clients
If you’re a developer or reseller moving client sites, give clients a window rather than a precise minute. ‘Your site will be fully moved within the hour, with no downtime, and we’ll confirm when it’s live’ sets the right expectation. The zero-downtime approach means the actual duration rarely matters to them — their site stays up the whole time.
Worked examples
A few realistic scenarios help calibrate expectations. A small business brochure site of perhaps 200 MB typically migrates in a handful of minutes start to finish. A medium WordPress blog with a few years of images, around 1.5 GB, might take fifteen to twenty minutes. A busy WooCommerce store at 6 GB with a sizeable database could run forty-five minutes to an hour. A 12 GB media-heavy account can take well over an hour. These are illustrative — your old host’s speed shifts them up or down.
Why your old host is the main variable
iWebVault’s side of the migration is consistently fast. The biggest swing factor is how quickly your old host builds the backup, which depends on its hardware, its current load, and any throttling it applies. A backup that takes five minutes on a fast, quiet server might take twenty on a busy budget one. This is why two accounts of identical size can migrate in noticeably different times.
Planning a reseller fleet’s timing
For a reseller migrating many accounts sequentially, estimate total time by summing the individual account times. Twenty accounts averaging fifteen minutes each is roughly five hours — comfortably an overnight job. Because it runs unattended, you start it before you finish for the day and review the completion summary the next morning. There’s no need to watch it.
Managing expectations, not the clock
The single most useful mindset for migration timing is to plan around completion, not to watch progress. Start the migration, let it run in the background, and schedule your verification and DNS cutover for after it finishes. Because your live site is unaffected throughout, the exact duration rarely matters — what matters is that you cut over only once everything’s confirmed ready.
Key takeaways
Small sites migrate in minutes; medium sites in fifteen to twenty; large accounts in tens of minutes to over an hour; very large accounts longer still. The biggest variable is your old host’s backup speed, not iWebVault. Plan around completion rather than watching the progress bar — the migration runs in the background and notifies you when done, and your live site is unaffected throughout.
Can I speed up a slow migration?
The backup stage speed is largely set by your old host, so there’s little to push there. What you can do is run the migration during the old host’s quiet hours (less competition for its resources) and, for large accounts, ensure the time ceiling is generous so the job isn’t cut short. Otherwise, patience through the backup stage is the right approach.
What’s next
- Migrating Very Large Accounts
- Migration Backup Seems Stuck
- Why Bulk Migration Runs One Account at a Time
Still stuck? Our team can run or finish the migration for you — open a support ticket and we’ll take it from there.
Was this helpful?
Thanks for your feedback!
