Taking on another reseller's clients is a migration where you control neither end of the timeline. The sites are on someone else's server, the domains are managed by someone who is losing the business, and the clients are watching.
The technical work is ordinary. The sequencing and the communication are what determine whether it goes well.
Find out what access you have first
Everything else depends on this, and the answer is usually one of three.
Root or WHM access to the source server. The best case: Transfer Tool pulls accounts directly and the whole job is straightforward. See transferring cPanel accounts.
cPanel access per account. Workable: generate a full backup from each account and restore it on your side. Slower, and it needs each client's cooperation or their credentials.
Neither. You are rebuilding from files and databases the client can extract, which is a different and much larger job. Price it accordingly, and be honest with the client about what may not survive.
Inventory before you move anything
For each site, write down what it needs. This is the step people skip and then discover mid-migration.
The PHP version. Any extension beyond the defaults. Cron jobs and what they do. Email accounts and their sizes. Databases and their sizes. Whether the domain is registered elsewhere.
Then check your server offers all of it before you begin. A site needing a PHP version you do not have is a decision to make in advance, not a discovery at two in the morning.
Lower the TTL: days ahead
This one is genuinely awkward here, because the DNS is usually controlled by the outgoing provider.
If you can get the TTL lowered a day or two before, the cutover takes minutes. If you cannot, plan for the old TTL, often four hours, sometimes twenty-four, during which visitors reach either server unpredictably.
When you cannot control it, that window is the constraint the whole plan works around. Understanding DNS propagation explains why lowering it on the day accomplishes nothing.
The gap where data is lost
Between copying an account and pointing the domain at your server, the site is live on the old one and still receiving.
Orders. Form submissions. Comments. Email. All landing on a server you are about to stop using, and none of it in the copy you made.
Two ways to handle it. Put the site into maintenance mode for the cutover, which is clean and visible. Or re-sync the database and mail immediately before flipping DNS, which is invisible to visitors and requires you to be watching.
For a shop, choose one deliberately and tell the client which.
Test before DNS moves
Edit your local hosts file to point the domain at your server. You then see the migrated site while everyone else still sees the old one.
Load it properly: a page with images, a form, the admin login, a page that queries the database. This is your only chance to find a missing extension or a broken database connection privately.
Do this for every site, not a sample. The one you did not check is the one that breaks.
Email is the part that goes wrong
Websites move visibly and mail moves quietly.
Mailboxes have to be recreated with the same addresses, and the contents have to come across. Passwords rarely transfer, which means every client reconfigures their mail client, and that is the single largest source of support contact during a migration.
Warn them before, not after. A message explaining that they will need to re-enter their password, sent the day before, prevents most of the calls. There is more on moving the mail itself in migrating email to a new host.
Keep the old server reachable
Do not let the outgoing provider terminate accounts on the day you switch.
Mail already in flight is delivered to whichever server the sending system resolved, so some arrives on the old one for a day or two afterwards. And problems from a migration surface days later, when having the original still on disk turns a crisis into a copy.
A week is the minimum. Two is better, and it is worth paying for.
Domains are a separate job
Moving hosting does not move the domain registration, and it does not have to.
Changing nameservers is enough to move the hosting. Transferring the registration is a separate process with its own timeline and its own failure modes, and doing both at once means two things can go wrong while you are trying to diagnose one.
Move the hosting first, settle it, then transfer domains if the client wants that. There is more on the second step in What to Check After Transferring a Domain.
Take over billing deliberately
Clients arriving from another reseller have expectations set by that reseller: renewal dates, prices, what support included.
Decide what you are honouring and say so in writing before the migration, not after. A client discovering a price change in their first invoice from you associates it with the move, and that is the worst possible framing for a conversation you were going to have anyway.
Get the renewal dates into your system before you need them. An account expiring in the first month of a migration, unnoticed, is an avoidable way to lose a client you just acquired. Integrating billing and automation explains the setup.
Tell clients what to expect
Three messages, and they do more for the outcome than any technical step.
Before: when it is happening, what may be briefly unavailable, that they will need to reconfigure mail.
On the day: that it has started, and where to reach you.
After: that it is complete, what to check, and what to report.
Migrations are judged on how informed people felt rather than on how long the switchover took. A silent, technically perfect migration generates more complaints than a communicative one with a small hiccup.
Check afterwards, for a week
Watch the error logs rather than only confirming homepages load. Cron jobs with hardcoded paths from the old server, a form that stopped emailing, an upload directory that came across empty; these appear on their own schedule.
Ask each client to confirm their site and mail work. The problems they notice are not the ones you would check for, and a fortnight of silence is not the same as success.