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

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.

Describe my issue Send a message

An opened code structure inspected with a magnifying glass, with an incomplete folder and a key ready to be handed over.

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.

Related pages

Frequently asked questions

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.

Describe your need in one minute

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

attente
plateforme
historique (facultatif)
frequence-souhaitee (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.

Related pages