Introduction

A hosting migration can move the account and website successfully while cPanel or WHM logins still open the old server. Admins often notice this when the domain itself works on the new host, but panel access through the server hostname, branded shortcut, or port-based login still lands on legacy infrastructure.

Treat this as an admin-access routing problem instead of a general website migration failure. Start by checking exactly which hostname and port the login URL uses, because cPanel and WHM access often depends on server-hostname records or redirects that were not updated during the cutover.

Symptoms

  • cPanel or WHM login still opens the old server after migration
  • The website loads from the new host, but panel access lands on legacy infrastructure
  • The login page shows the old hostname, certificate, or branding
  • Port-based access like :2083 or :2087 still resolves to the previous server
  • Panel credentials appear wrong because the browser reached the wrong machine
  • The issue started after account transfer, server replacement, or hostname cutover

Common Causes

  • The server hostname used for cPanel or WHM still resolves to the old server
  • A branded panel shortcut or redirect still points at the previous host
  • The old server still answers on the panel ports and looks valid from the outside
  • SSL certificate details reveal that the browser reached legacy infrastructure
  • Hosting migration updated the website domain but not the admin-access hostname
  • Saved bookmarks or control panel shortcuts still reference the old server path

Step-by-Step Fix

  1. Test the exact cPanel or WHM login URL you are using and identify the hostname, port, certificate, and response you receive, because you need proof of which server currently answers the admin login.
  2. Check DNS for the server hostname or branded admin hostname behind that login URL, because panel access often relies on a different hostname than the public website.
  3. Review any redirects or shortcuts used for cPanel, WHM, or hosting-login links, because one stale shortcut can keep sending administrators to the previous server even when DNS for the main site is correct.
  4. Compare the certificate and hostname presented on the live panel login with the destination server you expect, because certificate details often expose that you are still reaching legacy infrastructure.
  5. Verify whether the old server is still publicly answering on ports 2083 or 2087, because a reachable legacy panel endpoint can keep misleading users after the migration.
  6. Update the hostname record, branded shortcut, or redirect that actually controls panel access, then retest with a clean browser session, because cached redirects and stored credentials can hide whether the login path is fixed.
  7. Compare direct server-hostname panel access with any domain-based or branded login URL, because one path may already be correct while another still points to the old host.
  8. Confirm that successful login actions occur on the intended new server rather than only showing the right splash page, because the true fix is correct authenticated access on the destination system.
  9. Document the final panel-access hostname, ports, and redirect path after recovery, because admin URLs are often forgotten during future server migrations.