# My site broke after changing host

> The files are there, the database is there, and yet one feature refuses to work. In almost every case I handle, nothing was lost during the copy: the new server is simply not configured like the old one, and the site relied on details of the old environment that nobody documented.

- Source canonique : [https://allaux.fr/en/problemes/panne-apres-changement-d-hebergeur](https://allaux.fr/en/problemes/panne-apres-changement-d-hebergeur)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Update the site address in the database first: the ps_shop_url table on PrestaShop, wp_options.siteurl and home on WordPress. An address still pointing at the old server distorts every later test. Then compare the PHP extensions loaded on both hosts, intl, gd, zip and curl being the ones most often missing, and confirm .htaccess is actually read, otherwise no URL rewriting works.

## The six differences that break a site

1. **The PHP version** — The first to check. A recent server offers a newer version by default, and an old module that tolerated the previous one stops dead. The symptom is a fatal error, not a warning.
2. **Missing PHP extensions** — Image processing, archives, encryption, connecting to an external service: each depends on an extension. If it is not installed, that one feature fails on its own, the rest of the site works, and the diagnosis goes the wrong way.
3. **Address rewriting** — If the rewrite module is not active, the home page shows and every other page returns not found. The most recognisable symptom on this list.
4. **File permissions** — A copy made with a different account leaves directories the web server can no longer write: image uploads fail, the cache is not regenerated, logs stay empty.
5. **Database character set** — A database recreated with a different character set turns accents into symbols across the whole catalogue, with no error raised at all.
6. **Scheduled tasks and mail sending** — Neither automated tasks nor the sending configuration travel with the files. They must be recreated, and their absence only shows up days later.

## What shows immediately and what shows later

Immediately visible failures — blank page, broken addresses, mangled accents — are the cheapest: they are dealt with the same day. Silent failures are more troublesome. A scheduled task that was never recreated only surfaces the day the product feed goes stale. Unconfigured mail sending is only noticed when a customer reports a missing confirmation.

That is why I consider a hosting migration finished not on switch day, but after a week of checks: a complete test order, verified mail sending, scheduled tasks run at least once, backups reconfigured and verified.

## Keep the old server reachable for a few weeks

> While the old hosting stays in place, comparison is possible: PHP version, active extensions, server settings, directory contents. Cancelling immediately to save a month’s subscription removes the only available reference.

## Carry on with the right page

- **Changing host on PrestaShop** — The full procedure and PrestaShop-specific settings. ([/prestashop/migration/changer-d-hebergeur](/prestashop/migration/changer-d-hebergeur))
- **Changing host without downtime on WordPress** — The WordPress switch, with the final database sync. ([/wordpress-woocommerce/migration/hebergeur-sans-interruption](/wordpress-woocommerce/migration/hebergeur-sans-interruption))
- **File permissions on an e-commerce server** — If image uploads or cache writing no longer work. ([/guides/droits-fichiers-serveur-ecommerce](/guides/droits-fichiers-serveur-ecommerce))
- **Moving to PHP 8** — If the new PHP version is behind the errors. ([/prestashop/migration/passer-a-php-8](/prestashop/migration/passer-a-php-8))

## FAQ

### How do I find out which PHP version ran before?

If the old hosting is still active, the information is in its control panel. Otherwise the site’s error logs often keep a trace, as do the CMS configuration files.

### Every page except the home page errors out. What now?

That is the signature of inactive address rewriting. Depending on the server, either the relevant module has to be enabled or the rewrite rules moved into the server configuration.

### My accents turned into symbols. Is that recoverable?

Yes if the original database is still available: reimport it with the right character set. If the conversion has already been saved over the data, recovery becomes much heavier.

### Should I copy everything again from scratch?

Rarely. Once the environment difference is identified, the fix targets one specific setting. Copying everything again usually reproduces the same situation.

### How long should a clean migration take?

The transfer itself is short. It is preparation and verification that take time, and I would rather quote a verification window than a switch time alone.