What Breaks the Week After You Migrate to PrestaShop
Launch day almost always goes fine. That is a false signal
A migration that "works", in the narrow sense that the new store runs and takes orders, is relatively easy to pull off: products, prices, stock and order history are structured data, import tools move them reasonably well, and on day one everything looks fine. The real problems do not show up on launch day, they show up seven to ten days later, when visitors arrive carrying an old URL they had bookmarked, when Google resumes crawling with the map of addresses it had before, and when someone notices a feature that "used to be there" is gone, not because anyone removed it on purpose but because no import tool ever considered it in the first place. This is not an article about how to migrate (specialized services exist for that, it is not what we do): it is about what to check the week after, once the store is already live and the list of problems starts surfacing on its own.
Dead URLs, not by the dozen: by the hundred
The most underestimated problem is scale. People migrating expect to fix "a handful of URLs", not the entire address structure. In practice almost no platform shares another one's URL scheme: a catalog that lived under /product/product-name/ on WooCommerce, under /category-name/product-name.html on Magento, or under /products/product-name on Shopify, arrives on PrestaShop with yet another scheme, often carrying the product's numeric ID in the address. Every single URL a search engine had indexed, every link another site or a customer had saved, now points to a path that simply does not exist on the new store. On a catalog of a few thousand products, with categories, indexed filter pages and editorial content, the number of URLs needing a remap easily reaches a few hundred even for a mid-sized store, it is not an edge case reserved for large catalogs.
The correct practice, almost never done in time, is to export the full list of URLs the old platform had indexed (from Google Search Console, not from the old site's sitemap, which is often already incomplete) before the switch, and build the redirect map as part of the migration plan, not as a follow-up once the first lost-traffic reports come in.
The cookie banner that stopped telling countries apart
A rushed multi-language migration almost always carries over text and settings built for the main language, and cookie consent configuration is one of the first places this shows: a banner that used to correctly tell the audience apart by language or country sometimes reverts to a single default after migration, or worse, shows untranslated text for secondary languages (we found and fixed a defect of exactly this shape, not caused by a migration but by the same underlying cause, text covering only two languages out of five, in our own cookie consent module in September 2026). It is worth re-checking consent configuration on every active language right after the switch, not just on the main one the testing was actually done on.
Compliance data the import tool never knew to look for
Import tools move well whatever already existed as a concept on the source platform: price, description, images, categories. A field like "GPSR manufacturer", "safety warning for this specific product" or "EU authorised representative" often did not exist as structured data on the old platform at all, so no import tool could carry it, simply because there was no source field to copy it from. The real risk is a migrated store assuming "if it was fine before, it is fine now", when in fact the compliance gap, if it existed, was already there before and the migration only makes it more visible, by forcing a rethink of product data from scratch.
Internal search starting from zero
If the previous store had a search engine tuned over time, with synonyms added by hand after customers searched a term and found nothing, with stopwords calibrated to the catalog's language, with a relevance order corrected after months of watching what customers actually clicked, none of that tuning travels with a product import. It is work done on search behavior, not on catalog data, and no migration tool can move it because it is not even a "data point" in the usual sense, it is accumulated configuration. The typical symptom is a drop in internal-search conversions in the first weeks, not because the new engine is inherently worse, but because it starts from a generic default instead of months of corrections.
Product feeds still pointing at the old scheme
A Google Shopping or marketplace feed is built on the source platform's URLs and identifiers. After migration, unless the feed is rebuilt from scratch on the new address scheme, every listing keeps pointing at a URL that returns a redirect or, worse, a 404: past a certain percentage of broken links, Google Merchant Center starts flagging the feed and can suspend ad visibility, which is a direct, immediate commercial hit, not just an organic-ranking issue.
A first-week checklist
- Compare the list of URLs indexed before the migration (from Search Console) against what returns a 200 today: every missing URL either needs a permanent redirect to the equivalent content, or a deliberate closure if the content genuinely no longer exists.
- Check the cookie banner on every active language and country, not just the main one.
- Re-audit product compliance data (GPSR included) on the assumption the import did not carry it, because it almost certainly did not.
- Track internal-search conversions separately for the first two weeks, it is the fastest signal for whether the search configuration needs rebuilding.
- Rebuild the product feed on the new URL scheme before turning campaigns back on, not after noticing the drop.
In short
The week after a migration is not a quiet settling-in period, it is when the problems launch day could never have shown up: URLs nobody remapped, settings with no source field to be copied from, months of tuning (search, consent, feeds) that simply never existed as a "data point" to migrate. A redirect manager and 404 monitor, such as cll_seoredirect, helps spot these gaps as they open instead of after visitors have already noticed, but the checklist above holds regardless of which tool ends up covering it.
