Available for projects & agency overflow · Quick reply, from the person who does the work

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

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.

Describe my issue Send a message

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.

Carry on with the right page

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

depart
arrivee
catalogue
contraintes (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

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.

Related pages