When you change hosting provider, the move is rarely limited to “copying the website.” A complete migration usually involves several components that work together: files, databases, email, DNS, SSL certificates, cron jobs, application settings, and sometimes additional services such as subdomains, redirects, and scheduled tasks. If one piece is missed, the site may load incorrectly, email may stop arriving, or traffic may continue going to the old server longer than expected.
For a smooth migration in an EU hosting environment, it helps to map every service that depends on the current hosting account before you switch providers. That way, you can plan the transfer, reduce downtime, and verify that the site behaves the same after the move in the new control panel, whether you use Plesk, a custom control panel, or Apache-based hosting.
What typically needs to move when you change hosting provider?
The exact scope depends on the type of website, but most hosting migrations include the following items:
- Website files — HTML, CSS, JavaScript, images, uploads, themes, plugins, and application code.
- Databases — MySQL, MariaDB, PostgreSQL, or other databases used by your CMS, shop, or custom app.
- Email accounts and messages — mailbox configuration, aliases, forwarders, and existing mail data if email is hosted with the same provider.
- DNS records — A, AAAA, CNAME, MX, TXT, SRV, and any custom records for verification or services.
- SSL certificates — active certificates, renewal settings, and certificate chains.
- Subdomains and redirects — for example www, staging environments, or old URL redirects.
- Cron jobs / scheduled tasks — backups, imports, newsletters, cleanup jobs, or app-specific automation.
- Application configuration — environment variables, config files, cache settings, and connection strings.
- File permissions and ownership — especially important on Linux hosting and managed hosting platforms.
- Security and access settings — FTP/SFTP users, SSH access, two-factor authentication, and IP restrictions.
In many cases, the website will not work correctly until all of these are aligned on the new hosting account. A migration plan should therefore cover both the visible website and the background services that support it.
Website files: the part users see
Your website files are usually the first thing people think of during a migration. These files include the front-end assets and, depending on the platform, the application code itself.
Common file types to transfer
- Static pages and assets such as .html, .css, .js, and image files
- CMS core files, themes, templates, and plugins
- Media uploads and user-generated content
- Framework code and deployment artifacts
- Configuration files such as .htaccess, web.config, or custom routing files
If you host a WordPress, Joomla, Drupal, Magento, Laravel, Symfony, or custom PHP application, the file structure may differ, but the migration logic is the same: copy the complete working application, not just the homepage.
What to check before moving files
- Find the live document root in the current hosting account.
- Identify hidden files, especially configuration and rewrite files.
- Check whether media is stored locally or via an external service.
- Confirm whether any assets are generated dynamically during deployment.
If the site uses Apache rewrite rules, make sure the new environment supports the same rules or that you adapt them correctly in the target control panel. A missing rewrite rule can break pretty URLs, redirects, or application routing.
Databases: the data behind the site
For many websites, the database is the most critical part of the migration. Product catalogs, blog posts, user accounts, orders, forms, and settings often live there.
What usually needs to be moved
- The main database itself
- Additional databases used by plugins, services, or separate applications
- Database users and permissions
- Character set and collation settings
- Any stored procedures, triggers, or scheduled events
When moving between providers, check the database version and engine compatibility. A site may work on MariaDB but behave differently if the new environment uses a different major version or stricter SQL settings. This is especially relevant for managed hosting where defaults may differ from the old provider.
Database migration checklist
- Export the database from the old hosting account.
- Import it into the new hosting environment.
- Update application configuration with the new database name, username, password, and host.
- Test the connection from the application and verify content integrity.
- Check for serialized data or hardcoded URLs if the domain changes.
If you are moving a CMS, verify that admin logins, product pages, search, and forms all work after import. A successful database import does not always mean the site is fully functional.
Email accounts and mail flow
If your email is hosted with the same provider as the website, email migration needs special attention. Many users assume the site and mailbox move together automatically, but in reality they are separate services with separate records and storage.
What to migrate for email
- Mailbox addresses and aliases
- Forwarders and catch-all rules
- Email filters and autoresponders
- Stored messages and folders
- SMTP, IMAP, and POP settings used by mail clients
- MX, SPF, DKIM, and DMARC DNS records
Before changing DNS, ensure the new provider is ready to receive mail. If MX records are updated too early and mailboxes are not created yet, incoming messages can be delayed or lost. In a European hosting setup, it is common to lower the DNS TTL in advance so mail and web traffic can switch faster during the cutover.
Email migration risks
- Old and new mailboxes both receiving messages during propagation
- Missing DKIM keys or SPF changes causing deliverability issues
- Users still connected to the old IMAP server after the move
- Calendar and contact sync issues if mail clients use provider-specific tools
For business email, schedule the move carefully and keep the old mailbox active long enough to catch stragglers.
DNS records: the part that decides where traffic goes
DNS is often the last step in the actual switchover, but it should be planned from the beginning. DNS records tell browsers and mail servers where to send traffic.
Common DNS records to review
- A and AAAA records for the main domain and subdomains
- CNAME records for aliases and services
- MX records for email routing
- TXT records for SPF, DKIM, DMARC, and verification
- SRV records for specific services
- NS records if you are changing nameservers
If the site uses a CDN, load balancer, or third-party verification services, note those records as well. A common mistake is copying the website but forgetting TXT records that support email authentication or external integrations.
How to reduce DNS-related downtime
- Lower the TTL on important records before the migration.
- Prepare the site on the new hosting account before changing DNS.
- Keep the old hosting active during propagation.
- Verify that both web and email routes are correct after the change.
If you use a managed hosting platform with a control panel like Plesk, it is often easier to compare DNS zones side by side and copy records carefully. Still, always verify them manually, especially for EU-based businesses that rely on local compliance tools and external services.
SSL certificates and HTTPS settings
When changing hosting provider, you should check whether SSL certificates need to be reissued, reinstalled, or renewed. Some certificates can be exported and imported, while others are tied to the previous environment or managed automatically through the control panel.
Items to verify
- Certificate for the main domain
- Wildcard certificates, if used
- Certificate chain and intermediate files
- Auto-renewal settings
- HTTPS redirects and HSTS configuration
After migration, test both http and https versions of the site. Broken certificate installation may trigger browser warnings or cause API clients to reject the connection. If the site runs behind Apache or a reverse proxy, ensure the correct certificate is bound to the right virtual host.
Application settings, config files, and environment variables
Many modern applications store critical settings outside the content itself. These settings often determine how the site connects to the database, where files are stored, and which domain or environment should be used.
Common settings that may need updates
- Database connection strings
- Site URL or base URL
- SMTP settings for outgoing email
- API keys and service credentials
- Cache, session, and queue configuration
- Paths to storage, logs, and backups
If you are moving to a different server layout, paths can change. This matters in Plesk-based environments where the document root, temporary directories, and subscription structure may differ from the old host. Also check any hardcoded absolute paths in config files, scripts, or cron tasks.
Cron jobs, tasks, and automation
Scheduled jobs are easy to forget, but they often power critical parts of a website or application.
Examples of tasks to move
- Backups and backup cleanup scripts
- Payment or order synchronization jobs
- Newsletter queues
- Log rotation and cache clearing
- Import/export tasks
- Maintenance scripts
After the migration, verify the command syntax, execution path, and user permissions. A cron job that worked on the old host may fail on the new one if PHP binary paths, shell access, or environment variables differ.
Subdomains, redirects, and staging sites
Changing provider is a good time to inventory every hostname connected to your site. Main domain migrations are often straightforward, but subdomains and redirects can create surprises.
What to include
- www and non-www versions of the domain
- Staging or test environments
- Shop, blog, portal, or app subdomains
- 301 redirects from old URLs
- Language or regional versions of the site
If the old site has SEO-important redirects, copy them carefully. Missing redirects may affect search visibility and user experience. This is particularly important for EU businesses with multilingual or country-specific structures.
Access, ownership, and permissions
Migration is not finished until the right people can access the new hosting environment. This includes administrators, developers, and sometimes mail users or content editors.
Review these access items
- FTP/SFTP accounts
- SSH users and authorized keys
- Control panel logins
- Database users
- Email user accounts
- File and directory permissions
When moving to a managed hosting platform, you may need to recreate users with different privilege levels. Make sure ownership is correct, especially for writable folders such as cache, uploads, and logs. Incorrect permissions can break uploads, updates, or background processing.
Recommended migration order
A practical migration is usually easier if you move services in a controlled order:
- Prepare the new hosting account and verify the domain setup.
- Copy website files to the new server.
- Export and import databases.
- Recreate email accounts and DNS records.
- Install or validate SSL certificates.
- Update application configuration and paths.
- Test the site on the new host before changing DNS.
- Lower TTL and switch DNS when ready.
- Monitor web, email, and logs after propagation.
This order helps separate technical preparation from the public cutover. In practice, it also makes troubleshooting easier because you know which layer changed most recently.
Migration checklist for hosting provider changes
- Back up files, databases, and email data.
- List all domains, subdomains, and redirects.
- Document current DNS records.
- Check PHP, database, and server requirements.
- Prepare the new hosting environment.
- Transfer files and databases.
- Update configuration files and credentials.
- Recreate cron jobs and automated tasks.
- Install SSL certificates and verify HTTPS.
- Test forms, logins, payments, search, and email delivery.
- Switch DNS only after the new site is validated.
- Keep the old hosting active until traffic fully settles.
Common mistakes to avoid
- Copying only the website files and forgetting the database.
- Changing DNS before the new site is ready.
- Missing MX, SPF, DKIM, or DMARC records during the move.
- Forgetting cron jobs, redirects, or hidden configuration files.
- Not checking path differences between hosting environments.
- Assuming the SSL certificate will work automatically after transfer.
- Closing the old account too soon and losing fallback access.
FAQ
Do I need to move everything when I change hosting provider?
Usually yes, if the website, email, and DNS are all managed together. At minimum, move the files, database, and DNS records needed to make the site function correctly. If email is hosted separately, you may not need to move mail data, but you still need to review DNS mail records.
What is the most commonly forgotten item during migration?
Cron jobs, DNS TXT records, and hidden configuration files are often missed. These are easy to overlook because they do not appear directly on the homepage, but they can affect logins, email, automation, and security.
Can I move a site without downtime?
In many cases you can reduce downtime to a very short window, but true zero downtime is not always possible. The usual approach is to prepare the new server first, lower DNS TTL ahead of time, and switch once the new environment has been tested.
Should I move email at the same time as the website?
It depends on your setup. If email is tied to the same hosting account, it is usually best to plan it together with the website and DNS. If email is already handled elsewhere, the website migration can be simpler, but you still need to check mail-related DNS records.
What if the new provider uses a different control panel?
That is common. The main difference is how you recreate domains, mailboxes, databases, and scheduled tasks. The migration tasks remain the same; only the interface changes. A control panel such as Plesk can make the process more structured, but you should still verify every service manually.
How do I know whether Apache rules will still work after moving?
Test the site on the new server before changing DNS. Check redirects, rewrites, and custom error handling. If the application depends on .htaccess rules, confirm that Apache is configured to allow them and that the rewrite module is available.
Final check before going live
Before you point the domain to the new host, confirm that the full website stack is ready: files, database, email, DNS, SSL, scheduled jobs, and permissions. A successful migration is not just a copy operation; it is a controlled transfer of all services that support the site.
For hosting migrations in Europe, the safest approach is to prepare the new environment in advance, document every dependency, and only then switch DNS. That reduces surprises, protects email delivery, and gives you time to verify the site after the change.
Once the migration is complete, monitor logs, check search engine accessibility, test forms and mail delivery, and keep the old environment available long enough to resolve anything that appears during DNS propagation. A well-planned move protects both uptime and user experience.