Moving a WordPress site has one hard requirement and one easy way to get it wrong. The requirement is that files and database must arrive together and matched; a database restored against a different set of files produces a site that half works in ways that take hours to unpick. The easy mistake is switching DNS before testing, which means every visitor sees the broken half of the migration while you debug.
Ahosting offers free migration, and for most sites that is the right answer: open a ticket, provide access to the old host, and the work is done for you. What follows is for when you would rather do it yourself, or when you want to understand what the migration actually involves.
Before you start
Note the PHP version and the WordPress version on the old host. Arriving on a much older or newer PHP version is a common source of errors that look like migration failures but are not.
Take a backup of the old site and keep it somewhere other than either server. This is the copy you fall back to if something goes badly wrong, and it needs to survive both accounts.
Then decide the method. A migration plugin handles export, import and URL rewriting in one pass and is the right choice for most sites. A manual migration is more work but does not depend on the plugin being able to complete a large export inside the old host's time limits, which is where plugin migrations usually fail on big sites.
The plugin route
Install a migration plugin on the old site, run the export, and download the resulting package. Install WordPress on the Ahosting account (a plain one-click install is fine, the import overwrites it) then install the same plugin and import the package.
The plugin rewrites URLs during the import, which is the part that saves the most work. Verify anyway: load several pages, check images appear, and check any forms submit.
If the export fails partway through, the old host is timing out. Exclude the uploads folder from the package, move that separately over SFTP, and the export usually completes.
The manual route
Copy the files. On the old host, compress the site directory and download the archive rather than transferring thousands of files individually. Upload it to the Ahosting account and extract it in place.
Export the database. In the old host's phpMyAdmin, select the site database and export it as SQL. Take the whole database, not selected tables: missing one table produces failures that appear later and look unrelated.
Create the destination database. In cPanel, open MySQL Databases, create a database and a user, then add the user to the database with ALL PRIVILEGES. That last step is skipped constantly and produces "Error establishing a database connection" at the end while every credential looks correct.
Import. Open phpMyAdmin, select the new database, and import the SQL file. If the file is too large to upload, compress it first; if it is still too large, that is a support ticket rather than something to fight in the browser. Managing MySQL databases with phpMyAdmin goes over the interface.
Point wp-config at the new database. Edit wp-config.php with the new name, user and password. DB_HOST stays localhost:
define( 'DB_NAME', 'account_wp01' ); define( 'DB_USER', 'account_wpuser' ); define( 'DB_PASSWORD', 'the new password' ); define( 'DB_HOST', 'localhost' );
Include the account prefix on both names. Its absence is the most common cause of a failed manual migration.
Test before touching DNS
This is the step that separates a calm migration from a bad afternoon. The domain still points at the old host, so the site is live and untouched while you work.
Add an entry to your computer's hosts file mapping the domain to the Ahosting server address. Your machine then loads the new server while everyone else continues to reach the old one. Browse the site properly: homepage, a post, an archive, a form, the admin area, and checkout if there is one.
Remove the hosts entry when you are finished testing. Forgetting it means you keep seeing the old server after the switch and conclude the migration failed when it did not.
Switch DNS
Once the test passes, change the nameservers or the A record at your registrar. Propagation takes anywhere from a few minutes to a day or so depending on the previous time-to-live value.
During that window, visitors reach one server or the other depending on their DNS cache. This is why you keep the old account alive for at least a week: orders and comments arriving during propagation may land on the old site, and you want to be able to retrieve them.
Lowering the time-to-live on the DNS record a day before you migrate shortens this window considerably, and costs nothing.
After the switch
Reissue SSL. The certificate on the old host does not travel with the site. Once DNS points at Ahosting, run AutoSSL for the domain, then confirm the site loads over https:// without warnings, see setting up an SSL certificate in WordPress.
Re-save permalinks. Open Settings then Permalinks and save without changing anything; this regenerates the rewrite rules and fixes the case where the homepage works and every other page returns a 404.
Check email. If mail was handled by the old host, sending may silently stop. Confirm password reset and contact form messages actually arrive.
Set up backups on the new account. Whatever the old host was doing does not follow you. Managing WordPress backups goes into the schedule and the restore test.
Symptoms and what they mean
Homepage works, everything else 404s. Permalinks not regenerated. Save the permalink settings.
Error establishing a database connection. Credentials mismatched, or the user was never granted privileges on the database.
Site loads without styling. Stored URLs still point at the old domain or old path. Run a proper search-and-replace with a tool that understands serialized data.
Some visitors see the old site. Normal during propagation. It resolves on its own.
White screen. Usually a PHP version mismatch. Set the new account to match the old host's version, confirm the site loads, then move up deliberately one major version at a time.
If the site is currently in a subdirectory and you want it at the root, that is a separate job. How to Move WordPress from a Subdirectory to the Root has the detail.
If you did not build the site you are moving, it is worth knowing what is in it first. How to Audit a WordPress Site You Inherited sets out the audit.
Coming from Joomla, Drupal or something similar is a different job. There is more on what transfers and what has to be rebuilt in How to Migrate from Another CMS to WordPress.
The move itself is the easy half; the window where both servers are live is where sites go down. How to Plan a DNS Cutover with No Downtime walks through planning for it.