# Having someone else’s site taken over

> Taking over a site is not an administrative act, it is a technical decision. Before accepting, I look at three things: what has been edited in the software core, what is documented nowhere, and what is not in your name. Those three points settle whether a takeover is reasonable, expensive or ill-advised.

- Source canonique : [https://allaux.fr/en/creation/reprendre-un-site-existant](https://allaux.fr/en/creation/reprendre-un-site-existant)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## What I read first, and why

The first question is not “does the site work”, it is “what happens if we update it”. The answer sits in one precise place: have core files been edited directly?

On PrestaShop, clean extension goes through a module or an override placed in the directory provided for it. On WordPress, through a plugin or a child theme. Where those mechanisms were respected, a version step is predictable work. Where code was written into original files, every update wipes it, and nobody knows what disappeared — because nothing records it.

Then comes the question of traces: is there a source repository, a test environment, any note explaining why something was done? A site with no history is not modified, it is explored. That exploration is billed time producing nothing visible, and it is the part clients find hardest to accept — rightly, since they pay for it without having caused it.

## What I check before pricing anything

- Core files, compared against a reference install of the same version. That is what reveals direct edits, including ones nobody mentioned.
- The module and plugin estate: which are active, which are abandoned by their publisher, which were edited after installation.
- Whether a source repository and a staging environment exist. Without them every change happens straight in production, which I refuse on a shop that sells.
- Backups: their existence, their frequency, and above all proof that a restore has already been performed. A backup never restored is not a backup.
- The PHP version and the platform version, to know whether we work on a base still receiving fixes or on an abandoned one.
- Access: who holds the domain, the hosting, the back office, the payment accounts and the carrier accounts. This is where the nastiest surprises live.
- Scheduled tasks and outbound connections, often invisible in the interface yet vital: synchronisations, accounting exports, merchant feeds.

## How a takeover runs

1. **Back up before touching anything** — Files and database, a copy pulled off the original server, a restore verified on a separate environment. Until that copy exists and works, no work begins.
2. **Reproduce the site outside production** — A working copy you can break without consequence. That is where exploration happens, not on the shop taking money. Without that environment, a takeover becomes a series of live incidents.
3. **Map what was changed** — Comparison against a reference install, an inventory of overrides, a list of non-standard modules. The result is a document that belongs to you, including if you then choose to work with someone else.
4. **Restore ownership of access** — Domain and hosting in your name, administrator accounts recreated, old accounts disabled, API keys and tokens renewed. This step is independent of the technical work and it takes priority.
5. **Then decide, with figures** — Take it over, tidy it progressively, or rebuild. That decision comes after the audit, not before — and sometimes the honest answer is not to take it over.

## When I decline a takeover

> A core rewritten with no trace, on a version no longer patched, with no usable backup and no complete access: in that configuration every change creates a risk I cannot control, and I say so rather than bank a first invoice. I also decline to work straight in production on a shop that sells, with no working copy. That is not posturing: it is the only way not to turn a problem into an outage.

## Related pages

- **Previous supplier unreachable** — The emergency case: establishing what you own when nobody answers any more. ([/problemes/prestataire-precedent-injoignable](/problemes/prestataire-precedent-injoignable))
- **Site left without maintenance** — What degrades when nobody looks after a site for months. ([/problemes/site-laisse-sans-maintenance](/problemes/site-laisse-sans-maintenance))
- **Override or PrestaShop module** — The technical criterion separating clean extension from a time bomb. ([/guides/override-ou-module-prestashop](/guides/override-ou-module-prestashop))
- **Module estate audit** — The detailed inventory of modules installed, active, abandoned or edited. ([/modules/audit-du-parc-de-modules](/modules/audit-du-parc-de-modules))

## FAQ

### Does changing supplier mean redoing everything?

No, and it is rarely the right answer. A working, up-to-date, cleanly built site is taken over without particular difficulty. What triggers a rebuild is not the change of hands: it is a core edited without trace, an abandoned version, or catalogue modelling wrong at the root.

### What does the entry audit cost?

It is a short, bounded piece of work billed by the day, whose deliverable is a document: what was changed, what is at risk, what access is missing, and a ranking of the fixes. That document stays with you, including if you hand the rest to someone else. That is deliberate: paying for an audit only to end up captive would make no sense.

### Can a site be taken over without the original source code?

The code is on the server: with full hosting access you have the code, repository or not. What is missing is the history — why a change was made, what was tried, what was abandoned. That is recoverable, but it is paid for in exploration time.

### What if the previous supplier keeps access?

Revoke it, without negotiation. Administrator accounts deleted, passwords changed, API keys regenerated, server and database access reviewed. Access left open is not only a security risk: it also guarantees a change can appear with nobody knowing where it came from.

### Do you maintain a site you did not build?

Yes, and it is the most common situation in my work. The condition is the entry audit: I do not maintain code I have not read. A contract signed without that reading would commit me to a state I do not know, which always ends badly, for you as much as for me.