Moving customer accounts to a new server is one of the riskiest jobs a reseller does, because every mistake lands in front of end customers as missing email, broken sites or a lost database. This server migration checklist for hosting resellers is grouped by area, so you can work through it in order and hand sections to different people. If you would rather have specialists run the move, see our server migration service for Linux and Windows servers.
The checklist assumes a common scenario: cPanel and WHM accounts moving from one server to another. The same structure applies to other panels and to Windows servers, although the specific tools differ. Treat every item as a prompt to check your own environment rather than a guarantee that the steps are complete for your setup.
How to Use This Server Migration Checklist for Hosting Resellers
Print it or copy it into your ticketing system. Assign an owner to each section, record the date each item was finished and keep notes on anything that deviated from plan. A migration that is documented is easier to repeat, easier to hand over and far easier to roll back if something goes wrong.
Work through the sections in this order:
- Pre-migration audit
- TTL and DNS planning
- Account packaging and transfer
- Email and databases
- SSL certificates
- Cutover
- Post-migration verification
- Rollback
Section 1: Pre-Migration Audit
The audit decides how long the migration takes and where it is likely to fail. Skipping it is the most common reason for surprises later.
Inventory the source server
- List every cPanel account, its domains, addon domains, subdomains and parked domains.
- Record disk usage per account so you can confirm the destination has room, including space for backups made during the move.
- Note which accounts are suspended, unused or abandoned. Decide whether to move them or archive them.
- Export the list of packages, feature lists and reseller privileges so they can be recreated.
- Document custom items such as cron jobs, custom DNS records, redirects and special Apache or PHP settings.
Compare source and destination
- Check operating system and control panel versions on both servers.
- Compare PHP versions and installed extensions. Older sites may depend on a version the new server no longer offers.
- Compare database server versions, since differences can affect older applications.
- Check for third-party software on the source, such as mail filters, backup agents or security tools, and decide what to reinstall.
- Confirm the destination IP addresses, reverse DNS and firewall rules are ready.
Agree scope and communication
- Decide whether you will migrate everything in one window or in batches.
- Choose a time window with the lowest customer traffic and tell customers beforehand.
- Name a single person responsible for go or no-go decisions on the day.
Section 2: TTL and DNS Planning
DNS is where a clean migration can still look broken for hours. Planning it early keeps the cutover short.
Lower TTL values in advance
- Find the current TTL on the A, MX and other key records for each domain.
- Lower those TTL values well before the cutover, and wait at least as long as the old TTL so resolvers pick up the shorter value.
- Keep a record of the original values so you can restore them after the migration settles.
Map out who controls DNS
- Identify domains using your nameservers, domains using customer-managed DNS and domains using an external DNS provider.
- For customer-managed DNS, plan how you will ask customers to update records and how you will follow up.
- Check for glue records and custom nameservers that point at the old server IP address.
Prepare the destination zones
- Confirm the DNS zones on the new server match the old ones, including MX, TXT, SPF, DKIM and any CNAME records.
- Decide how you will test the new server before DNS changes, for example by using a local hosts file entry.
Section 3: Account Packaging and Transfer
This is the mechanical part of the migration, and it works best when it is repeatable.
Packaging accounts
- Create full account backups from the source server, or use the transfer tool built into WHM, depending on what your setup allows.
- Make a test run with one low-risk account first and review the result carefully before moving others.
- Check that file ownership, permissions and home directory structure are intact on the destination.
- Verify that packages and feature lists on the destination match what the accounts expect.
Transfer and sync
- Confirm the transfer method, whether a direct server-to-server copy or backup files moved through an intermediate location, and make sure enough bandwidth and time are available.
- Plan a second, incremental sync just before cutover to capture files changed since the first copy.
- Keep logs of every transfer so any failures can be re-run for that account alone.
Application-level checks
- Look for hard-coded paths, IP addresses or database hosts in configuration files, especially in older CMS installations.
- Check that scheduled tasks and cron jobs were carried over and still point at valid paths.
- Test each site using a hosts file entry before any DNS change goes live.
Section 4: Email and Databases
Websites are easy to test by eye. Email and databases are where silent data loss happens, so give them their own section.
- Confirm all mailboxes, forwarders, autoresponders and filters exist on the destination.
- Plan for mail that arrives during the DNS propagation window. Mail may land on either server for a time, so schedule a final sync of mailboxes after DNS has settled.
- Check SPF, DKIM and DMARC records on the new server and confirm they still match the sending IP address.
- Check reverse DNS for the new mail IP address and review whether the address has a clean sending reputation.
- Test sending and receiving for a sample of mailboxes using webmail and a desktop mail client.
Databases
- Confirm every database and database user was recreated with the correct privileges.
- Compare table counts or sizes between source and destination as a sanity check.
- Plan how to handle databases that change frequently, such as ecommerce or membership sites. A final export and import during the cutover window avoids lost orders and registrations.
- Check character sets and collations on the new server, since mismatches can corrupt text in older applications.
- Update application configuration files if the database host name changes.
Section 5: SSL Certificates
Certificates are easy to forget until browsers start showing warnings on customer sites.
- List every certificate on the source server, including its domain, issuer, type and expiry date.
- Check whether certificates are issued automatically on the destination and whether domain validation will succeed before DNS has moved.
- For purchased or customer-supplied certificates, confirm the certificate, private key and intermediate chain are all copied across.
- Check the panel hostname certificates for WHM, cPanel and mail services, not just customer domains.
- After cutover, re-test every domain for chain errors, mixed-content warnings and redirect loops.
If SSL is a recurring pain point across your servers, our team can help review it as part of a wider migration through the CloudHouse migration team.
Section 6: Cutover
Cutover is the shortest section and the one that needs the most discipline. Everything above exists to make this step uneventful.
Before the switch
- Confirm that all earlier sections are signed off by their owners.
- Take a fresh backup of the source server and confirm it can be restored.
- Put frequently changing sites into maintenance mode, if you plan a final data sync.
- Run the final incremental sync of files, databases and mailboxes.
The switch
- Update DNS records, or ask customers to update theirs, in a defined order, starting with a small group of sites.
- Update nameserver glue records and any hostnames used by customers for mail, FTP and panel access.
- Keep the old server online and untouched. Do not cancel or wipe it during this stage.
During propagation
- Monitor both servers, since some visitors will reach each one for a while.
- Watch for support tickets and group repeated issues so they can be fixed once.
- Check the logs on the new server for errors, blocked IP addresses and failed mail delivery.
Section 7: Post-Migration Verification
Do not declare success because the home page loads. Verify systematically, and record the result for each account.
- Websites: check key pages, forms, logins, checkout flows and image or file uploads.
- Email: send and receive test messages, check that no mail is stuck in a queue and confirm spam filtering works.
- Databases: confirm write operations work, not just reads.
- SSL: check every domain and the panel hostnames for valid certificates.
- Scheduled tasks: confirm cron jobs ran at their expected times.
- Backups: make sure the new server is included in your backup schedule and run a test restore.
- Monitoring: update uptime monitoring, alerting and any inventory or billing records to point at the new server.
- Performance and security: compare load and response with expectations and confirm firewall and update settings are applied.
Once DNS has settled, restore TTL values to their normal level and run one more sync of any mail that arrived on the old server during the move.
Section 8: Rollback Plan in Your Server Migration Checklist for Hosting Resellers
Every item in a server migration checklist for hosting resellers should have a way back. Decide your rollback triggers before you start, not during an incident.
Define the triggers
- Agree in advance which problems justify rolling back, for example widespread email failure, database corruption or a service that cannot be fixed within the window.
- Name the person with authority to make that decision.
Keep the escape route open
- Leave the old server intact and running until verification is complete and a safe period has passed.
- Keep original TTL values and DNS records documented so they can be restored.
- Remember that data written to the new server after cutover, such as orders or new mail, must be copied back if you revert.
Decommission carefully
- Only retire the old server once customers have confirmed everything works and your own verification is signed off.
- Keep a final backup of the old server for an agreed period before wiping it.
- Remove old access credentials and update documentation.
Common Mistakes This Checklist Helps You Avoid
- Changing DNS without lowering TTL first, which stretches the cutover over a long period.
- Forgetting that mail keeps arriving on the old server after the switch.
- Testing only the home page and missing broken forms or checkout steps.
- Shutting down the old server too early, leaving no way back.
- Moving everything at once instead of starting with a pilot account.
- Not telling customers, so planned changes arrive as unexplained support tickets.
When to Hand the Migration to Specialists
Resellers often do their first few migrations themselves, then reach a point where the risk is no longer worth it. Common signs include a large number of accounts, mixed Linux and Windows servers, business-critical ecommerce clients, a short maintenance window or no one on the team with migration experience. Pricing for a managed migration depends on factors such as the number of accounts, data volume, server types and how much testing and follow-up you need, and it is agreed after reviewing your requirements. You can read more about the scope on our server migration page.
Why Choose CloudHouse for Server Migration
CloudHouse Technologies works with hosting providers and resellers on server management, and our migration service is built for teams that want a structured move without taking on the risk alone.
- Linux and Windows coverage: migration support for both server types, including cPanel account moves.
- Structured process: audit, DNS planning, transfer, verification and rollback thinking built into the plan.
- Clear communication: you know what is happening at each stage and what is expected of you.
- Works with your team: we can take over the whole move or support your own technicians.
- Scope agreed first: pricing is agreed after we review your servers and requirements.
Conclusion
A reliable migration comes from preparation: a thorough audit, early DNS planning, careful packaging, separate attention to email and databases, tested SSL, a disciplined cutover, systematic verification and a rollback plan you hope never to use. Use this checklist as a starting point and adapt it to your own servers. If you want an experienced team to run the move, request a free quote or book a consultation through our server migration page, and we will review your requirements and recommend a plan.
