PrestaShop to Shoptet migration

PrestaShop gives full control, but that control comes with server administration, PHP upgrades, module compatibility checks and a developer on call. For many Czech and Slovak shops, a large part of the module stack exists only to cover local needs: Czech carriers like Zásilkovna and PPL, local payment gateways, invoicing with Czech VAT rules, and XML feeds for Heureka and Zboží.cz. Shoptet is built for that market, and much of it is available natively or through the Shoptet add-on marketplace, depending on your plan.

The trade-off is flexibility. PrestaShop lets you change anything through a module or an override; Shoptet offers a defined set of fields, templates, settings and add-ons. Stores with heavy custom logic, complex B2B pricing, or a sales strategy that extends well beyond Central Europe should compare Shoptet with other targets before committing. We say so during the audit if Shoptet is not the right fit.

PrestaShop combinations map to Shoptet variants. Shoptet's own PrestaShop import guide works this way: the product ID becomes the product code, the combination ID becomes the pair code that groups variants, and each attribute group becomes a variant column. We follow that model but go further than a straight export: combination references and EANs become variant codes, price impacts are resolved into final variant prices, and stock is carried per variant. Attribute groups with inconsistent naming across years of catalog work are cleaned first, because Shoptet variant parameters work best with one consistent set of values.

PrestaShop features, the specification table used for filtering and comparison, become Shoptet parameters. Parameters and their values are set up in Shoptet before products are imported, and we decide which become filtering parameters and which are informational only. Categories keep their tree; products that belong to several categories keep those assignments, and the PrestaShop default category becomes the product's primary category in Shoptet so breadcrumbs and feeds stay consistent.

Packs, virtual products, customization fields and customer-group or specific prices need a decision per case, because Shoptet models them differently and some depend on add-ons. We mark those items as assess until the audit confirms the approach.

Customers, billing and delivery addresses, company details (IČO and DIČ where stored) and group membership are imported into Shoptet. Newsletter consent is carried as recorded, and we check it matches your GDPR records. Whether existing password hashes can be reused on Shoptet is something we treat as an open question for each project; the safe plan is a password reset flow, announced to customers in advance.

Order history can matter to your customers and to your support team. How much of it can be imported into Shoptet, and in what form, depends on the import route available for your plan and on add-ons, so we confirm it during the audit. Where orders do move, they are historical records, not live orders, and invoices remain authoritative in your accounting system.

PrestaShop friendly URLs are set under SEO & URLs and usually include numeric IDs, for example /{category}/{id}-{rewrite}.html for products and /{id}-{rewrite} for categories, with a /cs/ or /sk/ prefix when several languages are active. Many stores have changed these patterns over time, so older URL generations are still indexed and linked. Shoptet generates its own URL format for products, categories and articles, and does not let you reproduce PrestaShop's ID-based paths.

We crawl the live PrestaShop store, add URLs from the sitemap, Search Console and analytics landing pages, and map every relevant URL to its Shoptet equivalent: products, categories, manufacturers, CMS pages and blog posts. Meta titles, descriptions and headings move with the content. Redirects are loaded through Shoptet's redirect settings; we confirm the import method and any volume constraints for your plan during the audit, and test the map on the new store before the domain switch. After launch we recrawl, compare with the old crawl, and watch Search Console for 404s and coverage changes. This protects URL continuity; it does not guarantee rankings.

We list every active PrestaShop module and decide what replaces it: a native Shoptet function, a Shoptet add-on, an external service connected through Shoptet's import or API options, or nothing because it is no longer needed. Typical candidates are carrier and payment modules, invoicing and accounting exports, comparison-site feeds, product reviews, loyalty programmes, and ERP or warehouse connectors. Module data stored in its own tables, such as reviews or loyalty balances, is moved only where the replacement accepts it.

The theme is rebuilt on a Shoptet template; Smarty templates and PrestaShop overrides do not carry over. Checkout, payment methods, shipping and VAT are configured in Shoptet rather than migrated. Feeds for Heureka, Zboží.cz and marketplaces are regenerated from Shoptet and checked against the old feeds so product IDs and categories used by those services stay consistent.

Many Czech PrestaShop stores also sell to Slovakia, sometimes with a separate shop in multistore, sometimes with a second language and currency in one shop. Shoptet's options for foreign-language versions and additional currencies depend on the plan and on how you want to run the markets, so we treat multilingual and multistore setups as assess items. The audit compares how your PrestaShop shops actually differ, by assortment, prices, language or legal entity, with what Shoptet supports, and proposes one Shoptet project or several.

Audit: we review the PrestaShop database and admin, modules, overrides, languages, shops and URL history, and list open decisions. Mapping: combinations, features, categories, customer groups and URLs are mapped in a document you sign off. Trial migration: a full import into your Shoptet project, followed by checks on counts, variant codes, prices with VAT, stock, parameters and redirects, with differences listed for your review.

After sign-off we agree a freeze window, run the final import and a delta migration for new orders, customers and stock changes, then switch the domain following Shoptet's domain-transfer process. Post-launch QA covers product and category pages, filters, checkout, emails, feeds and Search Console. Scripts help compare the old and new data; a person approves every production decision.

Shoptet's own guidance notes that only part of PrestaShop's data can be exported and transferred through the standard route, and that imported products usually need further editing. Custom module logic will not come across as code; it is replaced or dropped. Password reuse, full order history, multi-language setup and some pricing rules depend on your plan, add-ons and the import route, so we confirm them before quoting. And after any platform change search engines re-evaluate the site; we check URLs, metadata and indexing, but do not promise traffic or positions.