Large accounts — multi-gigabyte file stores, big databases, media-heavy sites — migrate perfectly well, they just need more time and occasionally a higher time ceiling. This article sets expectations and shows how to avoid the one common pitfall: a premature timeout.
What ‘large’ means here
Anything from a few gigabytes upward. Think WooCommerce stores with big media libraries, image galleries, or sites with years of uploads. The migration handles them; it just takes proportionally longer to back up and transfer.
The per-account time ceiling
Each account has a maximum time it’s allowed to spend migrating, to stop a genuinely broken job from running forever. For most accounts the default is plenty. For a very large account, the backup-and-transfer can bump against it — which shows up as a failure.
Best practices for large migrations
- Tell us in advance if an account is very large, so we set a generous ceiling
- Run large migrations when your site is least busy, easing load on the old host
- Be patient through the backup stage — it’s the longest part
- Don’t repeatedly cancel and restart — let each attempt run
If a large account times out
If you see a failure that points to the backup not finishing in time, that’s the ceiling. Ask us to raise it and retry — the account will then migrate fully. See the ‘source pull failed’ article for the related timing case.
Why large accounts need special thought
Most migrations are small enough that defaults handle them invisibly. Large accounts — multi-gigabyte media libraries, big databases, years of uploads — push against time limits simply because backing up and transferring more data takes longer. None of this is a barrier; it just means planning for time and, occasionally, a raised ceiling.
The per-account time ceiling explained
Each account is allowed a maximum migration duration so that a genuinely broken job can’t run forever. For ordinary accounts the default is generous. For a very large account, the legitimate backup-and-transfer time can approach or exceed that default, which surfaces as a timeout-style failure. The remedy is simply to raise the ceiling for that migration so the large but healthy job has room to finish.
Best practices for big migrations
- Tell us in advance that an account is large so we set a generous ceiling up front
- Run the migration during the old host’s quiet hours to ease backup load
- Be patient through the backup stage — it’s the longest part for big accounts
- Avoid cancelling and restarting repeatedly; let each attempt complete
- For active stores, take a short maintenance window for the final run
Splitting an enormous account
Occasionally an account is so large that migrating it whole is impractical. In those cases we can take a staged approach — for example, moving the bulk of static files first and syncing the most recent changes close to cutover, or handling an oversized database separately. This is a hands-on, case-by-case process; open a ticket and we’ll design the right approach for your specific account.
Verifying a large migration
After a big account migrates, spend a little extra time on verification: spot-check large media folders actually arrived, confirm big databases restored fully (compare a table row count if you can), and load the heaviest pages. The post-migration checklist applies; just give it the thoroughness a large account deserves before cutover.
Letting us run it
For the largest or most complex accounts, the simplest path is to let our team run the migration directly with tuned settings and direct monitoring. Open a ticket with the account details and rough size, and we’ll handle the heavy lifting and confirm when it’s ready to cut over.
Setting expectations for big moves
Large accounts migrate perfectly well; they simply need more time and occasionally a raised time ceiling. Backing up and transferring more data inherently takes longer, and that’s the only real difference from a small migration. Approaching a large move with that expectation — planning for time rather than expecting instant completion — makes it straightforward rather than stressful.
The time ceiling, and why it’s there
Each account has a maximum migration duration so a genuinely broken job can’t run indefinitely. For ordinary accounts the default is generous and never an issue. For a very large account, the legitimate backup-and-transfer time can approach or exceed that default, surfacing as a timeout-style failure. The remedy is simply raising the ceiling for that migration — telling the system ‘this big-but-healthy job needs more time’ — after which it completes fully.
Best practices for large migrations
- Tell us in advance that an account is large, so we set a generous ceiling up front
- Run during the old host’s quiet hours to ease backup load
- Be patient through the backup stage — it’s the longest part for big accounts
- Avoid repeatedly cancelling and restarting; let each attempt complete
- For active stores, take a short maintenance window for the final run
Staging an enormous account
Occasionally an account is so large that migrating it as one piece is impractical. In those cases we take a staged approach — for example moving the bulk of static files first, then syncing the most recent changes close to cutover, or handling an oversized database as a separate step. This is hands-on and case-by-case; open a ticket and we’ll design the right approach for your specific account and confirm it with you before running.
Verifying a large migration thoroughly
Give a big migration the verification it deserves: spot-check that large media folders actually arrived, confirm big databases restored fully (comparing a table’s row count between old and new is a quick sanity check), and load your heaviest pages. The standard post-migration checklist applies — just bring extra thoroughness given the volume of data involved — all before you cut over, while the old site is still live.
What’s next
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!
