How We Moved 200 Client Accounts Between Reseller Servers in a Weekend With Zero Tickets
We moved 200 client reseller accounts from an aging reseller server to a new one over a single weekend, and the migration closed with zero migration-related support tickets. That is not a marketing number.
It came from roughly 1.4 terabytes of data across 220 websites, 350 databases, and 1,800 email accounts, all verified individually before a single DNS record pointed anywhere new. This post walks through exactly how we planned, executed, and verified that migration, and what any reseller running a similar move can take directly from it.
How Did We Plan a 200-Account Reseller Server Migration?
We planned this migration as a project with a fixed weekend timeline, starting from a complete inventory of every account’s websites, databases, email, and DNS dependencies, and we built a rollback plan before touching a single live account.
Defining the migration scope and weekend timeline
We set the migration window to Saturday through Sunday specifically because that is when the accounts on this reseller server saw the lowest traffic. Total migration time came in at roughly 18 hours across the two days, which sounds tight for 200 accounts until you break it into batches rather than one continuous push.
A fixed window also forces discipline. Knowing the migration has to close by Sunday night means every task earlier in the week gets treated as a hard prerequisite instead of something to get to eventually.
Building a complete inventory of client accounts
Before moving anything, we built a full inventory of all 200 accounts on the source server: account size, primary domain, any addon domains, and which accounts belonged to which client. Average account size across the group came out to about 7 gigabytes, but that average hid a wide range.
The largest single account on the server was closer to 65 gigabytes, and an account that size needs a different migration plan than a typical 3 gigabyte site. Skipping this step and migrating in whatever order accounts happen to sit in WHM is how a migration ends up backing into surprises mid transfer instead of catching them ahead of time.
Identifying websites, databases, email accounts, and DNS dependencies
The inventory wasn’t just account sizes. We counted 220 websites, 350 databases, and roughly 1,800 individual email accounts spread across the 200 client accounts, along with about 270 domains and subdomains that each needed their own DNS entries to carry over correctly.
A database count higher than the account count is normal. Plenty of WordPress sites run more than one database for staging environments or plugin specific data, and missing even one of those during migration is exactly the kind of gap that turns into a support ticket a week later when a client notices a broken feature.
Checking storage and resource requirements before migration
We confirmed the destination reseller server had enough headroom for the full 1.4 terabytes of data before starting, with room left over for growth rather than migrating right up to the new server’s ceiling.
Reseller accounts with overselling enabled make this easier to plan around, since the destination pool doesn’t need to match the source server account for account. Checking this ahead of time also caught the handful of unusually large accounts early, including the 65 gigabyte outlier, so those got flagged for individual attention instead of being treated the same as a typical account.
Creating a rollback plan before moving the first account
Every account’s original files, databases, and DNS configuration stayed untouched on the source server throughout the entire migration. If anything had gone wrong with a specific account on the new server, reverting that one account back to the source was a DNS change, not a data recovery project.
We didn’t end up needing it for any of the 200 accounts, but having it in place changed how the whole team approached the migration. Nobody was rushing a step because reverting felt risky. The rollback plan removed that pressure before it could cause a mistake.
How Did We Prepare the Old and New Reseller Servers?
We fully provisioned and tested the destination reseller server, including PHP versions, databases, SSL, and required software, days before moving a single account, and we lowered DNS TTL values ahead of time so the eventual cutover would propagate fast.
Preparing the destination server and reseller environment
The new reseller server needed its WHM environment configured to match, and in several cases improve on, what the 200 accounts were running on the old server. Moving to NVMe drives on the new hardware was one of those improvements, not just a like for like swap.
That meant setting up the reseller packages, resource limits, and account creation templates before a single client account moved over, so every account landing on the new server dropped into an environment already built for it rather than getting configured account by account after arrival.
Verifying available storage and account capacity
With roughly 1.4 terabytes of data expected to land on the new server, we verified actual available storage against that number directly, not against the plan’s advertised capacity.
Advertised storage and comfortably usable storage are not always the same figure once overhead, backups, and normal operating headroom get factored in. We wanted enough room that the new server wasn’t sitting close to capacity the moment the migration finished, since a server that starts tight on day one only gets tighter as client sites keep growing.
Checking PHP versions, databases, SSL, and required software
We matched PHP versions across both servers for every account before migrating, since a site running on an older PHP version that lands on a server defaulting to something newer can break in ways that are hard to predict from a compatibility checklist alone. All 350 databases needed their engine versions confirmed compatible too.
SSL was a bigger checkpoint than usual here specifically because 195 of the 200 accounts had active SSL certificates, and a certificate that doesn’t carry over cleanly turns into an immediate browser warning the moment DNS points at the new server, which is one of the fastest ways to generate a client support ticket.
Preparing DNS and nameserver changes
Every one of the roughly 270 domains and subdomains in scope needed its DNS records mapped out before migration day, not figured out live during the cutover.
We prepared the exact DNS changes each domain would need in advance, so the actual cutover step was closer to executing a script than making live decisions under time pressure. Getting DNS wrong at this stage is one of the most common ways a migration turns into visible downtime, because a missed record doesn’t fail loudly. It just quietly points somewhere wrong until a client notices.
Lowering DNS TTL where appropriate before migration
We reduced TTL values on the domains involved in the days leading up to migration, which shortens how long DNS changes take to propagate once the actual cutover happens. Domains managed through CloudFlare made this step faster to execute consistently across the full domain list.
A high TTL left at its default setting can mean some visitors keep hitting the old server for hours after DNS technically changed, which is exactly the kind of inconsistent experience that generates confused support tickets even when nothing is actually broken. Lowering TTL ahead of time is a small step that’s easy to forget under migration pressure, and it was part of why customer visible downtime across the whole migration stayed in the zero to five minute range per account rather than stretching out.
Testing the migration process with a small group of accounts
Before touching all 200 accounts, we ran the full migration process, transfer, verification, and DNS cutover, against a small handful of low risk accounts first.
That test batch caught process level issues while the blast radius of a mistake was still five accounts instead of two hundred. Anything that went wrong in the test batch got fixed in the process itself before it had a chance to repeat across every remaining account.
How Did We Move 200 Client Accounts Without Major Downtime?
We moved the 200 accounts in controlled batches rather than all at once, kept the source server fully live throughout, and only pointed DNS at the new server for each account after that specific account was verified working.
Migrating accounts in controlled batches
We split the 200 accounts into batches rather than attempting one continuous transfer. Batching meant a problem discovered in an early batch could be fixed before it repeated across the remaining accounts, instead of discovering the same mistake 200 times over.
It also kept the migration team’s attention focused on a manageable number of accounts at once, which matters more than it sounds like it should when you’re personally verifying each one before moving to the next.
Prioritizing high-traffic and business-critical websites
Not every account carries the same stakes. We identified which of the 220 websites saw meaningful daily traffic or ran business-critical functions like ecommerce checkouts, and scheduled those earlier in the weekend window rather than later, when fatigue and time pressure are higher.
A quiet portfolio site going down for a few minutes is a non-event. An active online store doing the same is a very different conversation with a client, so the highest stakes accounts got the most attention and the most buffer time around their migration slot.
Keeping the source environment available during the transition
The old reseller server stayed fully live and untouched throughout the entire 18 hour migration window. Nothing was deleted or disabled on the source side until an account was confirmed working correctly on the new server.
This is what made the rollback plan real rather than theoretical, and it’s also what kept customer visible downtime as low as it was, since DNS only moved once there was somewhere fully working for it to point to.
Synchronizing recent changes before final cutover
Because the source server stayed live during migration, some accounts had new emails, new database entries, or updated files land after their initial copy to the new server but before DNS actually cut over.
We ran a final synchronization pass on each account immediately before its cutover to catch anything that changed in that gap. Skipping this step is one of the more common ways a migration technically succeeds but still loses a handful of emails or a few hours of database changes that a client notices days later.
Coordinating DNS changes after account verification
DNS only changed for an account after that specific account passed verification on the new server, never before. That ordering is what kept the 12 accounts that needed manual checks from becoming visible problems.
Those accounts got extra attention before their DNS moved, rather than getting migrated on the same schedule as everything else and dealt with after something broke. Sequencing verification before DNS, every single time, without exception, is arguably the single biggest reason this migration finished at zero support tickets.
How Did We Verify 200 Accounts After the Migration?
We individually checked website availability, database functionality, email routing, SSL, and DNS resolution for all 200 accounts, and out of that full set, 12 accounts needed manual follow up before we considered them fully migrated.
Checking website availability and HTTP responses
For each of the 220 websites, we checked that the site actually loaded and returned a proper HTTP response rather than just confirming files existed on the new server.
A file being present and a website actually rendering correctly are two different checks, and only one of them catches a broken database connection or a misconfigured path. Every site got checked directly in a browser, not just pinged programmatically, since a working status code doesn’t guarantee the page underneath it looks right to an actual visitor.
Verifying databases and dynamic website functionality
All 350 databases got checked for successful migration, but the more important check was whether the dynamic functionality depending on them actually worked.
A WordPress site can load its homepage even with a partially broken database connection, right up until someone tries to log into the admin area or submit a form. We tested login pages, contact forms, and any ecommerce checkout flows specifically, rather than assuming a loading homepage meant the whole site was healthy.
Testing email accounts and mail routing
With roughly 1,800 email accounts in scope, this was the single largest verification task by volume. We tested that mail was actually routing correctly rather than just confirming the accounts existed on the new server.
An email account that exists but is not receiving mail correctly is invisible until a client misses something important. Accounts running through MailChannels needed their spam filtering and routing rules confirmed specifically, and this is also where a handful of the 12 manual check accounts came from. Complex mail forwarding setups on a few accounts needed direct attention to carry over exactly as configured.
Confirming SSL certificates and HTTPS access
We confirmed all 195 SSL certificates in scope, issued through the SSL reseller program and third-party providers alike, were active and serving correctly over HTTPS on the new server before any DNS pointed there.
An expired or mismatched certificate throws an immediate, scary looking browser warning the second a visitor’s browser complains, and it’s one of the fastest ways to turn a technically successful migration into a flood of anxious client messages. Checking this before cutover, not after, is what kept it from becoming a problem at all.
Checking DNS records and nameserver resolution
For each of the roughly 270 domains and subdomains, we confirmed DNS was actually resolving to the new server correctly from multiple locations, not just from inside our own network where cached results can hide a real problem.
Nameserver resolution getting checked externally is what actually catches a propagation issue in progress, rather than assuming a DNS change worked just because it was submitted correctly on our end.
Monitoring migrated accounts for post-migration problems
We didn’t close the migration out the moment DNS finished propagating for the last account. Migrated accounts got monitored for issues in the days immediately following the weekend.
That ongoing check is how minor problems on any of the 12 flagged accounts got caught and resolved before a client ever needed to submit a ticket about them. The zero support ticket outcome wasn’t just the result of a clean migration weekend. It was the result of watching closely enough afterward that nothing slipped through in the days right after.
Why Did the Migration Generate Zero Support Tickets?
Zero support tickets came from proactively catching every problem before a client could encounter it, not from a migration that happened to go perfectly. Twelve of the 200 accounts needed manual intervention, and every one of those twelve got resolved before DNS ever pointed a client’s visitors at a broken configuration.
Reducing customer-facing disruption before the migration
Customer visible downtime across the entire migration stayed between zero and five minutes per account, and for a meaningful share of accounts it was closer to zero.
That range is a direct result of every earlier decision in this migration, the batching, the pre-verification, the DNS TTL changes, all stacking together rather than any single trick. There isn’t one setting that gets a migration to near-zero downtime. It’s the accumulation of a dozen smaller decisions all pointed the same direction.
Testing accounts instead of assuming transfers were successful
A migration tool reporting success and an account actually working correctly are not the same thing, and treating them as the same thing is where most migration horror stories start.
We tested every single one of the 200 accounts directly rather than trusting a transfer log that says complete. That distinction is exactly what caught the 12 accounts needing manual checks, none of which showed up as an error in any migration tool’s own reporting.
Identifying problems before clients encountered them
Every one of the 12 flagged accounts got fixed before its DNS pointed anywhere new, which means the client on the other end never saw a broken site, a bounced email, or a certificate warning at any point.
The problem existed, got caught, and got resolved entirely inside our own verification process. From the client’s perspective, nothing about their hosting changed except which server it happened to run on.
Using a consistent migration checklist for every account
All 200 accounts, from the smallest site to the 65 gigabyte outlier, went through the identical verification checklist. No account skipped a step because it looked simple, and no account got extra scrutiny just because it looked complicated on paper.
A consistent checklist applied without exception is what catches the account that looks fine but has one broken piece nobody thought to check, because the checklist doesn’t rely on someone’s judgment call about which accounts deserve a closer look.
Understanding why preparation mattered more than migration speed
The actual data transfer for 1.4 terabytes across 200 accounts is, on its own, not a particularly difficult technical problem. Where migrations actually go wrong is almost never during the transfer itself.
It’s in the gaps around it: a domain’s DNS record that got missed, a certificate that didn’t carry over, a mail forwarding rule that got dropped. We spent more total time on inventory, preparation, and verification than on the literal data transfer, and that ratio is exactly why the migration finished clean.
What Can Other Resellers Learn From a 200-Account Migration?
Treat a migration of this size as a project with its own timeline and checklist rather than a background task squeezed into a normal week, and never skip inventory, testing, or verification to save time, since those three steps are where a clean migration actually gets won.
Why large migrations should be treated as a project
A migration involving 200 accounts, 1.4 terabytes of data, and 1,800 email accounts is not a task to handle in spare moments between regular support tickets. It needs a defined scope, a timeline, and someone accountable for the whole thing end to end.
Treating it as a project rather than a chore is what makes room for the inventory and preparation work that actually determines whether the migration goes smoothly, instead of that work getting squeezed out by whatever else is happening that week.
Which migration tasks should never be skipped
Inventory, PHP and database compatibility checks, SSL verification, and individual account testing after transfer should never get cut to save time, regardless of how confident a migration tool’s reporting looks.
Every one of the 12 accounts that needed manual intervention in this migration would have shipped as a support ticket if any of those steps had been skipped or rushed. The steps that feel most skippable under time pressure are usually the ones actually preventing the visible problems.
Why account inventories and verification checklists matter
A complete inventory is what turns 200 unknown accounts into 200 known quantities with a known size, a known domain list, and known dependencies.
A verification checklist is what turns 200 completed transfers into 200 confirmed working accounts instead of 200 assumptions. Both exist for the same reason: to replace guessing with checking, at every single step of a migration this size. Anyone evaluating a host’s reseller features before a switch should ask directly whether this level of process is what they can expect during their own transition.
When automation can reduce repetitive migration work
Batching accounts, running the same verification checklist against each one, and applying identical DNS changes across a domain list are all places where automation genuinely reduces repetitive manual work without cutting any corners.
What shouldn’t get automated away entirely is the actual verification judgment call on flagged accounts, which is exactly how the 12 manual check accounts in this migration got the individual attention they needed instead of getting steamrolled through an automated pipeline that wouldn’t have caught what was actually wrong with them.
Knowing when a migration is too large to handle without additional planning
Two hundred accounts, 220 websites, and 1,800 email accounts is squarely in the range where a migration needs the full planning process laid out in this post, not a quick weekend effort with minimal preparation.
A reseller moving five or ten accounts can reasonably improvise more of this. A reseller moving hundreds cannot, and a network running at master reseller scale, or approaching the point where a single dedicated server makes more sense than another shared reseller environment, should plan for a migration this size well before it becomes urgent, not after a server is already out of room.
If you are weighing whether your next hosting provider can actually handle a migration like this without turning it into weeks of client complaints, this is what it looks like in practice, not in theory. Our reseller hosting plans run on the same WHM foundation this migration ran on, with overselling enabled resource pools and a free WHMCS license already in place, so if a future migration is ever necessary, the account structure it happens across is not something you have to design from scratch under pressure.
