# PrestaShop site rebuild or repair: what actually needs redoing?

> A PrestaShop site rebuild resets things that worked. Before ordering one, you need to know what actually bothers you: in half the cases I see, the problem comes down to three targeted jobs, and the rebuild budget would have paid for five years of maintenance.

- Source canonique : [https://allaux.fr/en/creation/refonte-ou-reparation](https://allaux.fr/en/creation/refonte-ou-reparation)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Short answer

> Rebuild your PrestaShop site when the problem sits in the foundations: a version that no longer gets security fixes, a badly modelled catalogue, a core edited with no record, or a business that has changed in nature. For everything else — slowness, a dated design, mobile display, errors after an update — a targeted repair costs far less and puts neither your rankings nor your order history at risk.

## What “redoing the site” means in practice

The word covers three very different projects, priced one to ten. The first is a theme change: the shopfront changes, catalogue, orders and addresses stay. The second is a rebuild on the same platform: new install, new theme, catalogue reimported, addresses recalculated. The third is a platform change, which adds translating the product model and replacing every module.

Conflating the three is the classic quoting error. A supplier answering “rebuild” to a modernisation request sells the third project when the first would have done. A supplier proposing a theme where catalogue modelling is broken will have you back at the till in eighteen months.

So the useful question is not “should we redo it”. It is: what exactly cannot be fixed on what exists? Until someone answers that in writing, rebuild quotes are not comparable.

## What looks like a rebuild need and is not

- “The site is slow.” Slowness almost always comes from a module, an unindexed query or undersized hosting. Rebuilding with the same modules on the same server reproduces it exactly.
- “The design looks dated.” A theme changes without touching the catalogue or the addresses. It is the only item here with immediate visible effect, and the least risky.
- “It is not mobile-friendly.” That is template and stylesheet work, not a reconstruction. Unless the theme is so old it never had a mobile version at all.
- “We can no longer change anything.” Usually the symptom of a theme edited without a child theme, or accumulated overrides. The fix is tidying up, not a clean slate.
- “Rankings are dropping.” A rebuild lowers rankings, it does not raise them. A drop has an identifiable cause, and it is fixed where it is.
- “We want to add a feature.” A new need is built on what exists. Rebuilding the site in order to add a function is the most expensive reasoning available.

## Five cases where rebuilding is justified

1. **The catalogue model is wrong at the root** — Variants created as separate products, or features used as attributes. Everything else — filters, stock, pricing, merchant feeds — inherits the error. Fixing it means rewriting the catalogue and its addresses: that is a rebuild, so call it one.
2. **The installed version is no longer maintained** — No more security patches, an end-of-life PHP base, modules whose publishers have vanished. From then on every update is a gamble, and you are the site’s insurer.
3. **The core has been edited directly** — Kernel files rewritten, with no source repository and no record of what changed. Any version step wipes the work. On an old site, recovering those edits sometimes costs more than rebuilding cleanly.
4. **The business has changed in nature** — Moving to B2B, going international, adopting a management system, multistore. These are not additions: they are different data models, which the current platform may not carry.
5. **Nobody can work on it any more** — No documentation, no complete access, code that three successive developers declined to take on. The rebuild then becomes an economic decision, not a technical one.

## Rebuild or repair: what each option commits you to

A repair fixes an identified fault on the existing install: a crashing module, a slow SQL query, an override that no longer fits, a page returning a PrestaShop 500 error. Addresses, customer accounts, order history and settings stay where they are. The risk is limited to what is touched, and it is tested on a copy before going live.

A rebuild starts again: new install, theme redone or replaced, data carried over, modules reinstalled or swapped for equivalents. It flattens everything that had built up, good and bad alike. The risk covers the whole site at once, which is why a rebuild takes longer to prepare than to develop.

Between the two sits an often forgotten route: a version upgrade that keeps the data, replacing the foundations without starting from scratch. That is what a PrestaShop migration from 1.7 to 8, or 8 to 9, covers. On a very old shop the route closes: a PrestaShop 1.5 to 8 migration is in practice a rebuild with data recovery, and is priced as one.

## Taking over a PrestaShop site: read what exists before redoing it

Many rebuild requests arrive when the supplier changes: the old one has gone quiet, the new one offers to redo everything. Understandable — taking over someone else’s code means reading it first — but it is not a technical reason. Rebuilding to avoid understanding is paying twice for what works.

So before quoting a rebuild, I read what is there: what was changed in the core, the contents of the override/ folder, modules whose publisher has vanished, the PHP version actually supported, and access that is not in your name. The review is short and billed by the day. Its deliverable states plainly what can be repaired, what must be redone, and in which order. The full approach is set out in taking over a PrestaShop site left by another supplier.

## What you lose by rebuilding, and nobody costs

> Rankings earned on the old addresses, if the redirect plan is not written first. Order and customer history, if data migration is not in the quote. The fine settings accumulated over years of trading: pricing rules, shipping exceptions, custom statuses, email templates. And your team’s habits, since they must relearn the back office. These four lines exist in every rebuild; they only appear in honest quotes.

## PrestaShop site rebuild: indicative costs and timescales

These are ballpark figures to get your bearings, consistent with the pricing page. The real price depends on the state of the code, the volume of data and the number of modules to carry over; it is set after a conversation, never before.

Targeted repair (failing module, localised slowness, override to fix): billed on time spent, from a few tens to a few hundred euros per job. On a sound base, it is counted in hours.

Improvement or new feature on the existing site: from around €500 for a targeted feature, more depending on the scope agreed at the outset.

Version upgrade or rebuild with data carried over: usually between €1,000 and €8,000, depending on catalogue and history volume, the number of modules to replace and whether the platform changes. A simple shop takes a few days of work; one with custom modules or a heavily customised theme takes several weeks.

Preliminary audit: a short engagement billed by the day, which settles repair versus rebuild before any commitment on the rest.

Graphic design mock-ups are not included by default: if the rebuild includes a bespoke new design, it comes on top. As for the schedule, it depends less on development than on everything around it: mock-up approval, catalogue clean-up, the redirect plan, testing the checkout. The shop budget and realistic launch timescales pages show where the money and the weeks really go.

## Related pages

- **Rankings lost after a rebuild** — What happens when the redirect plan was missing, and what can still be recovered. ([/problemes/referencement-perdu-apres-refonte](/problemes/referencement-perdu-apres-refonte))
- **Fashion e-commerce rebuild** — A real release, including catalogue and address migration. ([/realisations/refonte-ecommerce-pret-a-porter](/realisations/refonte-ecommerce-pret-a-porter))
- **Performance and technical SEO** — Treating slowness where it lives, rather than rebuilding the site for it. ([/services/performance-web](/services/performance-web))
- **PrestaShop migration** — Moving major version without starting over: what it genuinely involves. ([/prestashop/migration](/prestashop/migration))
- **PrestaShop 1.5 to 8 migration** — On a version that old, migrating means rebuilding: what is carried over, what is redone. ([/prestashop/migration/1-5-vers-8](/prestashop/migration/1-5-vers-8))
- **Taking over an existing PrestaShop site** — What I check before accepting a takeover, and what makes it reasonable or not. ([/creation/reprendre-un-site-existant](/creation/reprendre-un-site-existant))
- **SEO during a rebuild** — The redirect plan and address inventory are prepared at scoping, not on cutover day. ([/creation/referencement-pendant-une-refonte](/creation/referencement-pendant-une-refonte))
- **Broken display after a theme change** — The symptom that makes a rebuild look necessary, and which is fixed in the theme. ([/prestashop/problemes/bugs-css-responsive-apres-theme](/prestashop/problemes/bugs-css-responsive-apres-theme))

## FAQ

### How do I know whether my PrestaShop site needs a rebuild or a repair?

Write the list of what bothers you, without naming a solution. Then, against each line, ask: can this be fixed on the current install? If most answers are yes, you do not need a rebuild, you need a ranked improvement plan. If the blockers touch the data model or an unmaintained version, the answer tips the other way.

### How much does a PrestaShop site rebuild cost, and how long does it take?

A version upgrade or a rebuild with data carried over usually falls between €1,000 and €8,000, excluding graphic design, depending on catalogue volume and the number of modules to replace. A simple shop takes a few days of work, a heavily customised one several weeks including approvals. A targeted repair, by contrast, is billed on time spent and counted in hours. The exact figure follows a conversation or an audit, never the other way round.

### Can the design be redone without touching the rest?

Yes, and it is often the best ratio of visible effect to risk. A theme change alters neither addresses, nor orders, nor customer accounts. The watch points are modules injecting their display into theme hooks, and customisations made directly in the old theme with no child theme.

### Does a rebuild always cost traffic?

No, but it costs traffic by default. Traffic survives if every old address redirects to its real equivalent, if the content carrying the rankings is carried over rather than trimmed, and if the new site is not slower than the old one. Those three conditions are work, therefore quote lines.

### Should I switch platform while I am at it?

Only if the current platform prevents something specific. Switching because another is fashionable adds product model translation, repurchasing every module equivalent and a learning curve, for a result your customers will not see. The good reason to switch is a named constraint.

### How long do we keep the old site available?

The old site stops at cutover, but a complete, working backup including the database is kept for several months. That is not excess caution: gaps surface over weeks — an invoice template, a forgotten pricing rule, a customer file. Without a usable copy, those are gone.