Migrate My Website

When someone searches for "migrate my website," they usually need a clean path from old hosting to new hosting without losing files, database records, mail, DNS, SSL, forms, orders, redirects, or login access. Migration Monkey is built for that work at operator scale: detect the app, estimate credits, create a source and destination path, transfer directly whenever possible, and leave a migration log that a support team can actually use.

This guide is written for agencies, web hosts, freelancers, and support teams running many migrations. A one-off site owner can use the same checklist, but the goal is repeatable intake, quoting, transfer, verification, and handoff.

Start With The Access Model

Before touching data, confirm that the requester owns the site or has written permission to move it. Then classify the source access: wp-admin only, cPanel, SSH, SFTP, WHM root, Plesk, WordPress.com, managed host dashboard, CDN-protected origin, or email-only mailbox access. That access model decides whether the job uses a plugin helper, a direct server agent, a control-panel transfer, an IMAP/API mailbox copy, or a guided export/import path.

Detect The Application

Do not price every website as if it were WordPress. A migration estimate should inspect the install folder for markers like wp-config.php, Magento app/etc/env.php, Laravel artisan, Node.js package.json, Drupal, Joomla, PrestaShop, OpenCart, Nextcloud, or custom files. Old versions matter because PHP runtime, database engine, character set, and rewrite behavior can change the job even when the file size looks small.

Decide The Route

• WordPress: move files and matching WordPress tables, then run serialized-safe search and replace when the domain changes.
• cPanel account: use WHM transfer tooling when both sides are cPanel and the operator has the right privileges.
• Magento or ecommerce: plan cache, media, cron, queues, sessions, order tables, and maintenance windows before cutover.
• Laravel or Node.js: capture environment variables, runtime versions, process manager config, storage paths, database, queues, and build steps.
• Email: map mailboxes, quotas, folders, labels, OAuth/app-password requirements, and DNS records before MX cutover.

Prepare The Destination

Create the destination runtime before transfer. For WordPress, a fresh install with a writable document root and database user is often faster than trying to guess what the destination host already broke. For Laravel, Node.js, Magento, or legacy PHP, match the runtime first, then move data. If the domain is not pointed yet, use a temporary domain, origin IP, hosts-file test, or staging URL.

Transfer Without A Middle Archive

Migration Monkey's preferred path is source-to-destination movement. The control plane stores consent, job state, warnings, credit ledger entries, hashes, and logs; the customer payload should move between the systems that already own it whenever the source and destination allow that route.

Verify Before DNS Cutover

1. Open the destination on a temporary hostname or hosts-file override.
2. Test login, forms, checkout, search, uploads, cron, redirects, and admin pages.
3. Run URL replacement only when the final domain path is clear.
4. Lower DNS TTL before cutover when the old DNS provider allows it.
5. After cutover, check SSL, mixed content, mail flow, analytics, sitemap, robots, and error logs.

Related Operator Guides

For cPanel-to-cPanel moves, read the WHM Transfer Tool migration guide. For repeatable agency workflows, use the agency website migration workflow. For direct no-custody transfer mechanics, read the server-to-server migration guide.