Moving a website to a new hosting provider is mostly about preparation. If you plan the transfer carefully, you can keep downtime low, avoid broken links or missing files, and make sure email, DNS, and databases continue to work after the move. Whether you are switching for better performance, support, price, or a managed hosting environment, the process is easier when you treat it as a structured migration rather than a simple file copy.
This guide explains how to transfer a website to a new hosting provider step by step, with practical notes for common hosting environments, including Plesk-based servers and managed hosting platforms. It covers the main migration tasks: backing up the site, moving files and databases, adjusting DNS, testing the new environment, and completing the switch with minimal disruption.
What needs to be moved during a website transfer
A website is often more than just a set of web pages. In most cases, the transfer should include the core application files, media uploads, database content, configuration files, and sometimes email accounts or scheduled tasks. If any of these parts are missed, the site may load incorrectly or stop working after the migration.
Typical items included in a website migration
- Website files: HTML, PHP, JavaScript, CSS, images, and application files.
- Database: MySQL, MariaDB, PostgreSQL, or another database used by the site.
- Configuration files: For example, application settings, environment files, or CMS configuration.
- SSL certificates: Reissued or reinstalled on the new server if needed.
- Email accounts: If mail is hosted with the website provider, mailbox migration may be required.
- DNS records: Updated to point the domain to the new hosting platform.
- Cron jobs and scheduled tasks: Important for WordPress, custom apps, and scripts.
If you use a control panel such as Plesk, some of these items may be exported or recreated more easily through built-in tools. Still, it is important to confirm each component manually, especially for custom setups.
Before you start: prepare the migration plan
A smooth website transfer begins with a short inventory of what you have now. Before making any changes, identify the site type, the current hosting provider, DNS setup, domain registrar, and whether email is connected to the same hosting account. This makes it easier to estimate the time required and reduce the risk of missing critical settings.
Pre-migration checklist
- Confirm what platform the website uses, such as WordPress, Joomla, Magento, or a custom application.
- Check where DNS is managed: registrar, current host, or a third-party DNS service.
- List all domains and subdomains that must work after the move.
- Identify database names, usernames, and connection details.
- Check whether email is hosted with the current provider.
- Review SSL certificate status and expiration dates.
- Note any third-party integrations, such as payment gateways, APIs, SMTP services, or analytics tools.
If you manage the site through Plesk, it helps to review the domains section, databases, mail settings, scheduled tasks, and file manager before beginning. In managed hosting environments, some tasks may be handled by support, but you should still verify the migration scope in advance.
Choose a low-risk migration window
Even when the transfer is well planned, DNS propagation can take time. Choose a period of lower traffic when possible. For e-commerce sites, avoid peak sales hours. For business websites, consider evenings or weekends. If the site changes frequently, shorten the time between the final sync and DNS switch.
Step 1: Back up the existing website
The first practical step is to create a complete backup of the current site. This backup is your rollback point if something goes wrong on the new server. A reliable backup should include both files and database content.
How to back up website files
Download the full site directory from the current host using the file manager, FTP, SFTP, or a backup tool in the control panel. Make sure hidden files are included, especially .htaccess or other configuration files. If your site contains large media libraries, verify that the entire uploads directory is present.
How to back up the database
Export the database using phpMyAdmin, the control panel database tools, or a command-line export if available. Use a format that can be imported into the new server, usually SQL. For larger databases, confirm that the export completed without timeouts or missing tables.
What else to save
- Current DNS zone records.
- Email account names and mailbox settings.
- SSL certificate details.
- Application environment variables.
- Custom rewrite rules or server rules.
Store the backup in more than one location if possible, such as local storage and cloud storage. This reduces the risk of losing access if one copy fails.
Step 2: Set up the new hosting account
Before moving any data, prepare the destination environment. The new hosting provider should have enough disk space, correct PHP or runtime version, and the right database support for your website. If you are migrating to a managed hosting platform, make sure the service plan matches the site’s resource needs.
Verify server requirements
Check the following on the new host:
- PHP version and extensions.
- Database engine and version.
- Web server type and supported rewrite rules.
- Memory and execution limits.
- SSL support and certificate installation options.
- Mail services if email is part of the hosting package.
For WordPress and similar CMS platforms, a mismatch in PHP version or extensions can break plugins or themes. For custom applications, review documentation carefully and match the runtime configuration as closely as possible.
Create the destination database and user
Set up a new database on the destination server and assign a database user with a strong password. Note the database name, username, password, and host value. If the control panel is Plesk, this is usually done from the Databases section. Keep these details ready for the application configuration update later.
Step 3: Move the website files
Once the new server is ready, transfer the site files from the old host. You can do this through SFTP, FTP, file manager tools, backup archives, or provider-assisted migration services. For most sites, an archive upload and extract process is the fastest and cleanest method.
Best practices for transferring files
- Preserve the original directory structure.
- Include hidden files and system files.
- Verify file permissions after upload.
- Check for incomplete transfers or corrupted archives.
- Keep a copy of the original files until the migration is fully confirmed.
If the site is large, split the migration into parts if needed. For example, move the application first, then the uploads directory, then any large static assets. This can make troubleshooting easier if one part fails.
Website transfer in Plesk
In a Plesk environment, the file manager or subscription tools can help you upload site files directly into the document root. If you are migrating between Plesk servers, migration tools may also copy files, databases, mailboxes, and settings together. Even then, review the final file structure to confirm that the site root and domain mappings are correct.
Step 4: Import the database
After the files are in place, import the database into the new server. The exact method depends on the hosting stack, but the goal is to recreate the original database content accurately and completely.
Database import checklist
- Confirm the new database exists.
- Make sure the database user has the correct privileges.
- Import the SQL file using the control panel, phpMyAdmin, or command line.
- Check for import errors, timeouts, or character set issues.
- Verify that all tables and records are present after import.
If the website uses a different database prefix, encoding, or collation on the new server, review the import results carefully. Character set mismatches can cause broken content, especially for multilingual websites.
Update the application configuration
After importing the database, update the website’s configuration file so it connects to the new database credentials. This may include database name, username, password, and host. For WordPress, this is typically stored in wp-config.php. For custom applications, it may be in a .env file or another config file.
If your host uses a control panel, confirm that the database connection settings are saved correctly and that the application has the needed permissions to read them.
Step 5: Test the site before changing DNS
Testing before switching DNS is one of the most important steps in a website migration. It lets you verify that the site works on the new hosting provider while the public domain still points to the old server.
Ways to test the new server
- Use a temporary URL provided by the host.
- Preview the site with a hosts file override.
- Use a staging subdomain if the environment supports it.
- Check the site through the server IP if safe and appropriate.
During testing, browse the homepage, key landing pages, forms, checkout flow, login pages, and admin area. Upload a sample file if relevant. Confirm that images load, links work, and no mixed content or certificate warnings appear.
What to verify during testing
- Page rendering and layout.
- Database content and dynamic features.
- Contact forms and transactional emails.
- Search functionality and internal links.
- Mobile responsiveness.
- Security redirects and HTTPS behavior.
If the website uses caching, clear both application-level and server-level caches before final testing. This helps avoid false positives from outdated content.
Step 6: Lower DNS TTL before the final switch
If you manage DNS, lower the TTL values before the cutover. A lower TTL helps DNS changes propagate faster once you point the domain to the new server. Ideally, do this 24 to 48 hours before the migration if possible.
Why TTL matters
TTL controls how long other DNS resolvers cache your records. A high TTL can delay the appearance of the new server after the switch. A lower TTL does not guarantee instant propagation, but it reduces the waiting time and makes the migration more predictable.
Common records to review include the A record, AAAA record, CNAME records, MX records, and any TXT records used for SPF, DKIM, or verification services.
Step 7: Point the domain to the new host
When you are confident that the new server is ready, update the DNS records so the domain resolves to the new hosting provider. Most often this means changing the A record to the new IP address, or updating nameservers if DNS is managed by the new host.
What to update during the DNS switch
- A record: Points the domain to the new server IP.
- AAAA record: Update if IPv6 is used.
- MX records: Keep them correct if email remains active elsewhere.
- TXT records: Preserve SPF, DKIM, verification, and DMARC values.
- CNAME records: Check subdomains and service aliases.
After the change, some visitors will still reach the old server for a short time because of cached DNS data. This is normal. Keep the old hosting account active until traffic fully shifts and the site is stable on the new platform.
Step 8: Reconfigure email if needed
Email is often the part of a migration that causes the most confusion. If mailboxes were hosted on the old server, they may need to be recreated on the new host or moved to a separate mail service. If DNS changes were made only for the website, but MX records were left untouched, email may continue to flow through the old system.
Email migration checks
- Recreate mailboxes and aliases if they are hosted on the new provider.
- Update MX records only if mail services are moving.
- Check SPF, DKIM, and DMARC after any mail-related changes.
- Test sending and receiving from external mail providers.
In managed hosting and Plesk environments, email accounts are often linked to the domain subscription. Make sure mailbox quotas, spam settings, and authentication records are recreated correctly.
Step 9: Final validation after the cutover
Once DNS has changed, validate the live site again. Check that the domain resolves to the new IP address, HTTPS works correctly, and all core features behave as expected. Also monitor logs for errors, failed database connections, or file permission issues.
Post-migration validation list
- Confirm the public site loads on the new server.
- Test login and admin functions.
- Check contact forms and automated emails.
- Review error logs and access logs.
- Verify redirects, canonical URLs, and sitemap generation.
- Test SSL certificate renewal if the certificate was reinstalled.
If the site uses caching, CDN, or reverse proxy services, purge those caches after the migration. This helps visitors see the correct version of the site faster.
Common problems during website migration
Even a simple website transfer can encounter issues. Most problems are caused by missing files, incorrect database credentials, overlooked DNS records, or environment differences between the old and new server.
Typical migration issues and causes
- White screen or fatal errors: Often caused by PHP version mismatch, missing extensions, or broken configuration.
- Database connection errors: Usually due to wrong credentials or host values.
- Missing images or assets: Files were not copied completely or paths changed.
- Form emails not sending: SMTP settings, mail server settings, or DNS authentication records need adjustment.
- SSL warnings: Certificate not installed or domain mismatch.
- Unexpected redirects: Old domain references, cached rules, or CMS settings still point to the previous host.
When troubleshooting, compare the old and new environments field by field. In many cases, the issue is a small configuration difference rather than a major failure.
Tips for minimizing downtime
The best way to keep downtime low is to prepare the new host in advance, test thoroughly, and switch DNS only after the site is fully functional. For dynamic sites, you may also need a content freeze period so new updates are not lost during the final sync.
Practical ways to reduce disruption
- Lower DNS TTL before the move.
- Keep the old host active until propagation is complete.
- Avoid making content changes during the final sync window.
- Test on a temporary URL before publishing.
- Have a rollback plan ready.
For busy websites, you can also migrate a copy to the new server first, then briefly pause updates, repeat a final database sync, and switch DNS immediately after validation.
When to use a migration tool or managed support
Manual migration works well for many small and medium websites, but larger sites or complex environments may benefit from automated migration tools or provider-assisted support. This is especially helpful if you are moving between Plesk servers, transferring multiple domains, or handling a site with email, databases, and custom application components.
Good candidates for assisted migration
- Multi-site WordPress installations.
- E-commerce websites with large databases.
- Sites with custom server rules or application dependencies.
- Hosting moves involving email and DNS changes.
- Projects with limited maintenance windows.
Managed hosting teams can often reduce migration risk by copying the account structure, validating permissions, and checking the environment after the move. However, you should still review the end result to ensure all business-critical functions work properly.
FAQ
How long does it take to transfer a website to a new hosting provider?
The file and database transfer itself may take from a few minutes to several hours, depending on site size and server speed. The full migration can take longer because DNS propagation may continue for up to 24 to 48 hours, though many changes happen faster.
Will my website go offline during migration?
It does not have to. If you prepare the new host first, test it before the DNS change, and keep the old account active during propagation, downtime can be kept very low. Some short disruption may still happen if the site changes frequently during the cutover.
Do I need to move email accounts too?
Only if your email is hosted with the same provider and you want mail to move as well. If email stays on a separate service, update DNS carefully so website records change without breaking MX or authentication records.
Can I migrate a WordPress site manually?
Yes. A WordPress migration usually involves copying the wp-content directory, exporting and importing the database, and updating wp-config.php. You should also review site URLs, permalink settings, and plugin compatibility after the move.
What if the new host uses Plesk?
Plesk can simplify migration by providing tools for domains, databases, mailboxes, and file management. If your previous server also uses Plesk, the transfer may be more straightforward. Even so, you should confirm domain mappings, PHP settings, and SSL configuration after the migration.
Should I change nameservers or just the A record?
Either can work. Changing the A record is often simpler if you want to keep DNS management where it is. Changing nameservers moves DNS management to the new provider. Choose the method that best fits your hosting and support setup.
Conclusion
Transferring a website to a new hosting provider is safest when it is handled as a planned migration with clear steps: back up the site, prepare the new hosting environment, move files and databases, test before switching DNS, and validate the live site after cutover. If your website also uses email, SSL, or custom application settings, include those in the checklist so nothing is overlooked.
For hosting and managed hosting environments, especially those using control panels like Plesk, the process can be efficient when each component is verified in order. Careful planning, complete backups, and post-migration testing are the keys to keeping downtime low and ensuring the website works correctly on the new platform.