# Prevedshop.com - full content for AI and answer engines

> Human-led ecommerce data migrations between platforms (Shopify, WooCommerce, PrestaShop, Adobe Commerce / Magento, BigCommerce, Shopware, OpenCart, Shoptet and 280+ other systems), plus supplier feed integration, data cleanup and SEO redirect mapping.

Canonical site: https://prevedshop.com
Short index: https://prevedshop.com/llms.txt
Sitemap: https://prevedshop.com/sitemap.xml
Contact: info@prevedshop.com
Legal entity: Microservices For Ecommerce s.r.o., Jaurisova 515/4, 140 00 Praha 4, Czech Republic

Usage notes: editorial pages describe common migration patterns, not a guaranteed project scope. Do not infer guarantees about data coverage, downtime, rankings, price or timing. Every migration starts with an assessment of the source, target and samples. When citing, link to the canonical URL of the page in the reader's language.

Services at a glance:
- Managed ecommerce migration: One accountable migration lead coordinates the source audit, mapping, trial runs, launch and post-launch checks across data, SEO and storefront dependencies. (https://prevedshop.com/services/managed-migration)
- Ecommerce replatforming: For stores that have outgrown their platform: we turn the decision, requirements, data, integrations and SEO into one replatforming plan, then run the migration and launch. (https://prevedshop.com/services/ecommerce-replatforming)
- Data cleanup and mapping: We turn inconsistent exports, custom schemas and legacy identifiers into an approved mapping that the target platform can validate. (https://prevedshop.com/services/data-cleanup-mapping)
- SEO and redirect migration: We inventory indexable URLs, map old pages to the most relevant new destinations and verify redirects, canonicals, metadata and internal links before and after launch. (https://prevedshop.com/services/seo-redirect-migration)
- Supplier feed integration: We normalise XML, CSV or API data, define ownership rules and connect catalogue updates without turning the feed into an unreviewed source of truth. (https://prevedshop.com/services/supplier-feed-integration)

## English (en)

### Platform profiles

### Magento migration: moving off (or onto) Adobe Commerce

URL: https://prevedshop.com/platforms/adobe-commerce-magento
Language: en
Last reviewed: 2026-09-25

This page is about changing platform with Magento on one side: most often moving a Magento 1, Magento Open Source or Adobe Commerce store to Shopify, BigCommerce, Shoptet or another platform, and occasionally moving onto Adobe Commerce. It is not about upgrading Magento 1 to Magento 2 or between Magento 2 versions, which is a different kind of project. A named migration lead maps Magento's attribute-heavy catalog, store views and URL rewrites to the target, runs a trial migration you check, and owns redirects, launch and post-launch QA.

#### Magento migration overview: replatforming, not a version upgrade

"Magento migration" is used for two different projects. A version upgrade (Magento 1 to Magento 2, or an older Magento 2 release to a current one) keeps you on Magento; Adobe provides a Data Migration Tool for the Magento 1 to 2 path, and themes, extensions and custom code have to be redone for Magento 2. Replatforming moves the store to a different platform altogether. This page covers replatforming. If a version upgrade is what you need, a Magento development partner is the right choice; if you are weighing an upgrade against a move, the assessment can help you compare.

Stores leave Magento for predictable reasons: Magento 1 reached end of life in June 2020 and still runs in places; Magento 2 needs hosting, patching and specialized developers; Adobe Commerce licence and Cloud costs; and extension conflicts that make every upgrade a project. Stores move onto Adobe Commerce less often, typically for complex B2B requirements, many store views, or deep custom integrations a hosted platform will not support.

#### Migrating from Magento: getting data out

Magento is self-hosted (or runs on Adobe Commerce Cloud), so the data is accessible through the REST API, the admin export, or directly from a database copy. For established stores we work from the database, because that is where the full picture is: EAV attribute tables, attribute sets, configurable, bundle and grouped product relations, store-view-specific values, customer groups, tier prices, and the URL rewrites table.

The EAV model means a single product's data is spread across many tables by attribute type and scope. Values can differ per website and store view, so the export must decide which scope wins for the target. Extensions add their own tables for things like layered navigation, product labels, reviews, rewards, B2B quotes or blog content, and custom modules may hold business logic in PHP rather than data. Magento 1 and Magento 2 have different schemas, so the extraction differs by version, and we confirm the exact version and edition first.

#### Migrating to Magento or Adobe Commerce: how data goes in

When Adobe Commerce or Magento Open Source is the target, the structure has to be designed before import: attribute sets, attributes with their scope (global, website or store view), configurable products and their super attributes, the category tree, websites and store views, and customer groups. Data then goes in through the native import, the REST API, or scripted imports for large volumes and order history.

Moving onto Magento from a hosted platform, customers arrive without passwords and need a reset step, and apps from the old platform are replaced by extensions or custom modules. Hosting, caching, search configuration and a patching plan are part of the project scope, because Magento does not provide them the way a SaaS platform does.

#### What usually needs transformation

Moving off Magento, the catalog is the main work. Configurable products become variant products on the target, which on Shopify means at most three option dimensions per product. Bundle and grouped products need an equivalent on the target (native bundles, an app, or separate products), and custom options that change the price become modifiers, line-item properties or an app. Hundreds of EAV attributes across attribute sets are reviewed: filterable ones become filterable attributes or metafields, the rest become custom fields or are dropped deliberately.

Store views and websites are mapped to the target's model: one store with markets and translations, several stores, or a mix. Customer groups and tier prices become price lists, customer tags or B2B features where the target supports them. CMS blocks and widgets, often with Magento directives in the content, are rebuilt as sections on the target.

#### Extensions, custom modules, themes and integrations

A Magento store's behaviour is spread across marketplace extensions and custom modules: payment and shipping methods, ERP and warehouse connectors, B2B pricing, product configurators, search, feeds and checkout changes. We list each one and what it does for customers or staff, then choose a native feature, an app or extension, custom development, or a deliberate decision to drop it. Logic that lives in custom PHP code has to be understood before it can be replaced, so a code review is part of the audit for customized stores.

Magento themes (layout XML, templates, Luma- or Hyvä-based frontends) do not transfer, so the storefront is rebuilt on the target. Integrations are reconnected and tested with real orders on staging before launch.

#### SEO and URL structure on Magento

Magento stores URLs in a URL rewrites table: product and category URL keys, optional `.html` suffixes, category paths in product URLs, store codes in URLs, and custom rewrites added over the years. Several URLs can point to the same product, and each store view can have its own. We export the rewrites, crawl the live site to see which URLs are actually indexed and linked, and build the redirect map from that evidence rather than from Magento defaults.

Every important URL gets a 301 destination on the target, including category paths, store-view variants, CMS pages and blog posts from extensions. Layered-navigation filter URLs are reviewed separately, because many should not be carried over at all. Titles, meta descriptions and canonical settings move with the content. After launch we crawl again and monitor Search Console. We check redirects and coverage; we do not promise rankings.

#### Limitations and edge cases

Customer passwords depend on the target. Hosted platforms cannot import Magento password hashes, so customers reset their passwords; self-hosted targets are assessed case by case. Stored cards and payment tokens depend on the gateway and never move silently. Adobe Commerce B2B features (company accounts, shared catalogs, quotes, requisition lists) have no direct equivalent on many platforms and need a scoped replacement.

Magento 1 stores often run on old PHP versions and servers, so getting a clean database copy can itself be a task. Multi-website setups with different catalogs, prices and languages may need several target stores, and orders spanning many store views need consistent mapping.

#### How Prevedshop runs a Magento replatforming

A named lead owns the project. We confirm the Magento version and edition, audit the database, attribute sets, store views, extensions, custom modules, integrations and indexed URLs, and write a mapping you approve. The trial migration runs into the target's staging store, and you check it record by record. After sign-off we plan launch: content freeze, final migration, a delta migration of new orders and customers, redirects, DNS and payment tests.

Scripts and automated comparisons check counts, prices, stock and URLs, and a person approves every production decision. After launch we review orders, emails, feeds and redirects, and fix what the first days of traffic uncover.

#### What moves when Magento is the source or target

- Simple and configurable products [transform]: Configurable products and their super attributes become variant products on the target, or are designed as such when moving in.
- Bundle and grouped products [assess]: Depends on the target's bundle support; alternatives are native bundles, an app, or separate products.
- EAV attributes and attribute sets [transform]: Each attribute gets an explicit destination on the target; when moving in, attribute sets and scopes are designed first.
- Category tree [transform]: Nested categories move directly to category-tree platforms and become collections and menus on Shopify.
- Images and media [migrates]: Product images, role assignments and alt text move; store-view-specific labels are checked in the trial.
- Customers, groups and addresses [migrates]: Customer records and addresses move; customer groups are mapped to tags, price lists or B2B features.
- Customer passwords [assess]: Hosted targets cannot import Magento hashes, so customers reset; self-hosted targets are assessed per project.
- Order history [migrates]: Historical orders move as records with statuses, store views and currencies mapped explicitly.
- Reviews [assess]: Native Magento reviews export well; reviews held by an extension depend on its tables and the target's import.
- CMS pages, blocks and blog [transform]: Pages move; widgets, Magento directives and extension blog content are cleaned up or rebuilt.
- URL rewrites and 301 redirects [transform]: The rewrites table and a live crawl feed the redirect map, including store-view and category-path URLs.
- Cart price rules and coupons [rebuild]: Magento's rule conditions rarely map one to one; discounts are rebuilt with the target's rules or an app.
- Extensions, custom modules and theme [rebuild]: Extension features and custom code are replaced by native features, apps or custom work; the theme is rebuilt.
- Store views, websites and translations [assess]: Mapped to one store with markets and translations, several stores, or store views when Magento is the target.

#### FAQ

Q: Do you upgrade Magento 1 to Magento 2?
A: This page is about moving to a different platform, not a Magento version upgrade. A version upgrade is a separate project type, usually handled by Magento developers. If you are deciding between upgrading and replatforming, the assessment compares both routes for your store.

Q: We are still on Magento 1. Where do we start?
A: With a clean copy of the database and a list of extensions and custom modules. Magento 1 has been out of support since June 2020, so the migration plan also has to account for old PHP versions and servers that make exports harder.

Q: What drives the cost of leaving Magento?
A: The number of attribute sets and attributes, configurable and bundle products, store views and websites, extensions and custom modules to replace, integrations, years of order history, and URLs to map. We price after the audit, not from a product count.

Q: Will we lose SEO when leaving Magento?
A: Nobody can guarantee rankings through a platform change. We build the redirect map from the URL rewrites table and a crawl of the live site, carry over metadata, and crawl the new store before and after launch so problems are found and fixed quickly.

Q: Can Adobe Commerce B2B features move to Shopify or BigCommerce?
A: Not one to one. Company accounts, shared catalogs, quotes and negotiated prices need a scoped replacement using the target's B2B features, apps or custom work, which depends on the plan. We assess each feature during the audit.

Sources:
- Adobe Commerce (Magento) - official product page: https://business.adobe.com/products/magento/magento-commerce.html
- Adobe Commerce documentation - How data migration works (Magento 1 to 2 Data Migration Tool): https://experienceleague.adobe.com/en/docs/commerce-operations/tools/data-migration/how-migration-works

### BigCommerce migration services: to or from BigCommerce

URL: https://prevedshop.com/platforms/bigcommerce
Language: en
Last reviewed: 2026-09-25

This page is for established stores with BigCommerce on one side of a platform change: stores moving to BigCommerce from WooCommerce, Magento or another platform, and BigCommerce stores moving elsewhere. BigCommerce is hosted like Shopify, but it keeps a nested category tree, flexible product and category URLs, and a catalog model with variant options, modifiers and custom fields, which changes what has to be transformed. A named migration lead maps your data to that model, runs a trial migration you check, and owns redirects, launch and post-launch QA.

#### BigCommerce migration overview: who moves to it, and who leaves

Stores move to BigCommerce when they want a hosted platform without flattening their catalog. A Magento or WooCommerce store with a deep category tree, many product attributes, B2B price lists or several storefronts often maps more directly to BigCommerce than to platforms built around flat collections. Some teams also choose it as a backend for a headless storefront.

Stores leave BigCommerce for other reasons: a move to Shopify for its app ecosystem or a team's familiarity with it, a move to a self-hosted platform for full code control, or a regional platform that suits their market better. Whether the move makes sense depends on the catalog, the integrations and the team that will run the store, not on feature checklists alone, and we look at those first.

#### Migrating from BigCommerce: getting data out

BigCommerce offers CSV exports for products, customers and orders in the control panel, and a REST API (with both older V2 and current V3 endpoints) that exposes the catalog, customers, orders, redirects, price lists and more. For a full migration we rely on the API, because CSV exports flatten variants, modifiers and custom fields in ways that lose structure.

What does not come out: customer password hashes, stored payment methods, and most data held by apps from the BigCommerce App Marketplace, such as reviews apps, subscriptions, loyalty or search configuration. Each app vendor's export or API has to be checked separately. Stencil theme files can be downloaded, but they only work on BigCommerce, so the storefront is rebuilt on the target.

#### Migrating to BigCommerce: how data goes in

Data goes into BigCommerce through CSV imports, migration apps listed in the BigCommerce marketplace, or scripted imports through the API, which we use for large catalogs, order history and anything the CSV cannot express. The catalog model matters. Variant options create sellable variants with their own SKU, price and stock; modifiers capture choices that do not create a variant, such as engraving text or a gift message; custom fields hold simple name-value specifications. Deciding which source attribute becomes which of these is the core mapping work.

Categories can be nested, so a source category tree often transfers without being flattened. Customer groups and price lists support group-specific or currency-specific pricing, which we map from the source platform's pricing rules. Customers arrive without usable passwords unless the source and the chosen method support something else, which we check per project, and historical orders are imported as records for customer history and reporting.

#### What usually needs transformation

Moving to BigCommerce, the typical work is splitting source attributes between variant options, modifiers, custom fields and filterable attributes, remodelling bundles or configurable products that do not match the option model, and translating customer-group pricing into price lists. Product descriptions with theme markup or shortcodes from the old platform are cleaned up, and order statuses are mapped to BigCommerce's status set.

Moving from BigCommerce, the reverse applies. On a target like Shopify, the category tree becomes collections plus navigation, modifiers become options, line-item properties or an app, and custom fields become metafields. Price lists and customer groups need an equivalent on the target (native B2B features, an app, or a simpler model). Multi-Storefront setups must be mapped to the target's model of markets or separate stores.

#### Apps, Stencil themes, checkout and integrations

Apps are replaced, not moved. Moving in, we list the plugins or apps that do real work in your current store and find the BigCommerce feature or marketplace app that covers each, noting what needs custom development. Moving out, we list the installed apps, what data each one holds and whether it can be exported.

The storefront is built with Stencil themes, customized from a marketplace theme or built from scratch; a headless setup replaces the theme layer with a separate frontend. Payment gateways, shipping rules, tax settings, ERP, PIM, feeds and marketing integrations are configured and tested on staging with real orders before launch. Checkout customization options depend on your plan and setup, and we confirm them before promising any specific checkout behaviour.

#### SEO and URL structure on BigCommerce

BigCommerce lets you set custom URLs for products, categories, brands and pages, and to choose URL formats in its SEO settings. That flexibility helps when migrating in: many old URLs can be matched or kept close, which reduces redirects. It does not happen automatically, though, and it has to be decided in the mapping before import. 301 redirects are managed in the control panel and through the API, and BigCommerce can create redirects automatically when a product or category URL changes.

Moving out, every BigCommerce URL that matters is mapped to the target's structure, including brand pages, blog posts and URLs that already redirect. We crawl the old site before migration, carry over page titles, meta descriptions and image alt text, crawl the new store on staging, and monitor Search Console after launch. We check coverage and redirects; we do not promise rankings.

#### Limitations and edge cases

Customer passwords are handled as a reset or reactivation step unless we confirm a supported alternative for your specific source and target. Stored cards and subscription tokens depend on the payment gateway and never move as part of a data export. Some features, such as 301 redirects, are not available on trial stores, and API limits, storefront counts and B2B features vary by plan, so we check your plan during the audit rather than quoting general numbers.

Multi-currency and multi-language setups need care in both directions: price lists, currency settings and storefront translations do not map one to one onto other platforms. Headless builds add a separate frontend project with its own routing and redirect handling.

#### How Prevedshop runs a BigCommerce migration

A named lead owns the project. We audit the source (catalog structure, attributes, pricing rules, customers, orders, apps, integrations and indexed URLs), write a mapping you approve, and run a trial migration into a non-production BigCommerce store or the target platform's staging store. You check it record by record. After sign-off we plan launch: content freeze, final migration, a delta migration of new orders and customers, redirects, DNS and payment tests.

Scripts and automated comparisons check counts, prices, stock and URLs, and a person approves every production decision. After launch we review orders, emails, feeds and redirects, and fix what the first days of traffic uncover.

#### What moves when BigCommerce is the source or target

- Products, variants and modifiers [transform]: Going in, source attributes are split between variant options and modifiers; going out, modifiers need an equivalent on the target.
- Custom fields and attributes [transform]: Specifications map to BigCommerce custom fields going in, and to metafields or attributes going out.
- Category tree [migrates]: Nested categories map directly into BigCommerce; leaving for Shopify, they become collections and menus.
- Images and media [migrates]: Product and variant images move in both directions, with alt text and image order checked in the trial.
- Customers and customer groups [migrates]: Customer records and addresses move; groups are mapped to the pricing and access model on each side.
- Customer passwords [assess]: Treated as a reset or reactivation unless a supported method exists for the specific route, which we confirm.
- Order history [migrates]: Historical orders move as records for customer history and reporting, with statuses mapped explicitly.
- Price lists and B2B pricing [assess]: Group and currency pricing maps to BigCommerce price lists going in; going out, the target needs an equivalent.
- Reviews [assess]: Depends on whether reviews are native or held by an app, and on the import options of the target.
- Pages and blog posts [migrates]: Web pages and blog posts move with their content; embedded markup and internal links are cleaned up.
- URLs, 301 redirects and SEO metadata [transform]: Custom URLs can stay close to old ones going in; going out, BigCommerce URLs are mapped to the target's structure.
- Coupons and gift certificates [assess]: Coupon rules are rebuilt; gift certificate balances depend on what the target platform can import.
- Apps and Stencil theme [rebuild]: Apps are replaced and the storefront is rebuilt on the target, or built in Stencil when moving to BigCommerce.
- Multi-Storefront and currencies [assess]: Storefronts, currencies and translations are mapped to the target's markets or separate stores, per plan.

#### FAQ

Q: Can we keep our category tree when moving to BigCommerce?
A: Usually yes. BigCommerce supports nested categories, so a multi-level tree from Magento or WooCommerce can often be recreated as it is. We still review it, because a migration is a good moment to fix categories that no longer make sense.

Q: Can our URLs stay the same on BigCommerce?
A: Often many of them can, because BigCommerce allows custom URLs for products, categories and pages. We decide in the mapping which URLs to keep and which to redirect, then test both on staging before launch.

Q: What drives the cost of a BigCommerce migration?
A: The distance between your catalog and BigCommerce's option, modifier and custom-field model, the number of apps and integrations to replace, B2B pricing, the years of order history you want, and the number of URLs to map. We price after the audit.

Q: What happens to our BigCommerce apps if we leave?
A: App data stays with each app vendor. We check which apps offer an export or API, move what is worth keeping, and choose replacements on the target platform.

Q: How long does the store have to be frozen at launch?
A: Only for the final switch. The old store keeps selling during the build and trial, and at launch we run a delta migration of new orders and customers before switching DNS. The length of the freeze is planned with you around your order volume.

Sources:
- BigCommerce - official website: https://www.bigcommerce.com
- BigCommerce - Migrating to BigCommerce: https://www.bigcommerce.com/migration/
- BigCommerce Help Center - 301 Redirects: https://support.bigcommerce.com/s/article/MSF-301-Redirects?language=en_US

### OpenCart migration: moving off OpenCart safely

URL: https://prevedshop.com/platforms/opencart
Language: en
Last reviewed: 2026-09-25

This page is for OpenCart store owners who have outgrown a self-managed PHP store and need to move to another platform without losing orders, customers or search traffic. The main change is structural: OpenCart options are not true variants, SEO URLs are keyword-based and often only half configured, and many features live in extensions or modified core files. A named Prevedshop lead audits the store, maps the data, runs a trial migration and owns the launch; we also handle the less common move onto OpenCart.

#### OpenCart migration overview: who moves off OpenCart and why

OpenCart is self-hosted open-source ecommerce software built on PHP and MySQL. It is light and cheap to start with, which is why many stores began on it. The reasons we see for leaving are consistent: an old version that cannot be upgraded because of core modifications, extensions that are no longer maintained, PHP version pressure from the host, and the effort of keeping a self-hosted store secure. Most OpenCart stores we assess move to Shopify, WooCommerce or, in Czechia and Slovakia, Shoptet.

Moving onto OpenCart is less common but happens, usually for a small catalog where the merchant wants full code access at low running cost. The same data questions apply in reverse.

When not to move: if the store works, is on a supported version and the pain is one extension, replacing that extension is cheaper than a replatform.

#### Migrating from OpenCart: getting the data out

We read OpenCart data straight from the MySQL database, because the admin has no complete built-in export for products, customers and orders. The key tables are `product`, `product_description` per language, `product_option` and `product_option_value` for options, `product_special` and `product_discount` for prices, `customer` and `address`, and `order` with its related total, product and history tables.

The pitfalls come from the ecosystem. Extensions installed through VQMod or OCMOD may add columns or tables that the admin never shows. Some stores have edited core files directly. Options can carry their own price, weight and stock adjustments without a separate SKU. And the version matters: table names and the SEO URL table changed between 2.x and 3.x, and 4.x changed the extension structure again. We confirm the version and schema before writing any mapping.

#### Migrating to OpenCart: how data goes in

Going into OpenCart there is no general-purpose import in core, so we load data with scripts against the database or through an import extension, after the categories, option types and customer groups exist. The model expects options to be defined once and attached to products, SEO keywords to be unique per store and language, and each product to belong to at least one category and store.

If the source store uses real variants with their own SKUs, stock and images, OpenCart's options will hold price and stock adjustments but not a full variant record, so some variant data has to be stored in extension fields or simplified. We agree that trade-off with you before import.

#### What usually needs transformation

The main transformation leaving OpenCart is turning options into variants. Each combination of option values becomes a variant with its own SKU, price and stock, which means we generate SKUs where OpenCart only had option values, calculate prices from base price plus adjustments, and decide what to do with options that are not variant-like, such as text inputs, file uploads or checkboxes. Those usually become line-item properties or product customisation apps on the target.

Other common transformations: `product_special` and `product_discount` become sale prices, customer-group pricing or discounts; manufacturers become vendors or brand fields; attributes become metafields or filterable attributes; information pages become CMS pages. Description HTML from older editors is cleaned so it renders on the new theme.

#### OpenCart extensions, themes and integrations

OpenCart stores rely on extensions for payments, shipping, feeds, filters, reviews, blogs and one-page checkout. Extension data does not move by itself. We list every installed extension and modification, check which tables and settings each one uses, and decide per extension whether its data is exported, replaced by an app on the target or retired.

Themes do not transfer, and themes built for 1.5 or 2.x are also incompatible with 3.x and 4.x, so the storefront is rebuilt on the target. Payment gateways, shipping rates and tax classes are configured again and tested with real test orders. Integrations such as accounting, ERP or marketplace feeds are reconnected and checked with live data before launch.

#### SEO and URL structure on OpenCart

OpenCart SEO URLs work only when Use SEO URL is enabled in the store settings and the web server rewrite rules are in place. Keywords are stored in a lookup table (`url_alias` in older versions, `seo_url` from 3.x) and resolved on each request. Stores without that setup serve URLs such as `index.php?route=product/product&product_id=42`, and many stores have a mix: products with keywords, some without, and category paths that include the parent category.

We crawl the live store, export the keyword table, and combine both with Search Console and analytics data so the redirect map covers every indexed product, category, manufacturer and information page, including query-string URLs. After launch we re-crawl to catch 404s and redirect chains. We do not promise rankings; we make sure old URLs land on the right new page.

#### Limitations and edge cases

Customer passwords: OpenCart hashes vary by version, and hosted targets do not accept them, so customers usually set a new password through an activation or reset email. Stored cards stay with the payment provider. Options that were never meant as variants, such as engraving text, cannot become variants and are rebuilt as product customisation.

Old installs often hold inconsistent data: products without SKUs, duplicate SEO keywords, orders pointing to deleted products. We report these in the audit and fix them in mapping. Multi-store OpenCart setups with shared catalogs may map to one target store with markets, or to several stores; that choice changes the redirect plan.

#### How Prevedshop runs an OpenCart migration

We start with an audit of version, extensions and modifications, catalog and options, SEO URL setup and integrations. Then we write the data mapping, including the option-to-variant rules and SKU generation, and agree it with you. A trial migration loads the full catalog, a sample of customers and orders, and the redirect map into a staging store for your review.

After sign-off we set a short catalog freeze, run the final migration plus a delta of new orders and customers, switch DNS, activate redirects and run post-launch QA: test orders, redirect checks, Search Console monitoring and integration checks. One named lead owns the whole project.

#### What moves when OpenCart is the source or target

- Products and options [transform]: Leaving OpenCart, option combinations become variants with generated SKUs; moving onto it, variants are reduced to options with price and stock adjustments.
- Attributes and manufacturers [transform]: Attribute groups map to metafields or filterable attributes, manufacturers to a vendor or brand field.
- Categories [migrates]: The category tree moves to targets with a tree and becomes collections on platforms that use them.
- Images and media [migrates]: Main and additional product images are transferred; option images are linked to the matching variant where the target supports it.
- Customers and addresses [migrates]: Customer accounts, groups and addresses move; newsletter consent is carried over only where it was recorded.
- Customer passwords [assess]: Hash formats differ by OpenCart version; a hosted target needs a password reset, and we confirm this in the trial.
- Order history [transform]: Orders, totals and status history are mapped to the target's order model and imported as historical records.
- Specials, discounts and coupons [rebuild]: Special prices, quantity discounts and coupons are re-created with the target's pricing and discount tools.
- Reviews [migrates]: Core OpenCart reviews export from the database and import into a review app or the target's review feature.
- Information pages and blog [migrates]: Information pages move as CMS pages; blog content from an extension is exported from that extension's tables.
- SEO URLs and 301 redirects [transform]: Keyword and query-string URLs are mapped to new URLs and redirected with 301s on the target.
- Extension data [assess]: Each extension and OCMOD or VQMod modification is checked for stored data, then exported, replaced or retired.
- Theme and design [rebuild]: OpenCart themes do not transfer to other platforms or across major OpenCart versions; the storefront is rebuilt.

#### FAQ

Q: Is it worth upgrading OpenCart instead of migrating?
A: If the store is on 3.x with few core modifications, an upgrade or a hosting fix may be enough. If it runs 1.5 or 2.x with edited core files and abandoned extensions, an upgrade is close to a rebuild anyway, so comparing it with a move to another platform is sensible.

Q: How do you handle OpenCart options when moving to Shopify or WooCommerce?
A: We turn each valid combination of variant-like options into a variant with its own SKU, price and stock, calculated from the base price plus option adjustments. Options such as text inputs or file uploads are rebuilt as product customisation rather than variants.

Q: Will customers need a new password?
A: In most cases yes, when the target is hosted. Customers receive an activation or reset email. For a self-hosted target we check in the trial whether existing hashes can be kept.

Q: What affects the timeline of an OpenCart migration?
A: The OpenCart version, how many extensions and core modifications exist, how clean the option data is, how much order history you keep, and how many integrations must be reconnected. The audit gives a timeline based on those.

Q: Will we lose search traffic?
A: We cannot promise rankings, but we map every indexed URL, including old query-string URLs, to its new address, set 301 redirects and re-crawl after launch so no indexed page ends in a 404.

Sources:
- OpenCart - official website: https://www.opencart.com
- OpenCart documentation - SEO keywords: https://docs.opencart.com/administration/seo/

### PrestaShop migration services: to or from PrestaShop

URL: https://prevedshop.com/platforms/prestashop
Language: en
Last reviewed: 2026-09-25

This page is for merchants running PrestaShop who are moving to a hosted platform, and for merchants moving onto PrestaShop for self-hosted control. In both directions the hard parts are the same: combinations, features and attributes, module data, and friendly URLs that usually carry numeric IDs. Prevedshop runs the project with a named lead who audits the source, maps the data, runs a trial migration and handles redirects and launch QA; tools help us compare and check, a person signs off production decisions.

#### PrestaShop migration overview: who moves to and from it

PrestaShop is self-hosted open-source ecommerce software built on PHP and MySQL, with a strong installed base in Spain, France, Poland and Czechia. We see two groups. Stores moving off PrestaShop are usually tired of running upgrades, hosting and module compatibility themselves, or want to consolidate on a hosted platform such as Shopify or, in Czechia and Slovakia, Shoptet. Stores moving onto PrestaShop usually want full ownership of code and data, multistore, or a platform local agencies know well.

There are also PrestaShop-to-PrestaShop projects: a 1.6 store that cannot be upgraded in place because of years of overrides and abandoned modules is effectively rebuilt on a current version. We treat that as a migration, with the same audit, mapping and trial run, not as a one-click upgrade.

When not to move: if the real problem is a slow theme, a single broken module or poor hosting, fixing that is cheaper than a replatform. The assessment should tell you which case you are in.

#### Migrating from PrestaShop: getting the data out

Because PrestaShop is self-hosted, we can normally read the MySQL database directly, which is more complete than the CSV export in the back office or the webservice API. That matters because the useful data is spread across many tables: `product`, `product_attribute` for combinations, `feature_product` for features, `specific_price` for customer-group and quantity pricing, per-language tables for translated text, and `_shop` tables when multistore is active.

The pitfalls we look for first are overrides and custom modules that write their own tables or add columns to core tables, combinations that exist in the database but are disabled or have no stock, images stored per combination, and specific prices that no longer apply. Order history is readable, but order states, carriers and payment modules are store-specific, so orders are mapped rather than copied. Customer password hashes depend on the PrestaShop version and the cookie key, and a hosted target will not accept them.

#### Migrating to PrestaShop: how data goes in and what its model expects

Going into PrestaShop we load data through the CSV import for simple catalogs or through scripted imports and the webservice API for anything with combinations, multiple languages or customer history. The target model expects attribute groups and values to exist before combinations are created, features to be defined as reusable feature values, and every product to have a default category in the category tree.

The design decision to make early is what becomes a combination and what becomes a feature. Size and colour that affect stock and price are combinations; material or care instructions are usually features. Getting that wrong produces combinations nobody can filter or features nobody can buy. If you run several shops, multistore settings decide which products, prices and translations are shared, and that has to be designed before import, not fixed afterwards.

#### What usually needs transformation

Most PrestaShop migrations need the same transformations in one direction or the other. Combinations become variants on platforms with option-based models, and PrestaShop allows more attribute groups per product than some targets accept, so we check the maximum per product before promising a one-to-one mapping. Features become metafields, custom fields or filterable attributes, depending on the target.

The category tree is flattened into collections on Shopify, or rebuilt as a tree on platforms that have one. Specific prices and catalog price rules rarely have a direct equivalent and usually become customer-group pricing, price lists or discounts. Multi-language text is split per language and checked for missing translations. Text fields with inline HTML, module shortcodes or absolute image URLs are cleaned so they render on the new theme.

#### PrestaShop modules, themes and integrations

A working PrestaShop store depends on modules for payments, carriers, invoicing, feeds, reviews, loyalty, blogs and ERP connections. Module data does not move by itself. Leaving PrestaShop, we list every active module, check what it stores and decide per module whether its data is exported, replaced by a target app or dropped with your agreement. Moving onto PrestaShop, we pick modules from PrestaShop Addons or plan custom development and load their data after the core import.

Themes do not transfer between platforms, and PrestaShop 1.6 and 1.7+ themes are not compatible with each other either, so the storefront is rebuilt. Checkout, payment gateways, shipping and tax configuration are rebuilt on the target and tested with real test orders. Integrations with ERP, accounting and marketplaces are reconnected and checked against live data before launch.

#### SEO and URL structure on PrestaShop

PrestaShop friendly URLs are configured under Shop Parameters > Traffic & SEO > SEO & URLs, and the default routes include the numeric ID of the product, category or CMS page. Combinations can also produce their own URLs with attribute fragments. When you leave PrestaShop, those ID-based paths cannot be reproduced on most targets, so every indexed URL needs a 301 to its new equivalent. Stores that never enabled friendly URLs have `index.php?id_product=` style URLs, which need query-string-aware redirects.

We crawl the live store before migration, pull top landing pages from Search Console and analytics, build the redirect map per language, and crawl again after launch to catch 404s and redirect chains. Moving onto PrestaShop, we configure routes and language prefixes before import so the new URLs are stable. We do not promise rankings; we make sure no indexed URL is left without a destination.

#### Limitations and edge cases

Customer passwords rarely survive a move to a hosted platform; customers set a new password through an account activation or reset email. Saved payment methods stay with the payment provider and are not migrated silently. Module-specific data such as loyalty points, gift cards or wishlist items may have no import path on the target and is scoped case by case.

Old 1.6 stores often carry data inconsistencies: orphaned combinations, duplicate references, products in deleted categories. We report these during the audit and fix them in mapping, not after launch. Very large multistore installations with different catalogs per shop may need to be split into separate target stores, which changes the URL and SEO plan.

#### How Prevedshop runs a PrestaShop migration

The project starts with an audit: PrestaShop version, modules and overrides, catalog shape, multistore and languages, URL settings, integrations. From that we write the data mapping and agree on it with you. We then run a trial migration into the target, and you review products, customers, orders and URLs on a staging store before anything goes live.

After sign-off we agree a short content freeze, run the final migration plus a delta migration of new orders and customers, switch DNS, activate redirects and run post-launch QA: test orders, redirect checks, Search Console monitoring and a check of integrations. One named lead owns the whole sequence and is the person you talk to.

#### What moves when PrestaShop is the source or target

- Products and combinations [transform]: Combinations become variants when leaving PrestaShop and are rebuilt from attribute groups when moving onto it; the attribute-group count per product is checked against the target.
- Features and attributes [transform]: Features map to metafields, custom fields or filterable attributes, so each feature is assigned a target field in the mapping.
- Category tree [transform]: Flattened into collections or tags on platforms without a deep tree, rebuilt as a tree when PrestaShop is the target.
- Images and media [migrates]: Product and combination images are transferred and re-linked to the right variant; alt text is kept where it exists.
- Customers and addresses [migrates]: Customer accounts, groups and addresses move; customer-group logic is re-created on the target.
- Customer passwords [assess]: Hashes depend on PrestaShop version and cookie key; a hosted target needs a password reset, a self-hosted target may accept them with custom work.
- Order history [transform]: Orders are mapped to the target's order states and carriers so history stays readable; they are imported as historical records, not re-processed.
- Specific prices and cart rules [rebuild]: Catalog price rules, specific prices and cart rules are re-created as discounts, price lists or customer-group pricing.
- CMS pages and blog [migrates]: CMS pages move as pages; blog posts from a blog module are exported from that module's tables.
- URLs and 301 redirects [transform]: ID-based friendly URLs are mapped one by one to new URLs, per language, with 301 redirects on the target.
- SEO metadata [migrates]: Meta titles, descriptions and rewrite slugs move per language where the target has an equivalent field.
- Module data [assess]: Each module is checked for what it stores; data is exported, replaced by a target app or dropped with your agreement.
- Theme and design [rebuild]: PrestaShop themes do not transfer to other platforms, or between 1.6 and 1.7+; the storefront is rebuilt.
- Languages and multistore [assess]: Language versions and multistore shops are mapped to the target's markets, language settings or separate stores.

#### FAQ

Q: What drives the cost of a PrestaShop migration?
A: Mostly complexity rather than product count: the number of combinations and attribute groups, languages and shops in multistore, custom modules and overrides, the amount of order history you want kept, and integrations that must be reconnected. We price after the audit, once those are known.

Q: Can we upgrade PrestaShop 1.6 to a current version instead of changing platform?
A: Sometimes. If the store has few overrides and its modules have current versions, an upgrade can be the cheaper path. If it has years of custom code, a fresh install with a data migration is usually safer, and at that point it is worth comparing it with a hosted platform.

Q: Will our customers have to reset their passwords?
A: If the target is a hosted platform such as Shopify or Shoptet, yes: customers activate their account or set a new password by email. For a self-hosted target it may be possible to keep hashes; we confirm that in the trial migration.

Q: How long is the store offline during the switch?
A: The store stays live while we build and test on staging. At launch we ask for a short freeze on catalog edits, then migrate the delta of new orders and customers before switching DNS. The freeze length depends on data volume and is agreed in advance.

Q: How do you protect SEO when leaving PrestaShop?
A: We crawl the current store, map every indexed product, category and CMS URL to its new address per language, set up 301 redirects and re-crawl after launch. Rankings cannot be guaranteed, but no indexed URL is left without a destination.

Sources:
- PrestaShop - official website: https://www.prestashop.com
- PrestaShop 8 documentation - SEO and URLs: https://docs.prestashop-project.org/v.8-documentation/user-guide/configuring-shop/shop-parameters/traffic/seo-and-urls

### Shopify migration services: moving to or from Shopify

URL: https://prevedshop.com/platforms/shopify
Language: en
Last reviewed: 2026-09-25

This page is for established stores changing platform with Shopify on one side: most often moving to Shopify from WooCommerce, Magento, PrestaShop or another platform, and sometimes leaving it. Shopify is hosted and opinionated, with fixed URL paths, products with up to three variant options, collections instead of a category tree, and no way to import customer passwords. A named migration lead maps your data onto that model, runs a trial migration you can check record by record, and owns the redirects, the launch and the post-launch QA.

#### Shopify migration overview: who moves to Shopify, and who leaves

Most Shopify migrations are moves to Shopify, typically from a self-hosted WooCommerce, Magento or PrestaShop store whose team is tired of hosting, patches, plugin conflicts and developer dependency. Shopify is a reasonable answer when the catalog fits its product-and-variant model and the business can live with its checkout and URL conventions.

The other direction exists too. Stores leave Shopify when app subscriptions pile up, when they need a checkout or catalog logic Shopify will not allow, when a deep category tree or complex B2B pricing keeps fighting the collection model, or when they want full control of hosting and code (often moving to WooCommerce). Neither direction is automatically right. If the reason for moving is a theme that looks dated or a single missing feature, a redesign or one app may be cheaper than a platform change; the assessment should say so.

#### Migrating to Shopify: how data goes in

Shopify's own guidance is to import products first, then customers, then historical orders, so orders can link to the products and customers they belong to. The methods range from manual entry and CSV imports through migration apps from the Shopify App Store to custom scripts against the Admin API. For an established store we normally combine them: CSV or an import app for the bulk of the catalog, and scripted API work for what a CSV cannot express cleanly, such as metafields, metaobjects, order history with the right statuses, and redirects.

The constraints of the model decide most of the mapping work. A product has up to three option dimensions (for example size, colour, material), and every sellable combination is a variant with its own SKU, price and inventory. Extra product data lives in metafields or metaobjects that have to be defined before import. Categories become collections, manual or automated by rules, and a collection is not a tree. Customers arrive without passwords and must be invited to activate their accounts. Imported historical orders are records for reference and customer history, not live orders to be re-fulfilled, and Shopify notes that importing them can trigger new-order notifications to staff unless those are switched off first.

#### Migrating from Shopify: getting your data out

Shopify admin exports CSVs for products, customers and orders, which is enough for a first inventory but rarely for the migration itself. Metafields, metaobjects, collection rules, redirects, blog comments and multi-language content are more reliably pulled through the Admin API, and data held by apps (reviews, subscriptions, loyalty points, wishlists, bundles) lives with each app vendor and needs that vendor's export or API.

Two things cannot come out at all: customer password hashes and stored payment methods. Customers will set a new password on the target platform, and saved cards or subscription payment tokens depend on the payment gateway and its PCI process, never on a data export.

#### What usually needs transformation

Moving to Shopify, the heavy lifting is almost always the catalog. Products with more than three option dimensions, or with options that change price like add-ons or engraving, must be split into separate products, remodelled with bundles, or handled by an app. Custom attributes and specification tables are mapped to typed metafields so they can be filtered and displayed. A multi-level category tree is rebuilt as collections plus navigation menus, and the filters customers used before are rebuilt on metafields or tags. Customer groups often become customer tags or, on Shopify Plus, B2B companies and catalogs, which we check against your plan.

Moving from Shopify, the transformation runs the other way: collections have to become categories, tags that carried business meaning have to become attributes, and metafields have to land in the target platform's custom-field system. In both directions we transform order statuses, tax and shipping lines, and product descriptions that contain theme-specific markup or app shortcodes.

#### Shopify apps, themes, checkout and integrations

Apps from the Shopify App Store replace most plugins or modules from self-hosted platforms, but they are replacements, not ports. Moving in, we list every plugin that does something customers or staff rely on, find the app or native feature that covers it, and flag what needs custom work. Moving out, we list every installed app, what data it holds and whether that data can be exported.

Themes do not transfer between platforms. Shopify themes are built with Liquid, so moving in means adapting a theme from the Shopify Theme Store or building a custom one, and moving out means rebuilding the storefront on the new platform. Checkout customization is limited on standard plans; on Shopify Plus it runs through Checkout Extensibility and Shopify Functions, not edited checkout templates. Payment gateways, shipping rates, tax settings, ERP, PIM, feeds and email marketing connections are configured or reconnected on the target, then tested with real orders before launch.

#### SEO and URL structure on Shopify

Shopify uses fixed URL paths: `/products/{handle}`, `/collections/{handle}`, `/pages/{handle}` and `/blogs/{blog}/{handle}`. The prefixes cannot be removed, so a store moving to Shopify almost never keeps its old URLs. Every indexed URL that matters, including products, categories, CMS pages, blog posts, and old URLs that already redirect, needs a mapped destination, uploaded as URL redirects in Shopify admin (Online Store > Navigation > URL redirects). Shopify applies a redirect only when the old path no longer resolves to a live page, so we test the map after import, not just before.

Leaving Shopify, the fixed paths are predictable, which makes the redirect map simpler, but the target platform must be able to serve 301s for the old `/products/` and `/collections/` paths. Either way we crawl the old site before migration, carry over titles, meta descriptions, alt text and canonical intent, crawl the new store on staging, and watch Search Console after launch. Nobody can guarantee rankings through a platform change; we can make sure no important URL is lost without a destination.

#### Limitations and edge cases

Customer passwords cannot be imported into Shopify, and Shopify does not export password hashes, so every Shopify migration involves an account activation or reset step. Shopify Markets covers multiple countries, currencies and languages in one store, but a source with several separate stores or store views may still be better as several Shopify stores; that is a business decision we make with you, not a default. Subscriptions depend on the subscription app and the payment gateway, and moving active subscribers without asking them to re-enter payment details is only possible where the gateway supports a token transfer.

Large catalogs, many variants per product, heavy B2B logic or long order histories change the effort and the method, so we check your real data against current Shopify limits and your plan during the audit.

#### How Prevedshop runs a Shopify migration

A named lead owns the project from the first audit to post-launch QA. We audit the source store (catalog structure, custom data, customers, orders, apps or plugins, integrations, indexed URLs), agree a written mapping, and run a trial migration into a development store or staging target that you check record by record. Only after sign-off do we plan the launch: a content freeze, the full migration, a delta migration of orders and customers created since the trial, redirects, DNS and payment checks.

Import apps, scripts and automated comparisons help where they save time; a person approves every production decision. After launch we check orders, emails, feeds, redirects and Search Console, and fix what the first days of real traffic reveal.

#### What moves when Shopify is the source or target

- Products and variants [transform]: To Shopify, variants are remodelled into up to three options; from Shopify, options and variants map to the target's variant model.
- Custom attributes and metafields [transform]: Source attributes become typed metafields or metaobjects going in; metafields become custom fields or attributes going out.
- Categories and collections [transform]: A category tree becomes collections plus navigation menus in Shopify, and collections are rebuilt as categories when leaving.
- Images and media [migrates]: Product and variant images move in both directions; alt text and image order are checked in the trial migration.
- Customer accounts and addresses [migrates]: Customer records, addresses and marketing consent move; consent status is mapped carefully, not assumed.
- Customer passwords [not-migratable]: Shopify cannot import password hashes and does not export them, so customers activate or reset their accounts in either direction.
- Order history [migrates]: Historical orders move as reference records after products and customers; they are not re-fulfilled or re-charged.
- Product reviews [assess]: Reviews live in a review app or plugin, so the move depends on that vendor's export and the target app's import.
- CMS pages and blog posts [migrates]: Pages and articles move with their content; embedded shortcodes, page-builder layouts and inline links are cleaned up.
- URLs and 301 redirects [transform]: Old URLs are mapped to Shopify's fixed paths going in, and Shopify paths are redirected on the target going out.
- SEO titles and meta descriptions [migrates]: Titles, descriptions and handles are carried over and checked against the new URL for each product, collection and page.
- Discounts and gift cards [assess]: Discount logic is rebuilt as rules; gift card codes and balances depend on what the target and its tooling accept.
- Apps, plugins and theme [rebuild]: Plugins are replaced by apps and a Liquid theme is built when moving in; apps and theme are replaced when moving out.
- Checkout, payments and subscriptions [assess]: Gateways are reconnected and tested; stored cards and subscription tokens depend on the gateway and never move silently.

#### FAQ

Q: What drives the cost of a Shopify migration?
A: Mostly the data, not the product count alone: how far your catalog is from Shopify's option and variant model, how much custom data needs metafields, how many years of orders you want to keep, how many apps and integrations must be replaced, and how many URLs need redirects. We price after the audit, not from a product-count table.

Q: Will my store be down while you migrate to Shopify?
A: The old store keeps selling while we build and test the Shopify store. Launch is planned around a short content freeze and a delta migration of new orders and customers, then a DNS switch. We plan that window with you instead of promising no disruption at all.

Q: Can my customers keep their passwords after moving to Shopify?
A: No. Shopify cannot import password hashes, so customers are invited to activate their accounts or reset their password. We help you plan the invitation email and its timing so it is expected, not a surprise.

Q: Will we lose Google rankings when moving to Shopify?
A: Nobody can guarantee rankings through a platform change. What we control is that every important old URL has a mapped 301 destination, metadata carries over, and the new store is crawled before and after launch, so problems are found quickly and fixed.

Q: Can you move us off Shopify as well?
A: Yes. We export through the Admin API rather than relying on CSVs alone, collect app data from each app vendor, map collections and metafields to the target's model, and redirect Shopify's fixed paths on the new platform.

Sources:
- Shopify - official website: https://www.shopify.com
- Shopify Help Center - Migrate to Shopify: https://help.shopify.com/en/manual/migrating-to-shopify
- Shopify Help Center - Importing and exporting customer lists: https://help.shopify.com/en/manual/customers/import-export-customers
- Shopify Help Center - Creating and managing URL redirects: https://help.shopify.com/en/manual/online-store/menus-and-links/url-redirect

### Shoptet migration: moving to or from Shoptet

URL: https://prevedshop.com/platforms/shoptet
Language: en
Last reviewed: 2026-09-25

This page is for Czech and Slovak merchants moving onto Shoptet from WooCommerce, PrestaShop, Magento or a local platform, and for Shoptet stores leaving it, usually to expand beyond Czechia and Slovakia. Shoptet is hosted, so everything goes in and out through its imports, exports and API, not a database. A named Prevedshop lead audits what your store and plan actually expose, maps the data, runs a trial migration and owns the launch.

#### Shoptet migration overview: who moves to and from it

Shoptet is a hosted SaaS ecommerce platform built for Czechia and Slovakia, with Czech-language support, local payment and shipping integrations and a large partner network. Merchants move onto it from self-hosted WooCommerce, PrestaShop, OpenCart or Magento stores to stop running servers and plugins, and from smaller local platforms. Shoptet itself publishes "Převod dat z X do Shoptetu" help guides for many source platforms, which work well for simple catalogs.

Merchants leave Shoptet mostly for international expansion: several countries, languages and currencies, a larger app ecosystem, or marketplaces and integrations that are easier on Shopify or another platform. The typical route is Shoptet to Shopify.

When not to move: if you sell mainly in Czechia and Slovakia and Shoptet covers your needs, a move adds cost without clear benefit. We say so in the assessment.

#### Migrating from Shoptet: getting the data out

There is no database access on Shoptet, so data comes from its exports and, where your plan and set-up allow it, the API. Products export as CSV or XML, including variants linked by a shared pair code, parameters, categories, images and SEO fields. Customers and orders have their own exports. Which fields are included, and whether API access is available, depends on your plan and add-ons, so we confirm it on your store before promising scope.

The pitfalls: variants and parameters that look similar in the admin but export differently, filtering parameters versus informative parameters, images referenced by URL that must be downloaded before the old store closes, order exports that show totals but not every line-level discount, and data held by add-ons that is not in the standard exports. We check a full sample export before writing the mapping.

#### Migrating to Shoptet: how data goes in

Shoptet imports products from CSV or XML files in its own format. Each product has a `code`, and variants of one product share a `pairCode`, so a source catalog with variants has to be restructured into that shape. Categories, parameters, prices, stock and images are part of the product import; customers have their own import. Order history support is more limited, so we agree early whether historical orders are imported, kept in an archive or exported to your accounting system.

Shoptet's own guides and add-ons cover the basic transfer for common platforms. What they do not cover is the decisions: which source attributes become variants and which become parameters, how to handle products with more options than you want to show, what to do with customer-group prices, and how old URLs are redirected. That is where a managed migration adds value.

#### What usually needs transformation

Into Shoptet: WooCommerce variations and PrestaShop combinations become Shoptet variants joined by `pairCode`; attributes and features become parameters, split into filtering and informative ones; nested categories are rebuilt in Shoptet's tree; HTML descriptions are cleaned of shortcodes and module markup.

Out of Shoptet: variants grouped by `pairCode` become products with variants on the target, which on Shopify means checking the option names and counts; parameters become metafields or filters; categories become collections; Czech and Slovak text, VAT settings and prices in CZK and EUR are mapped to markets. Heureka and Zboží.cz XML feeds are rebuilt on the target, because the feed configuration does not move with the data.

#### Shoptet add-ons, templates and integrations

Shoptet stores rely on add-ons from the Shoptet add-on marketplace and on integrations for accounting (for example Pohoda or Money), carriers such as Zásilkovna or PPL, payment gateways, comparison-shopping feeds and marketing. Add-on data and settings do not move with the store. Leaving Shoptet, we check what each add-on stores and whether it can be exported; moving onto Shoptet, we choose add-ons and reconnect integrations after the core import.

Shoptet templates do not transfer to other platforms, and other platforms' themes do not transfer to Shoptet, so the storefront is rebuilt in both directions. Checkout, payments, shipping and VAT are configured on the target and tested with real test orders before launch.

#### SEO and URL structure on Shoptet

Shoptet generates product and category URLs from slugs that you can edit, and many CZ/SK stores have years of organic traffic and comparison-feed links pointing at them. Moving onto Shoptet, the source URLs rarely match Shoptet's structure, so a redirect map is needed; Shoptet lets you manage redirects in the admin. Leaving Shoptet for Shopify, URLs gain fixed prefixes such as `/products/` and `/collections/`, so every product and category URL changes.

We crawl the live store, combine it with the product export and Search Console data, and map every indexed product, category, article and page URL to its new address, per language and domain where there are several. After launch we re-crawl for 404s and redirect chains, and check that feeds point to live URLs. We do not promise rankings; we make sure old URLs land on the right new page.

#### Limitations and edge cases

Customer passwords: when moving onto Shoptet or off it to a hosted platform, plan for customers to set a new password by email; we confirm what is possible on your specific route. Stored payment methods stay with the payment provider. Order history into Shoptet is limited, so older orders may stay in an archive or accounting system.

What Shoptet exposes depends on plan and add-ons, and the platform changes over time, so we treat any Shoptet capability we have not seen on your store as something to assess. Multi-language and multi-country set-ups on Shoptet differ from markets on international platforms, and mapping them is decided per project.

#### How Prevedshop runs a Shoptet migration

We start with an audit: your plan, exports and API access, catalog with variants and parameters, add-ons and integrations, feeds, and current URLs. From that we write the data mapping and agree it with you. A trial migration loads the catalog, customers and agreed order history into the target, including the redirect map, and you review it on staging.

After sign-off we set a short catalog freeze, run the final migration plus a delta of new orders and customers, switch the domain, activate redirects and feeds, and run post-launch QA: test orders, redirect checks, feed checks and Search Console monitoring. One named lead owns the project, and we work in Czech or English.

#### What moves when Shoptet is the source or target

- Products and variants [transform]: Into Shoptet, variants are grouped under a shared `pairCode`; out of Shoptet, `pairCode` groups become products with variants on the target.
- Parameters and attributes [transform]: Source attributes become Shoptet filtering or informative parameters; leaving Shoptet, parameters become metafields or filters.
- Categories [transform]: Rebuilt as Shoptet's category tree when moving in, and as collections or categories on the target when moving out.
- Images and media [migrates]: Images are downloaded and re-uploaded with the product; this has to happen before the old store closes.
- Customers [migrates]: Customer accounts and addresses move through exports and imports; consent fields are carried over where recorded.
- Customer passwords [assess]: Plan for customers to set a new password on a hosted target; confirmed per route in the trial.
- Order history [assess]: Order import into Shoptet is limited; out of Shoptet, orders are mapped from exports or the API where available.
- Discounts, coupons and gift vouchers [rebuild]: Discount codes and vouchers are re-created on the target; open voucher balances are checked individually.
- Articles, pages and blog [migrates]: Articles and information pages move as blog posts and pages; embedded images and links are re-pointed.
- URLs and 301 redirects [transform]: Every indexed product, category and article URL is mapped to its new address and redirected with a 301.
- SEO metadata [migrates]: Titles, meta descriptions and slugs move where the target has matching fields.
- Heureka and Zboží.cz feeds [rebuild]: Feed configuration does not move with the data; feeds are rebuilt on the target from the migrated catalog.
- Add-on data and integrations [assess]: Each add-on and integration is checked for stored data, then exported, replaced or reconnected.
- Template and design [rebuild]: Shoptet templates do not transfer; the storefront is rebuilt on the target in both directions.

#### FAQ

Q: Shoptet has its own data transfer guides. Why use a managed migration?
A: Shoptet's "Převod dat" guides cover the basic import of products and customers for common platforms. A managed migration adds the audit, the variant and parameter decisions, order history handling, redirects, feeds, integrations and launch QA, with one person accountable for the result.

Q: Why do stores leave Shoptet?
A: Most commonly to sell in several countries, languages and currencies, or to use apps and integrations that are easier on an international platform. If you sell mainly in Czechia and Slovakia and Shoptet covers your needs, staying is often the right call.

Q: Can we keep order history when moving to Shoptet?
A: Partly. Customers and products import well; historical orders are more limited. We agree before the migration whether older orders are imported, archived or kept in your accounting system.

Q: Will our Heureka and Zboží.cz listings keep working?
A: The feeds are rebuilt on the target from the migrated catalog and pointed at the new product URLs. We check that product IDs used for pairing stay stable where possible, and verify feeds after launch.

Q: Will customers need new passwords?
A: Plan for yes. Customers receive an email to set a new password or activate their account on the new store. We confirm the exact behaviour for your route during the trial migration.

Sources:
- Shoptet - official website: https://www.shoptet.cz
- Shoptet Podpora - Převod dat z PrestaShopu do Shoptetu: https://podpora.shoptet.cz/hc/cs/articles/360015946652-P%C5%99evod-dat-z-PrestaShopu-do-Shoptetu

### Shopware migration services: Shopware 5, Shopware 6 and beyond

URL: https://prevedshop.com/platforms/shopware-6
Language: en
Last reviewed: 2026-09-25

This page is for merchants on Shopware 5 who must move now that it has reached end of life, for Shopware 6 stores moving to another platform, and for merchants moving onto Shopware 6. Shopware 5 to 6 is not an upgrade: the data model, plugins and themes are different, so it is effectively a replatform. A named Prevedshop lead audits the store, maps the data, runs a trial migration and owns launch and post-launch QA, whichever direction you are going.

#### Shopware migration overview: who moves and why

Shopware is PHP ecommerce software with its strongest base in Germany, Austria and Switzerland. We see three kinds of projects. Shopware 5 stores have to move because Shopware 5 has reached end of life and no longer receives regular security updates from Shopware; the options are Shopware 6 or another platform. Shopware 6 stores sometimes move to a hosted platform such as Shopify to reduce hosting, update and plugin maintenance. And merchants move onto Shopware 6 for its rule builder, B2B features and sales channels.

For a Shopware 5 store, the honest question is not "how do we upgrade" but "which platform do we rebuild on". Both Shopware 6 and a hosted platform mean a new theme, new plugins and a data migration. We compare them on your catalog, integrations and team, not on preference.

When not to move: a Shopware 6 store whose problem is one plugin or slow hosting usually needs a fix, not a replatform.

#### Migrating from Shopware 5 or 6: getting the data out

Both versions are usually self-hosted, so we can read the database, and Shopware 6 also exposes an Admin API. Shopware 5 stores articles, article details (variants), configurator groups and options, properties, and translations in its own tables, with custom data often in attribute tables added by plugins. Shopware 6 uses a different, entity-based model: products with parent and child variants, property groups, custom fields, and per-sales-channel visibility, SEO URLs and prices.

The pitfalls: plugin data outside the core tables, advanced prices by customer group and quantity, price rules tied to the rule builder, several sales channels or subshops with different catalogs and domains, and translations that are incomplete in one language. Order history is readable in both versions, but payment and shipping methods and order states are store-specific, so orders are mapped rather than copied.

#### Migrating to Shopware 6: how data goes in

For Shopware 5 to 6, Shopware provides the Migration Assistant plugin, which connects the two shops and moves core data such as products, manufacturers, categories, customers and orders, with a data check that flags records it cannot assign. We use it where it fits, but it does not move themes, and plugin data only moves when the plugin supports it, so the audit decides what goes through the assistant and what needs a custom import.

From other platforms we import through the Admin API or scripted imports. Shopware 6 expects property groups and options to exist before variants are generated, sales channels to be set up before visibility and prices are assigned, and custom fields to be defined in custom field sets. Rule-based prices and B2B structures are configured on the target and tested rather than imported blind.

#### What usually needs transformation

Shopware 5 to 6: configurator sets become variant properties, article attributes become custom fields, subshops and language shops become sales channels and domains, and shopping worlds (the Shopware 5 page builder) are rebuilt as Shopping Experiences layouts, because the layout structure differs.

Shopware to another platform: parent and child variants become the target's variant model, which may allow fewer option dimensions, so we check the number of properties per product first. Custom fields become metafields or custom attributes. Categories that act as landing pages with layouts become collections plus pages. Advanced prices and rule-based prices become customer-group pricing, price lists or discounts, and some rules have no equivalent. Each sales channel has to be mapped to a store, a market or a language.

#### Shopware plugins, themes and integrations

Shopware stores depend on plugins from the Shopware Store for payments, shipping, ERP connectors, B2B features, filters and marketing. Shopware 5 plugins do not run on Shopware 6, so each one needs a Shopware 6 version, a replacement or custom work. Leaving Shopware, each plugin's data is checked and either exported, replaced by an app on the target or retired with your agreement.

Themes are rebuilt in every direction: Shopware 5 Smarty themes and Shopware 6 Twig themes are not compatible with each other or with other platforms. Payment providers, shipping rules and tax settings are configured again and tested with real test orders. ERP and warehouse integrations, which are common in DACH stores, are reconnected and checked with live data before launch.

#### SEO and URL structure on Shopware

Shopware generates SEO URLs from templates. In Shopware 6 they are configured under Settings > SEO, per route and per sales channel, and the product template typically combines the product name and product number. Old URLs are kept in the SEO URL table, so a Shopware store often already has several historical URLs per product. Shopware 5 used its own router templates, so a 5 to 6 move changes URLs even when the domain stays the same.

We export the SEO URL tables, crawl the live store and pull top landing pages from Search Console, then map every indexed product, category and CMS URL to its new address, per domain and language. Moving onto Shopware 6, we set the templates before import so URLs are stable at launch. After launch we re-crawl for 404s and redirect chains. We do not promise rankings; we make sure old URLs land on the right page.

#### Limitations and edge cases

Customer passwords: within Shopware, legacy Shopware 5 hashes can be handled on Shopware 6, which we confirm in the trial; a move to a hosted platform means customers set a new password. Saved payment methods stay with the provider. Rule-builder logic, B2B hierarchies and quotes may have no equivalent on a simpler target.

Shopping worlds and Shopping Experiences are layout data and are rebuilt, not converted. Stores with many sales channels and different catalogs per channel may need several target stores. Shopware 5 stores on old PHP versions sometimes cannot run the Migration Assistant without server work, which the audit flags early.

#### How Prevedshop runs a Shopware migration

We start with an audit: Shopware version and edition, plugins, sales channels or subshops, catalog and variants, prices and rules, SEO URLs and integrations. From that we write the data mapping and decide which parts go through the Migration Assistant and which through custom imports. A trial migration loads the data into a staging store, and you review products, customers, orders and URLs there.

After sign-off we agree a short catalog freeze, run the final migration plus a delta of new orders and customers, switch domains, activate redirects and run post-launch QA: test orders, redirect checks, Search Console monitoring and integration checks. One named lead owns the whole project.

#### What moves when Shopware is the source or target

- Products and variants [transform]: Shopware 5 configurator variants become Shopware 6 property variants; leaving Shopware, variants are mapped to the target's option model after checking option counts.
- Properties and custom fields [transform]: Properties and custom fields map to filterable attributes or metafields; Shopware 5 attributes become Shopware 6 custom fields.
- Categories [transform]: The category tree moves to Shopware 6 directly and becomes collections on platforms that use them; category layouts are rebuilt.
- Images and media [migrates]: Product and category media transfer with their assignments; media folders are rebuilt where the target has them.
- Customers and customer groups [migrates]: Customers, addresses and groups move; group-based pricing is re-created on the target.
- Customer passwords [assess]: Shopware 5 hashes can be handled on Shopware 6 (confirmed in the trial); a hosted target requires a password reset.
- Order history [transform]: Orders are mapped to the target's states, payment and shipping methods and imported as historical records.
- Prices, rules and promotions [rebuild]: Advanced prices, rule-builder conditions and promotions are re-created with the target's pricing and discount tools.
- CMS pages and shopping worlds [rebuild]: Shopping worlds and Shopping Experiences layouts are rebuilt; the text and media inside them are carried over.
- SEO URLs and 301 redirects [transform]: SEO URL tables and crawl data feed a redirect map per sales channel and language, implemented as 301s.
- SEO metadata [migrates]: Meta titles and descriptions move per language where the target has matching fields.
- Plugin data [assess]: Shopware 5 plugins do not run on 6; each plugin's data is exported, handled by a Shopware 6 version, replaced or retired.
- Theme and design [rebuild]: Shopware 5 and 6 themes are incompatible with each other and with other platforms; the storefront is rebuilt.
- Sales channels, languages and currencies [assess]: Each sales channel or subshop is mapped to a Shopware 6 sales channel, a market or a separate store.

#### FAQ

Q: Can we still run Shopware 5?
A: It still runs, but Shopware 5 has reached end of life and no longer gets regular security updates from Shopware. Some hosts and third parties offer extended support. For a store taking payments, we recommend planning a move rather than waiting for a plugin or PHP incompatibility to force one.

Q: Is Shopware 5 to 6 an upgrade or a migration?
A: A migration. The data model, plugin system and theme engine are different, so you get a new theme, new or updated plugins and a data transfer. That is why it is worth comparing Shopware 6 with other platforms before committing.

Q: Does the Shopware Migration Assistant do the whole job?
A: It moves core data such as products, categories, customers and orders. It does not move themes, and plugin data depends on the plugin. URLs, redirects, integrations and QA still need to be planned and tested, which is the work we manage.

Q: What drives cost and timeline for a Shopware migration?
A: Number of sales channels and languages, variant and property complexity, rule-based pricing and B2B features, plugins to replace, and ERP or warehouse integrations. We estimate after the audit, when those are known.

Q: How do you handle SEO when moving from Shopware to Shopify?
A: We export Shopware's SEO URLs, crawl the live store and map every indexed URL per domain and language to its Shopify address, including the fixed `/products/` and `/collections/` prefixes, then set 301 redirects and re-crawl after launch. Rankings cannot be guaranteed.

Sources:
- Shopware - official website: https://www.shopware.com
- Shopware documentation - Shopware 5 End of Life: https://docs.shopware.com/en/shopware-5-en/end-of-life/shopware-5-end-of-life
- Shopware developer documentation - Migration Assistant: https://developer.shopware.com/docs/products/extensions/migration-assistant/

### WooCommerce migration services: to or from WooCommerce

URL: https://prevedshop.com/platforms/woocommerce
Language: en
Last reviewed: 2026-09-25

This page is for stores with WooCommerce on one side of a platform change: established WooCommerce shops moving to a hosted platform such as Shopify or BigCommerce, and stores moving onto WooCommerce for control over hosting, code and content. WooCommerce is a WordPress plugin, so a WooCommerce migration is really a WordPress database migration, with store data spread across core tables, post meta and plugin tables. A named migration lead inventories that database, maps it to the target, runs a trial migration you check, and owns redirects, launch and post-launch QA.

#### WooCommerce migration overview: who moves in and who moves out

A common WooCommerce project is leaving it, often for Shopify. The reasons are practical: the store has outgrown shared hosting, updates break plugins, a handful of plugins do business-critical work nobody fully understands any more, and every change needs a developer. A hosted platform trades some flexibility for less maintenance.

Stores move to WooCommerce for the opposite reasons. They want to own the hosting and the code, publish content in WordPress next to the shop, avoid per-app subscriptions, or build checkout and catalog logic a hosted platform will not allow. Both directions are valid. If the real problem is slow hosting or one badly written plugin, fixing that may cost less than replatforming, and the assessment should tell you so.

#### Migrating from WooCommerce: getting data out of WordPress

Because WooCommerce is self-hosted, the data is fully accessible: through the WooCommerce REST API, the built-in product CSV exporter, WP-CLI, or directly from a database copy. That is an advantage over hosted platforms, but it also means nothing is packaged for you. Products are WordPress posts with variations as child posts; attributes can be global taxonomies or local text on the product; custom fields sit in post meta, often written by Advanced Custom Fields or similar plugins.

Orders depend on the version and configuration. Older stores keep orders as posts and post meta, while High-Performance Order Storage (HPOS) stores them in dedicated order tables, and some stores run with synchronization between the two. Customers are WordPress users with WooCommerce meta. Subscriptions, bookings, product add-ons, bundles, memberships and B2B pricing are usually separate plugins with their own tables. We work from a copy of the real database, not an assumed default schema, and list every table that holds store data before mapping anything.

#### Migrating to WooCommerce: how data goes in

Going into WooCommerce, the main decisions are about structure. Variable products need their attributes defined, preferably as global attributes when customers filter by them. Categories map naturally, because WooCommerce uses a nested product category taxonomy, and tags are available for secondary grouping. Custom product data needs a home: native attributes, custom fields registered by a plugin, or a dedicated plugin whose data model we then have to respect.

Data goes in through the REST API, the product CSV importer, or scripted imports for large volumes and order history. Customers from a hosted platform such as Shopify arrive without passwords, because hosted platforms do not export password hashes, so they need a reset or activation step. Plugins for payments, shipping, tax, subscriptions, SEO and search have to be chosen and configured before the trial migration, not after, because they decide where some of the data must be written.

#### What usually needs transformation

Leaving WooCommerce, variations are often the first issue. WooCommerce allows many attributes per variable product and allows variations that match any value of an attribute, while a target such as Shopify has up to three option dimensions and expects each variant to be an explicit combination. Those products must be expanded, split or remodelled. Local attributes and post-meta fields become metafields or custom fields, and add-on plugins that change the price become options, bundles or an app on the target.

Content needs cleanup too. Product descriptions and pages built with Elementor, WPBakery, Divi or the block editor carry shortcodes and layout markup that means nothing on another platform. Order statuses from plugins, customer roles used for wholesale pricing, and tax classes all need explicit mapping. Moving into WooCommerce, collections or flat catalogs are turned into a category tree and filterable global attributes.

#### WordPress plugins, themes and integrations

A WooCommerce store's behaviour is spread across plugins. Before migrating out, we list every active plugin and what it does for customers or staff: payment gateways, shipping rules, invoices, feeds for Google or comparison sites, ERP or accounting connectors, search, reviews, subscriptions and email marketing. Each one needs an equivalent on the target (a native feature, an app or custom work) or a decision to drop it. Plugin data rarely has a portable export, so we find where it is stored and whether it is worth moving.

WordPress themes and page-builder layouts do not transfer to other platforms, so leaving WooCommerce means building a new storefront. Moving in, the theme and page builder are chosen with performance and maintainability in mind. Integrations are reconnected and tested with real orders on staging before launch.

#### SEO and URL structure on WooCommerce

WooCommerce URLs follow WordPress permalink settings. Defaults use a `/product/` base and a `/product-category/` base, but many stores have changed these, added category paths, or kept historical structures through redirect plugins. SEO plugins such as Yoast SEO or Rank Math store titles, meta descriptions, canonical settings and sometimes redirects in their own data. We therefore crawl the live site and read the actual permalink configuration instead of assuming defaults.

Leaving WooCommerce, every indexed product, category, page and blog URL is mapped to the target's structure, and existing redirects from plugins are merged into the new map so old chains resolve in one step. Moving in, permalinks can often be configured to stay close to the old URLs, which reduces the number of redirects. After launch we crawl again and monitor Search Console. We check coverage and redirects; we do not promise rankings.

#### Limitations and edge cases

Customer passwords can only carry over where the target platform accepts the WordPress hash format, which depends on the WordPress version (older phpass hashes, newer bcrypt) and on the target. Moving to a hosted platform such as Shopify, customers reset their passwords. Stored cards and subscription payment tokens depend on the gateway and are never moved silently. WordPress content outside the shop (blog, landing pages, forms, membership areas) is a separate scope decision: some targets handle a blog well, others do not.

Multilingual stores built with WPML, Polylang or similar plugins store translations as linked copies of posts, which must be matched correctly to the target's translation model. Heavily customized stores with custom plugins or theme functions need a code review before we can estimate reliably.

#### How Prevedshop runs a WooCommerce migration

A named lead owns the project. We start with a database copy and admin access, inventory plugins, custom tables and integrations, crawl the site, and write a mapping you approve. The trial migration runs into a staging target, and you check products, variants, customers, orders and content against the source. After sign-off we plan launch: a content freeze, the final migration, a delta migration of orders and customers created since the trial, redirects, DNS and payment tests.

Automated comparisons check record counts, prices, stock and URLs, and a person approves every production decision. After launch we check orders, emails, feeds and redirects, and fix what real traffic uncovers.

#### What moves when WooCommerce is the source or target

- Simple and variable products [transform]: Variations are expanded or remodelled for targets with fewer option dimensions; going in, variable products need defined attributes.
- Attributes and custom fields [transform]: Global and local attributes and post meta map to the target's attributes, metafields or custom fields, and back when moving in.
- Categories and tags [migrates]: WooCommerce's nested product categories map to category trees; for Shopify they become collections and menus.
- Images and media [migrates]: Product galleries and variation images move from the WordPress media library; unused and oversized files are flagged.
- Customers and addresses [migrates]: WordPress users with billing and shipping data move; staff and editor accounts are kept separate from customers.
- Customer passwords [assess]: Depends on the WordPress hash format and the target; moving to or from a hosted platform, customers reset their passwords.
- Order history [migrates]: Orders move from post meta or HPOS tables as historical records, with statuses from plugins mapped explicitly.
- Product reviews [assess]: Native WooCommerce reviews are WordPress comments and move easily; reviews held by a review plugin depend on its export.
- Pages and blog posts [transform]: WordPress content moves, but page-builder layouts and shortcodes are cleaned up or rebuilt on the target.
- URLs, 301 redirects and SEO metadata [transform]: Actual permalinks, Yoast or Rank Math metadata and existing plugin redirects are merged into one redirect map.
- Coupons and gift cards [assess]: Coupon rules are rebuilt on the target; gift card balances depend on the plugin or app on each side.
- Plugin data (subscriptions, bookings, add-ons) [assess]: Each plugin's tables are reviewed; subscriptions also depend on the payment gateway and token transfer.
- Theme and page builder [rebuild]: WordPress themes and page-builder layouts do not transfer; the storefront is rebuilt on the target.
- Translations [assess]: WPML or Polylang translations are linked post copies and must be matched to the target's translation model.

#### FAQ

Q: Why is a WooCommerce migration harder to estimate than a hosted one?
A: Because every WooCommerce store is a different combination of plugins, custom fields and theme code. Until we have seen the database and the plugin list, we cannot know where subscriptions, custom product data or wholesale prices are stored. That is why the assessment comes first.

Q: Do you need access to our WordPress database?
A: Ideally yes, as a copy rather than live access. The REST API is enough for simple stores, but a database copy shows plugin tables and custom fields the API does not expose and lets us run the trial migration without load on your live site.

Q: What happens to our Yoast or Rank Math SEO data?
A: We extract titles, meta descriptions, canonical settings and any redirects the plugin stores, and carry what is still accurate to the target's SEO fields and redirect list.

Q: Can we keep our WordPress blog when moving the shop to Shopify?
A: Yes, as a scope decision. The blog can move into Shopify's blog, or stay on WordPress while the shop moves. We compare the options for URLs, content features and maintenance before you decide.

Q: Can you migrate a store onto WooCommerce?
A: Yes. We design attributes and categories first, choose the plugins that will hold subscriptions, SEO data or custom fields, then import products, customers and orders into that structure and configure permalinks to reduce redirects.

Sources:
- WooCommerce - official website: https://woocommerce.com
- WooCommerce - Product CSV Importer and Exporter documentation: https://woocommerce.com/document/product-csv-importer-exporter/
- WooCommerce developer docs - High-Performance Order Storage: https://developer.woocommerce.com/docs/features/orders/high-performance-order-storage/

### Migration routes

### Magento to BigCommerce migration

URL: https://prevedshop.com/migrations/adobe-commerce-magento-to-bigcommerce
Language: en
Last reviewed: 2026-09-25
Route: adobe-commerce -> bigcommerce

This page is for Magento Open Source, Adobe Commerce and Magento 1 merchants who want a hosted platform but need to keep a real category tree, a complex catalog and as much of their URL structure as possible. BigCommerce changes the hosting and extension model, but unlike Shopify it lets you set product and category URLs yourself, which changes the redirect strategy. Prevedshop runs the move as a managed project: a named lead audits Magento, designs the mapping, runs a trial migration you check, and owns URLs, cutover and post-launch QA.

#### Why stores move from Magento to BigCommerce, and when they should not

Stores leave Magento for the same reason they leave for any hosted platform: the cost of hosting, security patching, extension maintenance and PCI scope for a self-hosted checkout has outgrown what the business needs. Magento 1 stores have had no official Adobe support since 30 June 2020, which turns the decision into a deadline.

BigCommerce tends to suit Magento stores whose value sits in catalog structure and URLs: nested categories, many product options, and an established URL scheme that ranks. It is a weaker fit when the business depends on code-level checkout changes, deep Adobe Commerce B2B workflows, or an ERP writing straight into the Magento database. B2B features and multi-storefront availability depend on the BigCommerce plan and edition, so we confirm them in the assessment rather than assume them.

#### Magento 1, Magento 2 and Adobe Commerce as a source

Magento 1 data is usually read directly from the database, including years of leftover extension tables. Magento 2 and Adobe Commerce have native import/export and a REST API, but attribute sets, URL rewrites and extension data are still verified at database level. Adobe Commerce content staging versions EAV rows by `row_id`, so extraction must pick the currently active version, not a scheduled one. Customer segments, reward points, store credit, gift card accounts and the B2B module each need a decision in the mapping sheet.

#### Magento attributes and configurable products in BigCommerce

Magento's EAV model allows arbitrary attributes per attribute set and per store view. BigCommerce products have core fields, variant options that create SKUs, modifier options that change the order without creating a SKU (engraving text, gift wrap, surcharges), and custom fields for extra specification data. That gives more places to put Magento data than Shopify's three option dimensions, but it still has to be designed.

Configurable products become BigCommerce products with variant options, and each Magento simple child becomes a variant SKU with its own price, weight, stock and image. Magento custom options usually become modifiers. Filterable attributes become custom fields or option values used in faceted search, depending on how the storefront filters are configured. Attributes nobody fills or uses are archived instead of recreated.

Bundle products need a rebuild: depending on pricing and stock logic, they become a product with modifier options that reference other products, a separate kit SKU managed in your ERP, or an app. Grouped products usually become related products or a category. Tier prices and customer group pricing map to BigCommerce customer groups and price lists where your plan supports them, otherwise to an app.

#### Magento categories to the BigCommerce category tree

BigCommerce uses a nested category tree, so Magento categories can keep their hierarchy and product assignments, including products that sit in several categories. That is a real structural advantage over collection-based platforms. We still review the tree: Magento stores often carry duplicate categories per store view, disabled branches and anchor settings that only made sense for layered navigation. Brands stored as a Magento attribute can become BigCommerce brands, which also get their own pages and URLs.

#### Customers, passwords and order history

Customers, addresses, customer groups and newsletter status migrate. Magento password hashes are not something we assume BigCommerce can accept, so we plan for customers to reset their password on first login, with an email sequence timed around launch; whether any other option exists is checked during the assessment.

Orders are imported as historical records through the BigCommerce API, linked to customers and to products by SKU, which is why products go first. Historical orders keep dates, line items, totals and statuses, without re-triggering payments or notifications. Stored cards and payment tokens are not moved unless the gateway supports a formal token transfer.

#### URLs and redirects: why BigCommerce is different from Shopify

Magento URLs come from the `url_rewrite` table (`core_url_rewrite` on Magento 1): product URL keys, often ending in `.html`, sometimes with the category path included, and different per store view. On Shopify almost every one of those changes, because Shopify forces `/products/` and `/collections/` prefixes. BigCommerce lets you set a custom URL for each product, category, brand and page, so many Magento URLs can be recreated exactly and need no redirect at all.

That changes the work rather than removing it. We decide per URL type whether to keep the Magento path or clean it up, set custom URLs during import, and build 301 redirects only for URLs that genuinely change: merged categories, retired products, store-view duplicates and parameter-based filter URLs. BigCommerce's 301 redirect manager supports manual redirects and dynamic redirects that point to a product or category and follow it if its URL changes later, and it can create redirects automatically when a URL is edited. We check that automatic behaviour during the trial so it does not create redirect chains.

Before launch we crawl the Magento site and pull Search Console pages with impressions; after launch we crawl the same list against BigCommerce, check status codes, resubmit the sitemap and monitor coverage. Keeping URLs reduces risk; it does not guarantee rankings.

#### Extensions, integrations, checkout and multi-storefront

Magento extensions and themes do not migrate. Every active module is listed and classified: native BigCommerce feature, app from the BigCommerce marketplace, custom integration against the BigCommerce APIs, or retired. Common cases are search and filtering, reviews, feeds, ERP and warehouse connectors, B2B quoting and loyalty. Extension data such as reviews or loyalty balances is moved only where the target app has an import path.

The theme is rebuilt on Stencil, or on a headless storefront if that is the plan. Checkout changes are made within BigCommerce's checkout customisation options, not by editing core code, so custom Magento checkout steps need a redesign. Cart price rules become BigCommerce promotions and coupon codes. Magento websites and store views for other languages, countries or brands map to BigCommerce multi-storefront, channels or separate stores depending on plan and requirements.

#### How a Magento to BigCommerce migration runs

Audit, mapping, trial migration, sign-off, freeze and delta migration, launch, post-launch QA. The audit sizes data, attributes, extensions, integrations and indexed URLs. The mapping sheet assigns every Magento field to a BigCommerce field, option, modifier or custom field, and records which URLs are kept. The trial migration runs into a BigCommerce trial or sandbox store for your team to check. Automated comparison of counts, prices and URLs flags differences; a person decides what is correct. At launch we freeze Magento briefly, migrate the delta of orders, customers and stock, switch DNS, activate redirects and run post-launch QA.

#### What moves from Magento to BigCommerce

- Simple and configurable products [transform]: Configurable parents become products with variant options; simple children become variant SKUs.
- Custom options, bundles and grouped products [rebuild]: Custom options become modifiers; bundles and grouped products are rebuilt as kits, related products or via an app.
- EAV attributes [transform]: Used attributes are mapped to variant options, modifiers, custom fields or brands; unused ones are archived.
- Category tree [migrates]: BigCommerce keeps a nested tree, so hierarchy and multi-category assignments carry over after cleanup.
- Product images and media [migrates]: Images move with alt text and sort order and are reattached to the correct variants.
- Customers, addresses and groups [migrates]: Customer groups carry over; group pricing depends on plan-level price list support.
- Customer passwords [assess]: Planned as a password reset at first login; any alternative is confirmed during the assessment.
- Order history [transform]: Imported via API as historical orders linked by customer and SKU, without new notifications.
- Product reviews [transform]: Moved to native BigCommerce reviews or to the chosen review app via its import path.
- CMS pages, blocks and blog [transform]: Pages and posts migrate; widgets and Page Builder markup are cleaned or rebuilt in the theme.
- URLs and 301 redirects [transform]: Magento paths are kept as custom URLs where sensible; only changed URLs get 301 redirects.
- SEO titles and meta descriptions [migrates]: Meta titles and descriptions move per product, category, brand and page.
- Cart price rules, coupons and gift cards [transform]: Rules are rebuilt as BigCommerce promotions; gift card balances need a checked import route.
- Extensions and integrations [assess]: Each module is replaced by a native feature, an app or a custom API integration, or retired.
- Theme and checkout [rebuild]: The storefront is rebuilt on Stencil or headless; checkout changes use BigCommerce's own options.
- Store views, websites and languages [assess]: Mapped to multi-storefront, channels or separate stores depending on plan and requirements.

#### FAQ

Q: Is Magento to BigCommerce easier on SEO than Magento to Shopify?
A: Usually the URL work is smaller, because BigCommerce allows custom product and category URLs and many Magento paths can be kept. URLs that change still need 301 redirects, and the crawl before and after launch still happens. Rankings are never guaranteed.

Q: Can BigCommerce handle our Magento attributes and product options?
A: Through a combination of variant options, modifiers and custom fields. We map the attributes you actually use and design where each belongs, rather than recreating every attribute Magento has defined.

Q: What affects cost and timeline?
A: The number of attribute sets and used attributes, configurable and bundle complexity, store views and languages, extensions with data to keep, integrations, and how many URLs change. The assessment converts those into a scope before any migration work starts.

Q: Will our store be offline during the move?
A: Magento stays live until launch. At cutover there is a short content freeze while the delta migration runs and DNS switches, planned for a quiet trading period.

Q: Do customers keep their passwords?
A: Plan on no. Accounts, addresses and order history move; customers reset their password at first login. We confirm during the assessment whether any other option is available for your setup.

Sources:
- BigCommerce official site and documentation: https://www.bigcommerce.com
- Adobe Commerce / Magento Open Source documentation: https://experienceleague.adobe.com/en/docs/commerce
- BigCommerce Help Center - Guide to Migration from Magento: https://support.bigcommerce.com/s/article/Guide-to-Migration-from-Magento?language=en_US
- BigCommerce Help Center - 301 Redirects: https://support.bigcommerce.com/s/article/301-Redirects
- Magento - Support for Magento 1 software ends June 30, 2020: https://magento.com/blog/magento-news/support-magento-1-software-ends-june-30-2020

### Magento to Shopify migration

URL: https://prevedshop.com/migrations/adobe-commerce-magento-to-shopify
Language: en
Last reviewed: 2026-09-25
Route: adobe-commerce -> shopify

This page is for established Magento Open Source, Adobe Commerce and Magento 1 stores that want to move to Shopify without losing their catalog logic, order history or organic traffic. The move replaces a self-hosted EAV platform with a hosted one that has a fixed product model, fixed URL paths and an app ecosystem instead of extensions. Prevedshop runs it as a managed project: a named lead audits the Magento database, designs the Shopify mapping, runs a trial migration you check, and owns the redirects, cutover and post-launch QA.

#### Why stores move from Magento to Shopify, and when they should not

The usual trigger is running cost, not features. A Magento store needs hosting, PHP and Magento security patching, extension updates that break after upgrades, and PCI scope for a self-hosted checkout. Magento 1 stores have a harder deadline: Adobe ended Magento 1 software support on 30 June 2020, so anything still running it depends on community patches or a fork such as OpenMage.

Shopify is not the right target for every Magento store. If your business depends on deep B2B logic (shared catalogs, negotiated quotes, requisition lists), heavily customised checkout steps, complex multi-website pricing, or an ERP that writes directly into the Magento database, the assessment has to show how each of those works on Shopify before you commit. Sometimes the honest answer is a Magento 2 upgrade or BigCommerce.

#### Magento 1, Magento 2 and Adobe Commerce as a source

The source version changes how data comes out. Magento 1 stores are usually extracted directly from the database, because the old SOAP/REST APIs are slow and incomplete, and the schema often carries years of abandoned extension tables. Magento 2 and Magento Open Source offer the native import/export and REST API, but we still read the database for attribute sets, URL rewrites and extension data that exports leave out.

Adobe Commerce adds features that have no one-to-one Shopify field: content staging (which versions EAV rows by `row_id` rather than `entity_id`, so a naive query can return scheduled future values), customer segments, reward points, store credit, gift card accounts and the B2B module. Each gets an explicit decision in the mapping sheet: migrate to an app, rebuild, or retire.

#### EAV attributes, configurable and bundle products in Shopify

Magento stores product data across EAV tables, with attribute sets per product type and values that can differ per store view. Shopify has fixed core product fields, up to three option dimensions for variants, and metafields and metaobjects for everything else. We do not convert every Magento attribute automatically. We first measure which attributes are actually filled, shown on the storefront, used in layered navigation or sent to feeds, then design a metafield scheme with defined types, and drop or archive the rest.

Configurable products become Shopify products with variants: the configurable attributes become options and each simple child becomes a variant with its own SKU, price, weight, stock and image. A configurable product with more than three configurable attributes has to be restructured, usually by splitting it or by moving one attribute into a metafield. Simple children that were also sold individually need a decision too, because a Shopify variant is not also a standalone product page.

Bundle products, with selectable components and dynamic pricing, have no native equivalent in the Shopify product model; they are rebuilt with Shopify's bundle functionality or a bundle app, depending on how the bundle is priced and fulfilled. Grouped products usually become a collection or a product with linked complementary items. Magento custom options (text fields, file uploads, per-option price surcharges) move to a product options app. Tier prices and customer group prices move to Shopify B2B price lists where your plan includes it, or to an app.

#### Categories, collections and layered navigation

A Magento category tree with anchor categories and layered navigation becomes Shopify collections plus menus and storefront filters. Collections are either manual or automated by rules such as tag, type or metafield value, and they are not nested; the hierarchy lives in the navigation menu. We rebuild the tree as collections, decide which categories really need their own landing page, and turn filterable attributes into metafield-based filters. Magento filter URLs with query parameters generally get no Shopify equivalent.

#### Customers, passwords and order history

Customers, addresses, newsletter consent and customer group membership (as tags or B2B companies) migrate. Passwords do not: Magento stores salted hashes, and Shopify does not accept imported password hashes, so every customer sets a new password through an account invitation or on first login. We plan that invitation email with you.

Order history is imported as historical orders linked to customers by email and to products by SKU, which is why products are imported first. Historical orders keep dates, totals, tax lines and statuses for reference, but they do not re-trigger payments, fulfilment or notifications. Invoices and credit memos are summarised onto the order or archived.

#### Magento URL rewrites to Shopify fixed paths and 301 redirects

Magento URLs come from the `url_rewrite` table (`core_url_rewrite` on Magento 1): product URL keys, often with a `.html` suffix, sometimes with the category path in the product URL, and different keys per store view. Shopify uses fixed paths: `/products/{handle}`, `/collections/{handle}`, `/pages/{handle}` and `/blogs/{blog}/{handle}`. Almost every Magento URL therefore changes, so the redirect map is a core deliverable, not an add-on.

We build the map from four inputs: the Magento rewrite table, a full crawl of the live site, Search Console pages with impressions, and URLs that have external backlinks. Every indexable URL gets a destination: the matching product or collection, a parent collection, or a deliberate decision to let it 404. The redirects are imported into Shopify's URL redirects before launch. Shopify only applies a redirect when the old path no longer loads a page, and filtered or parameterised URLs behave differently from plain paths, so both are checked in the trial.

After launch we crawl the old URL list against the live store, check status codes and destinations, resubmit the sitemap in Search Console and watch coverage and 404 reports. That reduces avoidable SEO loss; no migration can promise unchanged rankings.

#### Store views and websites to Shopify Markets

Magento separates websites, stores and store views, and teams use them for languages, countries, currencies and sometimes separate brands. On Shopify, languages, currencies and country-specific settings are handled by Shopify Markets in one store, with translations stored per field and managed through Translate & Adapt, a translation app or CSV import. Store-view product names, descriptions and URL keys become translated fields and localised handles.

Separate Magento websites with their own catalog, prices or brand usually become separate Shopify stores, or on Plus a set of stores managed together. Hreflang is checked after launch.

#### Magento extensions to Shopify apps, integrations and checkout

Themes and extensions do not migrate. We list every active extension and custom module from the codebase and database, then classify each one: replaced by a Shopify feature, replaced by an app, rebuilt as a custom app, or retired. Data stored by extensions (reviews, loyalty balances, blog posts, gift card accounts) is exported and imported into the chosen app where it provides an import path.

Checkout customisation on Shopify is deliberately limited; on Plus it uses Checkout Extensibility and Shopify Functions for discounts, payment and delivery rules. Cart price rules become Shopify discounts or Functions, and some multi-condition Magento rules need simplification. Stored payment tokens are never moved silently; whether they can move depends on the gateway and its PCI transfer process. The Magento theme is rebuilt as a Shopify theme.

#### How a Magento to Shopify migration runs

The sequence is audit, mapping, trial migration, sign-off, freeze and delta migration, launch and post-launch QA. The audit covers data volume, attribute usage, extensions, integrations and indexed URLs. The mapping sheet records where every Magento field and entity goes on Shopify. The trial migration loads a full or representative dataset into a development store, and you check products, prices, variants and redirects before anything is final. Automated comparison flags differences; a person decides what is correct.

At launch we agree a short content freeze on Magento, migrate new orders, customers and stock changes since the trial (the delta), switch DNS, activate redirects and run the post-launch QA checklist.

#### What moves from Magento to Shopify

- Simple and configurable products [transform]: Configurable parents become products and simple children become variants, restructured if more than three configurable attributes are used.
- Bundle, grouped and custom-option products [rebuild]: Rebuilt with Shopify bundles, collections or a product options app depending on pricing and fulfilment.
- EAV attributes and attribute sets [transform]: Used attributes are mapped to typed metafields or metaobjects; unused ones are archived, not recreated.
- Category tree [transform]: Categories become manual or automated collections, with hierarchy moved to navigation menus.
- Product images and media [migrates]: Images move with alt text and order; variant images are reassigned to the new variants.
- Customers and addresses [migrates]: Customer groups become tags or B2B companies where the plan supports it.
- Customer passwords [not-migratable]: Shopify cannot import Magento password hashes, so customers set a new password via invitation or first login.
- Order history [transform]: Imported as historical orders linked by email and SKU, without re-triggering payments or notifications.
- Product reviews [transform]: Exported from Magento or the review extension and imported into the chosen Shopify review app.
- CMS pages, blocks and blog [transform]: Pages and posts migrate; widgets, CMS blocks and Page Builder markup need cleanup or rebuilding in the theme.
- URL rewrites and 301 redirects [transform]: Every indexable Magento URL is mapped to a fixed Shopify path and imported as a redirect before launch.
- SEO titles and meta descriptions [migrates]: Meta titles and descriptions move per product, category and page, including translated values.
- Cart price rules and coupons [transform]: Rebuilt as Shopify discounts or Functions; complex multi-condition rules may need simplifying.
- Gift cards, store credit and reward points [assess]: Depends on the Shopify plan and the gift card or loyalty app chosen.
- Extensions and extension data [assess]: Each extension is replaced by a Shopify feature, an app or a custom app, or retired.
- Theme and design [rebuild]: The Magento theme is rebuilt as a Shopify theme.
- Store views, languages and currencies [transform]: Store views map to Shopify Markets languages and currencies; separate websites may need separate stores.

#### FAQ

Q: What drives the cost of a Magento to Shopify migration?
A: Mostly structure, not store size: the number of attribute sets and used attributes, configurable and bundle product complexity, store views and languages, the number of extensions with data to keep, integrations such as ERP or warehouse systems, and how many indexed URLs need individual redirect decisions. The assessment turns those into a fixed scope before you commit.

Q: How long does it take, and will the store go offline?
A: Timeline depends on catalog complexity, integrations and how quickly you sign off the trial migration. The Magento store stays live throughout. At launch there is a short content freeze while the delta migration runs and DNS is switched, typically planned for a quiet trading window.

Q: Does it matter whether we are on Magento 1 or Magento 2?
A: It changes the extraction, not the destination. Magento 1 data is usually read from the database, and old extensions often leave inconsistent tables. Magento 2 and Adobe Commerce have better exports, but staging, B2B and extension data still need database-level checks.

Q: Can customers log in with their old Magento passwords?
A: No. Shopify does not accept imported password hashes. Customer accounts, addresses and order history move, and each customer sets a new password through an invitation email or when they next log in.

Q: Will we lose SEO when moving from Magento to Shopify?
A: Nearly every URL changes because Shopify uses fixed paths, so risk depends on the redirect map. We map every indexable Magento URL, test redirects in the trial, and monitor crawl and Search Console after launch. That reduces avoidable losses; nobody can guarantee rankings.

Sources:
- Shopify - Migrate your store to Shopify: https://www.shopify.com/migrate
- Adobe Commerce / Magento Open Source documentation: https://experienceleague.adobe.com/en/docs/commerce
- Shopify Help Center - Creating and managing URL redirects: https://help.shopify.com/en/manual/online-store/menus-and-links/url-redirect
- Shopify Help Center - Importing and exporting customer lists: https://help.shopify.com/en/manual/customers/import-export-customers
- Magento - Support for Magento 1 software ends June 30, 2020: https://magento.com/blog/magento-news/support-magento-1-software-ends-june-30-2020

### Magento to Shoptet migration

URL: https://prevedshop.com/migrations/magento-to-shoptet
Language: en
Last reviewed: 2026-09-25
Route: adobe-commerce -> shoptet

This page is for Czech and Slovak merchants running Magento Open Source, Adobe Commerce or an old Magento 1 store who want to move to Shoptet, the hosted platform most of the local market uses. The move is a consolidation: Magento's attribute sets, configurable and bundle products, store views and custom modules are reduced to what Shoptet's simpler, fixed model can represent. Prevedshop runs it as a managed project: a named lead audits Magento, prepares the Shoptet import files, runs a trial import you check, and owns redirects, cutover and post-launch QA.

#### Why Czech and Slovak stores move from Magento to Shoptet

The typical case is a mid-sized store that chose Magento years ago for flexibility and now pays for hosting, security patches, extension licences and agency hours it no longer uses. Magento 1 stores have had no official Adobe support since 30 June 2020, and the developers who built them are often gone. Shoptet replaces that with a monthly plan, a managed environment and a market-specific ecosystem: Czech and Slovak carriers, payment gateways, comparison-site feeds such as Heureka and Zboží.cz, and accounting and ERP connections, available natively or through the Shoptet add-on marketplace.

The trade-off is depth. Shoptet has no attribute sets, no website and store-view hierarchy and no way to install arbitrary code. If your business depends on B2B workflows, complex pricing logic or large custom modules, the assessment says so before any work starts, and sometimes the better answer is Shopify, BigCommerce or staying on an upgraded Magento 2.

#### Getting data out of Magento 1, Magento 2 and Adobe Commerce

Shoptet's help centre publishes step-by-step transfer guides for several source platforms, but a Magento store is normally prepared as custom import files. We read Magento 1 stores directly from the database; Magento 2 and Adobe Commerce stores through export, API and database checks together, because standard exports leave out attribute sets, URL rewrites and extension data. On Adobe Commerce, content staging stores EAV values per `row_id`, so extraction takes only the currently active version. The data is then transformed into Shoptet's CSV and XML import formats.

#### Attribute sets, configurable products and Shoptet parameters

Magento groups attributes into sets per product type; Shoptet works with one shared list of parameters. Overlapping attributes from different sets (for example three different colour attributes) must be merged, renamed consistently and cleaned of duplicate values before import. We also decide which attributes become filtering parameters on category pages, which become variant parameters, and which only belong in the description or a specification table.

Configurable products become Shoptet products with variants: the configurable attributes become variant parameters, and each simple child becomes a variant with its own code, price, stock and image. Simple children that were also sold separately need a decision, because a variant is not a standalone product. Bundle and grouped products have no direct equivalent and are rebuilt as separate products, related products or a set sold with an add-on, depending on how stock and price should behave. Magento custom options with surcharges are the hardest case and are assessed one by one.

Magento prices are exported with the tax class of each product, and we check VAT rates, price rounding and prices including VAT in the trial import, because a wrong VAT mapping is one of the most common errors on this route.

#### Categories, brands and navigation

Magento's category tree transfers into Shoptet categories, including products assigned to several categories. Anchor categories and Magento layered navigation are replaced by Shoptet categories with parameter filters, which usually means removing categories that only existed to simulate a filter. Manufacturers stored as a Magento attribute become Shoptet brands. Category descriptions and SEO texts are moved with their HTML cleaned of Magento widget and Page Builder markup.

#### Store views, customers and order history

Magento store views are often used for a Czech and a Slovak version, or for separate brands. Shoptet can run language and currency versions of one store, depending on plan and setup, but not independent websites under one administration. Each store view therefore gets a decision: merge into one Shoptet store, run separate Shoptet stores, or retire.

Customers, addresses, company details (IČO, DIČ) and newsletter consent are imported. Customer groups map to Shoptet customer groups and price lists where the plan supports them. Passwords are handled as a reset: customers set a new password on first login, and we prepare the announcement with you. Order history is imported for reference and customer accounts, not as live orders to be fulfilled or invoiced again.

#### Magento URLs, redirects and SEO on Shoptet

Magento URLs come from the `url_rewrite` table (`core_url_rewrite` on Magento 1) and often end in `.html` or include the category path. Shoptet generates its own URL format, so most Magento URLs change. We collect every URL that matters from the rewrite table, a crawl of the live store, Search Console and backlink data, map each one to its Shoptet product, category, brand or article, and load the 301 redirects into Shoptet before the DNS switch.

After launch we crawl the old URL list against Shoptet, check status codes, resubmit the sitemap and regenerate product feeds for Heureka, Zboží.cz and Google Merchant Center, since feed URLs and product codes must match the new store. Redirects protect URL continuity and reduce risk; no migration can guarantee rankings.

#### Magento extensions, integrations and design

Magento modules and themes do not migrate. Each active module is listed and matched to a Shoptet built-in feature, an add-on from the Shoptet marketplace, a custom integration through the Shoptet API where your plan provides it, or retirement. Typical items are carrier and payment modules, feed generators, ERP and accounting connectors, reviews, loyalty and B2B pricing. Supplier feeds that updated Magento stock and prices are reconnected to Shoptet. The design is rebuilt on a Shoptet template, with custom styling within what the template allows.

#### How a Magento to Shoptet migration runs

Audit, mapping, trial import, sign-off, freeze and delta migration, launch, post-launch QA. The audit covers data volume, attributes, store views, modules, integrations and indexed URLs. The mapping sheet records where each Magento field and entity goes in Shoptet. The trial import loads the full catalog into a Shoptet test store, and your team checks prices, VAT, stock, variants and parameters. Automated comparison flags differences in counts and values; a person decides what is correct. At launch we freeze Magento briefly, import new orders, customers and stock changes, switch the domain, activate redirects and run post-launch QA.

#### What moves from Magento to Shoptet

- Simple and configurable products [transform]: Configurable parents become Shoptet products and simple children become variants with their own code, price and stock.
- Bundle, grouped and custom-option products [rebuild]: No direct Shoptet equivalent; rebuilt as separate or related products, or assessed case by case.
- Attribute sets and attributes [transform]: Merged into one parameter list and split into filtering parameters, variant parameters and descriptive data.
- Category tree [transform]: Categories transfer; filter-only categories are replaced by Shoptet parameter filters.
- Product images [migrates]: Images move with order and are reassigned to the correct variants.
- Prices and VAT [transform]: Magento tax classes are mapped to Shoptet VAT rates and prices are checked in the trial import.
- Customers and company details [migrates]: Addresses, IČO, DIČ and newsletter consent are imported; customer groups depend on plan support.
- Customer passwords [assess]: Planned as a password reset on first login; confirmed for the specific setup in the assessment.
- Order history [transform]: Imported for reference and customer accounts, not as live orders to fulfil again.
- Product reviews [assess]: Depends on the review source in Magento and the review solution chosen on Shoptet.
- CMS pages and blog [transform]: Pages and articles move with HTML cleaned of Magento widgets and Page Builder markup.
- URLs and 301 redirects [transform]: Indexed Magento URLs are mapped to Shoptet URLs and loaded as 301 redirects before launch.
- SEO titles and meta descriptions [migrates]: Moved per product, category and page, including the Slovak version where applicable.
- Discounts, coupons and gift cards [assess]: Cart price rules are rebuilt only where Shoptet discounts or add-ons can express them.
- Modules, feeds and ERP integrations [assess]: Matched to Shoptet built-in features, add-ons or API integrations, or retired.
- Theme and design [rebuild]: Rebuilt on a Shoptet template within its customisation limits.
- Store views, languages and currencies [assess]: Language and currency versions depend on the Shoptet plan; separate websites become separate stores.

#### FAQ

Q: Can Magento configurable products be migrated to Shoptet?
A: Yes. Each configurable product becomes a Shoptet product with variants, and the simple children become variants with their own code, price, stock and image. Products with unusual option logic are reviewed individually.

Q: What happens to Magento attribute sets?
A: Shoptet has one shared parameter list, so attribute sets are merged. Duplicate and conflicting attributes are cleaned, renamed and split into filtering and variant parameters before import.

Q: We run a Czech and a Slovak store view. What happens to them?
A: It depends on how different they are. Language and currency versions of one Shoptet store may cover it, depending on plan; if the catalogs, prices or brands differ significantly, two Shoptet stores can be the cleaner setup. We decide this in the assessment.

Q: What drives the cost and timeline?
A: The number of attribute sets and parameters to merge, variant and bundle complexity, store views, modules and integrations to replace, and how many URLs need redirects. The Magento store stays live until a short content freeze at launch.

Q: Do we keep customers, passwords and order history?
A: Customers, addresses and order history are imported. Passwords are planned as a reset, so customers set a new one on first login. Orders are kept as history, not as editable live orders.

Sources:
- Adobe Commerce - Data transfer (import and export): https://experienceleague.adobe.com/en/docs/commerce-admin/systems/data-transfer/data-transfer
- Shoptet Developers - Data import: https://developers.shoptet.com/shoptet-tools/data-import/
- Shoptet Podpora - Přechod na Shoptet z jiného e-shopového řešení: https://podpora.shoptet.cz/prechod-na-shoptet-z-jineho-e-shopoveho-reseni/
- Magento - Support for Magento 1 software ends June 30, 2020: https://magento.com/blog/magento-news/support-magento-1-software-ends-june-30-2020

### OpenCart to Shopify migration

URL: https://prevedshop.com/migrations/opencart-to-shopify
Language: en
Last reviewed: 2026-09-25
Route: opencart -> shopify

This route is for OpenCart stores that have outgrown self-hosting: years of products, customers and orders, a stack of OCMOD or vQmod extensions, and a server that someone has to keep patched. The biggest change is the product model, because OpenCart options are not true variants and Shopify needs real variants with their own SKU, price and stock. Prevedshop runs the move as a managed project: a named lead audits your OpenCart database, decides with you how options become variants, maps every SEO keyword URL to a 301 redirect, runs a trial migration and owns launch and post-launch QA.

#### Why stores move from OpenCart to Shopify, and when they should not

OpenCart is free, lightweight and self-hosted, which is why many stores started on it. Over time the costs shift: PHP and server upgrades, security patches, extensions built as OCMOD or vQmod modifications that conflict or stop being maintained, and core upgrades between OpenCart 2, 3 and 4 that break those extensions. Small teams often end up staying on an old version because upgrading is harder than it should be. Shopify removes hosting and platform patching, and most extension functionality is replaced by apps.

Shopify is not automatically the answer. If your store relies on custom checkout logic, unusual option pricing, or B2B rules coded into OpenCart, part of that work moves into apps, custom apps or a higher Shopify plan. If the real problem is an outdated OpenCart install with a clean catalog, an upgrade may cost less. We lay out both paths in the audit.

#### OpenCart options are not variants: rebuilding the product model

In OpenCart, a product has options (select, radio, checkbox, text, file, date and others). Each option value can carry its own quantity and a price, weight or points adjustment, but there is no combination record: a T-shirt with size and colour options has stock per size and per colour, not per size-colour pair, and no SKU for the combination. Shopify works the other way round. A product has up to three options, and every combination is a variant with its own SKU, barcode, price, weight and inventory.

So the migration has to create data that OpenCart never held. For each product we decide which options become Shopify variant options, generate the combinations, compute prices from the base price plus adjustments, and decide how to set stock when OpenCart only knew it per option value. Often the answer comes from an ERP or warehouse file rather than OpenCart. Options that are not purchase choices in the variant sense, such as checkbox add-ons, gift-wrap, engraving text or file uploads, become line-item properties handled by the theme or a product-options app. Products with more than three variant-like options are split or restructured. OpenCart 4 introduced a master and variant product concept; if your store uses it, those products map more directly, and we check this during the audit.

OpenCart attributes, the specification table grouped by attribute group, map to Shopify metafields. OpenCart filters and manufacturers map to metafield-based filters in Shopify Search & Discovery and to the vendor field. Special and discount prices by customer group need a decision, because Shopify handles them through compare-at prices, discounts or B2B features depending on the plan.

#### Categories and Shopify collections

OpenCart categories form a tree and products can sit in several categories, with separate category assignments per store in a multi-store setup. Shopify uses collections, manual or rule-based, and menus to express hierarchy. We rebuild important categories as collections with handles, descriptions and SEO fields, merge thin categories, and use automated collections where tags, product type or metafields give clean rules. Category descriptions and meta fields move with them.

#### Customers, passwords and order history

Customers, addresses, newsletter status and customer groups move to Shopify, with groups usually becoming tags or segments. Customer passwords cannot be imported into Shopify, so customers set a new password through Shopify's account invitation or activation flow; we plan the message and timing with you. Reward points and store credit held in OpenCart customer transactions need a replacement app and a decision on whether balances are carried over.

Orders are imported as historical orders linked to customers, with products, totals, taxes, shipping and OpenCart order statuses mapped. They are records for customer accounts and reporting and do not re-trigger payments, fulfilment or emails. Returns and order history comments are reviewed and moved where they matter to your support team.

#### SEO keyword URLs, query strings and 301 redirects

OpenCart builds friendly URLs from SEO keywords defined per product, category, manufacturer and information page, stored in a keyword table (`url_alias` in older versions, `seo_url` in newer ones, per store and language). With SEO URLs switched off or missing, pages fall back to query strings like `index.php?route=product/product&product_id=42`. A product can also be reachable under several paths, for example through different category paths or the manufacturer page, so an OpenCart store often has more indexed URL variants than products. OpenCart 4 changed the URL format again, including a language segment.

Shopify uses fixed paths: `/products/{handle}`, `/collections/{handle}`, `/pages/{handle}` and `/blogs/{blog}/{handle}`. We pull every keyword from the database, crawl the live store, add URLs from the sitemap, Search Console and analytics, and map each one to its Shopify target, reusing the OpenCart keyword as the handle where it is clean. Redirects are loaded as Shopify URL redirects, which apply only when the old path no longer resolves. Query-string URLs need testing on your store, because how they match depends on the exact pattern, and we verify them before DNS moves. After launch we recrawl and watch Search Console for 404s and coverage changes. Redirects protect URL continuity; rankings are not guaranteed.

#### OpenCart extensions, integrations and the Shopify app stack

Each installed extension and modification gets a decision: replaced by a Shopify feature, replaced by an app, rebuilt as a custom app or theme code, or retired. Common candidates are payment and shipping extensions, product-option extensions, SEO and sitemap tools, feed exporters for Google Shopping and marketplaces, reviews, blogs, and ERP or accounting connectors. Extension data often lives in its own tables, so it is exported separately and moved only where the replacement app accepts it.

The theme is rebuilt on Shopify's Liquid theme system; OpenCart Twig or TPL templates do not convert. Checkout on Shopify is standardised, with deeper customisation on Plus through Checkout Extensibility and Shopify Functions. Taxes, shipping zones and payment providers are configured in Shopify, and stored payment tokens are not migrated.

#### OpenCart multi-store, languages and currencies

OpenCart can run several storefronts from one admin, sharing a catalog with per-store settings, and each store can carry several languages and currencies. Shopify has no multi-store mode inside one store. Shopify Markets covers several countries, currencies and languages from one store; separate Shopify stores suit different brands or catalogs. We choose based on how your OpenCart stores actually differ, then import translations per language and check localized URLs and hreflang after launch.

#### How an OpenCart to Shopify migration runs

Audit: we read the OpenCart database and admin, the version, installed extensions and modifications, option structures, stores, languages and URL keywords, and list open decisions. Mapping: options to variants, attributes to metafields, categories to collections and URLs to redirects, in a document you sign off. Trial migration: a full run into a development Shopify store, with checks on variant counts, prices, stock, customers, orders and redirects, and a difference list for your review.

After sign-off we agree a freeze window, run the final migration and a delta migration for new orders, customers and stock, then launch with DNS, redirects, apps and payment tests. Post-launch QA covers product and collection pages, search, checkout, emails, feeds and Search Console. Scripts compare the data; a person approves every production decision.

#### Limitations to know before you commit

Combination-level stock and SKUs may not exist in OpenCart, so someone has to supply or decide them. Customer passwords do not move. Checkbox, text and file options depend on a product-options app or theme work. Reward points, store credit and gift vouchers need an app and a decision on balances. Custom extension logic is replaced, not copied. And search engines re-evaluate a site after a platform change; we check URLs, metadata and indexing, but do not promise traffic or positions.

#### What moves from OpenCart to Shopify

- Products and options [transform]: Option values are expanded into real Shopify variants with generated SKUs, computed prices and agreed stock.
- Non-variant options (checkbox, text, file) [assess]: These become line-item properties through the theme or a product-options app chosen during the audit.
- Attributes, filters and manufacturers [transform]: Attributes become metafields, filters feed Shopify filters, and manufacturers map to the vendor field.
- Categories [transform]: The category tree is rebuilt as manual or automated collections plus navigation menus.
- Product images [migrates]: Main and additional images move with alt text and are assigned to variants where possible.
- Customers and addresses [migrates]: Accounts, addresses and newsletter status move; customer groups become tags or segments.
- Customer passwords [not-migratable]: Shopify cannot import OpenCart password hashes, so customers set a new password via an account invitation.
- Order history [migrates]: Orders import as historical records with OpenCart statuses mapped and customers linked.
- Product reviews [transform]: Native OpenCart reviews and ratings are exported and imported into a Shopify review app.
- Information pages and blog [migrates]: Information pages become Shopify pages; extension-based blog posts move into Shopify blogs.
- SEO keyword URLs and 301 redirects [transform]: Keywords from the URL table, duplicate paths and query-string URLs are mapped and loaded as Shopify redirects.
- Meta titles and descriptions [migrates]: Per-language meta fields move into Shopify SEO fields and translations.
- Coupons, gift vouchers and specials [rebuild]: Coupons and special prices are recreated as Shopify discounts; voucher balances need a gift-card decision.
- Reward points and store credit [assess]: Balances move only if the chosen loyalty or credit app supports an import.
- Extension data and integrations [assess]: Each extension is replaced by an app, custom work or retired; its data moves only where the replacement accepts it.
- Theme and design [rebuild]: OpenCart templates do not convert; the storefront is built on a Shopify Liquid theme.
- Checkout, payments, shipping and taxes [rebuild]: Configured fresh in Shopify; stored payment tokens are never migrated.

#### FAQ

Q: Why can't OpenCart options just be imported as Shopify variants?
A: Because OpenCart stores options separately, with stock and price adjustments per option value, not per combination. Shopify needs every combination as a variant with its own SKU and inventory. We generate those combinations and agree with you where combination-level stock and SKUs come from.

Q: What happens to our OpenCart SEO URLs?
A: Shopify uses fixed `/products/` and `/collections/` paths, so OpenCart keyword URLs change. We pull every keyword from the database, crawl duplicate and query-string URLs, map each to its Shopify target and load 301 redirects, tested before and after launch.

Q: Do customers keep their passwords?
A: No. Shopify cannot import password hashes. Accounts and order history move, and customers get an invitation to set a new password, timed and worded with you.

Q: What drives the cost of an OpenCart to Shopify migration?
A: Mainly how many products need option restructuring, the number of extensions to replace and the data they hold, multi-store and language setup, integrations such as ERP or feeds, and the number of URLs to map. Old OpenCart versions with modified core files add audit time.

Q: Is there downtime when we switch?
A: The OpenCart store keeps selling until DNS moves. We agree a short freeze, run the final and delta migrations, then switch, so new orders are either brought across before launch or reconciled right after.

Sources:
- Shopify - Migrate your store to Shopify: https://www.shopify.com/migrate
- OpenCart official site and documentation: https://www.opencart.com
- OpenCart Documentation - SEO keywords: https://docs.opencart.com/administration/seo/
- Shopify Help Center - Creating and managing URL redirects: https://help.shopify.com/en/manual/online-store/menus-and-links/url-redirect

### PrestaShop to Shopify migration

URL: https://prevedshop.com/migrations/prestashop-to-shopify
Language: en
Last reviewed: 2026-09-25
Route: prestashop -> shopify

This page is for established PrestaShop merchants, often selling in several EU languages or from a multistore install, who want to stop running servers, PHP upgrades and module updates without losing catalog depth, order history or search visibility. The move changes more than hosting: combinations become Shopify variants, features and attributes become metafields and options, multistore becomes Markets or separate stores, and every ID-based friendly URL needs a mapped 301 redirect. Prevedshop runs it as a managed project: a named lead audits your PrestaShop data, owns the mapping, runs a trial migration you review, and handles the freeze, delta migration and post-launch QA.

#### Why stores move from PrestaShop to Shopify, and when they should not

The usual trigger is operational load. PrestaShop is self-hosted open source, so your team owns hosting, PHP compatibility, security patching, core upgrades and the module stack. Shopify takes hosting, platform security and checkout PCI scope off your plate, and most of what modules did is replaced by apps.

It is not the right move for every PrestaShop store. If you depend on deep checkout customisation, pricing logic in overrides, or very different multistore shops, Shopify can still work, but cost moves into apps, custom apps or Shopify Plus. Sometimes a PrestaShop upgrade or clean-up is the better decision.

#### Combinations, features and attributes: mapping the PrestaShop catalog

PrestaShop builds variants from attribute groups (size, colour, material) into combinations, each with its own reference, EAN, price impact, weight impact and stock. Shopify has products and variants with up to three option dimensions. Most combinations map directly: attribute groups become option names, combination references become variant SKUs, and price impacts are resolved into absolute variant prices. Products that use four or more attribute groups, or that use an attribute group for something that is not a real purchase choice, need a decision: split the product, merge option values, or move the dimension into metafields.

PrestaShop features (the specification table: fabric, capacity, country of origin) are not variants. We map them to Shopify metafields, usually typed product metafields or metaobjects when values are shared across many products, so they can drive filters in Shopify Search & Discovery and render in the theme. Inconsistent feature values are normalised before import.

Packs become bundles, virtual products need a digital-delivery app, and customization fields become line-item properties handled by the theme or an app. Specific prices and customer-group prices do not have a single Shopify equivalent; depending on your plan they become compare-at prices, automatic discounts or B2B catalogs, and we mark them as items to assess.

#### Categories, the default category and Shopify collections

PrestaShop products sit in a nested category tree and can belong to several categories, with one default category that often appears in the product URL and breadcrumbs. Shopify has no category tree. It uses collections, manual or automated by rules, plus menus that you build to express hierarchy.

We rebuild the tree as collections deliberately: top-level and important sub-categories become collections with their own handles, descriptions and SEO fields, thin categories are merged with a redirect, and automated collections replace manual assignment where rules are clean. The default category is kept as a product metafield when it is needed for breadcrumbs or feeds, because Shopify product URLs do not carry a category.

#### Customers, passwords and order history

Customer accounts, addresses, newsletter consent and customer-group membership move to Shopify, with groups usually becoming customer tags or segments. Guest checkouts in PrestaShop are handled separately so they do not become duplicate accounts. Customer passwords cannot be imported into Shopify, whatever hashing your PrestaShop version uses. Customers set a new password through Shopify's account invitation or activation flow, and we plan the timing and wording of that message with you.

Order history is imported as historical orders linked to customers, with line items, totals, taxes, shipping and status mapped from PrestaShop order states. Imported orders are records for customer accounts and reporting; they do not re-trigger fulfilment, payments or emails. Credit slips and invoice numbering stay authoritative in your accounting system.

#### Friendly URLs with IDs, languages and 301 redirects

PrestaShop friendly URLs are configured under SEO & URLs, and by default they usually contain numeric IDs, for example a product route like `/{category}/{id}-{rewrite}.html` or a category route like `/{id}-{rewrite}`, with a language prefix such as `/en/` or `/de/` when several languages are active. Combination links may add a `#/` fragment for the selected attributes; fragments never reach the server, so they redirect with their parent product URL.

Shopify uses fixed paths: `/products/{handle}`, `/collections/{handle}`, `/pages/{handle}` and `/blogs/{blog}/{handle}`. None of the ID-based patterns survive, so every relevant URL needs a mapped target. We crawl the live PrestaShop store, combine it with the sitemap, Search Console and analytics landing pages, and map each URL to its Shopify equivalent, including language versions, CMS pages, manufacturer pages and blog posts. Redirects are loaded as Shopify URL redirects, which only apply when the old path no longer resolves to a page, so they are tested against the migrated store before DNS changes. After launch we recrawl and watch Search Console for 404s. Redirects protect URL continuity; they do not guarantee rankings.

#### PrestaShop modules, integrations and the Shopify app stack

Every active module gets a decision during the audit: replaced by a Shopify native feature, replaced by an app, rebuilt as a custom app or theme code, or retired. Typical candidates: payment and carrier modules, product comments, layered navigation, loyalty, feed exporters, invoicing and ERP connectors. Module data such as reviews, loyalty balances or wishlists lives in the module's own tables, so it is extracted separately and imported into the chosen app where the app supports it.

The theme is rebuilt, not converted: PrestaShop Smarty templates have no path into Shopify Liquid themes. Checkout customisation on Shopify is limited, and on Plus it uses Checkout Extensibility and Shopify Functions. Taxes and shipping are reconfigured, and ERP, PIM and feed integrations are re-pointed to Shopify and tested before launch.

#### Multistore and multilingual PrestaShop shops

PrestaShop multistore lets one install run several shops, grouped so they may or may not share customers, orders and stock, with per-shop prices, content and themes. Multilingual shops keep translations per language for products, categories and CMS pages. Shopify has no multistore mode inside one store.

The options are Shopify Markets, which serves several countries, currencies and languages from one store with translated content and localized URLs, or separate Shopify stores, which suit genuinely separate brands, assortments or legal entities. We decide this from how your shops actually differ: shared catalog with regional prices points to Markets; different catalogs, teams or checkouts point to separate stores. Translations import per language, and hreflang is checked after launch.

#### How a PrestaShop to Shopify migration runs

Audit: we review your PrestaShop database, modules, overrides, languages, shops and URL generations, and list open decisions. Mapping: combinations, features, categories, customer groups, order states and URLs are mapped in a document you sign off. Trial migration: a full data run into a development Shopify store, followed by checks on counts, prices, variants, translations and redirects, with a list of differences for you to review.

After sign-off we agree a content freeze, run the final migration, then a delta migration for orders, customers and stock changes made since the trial. Launch covers DNS, redirects, app configuration and payment tests. Post-launch QA runs through key templates, search, checkout, emails, feeds and Search Console. Scripts and automated comparisons help check the data; a person approves every production decision.

#### Limitations to know before you commit

Customer passwords do not move. Some products will be restructured to fit three option dimensions. Customer-group pricing, complex cart rules and some module behaviour depend on apps or your Shopify plan. Invoice numbering, credit slips and payment tokens stay with PrestaShop, your accounting system or your payment provider. Search engines re-evaluate a site after a replatform, so we check what we can and do not promise traffic or positions.

#### What moves from PrestaShop to Shopify

- Products and combinations [transform]: Combinations become variants with SKUs, EANs and absolute prices; products with more than three attribute groups are restructured.
- Features and custom attributes [transform]: Feature values move to typed metafields or metaobjects so they can drive filters and theme blocks.
- Categories and default category [transform]: The nested tree is rebuilt as manual or automated collections plus menus; the default category can be kept as a metafield.
- Product images [migrates]: Images move with alt text and are linked to the right variant where combinations had their own images.
- Packs, virtual products and customization fields [assess]: These depend on a bundle, digital-delivery or product-options app chosen during the audit.
- Customers and addresses [migrates]: Accounts, addresses and consent move; customer groups become tags or segments.
- Customer passwords [not-migratable]: Shopify cannot import password hashes, so customers set a new password through an account invitation.
- Order history [migrates]: Orders import as historical records linked to customers, with PrestaShop order states mapped.
- Product comments and reviews [transform]: Reviews from the product comments module or a review module are exported and imported into a Shopify review app.
- CMS pages and blog [migrates]: CMS pages become Shopify pages; blog posts from a blog module move into Shopify blogs with internal links updated.
- Friendly URLs and 301 redirects [transform]: ID-based and language-prefixed PrestaShop URLs are mapped one by one to Shopify paths and loaded as URL redirects.
- Meta titles and descriptions [migrates]: Per-language meta fields move to Shopify SEO fields and translations.
- Cart rules, vouchers and specific prices [rebuild]: Rules are recreated as Shopify discounts or app logic; one-off codes are imported where the discount type allows it.
- Module data (loyalty, wishlists, feeds) [assess]: Each module's tables are reviewed and moved only when the replacement app can accept the data.
- Theme and design [rebuild]: Smarty templates do not convert; the storefront is built on a Shopify Liquid theme.
- Checkout, payments, carriers and taxes [rebuild]: Payment providers, shipping zones and tax settings are configured fresh; stored payment tokens do not move.
- Multistore and translations [assess]: Shops map to Shopify Markets or separate stores depending on how they differ; translations import per language.

#### FAQ

Q: Can Shopify handle our PrestaShop combinations?
A: Most combinations map directly to Shopify variants. The constraint is three option dimensions per product, so products built from four or more attribute groups, or groups that are really descriptive data, are restructured or moved to metafields. We list those products in the audit so you can decide before the trial migration.

Q: What happens to our PrestaShop URLs with IDs in them?
A: They cannot be kept, because Shopify uses fixed `/products/` and `/collections/` paths. Each indexed URL, including language versions and older route patterns, is mapped to its Shopify target and loaded as a 301 redirect, then tested before and after launch.

Q: Do customers need new passwords after moving to Shopify?
A: Yes. Shopify cannot import password hashes from PrestaShop. Accounts and order history move, and customers receive an invitation to set a new password. We help you time and word that message so it does not look like phishing.

Q: What drives the cost and timeline of a PrestaShop to Shopify migration?
A: Mostly the number of languages and shops, how many products need restructuring, the number of modules to replace, custom data in module tables, integrations such as ERP or feeds, and the volume of URLs to map. Catalog size alone matters less than how clean the data is.

Q: Will the store be offline during the switch?
A: The PrestaShop store keeps trading until DNS moves. We agree a short content freeze, run the final and delta migrations, and switch. Orders placed during the delta window are brought across before launch or reconciled right after, depending on the plan we agree.

Sources:
- Shopify - Migrate your store to Shopify: https://www.shopify.com/migrate
- PrestaShop official site and documentation: https://www.prestashop.com
- Shopify Help Center - Creating and managing URL redirects: https://help.shopify.com/en/manual/online-store/menus-and-links/url-redirect

### PrestaShop to Shoptet migration

URL: https://prevedshop.com/migrations/prestashop-to-shoptet
Language: en
Last reviewed: 2026-09-25
Route: prestashop -> shoptet

This route is for Czech and Slovak merchants who run PrestaShop on their own hosting and want a hosted platform built around their local market: Czech invoicing and VAT, local carriers and payment gateways, and feeds for comparison sites such as Heureka and Zboží.cz. The migration turns PrestaShop combinations into Shoptet variants, features into parameters and modules into native Shoptet features or add-ons, and replaces ID-based PrestaShop URLs with a tested 301 redirect map. Prevedshop runs it as a managed project with a named lead, a trial import you review, and a planned freeze, delta migration and post-launch QA.

#### Why Czech and Slovak stores move from PrestaShop to Shoptet

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.

#### Combinations, features and categories in Shoptet

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, passwords and order history

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, SEO and 301 redirects to Shoptet

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.

#### PrestaShop modules versus Shoptet features and add-ons

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.

#### Languages, currencies and PrestaShop multistore

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.

#### How a PrestaShop to Shoptet migration runs

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.

#### Limitations to know before you commit

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.

#### What moves from PrestaShop to Shoptet

- Products and combinations [transform]: Combinations become Shoptet variants grouped by pair code, with codes, EANs, final prices and stock.
- Features and attributes [transform]: Features become Shoptet parameters created before import; attribute groups become variant parameters.
- Categories [migrates]: The tree and multiple assignments move; the PrestaShop default category becomes the primary category.
- Product images [migrates]: Images move with the products and are reattached to variants where combinations had their own images.
- Customers and addresses [migrates]: Accounts, delivery and billing addresses, company IDs and group membership are imported.
- Customer passwords [assess]: Plan for a reset flow unless the audit confirms Shoptet can accept the PrestaShop hashes.
- Order history [assess]: Scope depends on the import route and add-ons available for your plan; imported orders are history only.
- Product reviews [assess]: Reviews from PrestaShop modules move only if the Shoptet feature or add-on used accepts an import.
- CMS pages and blog [transform]: CMS pages and module-based blog posts become Shoptet pages and articles with internal links updated.
- Friendly URLs and 301 redirects [transform]: ID-based and language-prefixed PrestaShop URLs are mapped one by one and loaded as Shoptet redirects.
- Meta titles and descriptions [migrates]: Per-page SEO fields move with products, categories and pages.
- Cart rules, vouchers and specific prices [rebuild]: Discounts and group prices are recreated in Shoptet's discount and pricing tools.
- Module data and integrations [assess]: Each module is replaced by a native feature, an add-on or an integration, or retired.
- Theme and design [rebuild]: The storefront is rebuilt on a Shoptet template; Smarty templates and overrides do not transfer.
- Checkout, payments, shipping and VAT [rebuild]: Carriers, gateways and VAT are configured in Shoptet; stored payment tokens never move.
- Languages, currencies and multistore [assess]: One Shoptet project or several depends on how your PrestaShop shops differ and on your plan.

#### FAQ

Q: Do PrestaShop combinations become Shoptet variants?
A: Yes. Each combination becomes a variant with its own code, price and stock, and attribute groups become the variant parameters. We clean inconsistent attribute names before import so filters and variant selectors work on Shoptet.

Q: Can we keep our order history?
A: Often in part, but it depends on the import route and add-ons available for your Shoptet plan. We confirm what can move in the audit. Imported orders are history, not live orders, and invoices stay in your accounting system.

Q: Will customers have to reset their passwords?
A: Plan for it. Unless the audit confirms Shoptet can accept your existing password hashes, customers set a new password after launch, and we prepare the announcement with you.

Q: How do you handle PrestaShop URLs with product IDs?
A: Every indexed URL, including older patterns and language prefixes, is mapped to its Shoptet equivalent and loaded as a 301 redirect. We test the map on the new store before the domain moves and recheck it in Search Console afterwards.

Q: What makes a PrestaShop to Shoptet migration take longer?
A: Many languages or shops, messy attribute and feature data, custom modules with their own data, integrations with ERP or warehouses, and a large URL history. Catalog size matters less than data quality and the number of decisions to make.

Sources:
- PrestaShop - Webservice documentation: https://devdocs.prestashop-project.org/9/webservice/
- Shoptet Developers - Data import: https://developers.shoptet.com/shoptet-tools/data-import/
- Shoptet Podpora - Převod dat z PrestaShopu do Shoptetu: https://podpora.shoptet.cz/hc/cs/articles/360015946652-P%C5%99evod-dat-z-PrestaShopu-do-Shoptetu

### Shopify to WooCommerce migration

URL: https://prevedshop.com/migrations/shopify-to-woocommerce
Language: en
Last reviewed: 2026-09-25
Route: shopify -> woocommerce

This route is for established Shopify merchants who want to own their stack: the database, the hosting, the checkout code and the content site in one WordPress installation. What changes most is responsibility, not just data. Hosting, plugin updates, backups and security become your team's job, and a lot of what Shopify apps stored has to be exported separately. Prevedshop runs the move as a managed project: a named lead audits the Shopify store and its apps, maps every entity to WooCommerce, runs a trial migration you check, and handles URLs, redirects, cutover and post-launch QA.

#### Why stores move from Shopify to WooCommerce (and when not to)

The usual drivers are cost structure and control. App subscriptions accumulate, third-party gateways can add transaction fees on top of processor fees, and checkout changes are limited unless you are on Shopify Plus and build with Checkout Extensibility. Stores with a large editorial or content operation often want commerce and content in one WordPress site rather than two systems stitched together.

The trade-off is real. On Shopify, hosting, scaling, PCI scope for the hosted checkout and platform security are handled for you. On WooCommerce you (or your hosting provider and developer) own server performance, caching, PHP and WordPress updates, plugin compatibility, backups and incident response. If the complaint is one missing feature or the theme, fixing it on Shopify is usually cheaper, and we say so.

#### Getting data out of Shopify: exports, API and app data

Shopify gives you CSV exports for products, customers and orders in the admin, but those files are not the whole store. Metafields, metaobjects, full order line and transaction detail, and some product relationships are more reliably read through the Shopify Admin API, which is what we use for the main extraction.

The bigger gap is app data. Reviews, loyalty points, wishlists, subscriptions, product options built by an app, bundles, back-in-stock lists and page-builder content usually live in the app vendor's system, not in Shopify. Each app has its own export (CSV, API or support request), and some offer none. The audit lists every installed app, what data it holds, how it can be exported and what will replace it in WooCommerce. Gaps are flagged before you commit.

#### Products, variants, metafields and collections in WooCommerce

A Shopify product with up to three options maps to a WooCommerce variable product: each option becomes an attribute (global attributes under Products > Attributes if you want filtering and shared values, or product-level attributes if not), and each Shopify variant becomes a variation with its own SKU, price, stock, weight and image. Simple Shopify products with a single default variant become simple WooCommerce products. We keep SKUs as the matching key so ERP, feed and warehouse integrations keep lining up.

Metafields have no single WooCommerce equivalent. Depending on how the new theme uses them, a metafield becomes a product attribute, post meta read by the theme, a field managed by a custom-fields plugin, or content in the description. Metaobjects (for example size charts or ingredient lists) often become a custom post type or reusable block.

Shopify collections are flat lists; WooCommerce has hierarchical product categories plus tags. Manual collections usually become categories, sometimes nested to recover a structure Shopify could not express. Automated collections defined by rules (tag, vendor, price) have no native rule engine in WooCommerce, so we either assign products to categories explicitly or rebuild the logic with a filtering plugin.

#### Customers, passwords and order history

Customer records, default and additional addresses, tags and marketing consent move into WordPress users with WooCommerce customer data.

Passwords do not move. Shopify does not export customer password hashes, so there is nothing to import. Customers set a new password on the WooCommerce store, typically through a reset email sent in a planned sequence after launch.

Order history is imported as completed historical orders with line items, prices, taxes, shipping, discounts and addresses, linked to the right customer, with Shopify statuses mapped to WooCommerce statuses. We keep the original Shopify order number as a reference so customer service can find old orders, and we disable order emails during import so no customer receives notifications for historical orders. Refunds on historical orders are still handled in the original payment provider.

#### URLs, SEO and 301 redirects: keeping or mapping Shopify paths

Shopify forces fixed prefixes: `/products/{handle}`, `/collections/{handle}`, `/pages/{handle}` and `/blogs/{blog}/{handle}`, plus collection-scoped product URLs like `/collections/{collection}/products/{handle}`. WooCommerce is the opposite: permalinks are configurable in WordPress, including the product base and product category base. That gives two valid strategies.

The first is to keep paths. With a product base of `/products/`, a category base of `/collections/` and a post structure matching the old blog path, most Shopify URLs can resolve at the same address, which reduces the number of redirects. The second is to map to a cleaner structure and redirect everything that changes. We check the details either way: WordPress adds trailing slashes by default, which creates an extra redirect hop unless configured, and `/pages/` paths need their own handling.

Before launch we crawl the live Shopify store, pull indexed and linked URLs from Search Console, the sitemap and backlink data, and build a redirect map from every old URL to its best new equivalent, including collection-scoped product URLs, blog tags and old redirects already stored in Shopify. Redirects are served by the WordPress site (a redirect plugin or server rules). After launch we crawl again, test the map, submit the new sitemap and watch Search Console coverage. Redirects protect URL continuity; they do not guarantee rankings, and we do not promise them.

#### Plugins, integrations and custom functionality

Every Shopify app is replaced by a WooCommerce extension, a WordPress plugin, custom code or a decision to drop it. We keep the plugin list short, because each plugin adds maintenance on a self-hosted store.

Payments are rebuilt: Shopify Payments does not exist on WooCommerce, so you choose a gateway plugin (for example WooPayments, Stripe or PayPal) and your provider decides whether stored cards or subscription tokens can move. Shipping rates, zones and carrier label integrations are reconfigured, and tax rules are set up in WooCommerce settings or a tax plugin. Subscriptions move to a WooCommerce subscriptions extension only where the gateway supports token migration; otherwise customers re-subscribe. Gift card balances need a gift card plugin and a balance import, which depends on what Shopify and the plugin can export and accept.

The Liquid theme does not transfer. The storefront is rebuilt as a WordPress theme (block theme or classic). ERP, PIM, marketing and product feed integrations are reconnected to WooCommerce endpoints and tested with real orders on staging.

#### How the Shopify to WooCommerce migration runs

Audit: store export, app inventory, URL crawl, integration list and hosting requirements. Mapping: a written data map for products, metafields, customers, orders, content, apps and URLs that you sign off. Hosting and staging: we specify or review the WordPress hosting, set up staging and install only the plugins agreed in the map.

Trial migration: a full run into staging with counts compared (products, variants, customers, orders, totals) and a sample of records checked by hand. Automated comparisons help, a person approves. Sign-off: you review the storefront, checkout, emails and admin workflows.

Launch: a short content freeze on Shopify, a delta migration of new orders, customers and stock changes since the trial, DNS switch, redirect activation and live test orders. The Shopify store is kept accessible for reference until post-launch QA is complete and all exports are archived. Post-launch QA: crawl, redirect tests, Search Console checks, order flow and integration monitoring.

#### Limitations to know before you commit

Customer passwords cannot be moved; plan a reset campaign. App data without an export path may be lost or need manual recreation. Stored payment methods and subscription tokens depend entirely on the payment provider. Shopify Flow automations, Shopify POS setups and other Shopify-native features have no direct WooCommerce equivalent and must be rebuilt or replaced. Order history imports are for reference and service, not for reprocessing payments. Ongoing cost shifts from apps and platform fees to hosting, maintenance and developer time.

#### What moves from Shopify to WooCommerce

- Products and variants [transform]: Shopify options and variants become WooCommerce attributes and variations, keyed on SKU.
- Metafields and metaobjects [transform]: Mapped field by field to attributes, post meta, a custom-fields plugin or custom post types.
- Collections [transform]: Manual collections become categories or tags; rule-based collections need explicit assignment or a filtering plugin.
- Images and media [migrates]: Product, variant and content images are downloaded from Shopify's CDN into the WordPress media library with alt text.
- Customers and addresses [migrates]: Imported as WordPress users with WooCommerce addresses, tags and mapped marketing consent.
- Customer passwords [not-migratable]: Shopify does not export password hashes, so customers set a new password on WooCommerce.
- Order history [migrates]: Imported as historical orders with mapped statuses and the original Shopify order number as reference.
- Product reviews [assess]: Reviews live in a Shopify app; migration depends on that app's export and the chosen WooCommerce review setup.
- Pages and blog posts [migrates]: Shopify pages and articles become WordPress pages and posts; embedded app widgets are rebuilt.
- URLs and 301 redirects [transform]: Paths are either kept via configurable permalinks or mapped, with a tested 301 map for every change.
- SEO metadata [migrates]: SEO titles, meta descriptions and handles are carried to WooCommerce and the chosen SEO plugin.
- Discount codes [transform]: Recreated as WooCommerce coupons; Shopify automatic discounts and complex rules need a plugin or custom logic.
- Gift cards [assess]: Balances need a gift card plugin and depend on what can be exported from Shopify.
- App data (loyalty, wishlists, bundles, options) [assess]: Each app is checked for an export path and a WooCommerce replacement during the audit.
- Theme and design [rebuild]: The Liquid theme is rebuilt as a WordPress theme; design can be matched or refreshed.
- Checkout, payments, shipping and tax [rebuild]: Gateway plugins, shipping zones and tax rules are configured and tested with real orders.
- Subscriptions and stored payment methods [assess]: Only possible where the payment provider supports token migration; otherwise customers re-subscribe.

#### FAQ

Q: Can we keep our Shopify URLs on WooCommerce?
A: Largely, yes. WordPress permalinks are configurable, so product, category and blog bases can be set to match Shopify's `/products/`, `/collections/` and blog paths. Collection-scoped product URLs, `/pages/` paths and trailing-slash differences still need redirects or configuration, which we test before launch.

Q: Do customers keep their passwords after moving from Shopify?
A: No. Shopify does not export password hashes, so customer accounts are recreated without credentials and customers set a new password through a reset email. We plan that email sequence as part of the launch.

Q: What happens to data stored in our Shopify apps?
A: It depends on each app. Reviews, loyalty, subscriptions and similar data sit with the app vendor, and export options range from full API access to nothing. The audit lists every app, its export path and its WooCommerce replacement before you commit.

Q: What drives the cost and timeline of this migration?
A: The number of apps holding data, how heavily metafields are used, the size of order history, the theme rebuild, and how many integrations (ERP, feeds, marketing) must be reconnected. Hosting setup and a proper staging environment are also part of the scope on this route.

Q: Will the store be offline during the switch?
A: We plan for a short content freeze rather than an outage: the Shopify store keeps selling until the delta migration and DNS switch. Some DNS propagation overlap is normal, which is why new orders are captured in the delta run and checked after launch.

Sources:
- WooCommerce - Product CSV importer and exporter: https://woocommerce.com/document/product-csv-importer-exporter/
- Shopify Help Center - Migrating to Shopify: https://help.shopify.com/en/manual/migrating-to-shopify

### Shoptet to Shopify migration

URL: https://prevedshop.com/migrations/shoptet-to-shopify
Language: en
Last reviewed: 2026-09-25
Route: shoptet -> shopify

This route is for Czech and Slovak merchants on Shoptet who are expanding abroad and need a platform built for several countries, languages and currencies. Both platforms are hosted, so the hard part is not servers. It is the local layer: Heureka and Zboží.cz feeds, Czech carriers and pickup points, invoicing and ERP connections that Shoptet handles or connects to natively, and none of which Shopify provides out of the box. Prevedshop runs the migration as a managed project: a named lead audits the Shoptet store and its integrations, maps data and URLs, runs a trial migration, and manages the launch and post-launch QA.

#### Why stores move from Shoptet to Shopify (and when not to)

The typical trigger is cross-border expansion from CZ/SK into Germany, Austria, Poland, Hungary or wider EU markets. Shoptet is built around the Czech and Slovak market: its add-ons, payment and shipping partners and support focus there. Shopify offers a global app ecosystem, Shopify Markets for selling in several countries from one store, and more freedom in theme design through Liquid.

It is not always the right move. If most revenue stays in Czechia and Slovakia and the store depends on Heureka, Czech carriers, cash on delivery and a Czech ERP, Shoptet may still be the cheaper platform to run, because on Shopify each of those needs an app, a connector or custom work. We map those costs in the assessment.

#### Getting data out of Shoptet

Shoptet is a closed SaaS platform with no database access. Data comes out through its CSV and XML exports for products, orders and customers, and through its API where your plan provides access. What each export contains depends on the plan, the add-ons in use and how fields were filled over the years, so the audit starts with a full export and a check of what is missing: product parameters, variant-level data, related products, custom texts, order detail and customer consent fields.

We also collect the live URL set by crawling the store, because Shoptet's export does not tell you everything search engines have indexed. Data that cannot be exported is identified early and rebuilt, archived or dropped by agreement.

#### Products, variants, parameters and categories on Shopify

Shoptet products with variants map to Shopify products with variants, but Shopify allows up to three option dimensions per product. Shoptet variant parameters beyond that, or parameters used only for filtering and product information (material, brand line, compatibility), move into Shopify metafields and are connected to Shopify's Search & Discovery filters where needed.

Shoptet uses a category tree, and products can sit in several categories. Shopify has no native category tree: it uses collections, manual or automated by rules such as tags, vendor or product type, and navigation menus that recreate the hierarchy visually. We rebuild the tree as collections plus menus.

Czech product names and descriptions come over as the default language content. Handles are generated consistently from the product names without diacritics, and the old-to-new URL pairs are stored for the redirect map. Images are transferred at full resolution with alt text.

#### Customers, passwords and order history

Customer records, billing and shipping addresses, company details (IČO and DIČ for business customers) and newsletter consent are imported into Shopify. Consent is carried over exactly as recorded, which matters under GDPR.

Passwords cannot be migrated. Shopify does not accept password imports from another platform, so customers set a new password or sign in through Shopify's customer accounts after launch. We plan the activation message and its timing with you, in the customer's language.

Order history is imported as historical orders linked to customers, with items, prices, VAT, shipping, payment method and status, and the original Shoptet order number kept as a reference. Notifications are suppressed during import. Invoice documents generated by Shoptet stay as archived records; Shopify does not re-issue them.

#### URLs, SEO and 301 redirects from Shoptet

Shopify uses fixed URL prefixes: `/products/{handle}`, `/collections/{handle}`, `/pages/{handle}` and `/blogs/{blog}/{handle}`. Shoptet paths do not follow these patterns, so practically every indexed URL changes and needs a 301 redirect. We confirm the real Shoptet URL patterns from a crawl rather than assuming them, then build the map from crawl data, Search Console, the XML sitemap and backlinks.

The map covers products, variant URLs where they exist, categories, articles, static pages, manufacturer pages and filter or parameter URLs that earned traffic. Redirects are added in Shopify admin under URL redirects (or imported in bulk) and apply when the old path no longer exists on Shopify, which is the case for Shoptet paths.

Before launch we test the map on the new store; after launch we crawl again, submit the sitemap and monitor Search Console coverage for the Czech and Slovak properties. Redirects protect URL continuity and existing link value; they cannot guarantee rankings, and we do not promise them.

#### Heureka, Zboží.cz, Czech carriers, invoicing and ERP

This is where Shoptet-to-Shopify projects are won or lost. Product feeds for Heureka and Zboží.cz, often including delivery times, categories and CPC settings, are generated by Shoptet. On Shopify they come from a feed app or a feed-management tool, and the category mapping, availability logic and Heureka review integration (Ověřeno zákazníky) need to be rebuilt and validated before launch.

Czech and Slovak carriers such as Zásilkovna (Packeta), PPL, DPD, Česká pošta and Balíkovna need Shopify apps or custom integration for rates, pickup-point selection at checkout and label printing. Pickup-point selection in Shopify's checkout depends on the app and the Shopify plan, so we test the exact flow. Cash on delivery is available as a manual payment method, but a COD surcharge usually needs an app. Local payment gateways must be checked for Shopify support.

Shoptet issues invoices natively. Shopify does not produce Czech tax documents in the expected format on its own, so invoicing moves to an invoicing app, an online invoicing service or your ERP. ERP and warehouse connections (for example Pohoda or Money S3) need a Shopify connector or middleware. We list every integration, confirm the replacement and test it end to end on staging with real orders.

#### Languages and currencies: from Shoptet to Shopify Markets

Shoptet stores that sell in several languages or currencies usually run language versions or separate projects per country. Shopify Markets groups countries into markets with their own currency, pricing, languages and domain or subfolder (for example `/sk` or a separate `.de` domain). Translations are managed through Shopify's Translate & Adapt app, CSV import or a translation app, and Shopify outputs hreflang for published languages and markets, which we verify after launch.

We design the market structure before migrating: which countries share a market, whether prices are fixed per market or converted, how VAT-inclusive prices are shown, and how existing Slovak or other foreign-language URLs redirect into the new structure.

#### How the Shoptet to Shopify migration runs

Audit: full Shoptet exports, crawl, add-on and integration inventory (feeds, carriers, payments, invoicing, ERP), and the target market plan. Mapping: a signed-off data map for products, parameters, categories, customers, orders, content, URLs and integrations.

Trial migration: a complete import into the Shopify store with counts compared against Shoptet and a hand check of edge cases: products with many variants, sets, items without stock, business customers, orders with discounts. Feeds and carrier flows are tested on the trial data. Automation compares; a person approves. Sign-off: you test storefront, checkout, emails, invoices and admin work.

Launch: a short freeze on Shoptet, delta migration of new orders, customers and stock, domain switch, redirect activation, feed switch and live test orders. Post-launch QA: redirect crawl, Search Console, feed validation in Heureka and Zboží.cz, order-to-invoice-to-ERP checks. Keep the Shoptet account active until exports are archived and the new flows are confirmed.

#### Limitations to know before you commit

Passwords do not transfer. Shoptet add-on data may not be exportable. Some local services (carriers, gateways, invoicing formats) depend on third-party Shopify apps whose quality and pricing vary, and a few may require custom development. Shopify's three-option variant model changes how complex Shoptet products are structured. Running costs change from one Shoptet plan to a Shopify plan plus several apps, which should be priced before the decision.

#### What moves from Shoptet to Shopify

- Products and variants [transform]: Shoptet variants become Shopify variants within the three-option limit; extra parameters move to metafields.
- Parameters and filters [transform]: Filtering parameters become metafields connected to Shopify's storefront filters.
- Categories [transform]: The Shoptet category tree is rebuilt as Shopify collections plus navigation menus.
- Images and media [migrates]: Product and content images are transferred at full resolution with alt text.
- Customers and addresses [migrates]: Includes company IČO and DIČ and newsletter consent, mapped to fields your invoicing can read.
- Customer passwords [not-migratable]: Shopify does not accept imported passwords, so customers activate their accounts after launch.
- Order history [assess]: Imported as historical orders where Shoptet exports provide enough detail; invoices stay archived.
- Product reviews [assess]: Store reviews depend on what Shoptet exports and the Shopify review app; Heureka reviews stay on Heureka.
- Pages, articles and blog [migrates]: Shoptet articles and pages become Shopify pages and blog posts with cleaned formatting.
- URLs and 301 redirects [transform]: Every indexed Shoptet URL is mapped to Shopify's fixed paths and redirected.
- SEO metadata [migrates]: Meta titles and descriptions move to Shopify's SEO fields per product, collection and page.
- Discount codes and gift vouchers [rebuild]: Recreated as Shopify discounts; voucher balances need a gift card setup and a check of what can be exported.
- Heureka and Zboží.cz feeds [rebuild]: Rebuilt with a feed app or feed tool, including category mapping and delivery times.
- Czech carriers and pickup points [assess]: Depends on available Shopify apps and plan for rates, pickup-point checkout and labels.
- Invoicing and ERP [rebuild]: Moves to an invoicing app, service or ERP connector because Shopify does not issue Czech invoices natively.
- Theme and design [rebuild]: The storefront is rebuilt as a Shopify theme ready for several markets.
- Languages and currencies [transform]: Shoptet language versions or country projects are consolidated into Shopify Markets.

#### FAQ

Q: Can we keep Heureka and Zboží.cz after moving to Shopify?
A: Yes, but the feeds are no longer generated by the platform. They come from a feed app or feed-management tool, and category mapping, delivery times and the Heureka review integration need to be rebuilt and validated before launch.

Q: Will Zásilkovna, PPL and other Czech carriers work on Shopify?
A: Usually through Shopify apps, but pickup-point selection at checkout, COD and label printing differ by app and plan. We test the exact delivery flow on staging before you commit to launch.

Q: Do customers need a new password after the move?
A: Yes. Shopify cannot import passwords from Shoptet, so customers activate their accounts on the new store. We plan the activation message in Czech, Slovak or the market language.

Q: Can one Shopify store replace our Czech and Slovak Shoptet shops?
A: Often yes, with Shopify Markets handling currencies, languages and domains or subfolders. Whether one store is right depends on pricing, VAT display, stock and legal requirements per country, which we check in the assessment.

Q: What drives the cost and timeline of a Shoptet to Shopify migration?
A: Mostly the local integrations: feeds, carriers, payments, invoicing and ERP. Catalog complexity, the number of languages and markets, and how much order history you want imported also matter more than raw product count.

Sources:
- Shopify - Migrate your store to Shopify: https://www.shopify.com/migrate
- Shoptet official site: https://www.shoptet.cz
- Shopify Help Center - Importing and exporting customer lists: https://help.shopify.com/en/manual/customers/import-export-customers

### Shopware to Shopify migration (Shopware 5 and 6)

URL: https://prevedshop.com/migrations/shopware-6-to-shopify
Language: en
Last reviewed: 2026-09-25
Route: shopware-6 -> shopify

This route is for DACH and EU merchants on Shopware who have decided that a hosted platform is a better fit than another Shopware upgrade. For Shopware 5 stores, which have reached end of life, the alternative is usually a Shopware 6 rebuild anyway, so Shopify is compared against that project, not against staying put. Shopware 6 stores move for maintenance cost and ecosystem reasons. Prevedshop handles both versions as a managed migration: a named lead audits the Shopware database and plugins, maps properties, sales channels and SEO URLs to Shopify, runs a trial migration and manages cutover and post-launch QA.

#### Why stores move from Shopware to Shopify (and when not to)

Shopware 5 has reached end of life, and Shopware no longer ships regular security updates for it. Its official path forward is Shopware 6, which is a different system: a new Symfony-based data model, a new administration, and plugins that must be replaced rather than updated. Because a 5-to-6 move is effectively a replatforming project, many merchants use that moment to compare Shopware 6 with Shopify.

Shopware 6 merchants move for different reasons: hosting and update overhead on self-hosted setups, plugin compatibility work at every major release, and agency dependency for changes that are app installs on Shopify. Shopify removes server operations, platform patching and checkout PCI scope from your team.

When not to move: stores with heavy B2B logic (customer-specific prices, quotes, complex Rule Builder conditions), deep ERP-driven processes or highly customised product configurators may find Shopware 6 fits better, or that Shopify requires Plus features and custom apps to match. We make that comparison explicit in the assessment.

#### Shopware 5 vs Shopware 6 as a source

The two versions store data differently, so the extraction is different. Shopware 5 keeps articles, variants built from configurator groups and options, filter properties, free text fields (attributes), subshops and language shops in its own schema; we usually extract directly from the database or through the Shopware 5 REST API, and check for legacy plugins that stored data in their own tables.

Shopware 6 uses products and variants generated from property groups and options, custom field sets, sales channels with domains, languages and currencies, Shopping Experiences layouts for CMS, and the Rule Builder for pricing and shipping logic. Extraction runs through the Admin API or the database. Both versions can hold plugin data not visible in the admin, so the audit checks the actual tables.

#### Properties, variants and custom fields on Shopify

In Shopware, variants are built from property options (size, colour, material), and further properties are attached for filtering and product information. Shopify products support up to three option dimensions. Products that use more variant-defining property groups have to be restructured: either one group moves to separate products, or the least important option becomes a metafield or a line-item property handled by an app.

Non-variant properties and custom fields (Shopware 6) or free text fields (Shopware 5) move into Shopify metafields with defined types, and filter properties are connected to Shopify's storefront filters. Variant-specific data such as EAN, manufacturer number, purchase unit and reference unit for base prices (important for German price labelling) is mapped explicitly, because Shopify has no built-in base-price field and needs metafields or an app to show unit prices in the required format.

The Shopware category tree becomes Shopify collections plus navigation menus. Dynamic product groups in Shopware 6 translate reasonably well to automated collections when the conditions can be expressed as tags, vendor, type or price.

#### Sales channels, languages and currencies

One Shopware installation can serve several storefronts: Shopware 5 through subshops and language shops, Shopware 6 through sales channels, each with its own domains, languages, currencies and sometimes different catalogs or prices. Shopify splits this differently. Countries, currencies, languages and domains or subfolders within one brand are handled by Shopify Markets in a single store. Separate brands, genuinely separate catalogs or strict legal separation usually mean separate Shopify stores, which on Plus can be managed as expansion stores.

We map each Shopware sales channel or subshop by its purpose: a translated storefront becomes a market language, a Swiss storefront in CHF becomes a market with its own currency and pricing, a B2B channel may need Shopify's B2B features (a Plus capability) or a separate approach. Old language-shop URLs are redirected into the new structure.

#### Customers, passwords and order history

Customers, addresses, customer groups (as tags or B2B companies), company data and VAT IDs, and newsletter status are imported. Double opt-in records are kept as documented consent.

Passwords cannot be moved. Shopify does not accept imported password hashes from another platform, so customers set a new password or sign in with Shopify's customer accounts after launch. We plan the activation email in German or the relevant market language.

Order history is imported as historical orders with line items, net and gross prices, tax rates, shipping, discounts, payment method and status, linked to customers, with Shopware order numbers kept as references. Notifications stay off during import. Invoices, delivery notes and credit notes generated by Shopware remain archived documents; Shopify does not recreate them.

#### SEO URL templates, redirects and search visibility

Shopware builds URLs from SEO URL templates, and many stores have customised them over the years, sometimes per sales channel. Defaults typically include the category path and an ID in Shopware 5 and the product name with product number in Shopware 6, but we never rely on defaults: we crawl every domain and read the SEO URL table to get the real, current URL set, including older URLs Shopware still redirects.

Shopify uses fixed paths: `/products/{handle}`, `/collections/{handle}`, `/pages/{handle}` and `/blogs/{blog}/{handle}`, with market subfolders in front where used. Nearly every Shopware URL therefore changes. The redirect map covers products, variants with their own URLs, categories, manufacturer pages, Shopping Experiences landing pages, blog posts and language-shop URLs, using crawl data, Search Console, sitemaps and backlink data. Redirects are imported into Shopify's URL redirects and apply because the old paths no longer exist there.

After launch we crawl again, test the map, submit sitemaps per domain and monitor Search Console. Redirects protect URL continuity; they cannot guarantee rankings, and we do not promise them.

#### Plugins, checkout, payments and DACH-specific requirements

Each Shopware plugin or app is reviewed: replace with a Shopify app, rebuild as a custom app, or drop. Common cases are payment plugins (PayPal, Klarna, SEPA and purchase on account through a provider), shipping and label plugins for DHL or DPD, ERP and marketplace connectors, product configurators and custom pricing rules. Shopware's Rule Builder and Flow Builder logic becomes Shopify discounts, Shopify Functions (on Plus for checkout-level changes), Shopify Flow or app logic, depending on what each rule does.

Legal and tax set-up is redone, not copied: tax-inclusive or net display per market, base price labelling, legal texts and checkout confirmation wording, invoice generation through an app or the ERP, and VAT for cross-border EU sales. The Shopware theme and Shopping Experiences layouts are rebuilt as a Shopify theme with sections and templates.

#### How the Shopware to Shopify migration runs

Audit: database and API access, plugin inventory, sales channel and domain map, SEO URL crawl, integration list. Mapping: a signed-off data map for properties, variants, custom fields, categories, customers, orders, content, URLs and integrations, with decisions on products exceeding three options.

Trial migration: a full import into the Shopify store, with counts and totals compared against Shopware per sales channel and a hand check of edge cases such as products with many variants, base price products, B2B customers and orders with mixed tax rates. Automation assists the comparison; a person approves. Sign-off: you test storefront, checkout, emails, invoices and admin workflows per market.

Launch: a short freeze, delta migration of new orders, customers and stock, DNS switch per domain, redirect activation and live test orders. Post-launch QA: redirect crawl, Search Console per property, feed and ERP checks, and order monitoring.

#### Limitations to know before you commit

Passwords do not transfer. Products with more than three variant dimensions must be restructured. Complex Rule Builder pricing and B2B logic may need Shopify Plus or custom apps. Plugin data without a Shopify equivalent may only be archived. German base price display and invoicing require apps or ERP support that we specify during the audit.

#### What moves from Shopware to Shopify

- Products and variants [transform]: Shopware variants map to Shopify variants; products with more than three variant groups are restructured.
- Properties, custom fields and free text fields [transform]: Moved into typed Shopify metafields and connected to storefront filters where needed.
- Categories and dynamic product groups [transform]: The category tree becomes collections plus menus; dynamic groups become automated collections where conditions allow.
- Images and media [migrates]: Product and media manager images are transferred with alt text and variant assignment.
- Customers and addresses [migrates]: Includes company data, VAT IDs, customer groups as tags and documented newsletter consent.
- Customer passwords [not-migratable]: Shopify does not accept imported hashes from Shopware 5 or 6, so customers activate new accounts.
- Order history [migrates]: Imported as historical orders with net and gross amounts and Shopware order numbers as reference.
- Product reviews [assess]: Shopware reviews or review plugins are imported into a Shopify review app where it accepts imports.
- CMS pages, Shopping Experiences and blog [rebuild]: Text content moves; layouts are rebuilt as Shopify theme sections and templates.
- URLs and 301 redirects [transform]: Real URLs from SEO URL templates are crawled and mapped to Shopify paths per domain.
- SEO metadata [migrates]: Meta titles and descriptions move per language into Shopify SEO fields and translations.
- Discounts, promotions and vouchers [transform]: Promotions become Shopify discounts; rules that Shopify cannot express need an app or Functions.
- Plugin data [assess]: Each plugin's tables are checked for data worth moving and a Shopify replacement.
- Theme and design [rebuild]: The Shopware theme is rebuilt as a Shopify theme ready for each market.
- Checkout, payments, shipping and tax [rebuild]: Providers, DACH shipping and tax display per market are configured and tested with real orders.
- Sales channels, subshops and translations [transform]: Mapped to Shopify Markets, languages and domains, or to separate stores where brands differ.
- B2B pricing and customer-specific rules [assess]: Depends on Shopify B2B (a Plus feature) or apps, and on how complex the Shopware rules are.

#### FAQ

Q: We are still on Shopware 5. Should we go to Shopware 6 or Shopify?
A: Both are real migrations because Shopware 6 is a different system. We compare them on your catalog, plugins, B2B needs and running costs. Stores with standard B2C processes often find Shopify simpler to run; complex B2B setups may fit Shopware 6 better.

Q: Does the migration work the same for Shopware 5 and Shopware 6?
A: The target is the same, but extraction differs: different database schemas, APIs, variant structures and plugin data. We audit the actual installation rather than assuming a version-generic export.

Q: What happens to our Shopware sales channels or subshops?
A: Each one is mapped by purpose. Country, language and currency storefronts usually become Shopify Markets in one store; separate brands or catalogs may need separate Shopify stores.

Q: Will we keep our Google rankings after moving from Shopware?
A: Nobody can guarantee rankings. What we do is crawl every Shopware domain, map all indexed URLs to Shopify with 301 redirects, keep metadata and hreflang consistent, and monitor Search Console after launch.

Q: What drives the cost and timeline?
A: The number of sales channels and languages, plugins that hold data, B2B and pricing rules, products exceeding three variant options, integrations such as ERP and payment providers, and the theme rebuild.

Sources:
- Shopify - Migrate your store to Shopify: https://www.shopify.com/migrate
- Shopware official site and documentation: https://www.shopware.com
- Shopware Documentation - Shopware 5 End of Life: https://docs.shopware.com/en/shopware-5-en/end-of-life/shopware-5-end-of-life
- Shopify Help Center - Importing and exporting customer lists: https://help.shopify.com/en/manual/customers/import-export-customers

### WooCommerce to BigCommerce migration

URL: https://prevedshop.com/migrations/woocommerce-to-bigcommerce
Language: en
Last reviewed: 2026-09-25
Route: woocommerce -> bigcommerce

This page is for established WooCommerce stores moving to BigCommerce because they want a hosted platform without giving up a real category tree, flexible product options or control over URLs. What changes is where the data lives: WordPress posts, taxonomies and plugin tables become BigCommerce products, variants, modifiers, custom fields and categories, and WordPress plugins become apps or API integrations. Prevedshop runs it as a managed project: a named lead audits the WordPress install, maps every field, runs a trial migration you sign off, and handles redirects, launch and post-launch QA.

#### Why stores move from WooCommerce to BigCommerce, and when not to

The reasons are similar to any move off WooCommerce: owning WordPress core and plugin updates, hosting capacity, security and PCI scope becomes expensive as the store grows. BigCommerce hands hosting, checkout security and platform updates to the vendor. Stores often choose it over other hosted platforms because its catalog model sits closer to WooCommerce: nested categories, products in several categories, options that do not all create SKUs, and custom URLs for products and categories.

It is not automatically the right move. If most of your organic traffic comes from WordPress content, if you rely on deep checkout customization in PHP, or if a single WooCommerce extension is core to how you sell, check the BigCommerce equivalent first. Sometimes the answer is a cleaner WooCommerce setup, or WordPress kept for content with BigCommerce for commerce. We say that in the assessment when it applies.

#### Variations, attributes and custom fields on BigCommerce

In WooCommerce, attributes are either global taxonomies (such as `pa_size`) or local to one product, and variations are child posts. BigCommerce separates two kinds of options. Variant options create a SKU per combination with its own price, stock and image. Modifier options change the order line (engraving text, gift wrap, a paid add-on) without creating a SKU.

The mapping follows that split. Attributes used for variations become variant options. Product add-on data from plugins such as WooCommerce Product Add-Ons usually becomes modifiers, with price adjustments checked one by one. Variations set to "Any" value for an attribute are expanded into explicit variants, which changes SKU and inventory counts, so we reconcile them deliberately.

Attributes not used for variations, and Advanced Custom Fields data, become BigCommerce custom fields (name and value pairs shown on the product page) or, where structure matters, product metafields read by the theme or integrations. Grouped products are rebuilt as related products or bundles, and external/affiliate products need a theme change. Weight, dimensions, tax class, sale prices and stock settings are mapped field by field.

#### Categories, brands and catalog structure

BigCommerce has a category tree, and a product can belong to several categories, so WooCommerce product categories usually map across with their hierarchy intact. That makes this route more direct than a move to a collection-based platform, but we still review the tree: empty categories, duplicates and categories used only as filters are cleaned up with your approval, because each removed URL needs a redirect target.

Product tags have no direct navigational equivalent; they become search keywords, custom fields or categories depending on how they were used. Brands managed by a WooCommerce brands plugin or taxonomy map to BigCommerce's native brand entity, with brand pages and descriptions.

#### Customers, passwords and order history

Customer accounts, addresses and customer groups can be imported into BigCommerce, and WooCommerce roles used for wholesale or trade pricing are mapped to customer groups with their price rules. Customer passwords are a separate question: WordPress stores hashes (phpass or bcrypt depending on version), and whether they can be carried over depends on the migration method BigCommerce supports at the time. We plan for a password reset flow unless a supported method is confirmed during the assessment.

Order history is imported so customers and your team keep past orders. BigCommerce assigns its own order IDs, which matters for accounting, ERP and customer service, so we keep the WooCommerce order number as a reference and agree how it will be searched. Order statuses are mapped to BigCommerce statuses, and totals, taxes and counts are reconciled after the trial run. Refunds for old orders stay with the original gateway, and stored cards are never moved silently.

#### WooCommerce permalinks, BigCommerce URLs and 301 redirects

WordPress permalinks are configurable, so a WooCommerce store might use `/product/{slug}/`, `/product-category/{parent}/{child}/` or a custom base. BigCommerce lets you set custom URLs for products, categories, brands and pages, which often makes it possible to keep product slugs close to the originals. We still assume nothing: each important URL is compared old against new, and any change gets a 301 redirect, managed in the BigCommerce admin.

The redirect list is built from a crawl of the live store plus Search Console, analytics and backlink data, and covers products, categories, tags, blog posts, pages and indexed archives. Redirects point to the closest relevant page, not the homepage. SEO titles and descriptions from Yoast or Rank Math, image alt text and canonical intent move with the content. After launch we recrawl the old URL list, check chains and 404s, and submit the new sitemap in Search Console. That protects URL continuity; no migration can promise unchanged rankings.

#### WordPress content, plugins and integrations

BigCommerce has web pages and a basic blog, but not WordPress's editor, custom post types or page builders. Posts and pages can migrate as content, with layouts rebuilt in the Stencil theme or Page Builder. If content drives significant traffic, keeping WordPress for content next to BigCommerce is an option we weigh with you from the data.

Every active plugin gets a decision: native BigCommerce feature, app, custom API integration, or dropped. Reviews are exported and imported into BigCommerce's native reviews or a review app. WooCommerce Subscriptions depend on whether your gateway can move stored payment methods to a BigCommerce subscription app; otherwise customers re-subscribe. Memberships, points, wholesale rules and gift cards come from plugins with their own tables and are assessed one by one. Payments, shipping, tax, ERP, email marketing and product feeds are reconnected and tested in the trial migration.

#### How Prevedshop runs a WooCommerce to BigCommerce migration

We audit the WordPress database and plugin list, not only the WooCommerce CSV export, because much plugin data sits in postmeta and custom tables. The result is a field-level mapping you approve: variant options versus modifiers, custom fields, categories, customer groups, order statuses and content.

A trial migration goes into a BigCommerce sandbox or staging store and is reconciled: product, SKU and order counts, prices, stock, a set of products checked by a person, and redirects tested against the crawl list. Automation compares source and target; a person approves what reaches production. At launch we agree a short freeze, run a delta migration of new orders, customers and stock, switch DNS and activate redirects, then run post-launch QA on orders, emails, feeds and Search Console.

#### Limitations to know before you commit

Password transfer is not something to assume. Active subscriptions depend on your gateway. Order IDs change, so old numbers need a reference field. Page-builder layouts and WordPress custom post types are rebuilt, not migrated. Some WooCommerce extensions, especially custom checkout logic, have no one-to-one BigCommerce equivalent and need an app, API work or a changed process.

#### What moves from WooCommerce to BigCommerce

- Simple and variable products [transform]: Variations become variant options with SKUs; "Any" values are expanded into explicit variants.
- Product add-ons [transform]: Add-on plugin fields usually become modifier options with price adjustments checked individually.
- Attributes and custom fields (ACF, postmeta) [transform]: Mapped to BigCommerce custom fields or metafields depending on how the data is used.
- Categories and brands [migrates]: The category tree maps across; brand plugins or taxonomies map to native brands.
- Product tags [transform]: Converted to search keywords, custom fields or categories depending on their role.
- Images and media [migrates]: Product and variant images move with alt text; the full WordPress media library is not copied.
- Customers and customer groups [migrates]: Accounts and addresses import; WooCommerce roles for trade pricing map to customer groups.
- Customer passwords [assess]: Depends on the method BigCommerce supports for WordPress hashes; plan for a reset flow unless confirmed.
- Order history [transform]: Imported with new BigCommerce IDs and the WooCommerce number kept as reference.
- Product reviews [transform]: Exported from WordPress and imported into native reviews or a review app.
- WordPress blog posts and pages [transform]: Text and images move to BigCommerce pages and blog; layouts are rebuilt.
- URLs and 301 redirects [transform]: Custom URLs keep many slugs close to the original; every changed URL gets a 301.
- SEO titles and meta descriptions [migrates]: Yoast or Rank Math fields move to BigCommerce SEO fields.
- Coupons and gift cards [assess]: Coupons are recreated; gift card balances depend on the WooCommerce plugin and import options.
- Subscriptions and memberships [assess]: Depends on the gateway and the BigCommerce app chosen; may require customers to re-subscribe.
- Theme, checkout and payments [rebuild]: The storefront is rebuilt as a Stencil theme; gateways, shipping and tax are configured fresh.

#### FAQ

Q: Can we keep our WooCommerce URLs on BigCommerce?
A: Often close to them, because BigCommerce allows custom product and category URLs. We still compare every important URL old against new and add a 301 for each one that changes, then recheck them after launch.

Q: Will customers need new passwords?
A: Plan for yes. Whether WordPress password hashes can be carried over depends on the migration method BigCommerce supports, which we confirm in the assessment. If they cannot, we plan the reset email with you.

Q: What happens to our WooCommerce order numbers?
A: BigCommerce assigns its own order IDs. We keep the WooCommerce number as a reference on each imported order and agree with your accounting and support teams how old orders will be looked up.

Q: Do WooCommerce product add-ons work on BigCommerce?
A: Usually as modifier options, which change the order line without creating a SKU. Complex conditional add-on logic may need an app or a theme customization, and we list those products during mapping.

Q: What drives the cost of a WooCommerce to BigCommerce migration?
A: The number of plugins holding data, variation and add-on complexity, custom fields, WordPress content volume, indexed URLs and integrations to reconnect. Catalog size matters less than how much of it needs transformation.

Sources:
- BigCommerce official site and documentation: https://www.bigcommerce.com
- WooCommerce documentation: https://woocommerce.com/documentation/
- BigCommerce - Migrating to BigCommerce: https://www.bigcommerce.com/migration/
- BigCommerce Help Center - Guide to Migration from WooCommerce: https://support.bigcommerce.com/s/article/Guide-to-Migration-from-WooCommerce?language=en_US

### WooCommerce to Shopify migration

URL: https://prevedshop.com/migrations/woocommerce-to-shopify
Language: en
Last reviewed: 2026-09-25
Route: woocommerce -> shopify

This page is for established WooCommerce stores leaving self-hosted WordPress for Shopify without losing product data, order history, content or search visibility. What changes is the model: WooCommerce lets WordPress store almost anything as posts, taxonomies and plugin tables, while Shopify has a fixed product schema, fixed URL paths and apps instead of plugins. Prevedshop runs it as a managed project with a named lead: audit, field-by-field mapping, a trial migration you sign off, redirects, launch and post-launch QA.

#### Why stores move from WooCommerce to Shopify, and when they should not

The usual reasons are operational. On WooCommerce you own WordPress core, theme and plugin updates, hosting, caching, backups and server security. As the catalog and plugin stack grow, update conflicts and slow admin screens become a recurring cost in developer time. Shopify replaces that with a hosted platform, a managed checkout and an app ecosystem, in exchange for working inside its data model and URL rules.

It is not the right move for every store. If your business depends on heavy custom checkout logic, complex B2B pricing built in PHP, or WordPress content that behaves more like a publication than a shop, check what Shopify supports on your plan first. Sometimes the better answer is cleaning up the WooCommerce install, or running WordPress for content next to Shopify for commerce. We say so in the assessment.

#### WooCommerce variations and attributes to Shopify options, variants and metafields

WooCommerce stores products as WordPress posts, with attributes either global (taxonomies such as `pa_color`) or local to a single product, and variations as child posts. Shopify gives each product up to three option dimensions, each combination becoming a variant, plus metafields and metaobjects for everything else. The mapping decisions are specific to this route:

Attributes marked "used for variations" become Shopify options. A variable product that uses more than three such attributes has to be restructured: combine two attributes into one option, split the product, or move one dimension into a line-item customization app. We list every affected product before the trial run, not after.

Variations set to "Any" value for an attribute (for example "Any size") do not exist in Shopify. They are expanded into explicit variants, which changes variant counts, SKUs and inventory rows, so we reconcile those numbers deliberately.

Attributes that are not used for variations (material, fit, compatibility) become metafields with definitions, so they can be shown in the theme and used for storefront filtering. Advanced Custom Fields data is mapped the same way, field by field.

Grouped and external/affiliate products have no native Shopify equivalent and are rebuilt as bundles or with a theme customization.

#### Categories, tags and Shopify collections

WooCommerce product categories form a nested WordPress taxonomy, and a product can sit in several branches; product tags add a flat second taxonomy. Shopify has no category tree. It uses collections, either manual or automated from rules such as tag, vendor, type or price, plus navigation menus built separately.

We map each category with traffic or a commercial role to a collection, carry the hierarchy into the menus, and use tags where automated collections can maintain themselves. Category descriptions, images and Yoast or Rank Math titles move with the collection. Removing empty or duplicate categories is agreed with you, because each one needs a redirect target.

#### Customers, passwords and order history

Customer accounts, addresses, marketing consent and tags can be imported into Shopify. Customer passwords cannot. WordPress stores password hashes (phpass or bcrypt depending on the WordPress version), and Shopify does not accept hashes from another platform, so every customer needs to set a new password through an account invitation or activation email, or sign in with Shopify's email code login if you use its newer customer accounts. We plan when and how customers are told, because a badly timed mass invite looks like phishing.

Order history is migrated as historical orders so customers see past purchases and your team keeps the reference. These are records, not live transactions: refunds for pre-migration orders stay with the original payment gateway. We keep the WooCommerce order number as a reference, map order statuses to Shopify's financial and fulfillment states, and reconcile order counts and totals after the trial run. Saved cards are never moved silently; they depend on your gateway.

#### WordPress permalinks, Shopify's fixed paths and 301 redirects

WordPress permalinks are configurable, so a WooCommerce store might use `/product/{slug}/`, `/product-category/{slug}/` or a custom structure, usually with a trailing slash. Shopify uses fixed paths: `/products/{handle}`, `/collections/{handle}`, `/pages/{handle}` and `/blogs/{blog}/{handle}`. On this route almost every URL changes, so the redirect map is a core deliverable.

We crawl the live store and combine the crawl with Search Console, analytics and backlink data to list the URLs that matter: products, categories, product tags, blog posts, pages and indexed archives. Each gets a 301 to the closest relevant Shopify URL, not a blanket redirect to the homepage. Shopify redirects are managed in the admin and only apply when the old path no longer exists on Shopify. Filter URLs from WooCommerce layered navigation need a separate decision.

SEO titles and meta descriptions from Yoast or Rank Math and image alt text move with the content, and we check structured data in the new theme. After launch we recrawl the old URL list, check chains and 404s, and submit the new sitemap in Search Console. Redirects protect URL continuity; nobody can promise unchanged rankings.

#### WordPress blog, pages and custom content

WordPress is a full CMS, and many WooCommerce stores rely on it for guides, page-builder landing pages and custom post types. Shopify has pages and blogs with a simpler editor, plus metaobjects for structured content. Blog posts, authors, featured images and tags can move into a Shopify blog; comments need an app or are archived. Elementor, Divi or WPBakery layouts do not migrate as layouts: text and images move, and the design is rebuilt as theme sections.

If content drives a large share of organic traffic, WordPress can stay for content while Shopify runs commerce. That adds a second system to maintain, so we decide it from traffic data.

#### Plugins, apps and integrations: reviews, subscriptions, memberships, checkout

Every active WooCommerce plugin gets an explicit decision: Shopify native feature, App Store app, custom app, or dropped. Plugins that hold data need the most care.

Product reviews live in WordPress comments or a review plugin's tables. Shopify says reviews cannot be migrated directly, so we export them and import them into the review app you choose, keeping ratings, dates and product links where the app supports it.

WooCommerce Subscriptions depend on the gateway that holds each customer's payment method. They move into a Shopify subscription app only where the gateway and app support token migration; otherwise customers re-subscribe. We check this per gateway before committing to a plan.

Memberships, wholesale pricing, points and gift cards come from plugins with their own tables. Each is rebuilt with an app or custom logic, and balances migrate only where the target app supports import.

Checkout customization is narrower than in a PHP checkout; custom logic moves to checkout extensions on Plus or is redesigned. Payments, shipping, tax, ERP, email marketing and product feeds are reconnected and tested during the trial migration.

#### How Prevedshop runs a WooCommerce to Shopify migration

We start with an audit of the WordPress database and plugin list, not only the WooCommerce CSV export, because plugin data often sits in postmeta and custom tables the export skips. From that we produce a field-level mapping document you approve.

Then we run a trial migration into a development Shopify store and reconcile it: product, variant and order counts, prices and stock, products checked by a person, and redirects tested against the crawl list. Automation compares source and target data; a person signs off every decision that reaches production.

At launch we agree a short content freeze, run a delta migration of new orders, customers and stock, switch DNS and activate redirects. Post-launch QA covers test orders, emails, tracking, feeds, Search Console coverage and 404 monitoring.

#### Limitations to know before you commit

Customer passwords do not transfer. Active subscriptions depend on your gateway and may require customers to re-subscribe. Products with more than three variation attributes need restructuring. Page-builder layouts are rebuilt, not migrated. Shopify URL paths are fixed, so redirects cannot be avoided, and redirects only fire for paths that no longer exist on Shopify. Some plugin behavior, especially custom checkout logic, has no one-to-one Shopify equivalent.

#### What moves from WooCommerce to Shopify

- Simple and variable products [transform]: Variations become variants; products with over three variation attributes or "Any" values are restructured first.
- Attributes and custom fields (ACF, postmeta) [transform]: Non-variation attributes and custom fields become typed metafields or metaobjects.
- Grouped and external products [rebuild]: No native equivalent; rebuilt as bundles or with a theme customization.
- Categories and product tags [transform]: Categories become collections plus menus; tags can drive automated collections.
- Product images and media [migrates]: Product and variant images move with alt text; the WordPress media library is not copied wholesale.
- Customers and addresses [migrates]: Accounts, addresses, tags and recorded marketing consent are imported.
- Customer passwords [not-migratable]: WordPress hashes cannot be imported; customers set a new password via invitation or use email code login.
- Order history [transform]: Imported as historical orders keeping the WooCommerce number as reference; refunds stay with the old gateway.
- Product reviews [transform]: Exported from WordPress comments or the review plugin and imported into a Shopify review app.
- WordPress blog posts and pages [transform]: Content moves to Shopify blogs and pages; page-builder layouts are rebuilt as theme sections.
- URLs and 301 redirects [transform]: WordPress permalinks are mapped to Shopify's fixed paths with one-to-one 301 redirects.
- SEO titles and meta descriptions [migrates]: Yoast or Rank Math fields move to Shopify SEO fields.
- Coupons and gift cards [assess]: Coupons are recreated as discounts; gift card balances depend on the plugin and Shopify's import options on your plan.
- Subscriptions [assess]: Depends on whether your gateway and Shopify subscription app support payment method migration.
- Memberships and other plugin data [assess]: Each plugin's tables are mapped to an app, a custom app or an archive.
- Theme and design [rebuild]: WordPress themes do not run on Shopify; the storefront is rebuilt as a Liquid theme.
- Checkout, payments, shipping and tax [rebuild]: Configured fresh in Shopify; custom checkout logic is moved to supported extensions or redesigned.

#### FAQ

Q: Will my customers have to reset their passwords after moving to Shopify?
A: Yes. Shopify cannot import WordPress password hashes, so customers set a new password through an account invitation or sign in with an email code if you use Shopify's newer customer accounts. We plan the timing and wording of that email with you.

Q: How do you protect SEO when WooCommerce URLs change to Shopify's /products/ and /collections/ paths?
A: We build a one-to-one 301 redirect map from a crawl plus Search Console and backlink data, carry over SEO titles and descriptions, and recheck every mapped URL after launch. That protects URL continuity; no one can guarantee rankings.

Q: What happens to products with many variation attributes?
A: Shopify allows three option dimensions per product. Products using more are restructured by combining attributes, splitting products or moving a dimension to a customization app, and we list them before the trial migration.

Q: Can WooCommerce Subscriptions move to Shopify without customers re-subscribing?
A: Sometimes. It depends on whether your gateway can hand stored payment methods to the Shopify subscription app you choose. We check this during the assessment.

Q: What drives the cost and timeline of a WooCommerce to Shopify migration?
A: Mostly the number of plugins holding data, variation complexity, custom fields, volume of WordPress content, the number of indexed URLs and the integrations to reconnect. Catalog size matters less than how much of it needs transformation.

Sources:
- Shopify - Migrate your store to Shopify: https://www.shopify.com/migrate
- WooCommerce documentation: https://woocommerce.com/documentation/
- Shopify Help Center - Migrate from WooCommerce: https://help.shopify.com/en/manual/migrating-to-shopify/migrating-from-woocommerce
- Shopify Help Center - URL redirects: https://help.shopify.com/en/manual/online-store/menus-and-links/url-redirect

### WooCommerce to Shoptet migration

URL: https://prevedshop.com/migrations/woocommerce-to-shoptet
Language: en
Last reviewed: 2026-09-25
Route: woocommerce -> shoptet

This page is for Czech and Slovak merchants, and foreign owners of stores in those markets, who want to leave a self-hosted WordPress and WooCommerce setup for Shoptet. What changes is the whole operating model: WordPress posts, taxonomies and plugin tables become Shoptet's structured import of products, variants, parameters and categories, and many local plugins are replaced by what Shoptet offers natively or through its add-on marketplace. Prevedshop runs the move with a named lead who audits the store, prepares the import, runs a trial you sign off, and handles redirects, launch and post-launch checks.

#### Why stores move from WooCommerce to Shoptet, and when not to

Most stores make this move because running WordPress well costs time: plugin updates, hosting, caching, security and backups all land on the merchant or their developer. Shoptet is a hosted platform built for the Czech and Slovak market, so local carriers, payment gateways, invoicing and feeds for comparison sites such as Heureka and Zboží.cz are available natively or as add-ons, and several WooCommerce plugins usually become unnecessary.

The trade-off is flexibility. Shoptet's product, content and checkout model is narrower than WordPress, and custom PHP logic has nowhere to run. If you sell mainly outside CZ and SK, rely on complex custom checkout rules, or run WordPress primarily as a publication, compare other targets first. We say so in the assessment when Shoptet is not the right fit.

#### Products, variants and parameters in Shoptet

WooCommerce keeps products as WordPress posts, with global attributes (such as `pa_size`), local attributes and variations as child posts. Shoptet expects a structured import in which products, variants, parameters, categories and availability are defined in its own columns, and every product needs a unique product code.

Variants are the main technical issue on this route. Shoptet's own help for WooCommerce transfers notes that a plain WooCommerce export does not import variants correctly: they have to be built through Shoptet's full export and import format or set up against variant templates. We therefore do not rely on the default CSV. We extract variations from the database, normalize attribute values (for example "XL", "xl" and "X-Large"), expand variations set to "Any" value into explicit variants, and generate an import file that matches Shoptet's variant parameters.

Attributes used for filtering become Shoptet filtering parameters, which are created and named before the import so filters work on launch day. Custom fields from Advanced Custom Fields or other plugins have no automatic target; each is decided on purpose as a parameter, part of the description, or dropped. Prices with and without VAT, VAT rates, stock and availability labels are checked against how you invoice in CZ and SK.

#### Categories and catalog structure

Both systems support nested categories, so the WooCommerce tree can usually be carried over. We still review it: WooCommerce stores often accumulate categories created only for filtering or campaigns, and product tags that duplicate categories. On Shoptet, a clean hierarchy plus parameters for filtering generally works better than a deep tree. Category descriptions, images and SEO fields from Yoast or Rank Math move with the category. Any category we remove needs a redirect target, so removals are agreed with you.

#### Customers, passwords and order history

Customer accounts with contact details, billing and delivery addresses and company data (IČO and DIČ where stored) can be prepared for import into Shoptet. Customer passwords are a different matter: WordPress stores hashes (phpass or bcrypt depending on the version), and whether Shoptet can accept them for your account is something we confirm during the assessment. Plan for customers setting a new password on first login, and for a clear message explaining why.

Order history matters for returns, warranty claims and repeat customers. Whether and how orders are imported depends on the tooling available for your Shoptet plan, including paid add-ons from the Shoptet marketplace, so we assess it per project. Where orders are imported they are history for reference, not live orders to process again, and we keep the WooCommerce order number as the reference. Stored payment methods are never moved.

#### WordPress permalinks, Shoptet URLs and 301 redirects

WordPress permalinks are free-form: `/product/{slug}/`, `/product-category/{slug}/`, a custom shop base or date-based blog paths. Shoptet generates its own URL paths, so most product, category and article URLs will change. Every indexed URL that changes needs a 301 redirect to its Shoptet equivalent.

We build the list from a crawl of the live store plus Google Search Console, analytics and backlinks, and map each URL to the closest relevant page rather than the homepage. Shoptet manages redirects in its admin, supports 301 and 302 redirects and a CSV import, and its help recommends entering paths with a trailing slash; we follow its format and test every rule before launch. After launch we recrawl the old URL list, check 404s and chains, and submit the new sitemap in Search Console. Redirects protect URL continuity; nobody can guarantee rankings.

#### WooCommerce plugins, Czech integrations and content

Every active plugin gets a decision: native Shoptet feature, Shoptet add-on, external integration, or dropped. On this route many local plugins are replaced by Shoptet's own tools: carrier and pickup-point integrations (for example Zásilkovna or PPL), Czech payment gateways, invoicing, and XML feeds for Heureka, Zboží.cz and Google Merchant Center. Feeds are regenerated from Shoptet and resubmitted, and category mapping in comparison sites is checked, because product IDs and URLs change.

Reviews, loyalty points, subscriptions, memberships and wholesale pricing come from plugins with their own tables; each is assessed for an import path or a Shoptet add-on, and some are rebuilt by process rather than migrated. Blog posts and pages move as text and images into Shoptet's articles and pages; page-builder layouts are rebuilt in the Shoptet template. Accounting, ERP and warehouse connections are reconnected and tested before launch, and access to Shoptet's API depends on your plan, which affects custom integrations.

#### How Prevedshop runs a WooCommerce to Shoptet migration

We audit the WordPress database and plugin list rather than only the WooCommerce CSV export, because variations and plugin data often sit in postmeta and custom tables. The output is a mapping you approve: product codes, variants and variant parameters, filtering parameters, categories, customer fields and content.

The trial import goes into a Shoptet store before launch and is reconciled: product and variant counts, prices with VAT, stock, a set of products checked by a person, feeds validated and redirects tested against the crawl list. Automation helps compare source and target; a person approves what reaches production. At launch we agree a short freeze, import new orders, customers and stock changes since the trial, move the domain following Shoptet's process, and activate redirects. Post-launch checks cover test orders, invoices, carrier labels, feeds and Search Console.

#### Limitations to know before you commit

WooCommerce variants do not import from the default export and need a prepared import. Password transfer and order import depend on Shoptet's options for your plan and are confirmed in the assessment. Custom PHP logic, page-builder layouts and some plugin features have no direct Shoptet equivalent. Most URLs change, so the redirect map is part of the project, not an optional extra.

#### What moves from WooCommerce to Shoptet

- Simple products [migrates]: Imported with unique product codes, prices with VAT, stock and availability.
- Variable products and variations [transform]: Rebuilt from database data into Shoptet's variant import, because the default WooCommerce export does not carry variants correctly.
- Attributes and custom fields [transform]: Filtering attributes become Shoptet parameters; ACF fields are mapped or dropped one by one.
- Categories and product tags [transform]: The category tree carries over after cleanup; tags become categories, parameters or are dropped.
- Images and media [migrates]: Product and variant images move with the import; the full WordPress media library is not copied.
- Customers and company data [migrates]: Contacts, addresses and IČO/DIČ where stored are prepared for Shoptet's customer import.
- Customer passwords [assess]: Depends on what Shoptet accepts for WordPress hashes; plan for customers setting a new password.
- Order history [assess]: Depends on the import tooling or add-on available for your plan; imported orders are history only.
- Product reviews [assess]: Review plugin data is checked for a Shoptet import path; otherwise archived.
- Blog posts and pages [transform]: Text and images move to Shoptet articles and pages; layouts are rebuilt in the template.
- URLs and 301 redirects [transform]: WordPress permalinks are mapped to Shoptet URLs and imported as 301 redirects.
- SEO titles and meta descriptions [migrates]: Yoast or Rank Math fields move to Shoptet's SEO fields for products, categories and articles.
- Coupons and gift vouchers [assess]: Active codes are recreated in Shoptet; plugin-based voucher balances are checked individually.
- Plugin data (loyalty, memberships, subscriptions) [assess]: Mapped to a Shoptet feature or add-on, rebuilt as a process, or archived.
- Comparison feeds (Heureka, Zboží.cz, Google) [rebuild]: Regenerated from Shoptet with category mapping rechecked, since IDs and URLs change.
- Theme, checkout, payments and shipping [rebuild]: Configured in Shoptet with local gateways and carriers; WordPress themes do not carry over.

#### FAQ

Q: Why can't we just use the WooCommerce CSV export for Shoptet?
A: For simple products it can be a starting point, but Shoptet's own help notes that the WooCommerce export does not import variants correctly, and plugin data is missing from it. We build the import from the database so variants, parameters and codes are right on the first trial.

Q: Will our WooCommerce URLs keep working on Shoptet?
A: Only through 301 redirects. Shoptet generates its own URL paths, so we map each indexed WordPress URL to its Shoptet equivalent, import the redirects and test them before and after launch.

Q: Can we move customers and orders?
A: Customers with addresses and company data can be imported. Passwords and order history depend on what Shoptet supports for your plan and account, which we confirm in the assessment before you commit.

Q: What happens to Heureka and Zboží.cz feeds?
A: They are regenerated from Shoptet and resubmitted, and category mapping on the comparison sites is checked, because product IDs and URLs change with the move.

Q: What decides how long the migration takes?
A: Variant complexity, how many plugins hold data, the number of indexed URLs, content volume and the integrations to reconnect. We give a timeline after the audit rather than a generic range.

Sources:
- Shoptet Developers - Data import: https://developers.shoptet.com/shoptet-tools/data-import/
- WooCommerce - Product CSV importer and exporter: https://woocommerce.com/document/product-csv-importer-exporter/
- Shoptet Podpora - Převod dat z WooCommerce do Shoptetu: https://podpora.shoptet.cz/prevod-dat-z-woocommerce-do-shoptetu/
- Shoptet Podpora - Přesměrování adres (URL): https://podpora.shoptet.cz/presmerovani-adres-url/

### Guides

### How to choose an ecommerce platform before you migrate

URL: https://prevedshop.com/guides/how-to-choose-ecommerce-platform
Language: en
Last reviewed: 2026-09-02

Choosing a platform is the decision that shapes every later migration cost. Feature checklists from vendors rarely help, because most modern platforms cover the basics. The useful questions are about your catalog structure, the market you sell to, the systems you must connect, how much ownership you want, and what the migration itself will demand. This guide walks through those five questions and ends with a short list of red flags that should stop a decision.

#### Start with your catalog, not the feature list

Count your products, variants and parameters, and look at how they relate. Three option dimensions with a clean set of filter attributes fit almost any platform. Attribute sets that differ by product type, bundles, configurators, B2B price lists or thousands of variants narrow the field to platforms with a richer data model, such as Adobe Commerce, Shopware or a composable stack. Write down the five most awkward products in your catalog and ask each candidate platform how it would store them; the answers reveal more than any comparison table.

#### Market, language and integrations

A store selling to Czech and Slovak customers needs local carriers, payment gateways, comparison-shopping feeds and invoicing rules. Shoptet or Upgates deliver those natively; a global SaaS platform can do it through apps at extra cost and maintenance. Selling into several countries raises different questions: language mutations, currencies, VAT handling and whether one store or several is the right shape. List the systems that must stay connected - ERP, accounting, warehouse, PIM, marketplace feeds - and check whether each candidate has a maintained connector or only an API you would have to build against.

#### Ownership, cost and the migration path

Hosted platforms trade control for convenience: you cannot touch the database, but you also never patch a server. Open-source platforms give you the data and the responsibility. Total cost includes licence or plan fees, hosting, apps or extensions, agency hours and the internal time spent on updates. Finally, price the migration itself: how much data you carry over, whether order history and customer accounts matter, how many URLs need redirects, and which custom functions must be rebuilt. A platform that looks cheaper on paper can cost more once the migration effort is added.

#### Red flags that should stop the decision

Be cautious when a platform cannot show how a specific data type from your current store will be represented, when an essential integration exists only as a third-party app with unclear maintenance, when the vendor promises that rankings will not change after migration, or when nobody can explain how you would leave the platform later. A short discovery with real samples of your data resolves most of these before you sign anything.

#### FAQ

Q: Should I choose the platform before or after the migration assessment?
A: Ideally the assessment informs the choice. A short discovery with real product, customer and order samples shows how each candidate would store your data and how much rebuild the migration would need.

Q: Is a hosted platform always cheaper than open source?
A: Not always. Hosted platforms have predictable fees but app costs add up; open-source platforms have no licence fee but require hosting, updates and developer time. Compare total cost over three years, including the migration.

Q: How important is the ecommerce platform for SEO?
A: Less than the migration process. Any mainstream platform can rank well; what loses visibility is a missing redirect map, changed content or slow pages after the move.

Q: Can I switch platforms again later?
A: Yes, if your data stays exportable. Check that products, customers, orders and content can be exported in a structured format before choosing, so the next migration is possible without vendor help.

Sources:
- Google Search Central: Site moves with URL changes: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### The Post-Launch QA Checklist

URL: https://prevedshop.com/guides/post-launch-qa-checklist
Language: en
Last reviewed: 2026-07-21

The migration isn't finished the moment the new store goes live — it's finished when you've confirmed, deliberately, that everything customers and search engines depend on actually works under real conditions. Staging catches most problems, but a handful only show up with live traffic, real payment processors, and search engines re-crawling the site. This checklist covers what to verify in the days and weeks after cutover, independent of which platforms were involved.

#### Verify the checkout flow end to end, with real conditions

Run a complete purchase yourself on the live site — not staging — covering the paths customers actually use: guest checkout and logged-in checkout, at least one product with variants, and any discount codes or promotions currently active. Check that order confirmation emails send correctly and that the order appears properly in your admin/order system afterward.

Don't assume staging coverage transfers automatically. Live payment gateways, live tax services, and live shipping-rate APIs sometimes behave differently than their staging or sandbox equivalents, which is exactly why this needs a real, live-conditions check rather than relying on what passed in staging.

#### Confirm payment gateways are fully live and correctly configured

Verify that payment processing is running in live (not test/sandbox) mode, that all payment methods your store previously supported are enabled and working, and that a real transaction settles correctly end to end — funds actually arriving, not just an order status changing. Check refund functionality too, since it's used less often than checkout and easy to leave unverified.

If you support multiple payment methods or currencies, test each one individually rather than assuming that because one method works, the rest are configured the same way.

#### Check tax and shipping rules against real orders

Tax and shipping logic is easy to get subtly wrong in a migration, since both often depend on configuration that doesn't map cleanly between platforms. Place test orders to your most common shipping destinations and confirm tax is calculated correctly and shipping rates and available methods match what you intended — not just what the new platform defaulted to.

Pay particular attention to any special cases your business relies on: tax exemptions, free-shipping thresholds, region-specific rules, or shipping restrictions on certain products. These are exactly the configuration details most likely to get lost or defaulted incorrectly during a migration.

#### Spot-check redirects, not just the ones you remember

Even with a complete redirect map built before launch, spot-check a real sample of URLs after cutover: your highest-traffic pages, a handful of lower-traffic ones, and a few of the deliberate exceptions (discontinued products, merged categories). Confirm each redirects to the correct destination in one hop, with no chains or loops.

Also check a sample of URLs that shouldn't exist on the old site — typos, old parameter-based URLs, anything a crawler might have indexed incidentally — to make sure they resolve sensibly rather than erroring in a way that looks like a broader problem.

#### Confirm analytics and tracking continuity

Verify that your analytics platform, conversion tracking, and any advertising pixels are firing correctly on the new site — a placed test order should show up in your analytics and ad platform reporting the way it did before. Tracking code is easy to lose silently during a platform change, since a missing or misconfigured pixel doesn't produce an error message; it just stops reporting data.

Compare early post-launch analytics numbers against your pre-migration baseline for the same type of day (weekday vs. weekend, similar traffic sources) rather than a raw before/after comparison, since normal traffic variation can otherwise mask or mimic a real tracking problem.

#### Check customer account access and order history

Have a few real (or test) customer accounts confirm they can log in, see their correct order history, and access any account features they relied on before — saved addresses, saved payment methods where applicable, loyalty or reward balances if your store has them. Account access issues are highly visible to the customers who hit them and directly affect trust, so they're worth verifying deliberately rather than assuming the account migration "probably worked."

If password migration wasn't part of the technical transfer (common when platforms use incompatible password hashing), make sure customers have a clear password-reset path and that it's communicated, not just technically available.

#### Monitor Search Console coverage in the following weeks

Keep watching Search Console (or the equivalent for other search engines) well past launch day — crawl errors, indexing status, and any spike in reported 404s are the earliest signals of a redirect or canonical issue that testing missed. Compare against your pre-migration baseline so you can distinguish a real regression from normal short-term fluctuation after a site change.

This monitoring period is also when it's worth resubmitting your sitemap if you haven't already, and confirming that pages you expect to be indexed are actually appearing in search results over the following weeks, not just crawled.

#### FAQ

Q: How long should post-launch QA continue after cutover?
A: Active, daily-style checking typically matters most in the first one to two weeks, when most configuration and redirect issues surface. Search engine re-indexing and traffic pattern stabilization take longer, so lighter monitoring (Search Console, analytics trends) is worth keeping up for longer — several weeks is common — rather than stopping the moment the first week looks clean.

Q: What's the single most important thing to check first after launch?
A: A real, live checkout and payment test, since it directly affects revenue and is the one flow every customer touches. Redirect and tracking issues matter too, but a broken checkout is the most costly problem to leave undiscovered even for a few hours.

Q: Is it normal for search rankings to dip slightly right after a migration?
A: Some short-term fluctuation is common even with a well-executed migration, since search engines need time to re-crawl and re-evaluate the new URLs. What isn't normal is a sustained drop or a spike in crawl errors — that's the signal to check your redirect map and canonical tags for a real mistake rather than waiting it out.

Q: Who on the team should own post-launch QA?
A: Ideally someone with visibility across the whole store, not just the technical migration team — because several of these checks (tax rules feeling right, customer account behavior, whether tracking numbers look normal) benefit from business context, not just technical verification that a feature is present.

Sources:
- Google Search Central: Site moves with URL changes: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### Product Data Cleanup Before Migration

URL: https://prevedshop.com/guides/product-data-cleanup-before-migration
Language: en
Last reviewed: 2026-07-21

A platform migration copies whatever you give it — it doesn't clean up after you. Duplicate SKUs, orphaned images, inconsistent categories, and mismatched variant structures that have quietly accumulated over years will move to the new platform exactly as-is unless someone deals with them first. Doing that cleanup before migration is far cheaper than doing it after, when customers and search engines are already relying on the result. This guide covers what to look for and how to work through it.

#### Find and resolve duplicate SKUs and near-duplicate products

Export your full product list and check for exact SKU duplicates first — these are usually a data-entry or import error and are simple to merge once found. Then look for near-duplicates: the same product re-created under a different SKU, often the result of a supplier feed re-import that didn't match against existing records, or a product that was manually recreated instead of edited after a system change.

For each duplicate pair, decide which record is the "real" one — usually the one with more complete data, more order history, or better SEO signals like backlinks or reviews — and merge or redirect the other into it rather than migrating both and sorting it out later on the new platform.

#### Track down orphaned images and media

Orphaned media — images and files uploaded to your media library that no product, category, or content page still references — accumulate naturally over years of product updates, seasonal campaigns, and platform changes. They add no value on the new platform and just increase migration time and storage, so it's worth identifying and excluding them.

Be careful with the reverse case too: images that are referenced but broken (a missing file, a dead external URL) are worth catching now, since a broken image on a product page is a small but real trust signal problem that's much easier to fix against your current, familiar data than after the move.

#### Standardize categories and attributes

Years of ad hoc additions tend to leave categories and attributes inconsistent: the same concept spelled or capitalized differently across products, categories that overlap or duplicate each other, attributes used for one purpose in one product line and a different purpose in another. This inconsistency usually doesn't cause visible problems on the old platform, where staff have learned to work around it, but it becomes a real liability once it's mapped mechanically to a new platform's data model.

Build (or confirm) a clean, agreed taxonomy before migration — a defined category tree and a defined attribute list with consistent naming — and reconcile your actual data against it. This is also the point where it's worth asking which attributes are still meaningful to customers or internal operations and which exist only because nobody removed them.

#### Reconcile variant structure mismatches

Variant structures (size, color, material, and how they combine into specific sellable SKUs) are handled differently across platforms, and inconsistent source data makes this worse. Look for products where variant options don't follow a consistent pattern — some size variants named "S/M/L" and others "Small/Medium/Large" for the same product line, or products where a variant combination exists in your system but has no valid price or stock behind it.

Decide your target variant model before migration, not during it. Knowing in advance whether the new platform handles variant combinations the same way the old one does — and where it doesn't — determines whether your existing variant data can map directly or needs restructuring first.

#### Decide what actually needs to move

Not everything in your current catalog deserves a spot on the new platform. Discontinued products with no remaining stock, test or placeholder entries, and legacy fields nobody can explain the original purpose of are all candidates for leaving behind — with a documented decision, not a silent drop. Migrating less, deliberately, is often better than migrating everything and sorting it out afterward on an unfamiliar new system.

For anything you decide not to migrate that still has an indexed URL, make sure it's accounted for in your redirect plan (see the redirect-mapping guide) rather than left to 404 by accident.

#### FAQ

Q: How much time should we budget for data cleanup before a migration?
A: It depends heavily on catalog size and how messy the data actually is — a small, well-maintained catalog needs far less time than one with tens of thousands of SKUs and years of supplier feed imports. Auditing the data first is what tells you the real scope; skipping the audit and guessing is how cleanup time gets underestimated.

Q: Should we clean up data before or during the migration project?
A: Before, or at minimum as an explicit early phase with its own review step — not blended into the technical data transfer. Cleanup decisions (what's a duplicate, what's safe to drop, what a mystery custom field was for) usually need input from someone who knows the catalog's history, and that's a different kind of work from the technical mapping and transfer itself.

Q: What if we're not sure whether a duplicate is really a duplicate?
A: Flag it rather than guessing either way. A near-duplicate with different pricing, different variant options, or different order history attached might be a legitimate separate product that just looks similar. When in doubt, keep both and revisit after the audit is complete rather than merging on a guess.

Q: Can data cleanup happen while the old store is still live and taking orders?
A: Yes, for most of the audit and planning work — reviewing exports, deciding on merges, and building the target taxonomy don't require touching the live store. The actual application of changes (merging records, deleting orphaned media) is usually safer to do on a copy or export, then bring the cleaned dataset into the migration rather than editing the live catalog mid-audit.

### The Ecommerce Replatforming Checklist

URL: https://prevedshop.com/guides/replatforming-checklist
Language: en
Last reviewed: 2026-07-21

Replatforming an online store is a project, not a button you press. The platforms involved matter less than most people assume — what actually determines whether a migration goes smoothly is whether you did the boring parts in order: audited what you have, mapped it deliberately, planned your redirects, tested on staging, and watched the store closely after cutover. This checklist walks through that sequence so you can run it regardless of which platform you're leaving or joining.

#### 1. Start with a discovery and audit, not a tool comparison

Before comparing target platforms, audit what you actually have on the current one: how many products and variants, how many customer accounts and how much order history, which custom fields are in active use versus abandoned leftovers, which apps or integrations the storefront depends on, and which URLs currently get meaningful traffic. This audit is what turns "we're migrating" into a scoped project with a real list of what has to move.

Be honest about data quality at this stage. If your catalog has known duplicates, orphaned categories, or inconsistent attributes, write that down now — cleaning it up later is cheaper before the move than after, and skipping the audit is how teams discover these problems mid-migration instead.

#### 2. Map your data model before you map a single field

Every platform structures products, variants, categories, and customer data slightly differently. Before moving any data, build an explicit mapping: which source field goes to which target field, which source concepts (a custom attribute, a tag, a bundle type) don't have a direct target equivalent and need a decision, and which fields are safe to drop entirely because nothing depends on them anymore.

Document this mapping somewhere durable — a spreadsheet or shared doc, not someone's memory. It becomes the reference everyone checks against during QA, and it's the first thing you'll want when something looks wrong after launch.

#### 3. Plan your redirects and URL structure early

URL structure is one of the most common places a migration quietly damages SEO and breaks bookmarks. Get a full list of your current URLs — product pages, category pages, blog or content pages, and any custom landing pages — and decide the new URL for each one before you launch anything. Pages with no clean new-platform equivalent need an explicit decision (usually a redirect to the closest matching category or hub page), not a silent 404.

This planning happens well before cutover, ideally in parallel with the data mapping work, since the two are related: how you map categories and products often determines what the new URLs look like. See the dedicated redirect-mapping guide linked below for the full process.

#### 4. Build a staging environment and run real QA

Never treat a first import as the final import. Load your mapped data onto a staging or test instance of the target platform and actually use the store: browse categories, view product pages, check variant selection and pricing, test the cart and checkout flow, and confirm customer accounts and order history display correctly. Involve someone outside the migration team — a fresh set of eyes catches things the people who built the mapping stop noticing.

Treat this stage as iterative. It's normal to find mapping issues on the first pass; the goal is to catch and fix them here, on staging, where a mistake costs a re-import, not a stretch of live downtime or a customer-facing error.

#### 5. Plan the cutover window like an operation, not a switch flip

Decide, in writing, what happens during the cutover: how new orders on the old platform are handled if the migration takes time (a temporary order freeze, a maintenance page, or continued operation until a defined final sync), who does the final data sync, who verifies DNS and SSL on the new platform, and who has the authority to roll back or pause if something looks wrong.

Give the team a shared checklist for the day itself, not just a plan in someone's head. A rushed or ambiguous cutover is where otherwise well-prepared migrations lose data — a handful of orders placed in the gap between the final sync and going live, for instance — so plan explicitly for that gap rather than hoping it doesn't matter.

#### 6. Monitor after launch — the migration isn't done at go-live

The days and weeks after cutover are when problems that staging didn't catch tend to surface: a payment gateway misconfigured for live traffic, a tax or shipping rule that behaved differently under real orders, redirects that work for the pages you tested but not for edge cases, or a tracking pixel that silently stopped firing. Set a deliberate monitoring routine rather than assuming silence means success.

Our post-launch QA checklist (linked below) covers this phase in detail — checkout and payment verification, redirect spot-checks, analytics continuity, and search console monitoring — since it deserves its own dedicated process, not a rushed afterthought once the team's attention has already moved on.

#### FAQ

Q: How long does a replatforming project take?
A: It depends heavily on catalog size, data complexity, and how many custom integrations are involved. A small, clean catalog typically moves faster than one with tens of thousands of SKUs, years of accumulated custom fields, and multiple connected apps. Get a realistic estimate after an audit of your specific store rather than trusting a generic timeline.

Q: Should we migrate everything at once, or in phases?
A: Both approaches work depending on the store. A single cutover is simpler to reason about and avoids running two platforms in parallel, but it concentrates risk into one window. A phased approach (for example, moving content and design first, then catalog, then transactional data) spreads risk but requires more careful coordination of what's "live" where at each stage. The right choice depends on your catalog size, your tolerance for a maintenance window, and how tightly your systems are integrated.

Q: What's the most common cause of migration problems?
A: Skipping or rushing the audit and mapping stages. Teams that jump straight into moving data without first understanding what they actually have — duplicate products, undocumented custom fields, URLs nobody accounted for — tend to discover those problems live, after cutover, instead of on staging where they're cheap to fix.

Q: Do we need to freeze the old store during migration?
A: Not necessarily for the whole project, but you do need a clear plan for the final cutover window — typically a short freeze or a defined final sync point — so no orders or customer changes get lost between the last data pull and the new store going live. How long that window needs to be depends on your order volume and how the final sync is handled.

Sources:
- Google Search Central: Site moves with URL changes: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### SEO-Safe Redirect Mapping for Ecommerce Migrations

URL: https://prevedshop.com/guides/seo-safe-redirect-mapping
Language: en
Last reviewed: 2026-07-21

Search rankings and organic traffic are valuable assets for an established store, and a careless migration can damage them. URL continuity is one of the parts you can control directly: inventory the old URLs, choose relevant destinations, implement the redirects correctly and monitor how search engines respond. This guide walks through that process end to end, independent of which platforms are involved, without promising unchanged rankings.

#### Build a complete URL inventory first

Before you can map anything, you need a full list of the URLs currently in use — not just the ones you remember, but every product page, category and collection page, blog or content page, and any custom landing pages that exist on the current site. Pull this from your sitemap, your analytics tool's page reports, and a crawl of the live site, and cross-check the three against each other, since each source tends to miss something the others catch.

Pay particular attention to URLs that get organic traffic or have external backlinks, even if they're pages you'd otherwise consider minor. A low-traffic blog post with a handful of good backlinks is worth mapping correctly; losing it silently is a small but avoidable loss.

#### Map every URL to its new equivalent — and decide the exceptions deliberately

For each URL in your inventory, decide its new-platform destination. Most product and category pages will have a reasonably direct equivalent once your data mapping is settled. Pages with no clean equivalent (a discontinued product, a one-off landing page, a category that no longer exists) still need an explicit decision — usually a redirect to the closest matching category, a relevant hub page, or in rare cases a deliberate, accepted 404 — rather than being left to redirect to the homepage by default or to 404 by accident.

A blanket "redirect everything to the homepage" approach is a common shortcut that actively hurts you: it dilutes relevance signals and gives users a poor experience compared to landing on the nearest relevant page.

#### Implement 301s, and check for chains and loops

Use permanent (301) redirects for URLs that have genuinely moved for good — that's the signal that tells search engines to transfer ranking signals to the new URL. Once your redirects are live, actively check for redirect chains (URL A → B → C, when A → C would do) and loops (A → B → A), since both are common byproducts of iterative redirect-map edits and both waste crawl budget and add latency. A one-hop redirect from every old URL straight to its final new destination is the goal.

Test a representative sample of redirects manually after launch — spot-check high-traffic pages, a handful of low-traffic ones, and a few of the deliberate exceptions — rather than assuming the map is correct just because it validated in a spreadsheet.

#### Handle canonical tags deliberately

Canonical tags tell search engines which URL is the authoritative version when similar content is reachable from more than one address. After a migration, make sure every page's canonical tag points to its own live, correct new URL — not to a leftover old URL, and not to a different page's URL by mistake from a copy-pasted template. Getting this wrong can confuse search engines about which version of a page to index, even when the redirects themselves are correct.

If the new platform generates canonical tags automatically, verify its default behavior rather than assuming it's right for your setup — automatic canonicalization occasionally points at unexpected URLs on parameterized or paginated pages.

#### Resubmit your XML sitemap and update internal links

Once the new site is live with working redirects, generate and submit a fresh XML sitemap reflecting the new URL structure through Google Search Central and other search engines' webmaster tools, so crawlers can discover the new pages efficiently instead of relying solely on following redirects from old URLs.

At the same time, update internal links across the site — navigation, footer, related-product links, blog content — to point directly at the new URLs rather than through a redirect. Internal links that still point at old URLs add unnecessary redirect hops on every click and are easy to miss since they don't break anything visibly; they just work less efficiently.

#### Monitor crawl and index status after cutover

Migration SEO work doesn't end at launch. In the weeks after cutover, watch Search Console (or the equivalent tool for other search engines) for crawl errors, a sudden spike in 404s, pages that aren't getting indexed, or a drop in impressions/clicks for pages that should be performing normally. Compare this against your pre-migration baseline so you're catching real regressions, not normal short-term fluctuation.

Be patient but not passive: some reindexing takes time even when everything is set up correctly, but a redirect or canonical mistake left unnoticed for weeks is much more expensive to fix than one caught in the first days after launch.

#### FAQ

Q: Will a migration definitely hurt my search rankings?
A: Not necessarily, but rankings can change even when a migration is well executed. A complete redirect map, correct canonical tags, updated internal links and a resubmitted sitemap reduce avoidable risk. Nobody can guarantee specific positions because search performance depends on many factors beyond the migration.

Q: Should I use 301 or 302 redirects?
A: Use 301 (permanent) redirects for URLs that have moved for good, which is the normal case in a platform migration. 302 (temporary) redirects signal that the move isn't permanent and search engines may not transfer ranking signals the same way, so they're the wrong choice for a completed migration's redirect map.

Q: What if two old URLs should point to the same new page?
A: That's fine and common — for example, two old category URLs that got merged into one on the new platform. Redirect both old URLs directly to the single new URL. What you want to avoid is the reverse: one old URL that's ambiguous about which new page it should map to, which usually means the mapping decision hasn't actually been made yet.

Q: How long should I keep old redirects in place?
A: Indefinitely, if practical. Backlinks, bookmarks, and old search results referencing the previous URLs can persist for a long time after a migration, and there's little cost to keeping a redirect rule alive. Removing redirects too early is a common way to turn what should be a one-time migration cost into a recurring source of broken links.

Sources:
- Google Search Central: 301 redirects: https://developers.google.com/search/docs/crawling-indexing/301-redirects
- Google Search Central: Consolidate duplicate URLs (canonicalization): https://developers.google.com/search/docs/crawling-indexing/canonicalization
- Google Search Central: Build and submit a sitemap: https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap

### Shopify vs WooCommerce: which one should you migrate to?

URL: https://prevedshop.com/guides/shopify-vs-woocommerce
Language: en
Last reviewed: 2026-09-02

Shopify and WooCommerce are the two platforms we migrate to and from most often, and the choice between them is rarely about features. Shopify is a hosted, fixed-model system that removes operations work; WooCommerce is an open plugin on WordPress that gives you the database and the responsibility. This comparison looks at the differences that actually change a migration: the data model, ownership, cost structure, content handling and SEO, then describes which stores tend to be happier on each side.

#### Data model: fixed versus open

Shopify products have a fixed schema with up to three option dimensions and metafields for everything else; collections are manual or rule-based lists, not a taxonomy tree. WooCommerce products are WordPress posts with unlimited attributes, custom fields and nested taxonomies. Moving into Shopify is therefore a consolidation exercise - deciding where each custom field lives - while moving into WooCommerce is mostly a mapping of a small, tidy model into a larger one. Stores with very structured catalogs usually migrate more easily towards Shopify; stores with unusual data lose less moving towards WooCommerce.

#### Ownership, hosting and cost

Shopify charges a plan fee plus transaction fees on non-Shopify gateways and app subscriptions; in return there is no server, no patching and no PCI scope on your side. WooCommerce has no licence fee, but you pay for managed WordPress hosting, plugin licences and the developer time that keeps updates safe. Over three years the totals are often closer than either camp claims. The real difference is where risk sits: on Shopify the platform can change rules and prices; on WooCommerce a neglected plugin stack can break the store.

#### Content and SEO

WordPress is a full CMS, so WooCommerce stores with large blogs, landing pages and custom templates keep all of that in one place. Shopify's pages and blog are simpler, and content-heavy stores often end up running WordPress for content next to Shopify for commerce. On SEO the platforms are equivalent when configured well; what matters in a migration is the URL change. Shopify enforces `/products/` and `/collections/` paths, WordPress permalinks are free, so every migration between them needs a complete 301 redirect map. Redirects reduce risk; rankings are never guaranteed.

#### Which stores fit which platform

Shopify tends to suit stores that want predictable operations, sell in several countries through Markets, use standard fulfilment and have a catalog that fits three option dimensions. WooCommerce tends to suit stores that need custom checkout logic, B2B pricing, unusual product structures, deep content integration or strict data residency. If neither description is clearly yours, a short discovery with real product and order samples answers it faster than any comparison table.

#### FAQ

Q: Is Shopify better than WooCommerce for SEO?
A: Neither platform has an inherent advantage. Visibility after a migration depends on the redirect map, content parity and page speed, not on the platform name.

Q: Which is cheaper, Shopify or WooCommerce?
A: It depends on scale and customisation. Shopify has predictable fees plus apps and transaction fees; WooCommerce has hosting, plugin licences and developer time. Compare three-year totals including the migration.

Q: Can I move from Shopify to WooCommerce, not just the other way?
A: Yes. We migrate in both directions; the Shopify-to-WooCommerce route is documented separately and mainly involves mapping metafields and rebuilding smart collections.

Q: Does the choice affect how long the migration takes?
A: Somewhat. Moving into Shopify often takes longer for catalogs with many custom fields, because each one needs a metafield decision; moving into WooCommerce takes longer when many apps have to be replaced by plugins.

Sources:
- Shopify Help Center - Migrating to Shopify: https://help.shopify.com/en/manual/migrating-to-shopify
- WooCommerce - Product CSV importer and exporter: https://woocommerce.com/document/product-csv-importer-exporter/

### Glossary

### 301 Redirect

URL: https://prevedshop.com/glossary/301-redirect
Language: en
Last reviewed: 2026-07-21

A 301 redirect tells browsers and search engines that a page has permanently moved to a new URL, and sends anyone - human or crawler - requesting the old address straight to the new one. The "301" is the HTTP status code returned by the server: it's the standard, permanent way to say "this content now lives here instead," as opposed to a temporary (302) redirect.

#### What a 301 redirect actually does

When someone requests an old URL, the server responds with an HTTP 301 status code and a new location. The browser follows automatically, so a visitor rarely even notices - they land on the new page, not an error. Search engines follow the same signal: a 301 tells them to transfer the old URL's ranking value to the new URL over time, rather than treating the new page as unrelated, brand-new content.

This is different from a 302 (temporary) redirect, which tells crawlers the move isn't permanent and that search value shouldn't be fully transferred. It's also different from a manual link update on your own site - a 301 catches everyone who still has the old URL bookmarked, linked from another site, or indexed in search results, not just people clicking links you control.

#### Why 301 redirects matter during a platform migration

Moving to a new platform almost always changes your URL structure, even when you try to keep it close - product URLs, category paths, and blog posts often end up in a different shape than before. Every old URL that search engines have indexed, and that other sites link to, needs a 301 pointing to its new equivalent, or you lose that page's accumulated ranking signal and send visitors to a dead end.

The risk isn't hypothetical: launch a new store without a redirect plan and you'll typically see 404 errors pile up, inbound links break, and organic traffic drop within days of going live, since search engines revisit indexed URLs quickly. A redirect plan built before launch, not patched together after traffic drops, is what keeps that from happening.

#### Getting redirects right, not just present

Having a 301 isn't enough on its own - it needs to point at the right target. Redirecting every old URL to your new homepage technically "resolves" the link but throws away the specific relevance a search engine or visitor was expecting. We map old URLs to their closest real equivalent on the new platform, and flag pages with no clean match instead of guessing.

We also check for redirect chains (URL A to B to C) and loops, which add latency and can cause crawlers to stop following the chain altogether. A clean migration ends with one hop per URL, not three.

#### FAQ

Q: Is a 301 redirect the same as a URL change?
A: No - changing a URL without a redirect just breaks the old link. A 301 redirect is the instruction that connects the old URL to the new one, so anyone (or anything) that requests the old address is sent automatically to the new page.

Q: Do 301 redirects fully preserve my search rankings?
A: They preserve most of the ranking signal associated with the old URL, but not automatically every position for every keyword - other factors like site quality and competition still apply. What a 301 reliably does is tell search engines the content moved, rather than letting them treat the new URL as unrelated.

Q: How long do I need to keep redirects in place?
A: Indefinitely, or as close to it as practical. Old links from other websites, saved bookmarks, and print materials can keep sending traffic to old URLs for years, and search engines can take time to fully process a large batch of redirects.

Q: What's the difference between a 301 and a 302 redirect?
A: A 301 signals a permanent move and passes ranking signal to the new URL; a 302 signals a temporary move, and search engines are more cautious about transferring that signal. For a platform migration, where the old URL isn't coming back, a 301 is almost always the correct choice.

Sources:
- Google Search Central: Redirects and Google Search: https://developers.google.com/search/docs/crawling-indexing/301-redirects

### Canonical Tag

URL: https://prevedshop.com/glossary/canonical-tag
Language: en
Last reviewed: 2026-07-21

A canonical tag (`<link rel="canonical">`) is an HTML tag that tells search engines which URL is the authoritative version of a page when the same or very similar content is reachable from more than one address. It doesn't redirect visitors anywhere - it's a signal to crawlers about which URL should get credit and show up in search results.

#### What a canonical tag actually does

Ecommerce platforms routinely serve the same product or category through multiple URLs - with and without a trailing slash, with different sorting or filter query parameters, or reachable from more than one category path. Without a canonical tag, search engines have to guess which version to index, which can split ranking signal across near-duplicate URLs instead of consolidating it on one.

The canonical tag sits in a page's `<head>` and points to the single URL that should be treated as the master copy. Every duplicate or near-duplicate variant carries a canonical tag pointing back to that one URL; the master URL typically has a canonical tag pointing to itself.

#### Why it matters during a platform migration

New platforms often introduce their own URL patterns for filtering, pagination, or sorting that didn't exist on the old platform, and it's easy to end up with unintended duplicate content if canonical tags aren't set correctly from day one. Getting this wrong doesn't usually cause a dramatic drop like a missing redirect does, but it quietly dilutes ranking signal across near-duplicate pages instead of consolidating it - a slower, harder-to-diagnose problem.

Migrations are also a natural point to fix pre-existing canonicalization issues from the old platform, rather than carrying them forward unchanged.

#### Canonical tags vs. redirects

A canonical tag and a redirect solve different problems. A redirect (see 301 redirect) is for a URL that no longer exists at all - it sends visitors and crawlers to the new address. A canonical tag is for URLs that still exist and are still reachable, but that shouldn't compete with each other in search results - both stay live, one is just marked as the reference version.

#### FAQ

Q: Does a canonical tag redirect visitors to the main URL?
A: No. Visitors can still land on the non-canonical URL and it loads normally - the canonical tag only signals to search engines which version to index and rank, it doesn't change what a browser does.

Q: Do I need canonical tags if I don't have duplicate content?
A: It's still common practice for every page to have a self-referencing canonical tag (pointing to itself), which removes ambiguity if a duplicate ever does appear later - e.g. through a tracking parameter or a new filter URL.

Q: Can a canonical tag point to a page on a different domain?
A: Yes, cross-domain canonicals are valid and are sometimes used deliberately, but for a platform migration they're usually not what you want - each new URL should typically canonicalize to itself, with redirects (not canonicals) handling the old domain or old URLs.

Q: What happens if my canonical tags point to the wrong URL?
A: Search engines may end up indexing and ranking the wrong version of a page, or ignoring your canonical signal altogether if it looks inconsistent with other signals (like internal links or the sitemap). We check canonical tags as part of migration QA rather than assuming the new platform sets them correctly by default.

Sources:
- Google Search Central: Consolidate duplicate URLs: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

### Data Migration

URL: https://prevedshop.com/glossary/data-migration
Language: en
Last reviewed: 2026-07-21

Data migration is the process of moving your store's information - products, customers, orders, content, and everything connected to them - from one platform to another, in a form the new platform can actually use correctly. It's the core technical work of a platform move, distinct from the design, redirect planning, or integration work that surrounds it, though all of those depend on the data migration being accurate.

#### What actually gets migrated

Beyond the obvious product catalog, a full data migration typically covers customer accounts and their order history, existing orders (open and historical), content like blog posts or static pages, reviews if they're stored on-platform, and any custom fields or metadata specific to your business. Not everything necessarily needs to move - some historical data may be archived rather than actively migrated, which is a scoping decision made during the assessment, not assumed by default.

#### Why a straight export/import isn't enough

Two platforms rarely model data identically - one platform's flat product list might be another's hierarchical categories-and-attributes system; one platform's simple customer record might need to be split across several object types on the new platform. A literal field-by-field copy from an export file often produces data that's technically present but structurally wrong - broken variant relationships, lost custom fields, or customer records that don't link correctly to their order history. Real data migration means mapping each data type deliberately, not just moving files.

#### How we approach it

We start with a data audit - understanding what actually exists in the old system, including inconsistencies that built up over time (duplicate customers, orphaned records, inconsistent categorization) - before deciding how it maps onto the new platform. Cleanup often happens as part of this step rather than after, since migrating bad data faithfully just reproduces the same problems on the new platform. See Data Cleanup & Mapping for how this fits into a managed migration.

#### FAQ

Q: Does data migration include my order history?
A: It can - whether historical orders are actively migrated into the new platform or archived separately is a scoping decision, since not every platform or business needs live order history in the new system. We discuss this during the assessment.

Q: Will my custom fields transfer automatically?
A: Not automatically - custom fields need an explicit equivalent on the new platform (often metafields or custom attributes), and that mapping has to be defined, not assumed to exist by default.

Q: Can I migrate data myself using a plugin or import tool?
A: For small, simple catalogs this can work. For stores with meaningful customization, order history, or data quality issues, a generic import tool typically can't make the judgment calls a proper data audit and mapping process requires - it just moves whatever's in the file, mistakes included.

Q: How do you avoid data loss during migration?
A: By auditing and mapping before moving anything, testing the migration against a staging environment first, and verifying record counts and spot-checking data after the move rather than assuming the import ran correctly.

### Headless Commerce

URL: https://prevedshop.com/glossary/headless-commerce
Language: en
Last reviewed: 2026-07-21

Headless commerce is an architecture where the storefront (what customers see and interact with) is built separately from the commerce backend (product catalog, cart, checkout, order management), and the two communicate through an API instead of being one tightly coupled system. "Headless" refers to the storefront - the presentation layer - being decoupled from the backend, which can then serve multiple different "heads" (a website, a mobile app, an in-store kiosk) from one source of truth.

#### Headless vs. traditional (monolithic) platforms

A traditional ecommerce platform bundles the storefront templates and the backend together - Shopify's Liquid themes or WooCommerce's WordPress templates are examples of the storefront being generated directly by the platform itself. In a headless setup, the storefront is a separate application (often built with a framework like Next.js or similar), and it fetches data from the backend platform's API instead of the platform rendering pages directly. Some platforms (Shopify, commercetools, several others) support both a traditional and a headless mode.

#### Why it changes a migration

Migrating into or out of a headless setup is a different kind of project than migrating between two traditional platforms. Moving a traditional-platform store to a headless architecture typically means building a new storefront from scratch (not porting an existing theme), while the backend/catalog migration follows the same data-mapping principles as any other move. Moving between two headless backends is often more contained on the storefront side, since the frontend can sometimes be updated to point at a new API rather than rebuilt entirely - but the backend's catalog, order, and customer data still need the same careful mapping as any migration.

#### When headless is (and isn't) the right move

Headless architectures generally trade more implementation and ongoing engineering effort for more flexibility in the storefront experience - custom interactions, non-website channels (apps, kiosks), or performance requirements a template-based storefront can't meet. For a store without that specific need, a traditional platform is usually simpler to run and migrate. This is a decision worth making deliberately during the assessment, not defaulting to either option.

#### FAQ

Q: Is headless commerce always faster than a traditional storefront?
A: Not automatically - performance depends on how the headless storefront is built, not just the architecture choice. A poorly built headless frontend can be slower than a well-optimized traditional theme.

Q: Do I need custom developers to run a headless store?
A: Generally yes on an ongoing basis - a headless storefront doesn't come with the theme editor and app-store customization options a traditional platform offers, so changes typically go through custom development rather than a visitual editor.

Q: Can I migrate from a traditional platform to headless without losing SEO?
A: Yes, but it requires the same redirect and URL-structure planning as any migration, plus specific attention to how the new headless frontend renders content for search engines (server-side rendering matters here) - it's not automatic just because the backend data is preserved.

Q: Which platforms support headless commerce?
A: Several major platforms offer a headless/API-first mode alongside or instead of their traditional storefront - the right choice depends on your specific backend requirements, which we help evaluate rather than defaulting to whichever platform is trending.

### Hreflang

URL: https://prevedshop.com/glossary/hreflang
Language: en
Last reviewed: 2026-07-21

Hreflang is an HTML attribute (and equivalent HTTP header or sitemap entry) that tells search engines which language and, optionally, which country a page is written for, and points to the equivalent page in other languages or regions. It's how a multilingual site tells Google "here's the Spanish version, here's the German version" instead of leaving search engines to guess.

#### What hreflang actually does

A page with hreflang markup lists a set of alternate URLs, each tagged with a language code (and optionally a region, like `es` vs `es-MX`) plus a special `x-default` entry for visitors who don't match any listed language. Search engines use this to serve the right language version of your site to the right searcher, and to avoid treating your translated pages as duplicate content of each other.

Every page in the cluster needs to reference every other page in the cluster, including itself - a common source of errors is a one-way link (page A points to page B, but B doesn't point back to A).

#### Why it matters during a platform migration

If your store operates in multiple languages, a migration is exactly the moment hreflang tends to break - URL structures change per locale, and it's easy for the new platform's language-switching mechanism to not automatically wire up correct hreflang clusters for every route, especially routes that don't have a live translation yet. An incomplete or inconsistent hreflang setup can cause the wrong language version to rank in the wrong country, or dilute ranking signal across near-duplicate localized pages.

Hreflang should be verified for every URL pattern in the new IA, not just the homepage - product pages, category pages, and any content pages all need it if they're multilingual.

#### Common mistakes

The most frequent issues are missing return links (A links to B, B doesn't link back), pointing hreflang at a URL that returns a redirect or a 404 instead of the live page, and using the wrong language/region code format. None of these usually cause an outright penalty, but they do mean search engines may not honor the signal at all, defeating the point of adding it.

#### FAQ

Q: Is hreflang the same as a language switcher on my site?
A: No - a language switcher is a UI element for visitors; hreflang is a signal for search engines, usually invisible to visitors, that lives in the page's HTML head, an HTTP header, or the sitemap. A site can have one without the other, though having both is standard practice.

Q: Do I need an x-default entry?
A: It's recommended if you have a fallback page for visitors whose language/region doesn't match any of your specific versions - commonly this points at your default-language page.

Q: Does hreflang affect my search ranking directly?
A: It doesn't act as a ranking boost - it affects which of your pages shows up for searchers in a given language/region, and helps prevent your translated pages from being treated as unwanted duplicates of each other.

Q: Can hreflang be set in the sitemap instead of on the page?
A: Yes, both are valid per search engine documentation - some sites prefer sitemap-based hreflang because it's easier to generate and validate programmatically for a large number of URLs, which is the approach we generally use on migrated sites.

Sources:
- Google Search Central: Tell Google about localized versions of your page: https://developers.google.com/search/docs/specialty/international/localized-versions

### Product Feed

URL: https://prevedshop.com/glossary/product-feed
Language: en
Last reviewed: 2026-07-21

A product feed is a structured export of your catalog - typically CSV, XML, or JSON - built for another system to read on a schedule: a supplier sending you their catalog, or your store sending its catalog to a marketplace, price comparison site, or ad platform (like a Google Shopping feed). Each feed follows a specific format the receiving system expects: certain fields, in a certain structure, sometimes with its own required identifiers.

#### Inbound vs. outbound feeds

An inbound feed comes from a supplier or distributor into your store - new stock levels, prices, and product data your platform needs to ingest on a schedule. An outbound feed goes the other way - your store's catalog formatted for a marketplace, comparison shopping engine, or ad platform to consume. A migration usually touches both: your new platform needs to keep receiving supplier feeds in whatever format they already send, and needs to produce outbound feeds in the format each destination expects, which isn't always identical to what your old platform produced.

#### Why feeds break during a migration

Feed formats are rarely a universal standard - a supplier's feed might use field names, category codes, or identifiers that your old platform's integration was custom-built to parse. Moving to a new platform means that parsing logic needs to be rebuilt, not assumed to carry over, even if the feed file itself doesn't change. The same applies in reverse: an outbound feed your marketplace or ad account depends on needs to keep matching that channel's required format after the move, or the channel may reject or misread it.

#### What a managed migration checks

We map every active inbound and outbound feed during the assessment - what format it's in, what fields it maps to, and how often it runs - so nothing breaks silently after cutover. A supplier feed that stops being parsed correctly doesn't throw an error most of the time; it just quietly stops updating stock or prices, which is worse than an obvious failure because it can go unnoticed for a while.

#### FAQ

Q: Will my supplier's feed work automatically on my new platform?
A: Not automatically - the new platform needs an integration built (or reused, if a compatible connector exists) to parse that specific feed's format. We evaluate each supplier feed individually during the assessment rather than assuming a generic import will handle it.

Q: What happens to my Google Shopping or marketplace feed during a migration?
A: It needs to keep matching the destination's required format after the move. We check outbound feeds as part of the migration plan so a channel doesn't reject your catalog or show stale data after cutover.

Q: Is a product feed the same as a CSV export?
A: A CSV export can be a product feed, but 'feed' usually implies a recurring, automated exchange on a schedule, not a one-time manual export - though the underlying file format can be identical.

Q: Can two systems use completely different feed formats for the same data?
A: Yes, this is common - the same catalog data might be exported as one XML structure for one marketplace and a different CSV structure for another, or use different field names and category taxonomies entirely, requiring separate mapping for each.

### Replatforming

URL: https://prevedshop.com/glossary/replatforming
Language: en
Last reviewed: 2026-07-21

Replatforming means moving an ecommerce store from one platform to another - not a redesign on the same platform, and not a minor version upgrade, but a genuine change of the underlying system that runs your store. It's the umbrella term for the whole project: data migration, redirect planning, theme/storefront rebuild, and integration reconnection are all pieces of a replatforming effort.

#### What counts as replatforming (and what doesn't)

Switching from Magento to Shopify is replatforming. Upgrading from Magento 1 to Magento 2 is arguably replatforming too, since the underlying systems are different enough to require a real migration, not just an update. A theme redesign on the same platform, or adding a new app/plugin, is not replatforming - the underlying system and your data model stay the same.

#### Common reasons stores replatform

The trigger is usually one or more of: the current platform can't support a feature or scale the business needs, the ongoing cost of maintaining a self-hosted platform (hosting, security patching, PCI compliance) no longer makes sense, the platform is reaching end-of-life or losing vendor support, or the business has outgrown what a template-based storefront can do. It's rarely one single reason - it's usually an accumulation of friction that eventually outweighs the cost and risk of moving.

#### Why replatforming is treated as a project, not a task

The riskiest part of replatforming isn't choosing the new platform - it's everything that has to move correctly for the business not to lose data, SEO ranking, or operational continuity: the catalog, customer records, order history, URL structure and its redirects, supplier feeds, and any custom logic the old platform ran. Treating it as a single import task instead of a planned project is where most of the real risk in a migration comes from.

#### FAQ

Q: How long does replatforming usually take?
A: It depends heavily on catalog size, data complexity, how many integrations exist, and how much custom functionality needs to be rebuilt - there's no universal timeline. We give a realistic estimate after assessing the specific store, not a generic number.

Q: Do I need to replatform if I just want a new design?
A: No - a redesign on your current platform is usually simpler and lower-risk than replatforming, and doesn't require migrating data or rebuilding integrations. Replatforming makes sense when the platform itself, not just its appearance, is the limitation.

Q: What's the biggest risk in a replatforming project?
A: Losing SEO ranking through broken redirects, and data quality issues (broken variant relationships, lost customer records, mismatched order history) from an incomplete or naive data migration - both are avoidable with proper planning, and both are common when they aren't planned for.

Q: Can I replatform without any downtime?
A: Downtime can be minimized with careful cutover planning (staging, DNS/traffic switch timing, final data sync), but an interruption-free launch cannot be promised without knowing your specific setup - see our Security page for how we handle this conversation honestly.

### SKU Mapping

URL: https://prevedshop.com/glossary/sku-mapping
Language: en
Last reviewed: 2026-07-21

SKU mapping is the process of matching each product identifier (SKU - stock keeping unit) from your old system to its correct equivalent on the new one, so orders, inventory, and supplier feeds keep referring to the same physical product before and after a migration. It sounds mechanical, but it's one of the places a migration most commonly goes wrong when it's automated blindly instead of reviewed.

#### Why SKUs don't always transfer cleanly

In an ideal migration, every SKU on the old platform maps 1:1 to the same SKU on the new one and nothing changes. In practice, platforms often have different rules for what a SKU can contain, different handling of variant-level vs. product-level SKUs, or a history of duplicate/reused SKUs on the old system that need to be resolved rather than copied forward as-is. A straight database export can carry these inconsistencies over instead of fixing them.

#### Where SKU mapping connects to other systems

Your SKU is often the join key between your store and everything around it - supplier feeds, a warehouse or fulfillment system, accounting software, marketplace listings. If a SKU changes format or value during a migration without updating every connected system, those integrations start failing to match products even though the store itself looks fine. Mapping needs to happen with those downstream systems in mind, not just inside the new platform.

#### What we check before migrating SKUs

We audit the existing SKU set for duplicates, inconsistent formatting, and orphaned SKUs (referenced by an order or feed but not an active product) before deciding whether to preserve them as-is or normalize them on the new platform. Preserving existing SKUs is usually preferable when downstream systems depend on them; normalizing makes sense when the old SKU scheme itself was the problem.

#### FAQ

Q: Should I keep my exact same SKUs on the new platform?
A: Usually yes, if any supplier feed, fulfillment system, or marketplace listing depends on them - changing SKUs breaks those integrations unless they're updated at the same time. We evaluate this case by case rather than defaulting to either option.

Q: What happens to duplicate SKUs during a migration?
A: They need to be resolved before or during the migration, not carried forward - most platforms don't allow true duplicate SKUs, and letting an automated import guess how to deduplicate them risks merging or dropping the wrong product.

Q: Does SKU mapping affect my order history?
A: It can, if historical orders reference SKUs that change - we account for this so past order records still resolve to the correct product after the move, rather than only mapping the live catalog.

Q: Is SKU mapping automated or manual?
A: It's a mix - straightforward 1:1 matches can be automated and verified quickly, but ambiguous cases (duplicates, inconsistent formats, missing SKUs) need a human decision rather than a best-guess algorithm.

### Structured Data

URL: https://prevedshop.com/glossary/structured-data
Language: en
Last reviewed: 2026-07-21

Structured data is markup added to a page (most commonly following the schema.org vocabulary, in JSON-LD format) that describes its content in a machine-readable way - marking up a page as a Product with a price and availability, or an Organization with a name and URL, rather than leaving search engines to infer that from the visible text. It's what lets search results show rich features like star ratings, price, or FAQ dropdowns directly in the results.

#### What structured data actually enables

Search engines can often understand ordinary page content well enough, but structured data removes ambiguity and unlocks specific presentation features - product rich results with price/availability/rating, FAQ accordions shown directly in search results, breadcrumb trails in the result snippet, and more. None of it is guaranteed to appear (search engines decide when to use it), but without the markup, those features generally aren't available at all.

#### Why it needs attention during a migration

Structured data isn't something every platform generates automatically, and platforms that do generate it don't all do so identically - product schema, FAQ schema, and breadcrumb schema each need to reflect what's genuinely on the page. A migration is a common point where structured data either gets dropped entirely (the new theme/template doesn't include it) or becomes inaccurate (marked-up data that no longer matches the visible page content, which search engines can penalize rather than reward).

#### Only markup what's genuinely true

The most important rule with structured data is that it should describe something real and visible on the page - FAQPage markup only where an FAQ is actually shown, Review/rating markup only for reviews that actually exist, Product markup with a real price and real availability. Markup that doesn't match the visible page is against search engines' own guidelines and can lead to structured data being ignored or the page being penalized, not just "not helping."

#### FAQ

Q: Does structured data guarantee rich results in search?
A: No - it makes rich results possible, but search engines decide independently whether to display them, based on relevance and their own quality checks. There's no way to guarantee a specific rich result will appear.

Q: Will my new platform add structured data automatically?
A: Some platforms generate basic structured data (like Product markup) by default; others need it added explicitly through a theme or app. We check what the new platform provides out of the box and fill in gaps rather than assuming it's handled.

Q: Can adding structured data hurt my SEO?
A: Only if it's inaccurate or manipulative - markup that doesn't match the actual page content violates search engine guidelines. Accurate structured data that reflects real page content doesn't carry that risk.

Q: What's the most common structured data mistake during a migration?
A: Losing it entirely when the new theme or template doesn't carry over what the old platform had, or leaving outdated markup live that no longer matches the redesigned page - both are things we check in migration QA.

Sources:
- Google Search Central: Understand how structured data works: https://developers.google.com/search/docs/appearance/structured-data/sd-policies

### URL Slug

URL: https://prevedshop.com/glossary/url-slug
Language: en
Last reviewed: 2026-07-21

A URL slug is the human-readable part of a page's address that identifies it - in `prevedshop.com/platforms/shopify`, `shopify` is the slug. It's usually derived from a product or page's name, made lowercase and URL-safe, and it's what both visitors and search engines actually see and reference when they link to or bookmark a page.

#### Why slugs matter beyond just readability

A clear, descriptive slug helps visitors understand what a page is about before clicking, and search engines do give some weight to relevant words appearing in the URL. But a slug's bigger significance is structural: it's part of the permanent address of the page, referenced by every internal and external link, saved bookmark, and indexed search result pointing to it.

#### Why migrations often change slugs, deliberately or not

Every platform has its own rules for how slugs are generated and structured - length limits, allowed characters, whether product slugs are nested under a category path or flat, how duplicate names are disambiguated. Moving to a new platform frequently changes at least some slugs, sometimes because the new platform enforces a different pattern, sometimes because it's a chance to fix messy legacy slugs from the old system. Either way, a changed slug means a changed URL, and a changed URL needs a redirect (see 301 redirect) from the old address.

#### Keeping slugs stable where it matters

For pages with meaningful existing search rankings or a lot of inbound links, keeping the exact same slug on the new platform (when the platform allows it) avoids the need for a redirect entirely and is often the simplest way to preserve that page's standing. Where a slug does need to change, planning the new slug and its redirect together - rather than letting the platform auto-generate one and dealing with the URL as an afterthought - is what keeps the transition clean.

#### FAQ

Q: Can I keep my exact old URL slugs on a new platform?
A: Often yes, if the new platform's URL rules allow it and you set them deliberately rather than accepting auto-generated ones - this is one of the simplest ways to avoid needing a redirect for that page at all.

Q: Does changing a slug hurt SEO?
A: Not if it's paired with a proper 301 redirect from the old slug to the new one - the redirect passes most of the accumulated ranking signal forward. Changing a slug with no redirect is what causes SEO harm, not the slug change itself.

Q: Should I use my product name exactly as my slug?
A: Generally yes, simplified to be URL-safe (lowercase, hyphens instead of spaces, no special characters) - slugs stuffed with unrelated keywords beyond the actual page topic don't provide extra benefit and read as spam to both visitors and search engines.

Q: What happens if two products would generate the same slug?
A: The platform needs a disambiguation rule - usually appending a number or an extra identifier. We check for this during migration since duplicate-slug collisions can otherwise cause one product's page to silently overwrite another's URL.

### Services

### Ecommerce data migration and mapping

URL: https://prevedshop.com/services/data-cleanup-mapping
Language: en
Last reviewed: 2026-09-25

Most migration problems are data problems in disguise: a variant that becomes a separate product, an attribute that silently disappears, an order total that no longer adds up. Our data migration service turns your source data into an approved, documented mapping for the target platform, cleans what should not travel, and proves with reconciliation that what arrived is what left.

#### Mapping every entity, not just the product file

Catalog data is the visible part: products, SKUs, variants and their options, attributes and custom fields, categories or collections, images and media, prices, tax classes and stock. Behind it sit customers and their addresses, customer groups, historical orders with their line items, taxes, discounts and statuses, reviews, CMS pages and blog posts, redirects and SEO metadata, and the data that apps or plugins keep in their own tables. Each of those entities gets its own mapping decision, because each behaves differently on the target.

#### Transformations: where platforms disagree

Platforms model the same thing differently. Magento's EAV attributes, PrestaShop combinations, WooCommerce variations and OpenCart options all have to land in whatever the target understands—Shopify options and metafields, BigCommerce variants and custom fields, Shoptet parameters. Deep category trees may become flatter collections; free-text attributes may need normalizing into a controlled list before they can drive filters.

Every transformation is written as a rule with examples, so you can see the effect before the full run: which source field feeds which target field, how values are converted, and what happens to values that do not fit.

#### Cleanup before migration

Years of supplier imports and manual edits leave duplicate products, inconsistent attribute names, orphaned categories, broken image links and fields nobody remembers the purpose of. We report what we find and agree with you what to merge, fix, archive or drop. Nothing is deleted without your approval, and anything excluded is listed in the migration record rather than silently lost.

#### Customers, orders and historical data

Customer records and order history usually matter for service, accounting and repeat purchases, but they are also the most constrained data. Many hosted platforms import historical orders as read-only records, and customer password hashes cannot be transferred to most hosted targets, which means customers set a new password. Personal data volume and retention are agreed up front, and only what is needed is moved.

#### Validation and reconciliation

After the trial and again after the full run we compare source and target: record counts per entity, variant-to-parent relationships, price and stock samples, order totals, customer-to-order links and media coverage. Differences are explained, fixed or accepted in writing. This is the step that turns "the import finished" into "the data is right".

#### Custom and legacy sources

If the source is a custom build, an ERP, a PIM or a platform without a clean export, we start from a database dump, API or CSV/XML samples and write a source contract describing the real structure. The mapping is built from that contract, not from assumptions about how the system probably works.

#### Ecommerce data we migrate, and how it is handled

- Products and SKUs [migrates]: Core fields move directly; SKUs are checked for duplicates and empties before import.
- Variants and options [transform]: Source variant models (combinations, variations, configurable products) are rebuilt in the target's option structure.
- Attributes and custom fields [transform]: Mapped to target attributes, metafields or custom fields by an agreed scheme; unused fields are archived with approval.
- Categories and collections [transform]: Hierarchies are rebuilt or flattened according to the target model and the URL plan.
- Images and media [migrates]: Files, order and alt texts are transferred; broken or missing source files are reported.
- Customers and addresses [migrates]: Imported with consent and marketing flags handled per the target's rules.
- Customer passwords [assess]: Depends on the target; most hosted platforms require customers to set a new password.
- Historical orders [transform]: Usually imported as historical records; totals, taxes and statuses are reconciled against the source.
- Reviews [assess]: Depends on the review app or plugin on both sides and its import options.
- CMS pages and blog posts [migrates]: Content and images move; embedded shortcodes or widgets are converted or rebuilt.
- SEO metadata [migrates]: Titles and descriptions move where still accurate; URLs are handled in the redirect map.
- App and plugin data [assess]: Each app's data is inventoried and either exported to its replacement, archived or dropped by decision.

#### FAQ

Q: Will you delete data without asking?
A: No. We report duplicates, empty fields and legacy data, agree the action with you, and list anything excluded in the migration record.

Q: Can you migrate product data from spreadsheets, a PIM or an ERP?
A: Yes. CSV, XML, API and database sources are all workable once we have samples and have written down how the source is structured.

Q: How do you prove the data migration is complete?
A: With reconciliation reports after the trial and full runs: counts per entity, relationship checks, sampled prices and stock, and order totals compared between source and target.

Q: Can customer passwords be migrated?
A: It depends on the target. Most hosted platforms cannot accept password hashes from another system, so customers are invited to set a new password; we plan that communication with you.

Q: Do you migrate data stored by apps and plugins?
A: We inventory it first. Some can be exported into the replacement app, some should be archived, and some is no longer needed; each gets a documented decision.

### Ecommerce replatforming, from decision to launch

URL: https://prevedshop.com/services/ecommerce-replatforming
Language: en
Last reviewed: 2026-09-25

Replatforming is a business decision before it is a data migration. You are replacing the system that runs your catalog, checkout, integrations and organic traffic, usually because the current one has become too expensive, too limiting or too risky to keep. We help you make that decision on evidence, then plan and run the move so the new platform launches with its data, URLs and integrations intact.

#### When replatforming is worth it (and when it is not)

Common, legitimate triggers: the platform has reached end of life or stopped receiving security updates (Magento 1, Shopware 5); hosting, patching and extension maintenance cost more than the store can justify; the platform blocks something the business needs, such as new markets, B2B pricing, a headless storefront or a modern checkout; or the team spends its time keeping the platform alive instead of selling.

Weak triggers are a dated theme, a single missing feature an app could provide, or a sales demo. A redesign or a targeted integration is often cheaper than a new platform. We say so when that is the case.

#### Requirements before platform choice

We start from what the store actually does: catalog structure and product types, pricing rules and customer groups, markets, languages and currencies, fulfilment and ERP/WMS integrations, marketplaces and feeds, content and SEO footprint, and the custom features someone once paid for. Each requirement is marked as must-have, replaceable or retirable. That list, not a feature matrix, is what the candidate platforms are compared against.

#### What breaks in a replatforming project

The data model rarely matches: attributes, variants, bundles and category trees behave differently on the target. URL structures change, so every relevant URL needs a destination and a 301 redirect. Plugins and apps do not transfer; their data and behaviour need a replacement, a rebuild or a decision to retire them. Integrations with ERP, accounting, carriers and marketplaces must be re-pointed and tested. Customer passwords usually cannot move to a hosted platform. None of this is exotic; it just has to be found before launch rather than after.

#### Total cost of ownership, not just the licence

Compare the full picture over several years: platform subscription or licence, hosting and security, payment and transaction fees, apps and extensions, development and agency time, the migration itself, and the internal time to run the store. A cheaper plan with five paid apps and a custom integration may cost more than it looks. We help you build that comparison from your real requirements; we do not sell platform licences.

#### From decision to launch

Once the target is chosen, replatforming becomes a managed migration: source audit, data mapping, trial migration and sign-off, SEO and redirect plan, integration cut-over, content freeze, delta migration, launch and post-launch QA. Large stores are often moved in phases, for example catalog and content first, then customers and orders, then integrations, so each step can be verified.

#### Where Prevedshop fits

We are a migration team, not a platform reseller. That means the recommendation follows your requirements and data, and the same person who assessed the risks runs the migration. Platform-specific build work such as a custom theme or complex app development can be done by your agency or partners; we coordinate the data, SEO and launch side with them.

#### FAQ

Q: What is the difference between replatforming and migration?
A: Replatforming is the decision and project of moving the business to a new ecommerce platform. Migration is the part of it that moves data, URLs and content from the old system to the new one. Every replatforming includes a migration; not every migration needs a new platform decision.

Q: How long does ecommerce replatforming take?
A: It depends on catalog complexity, integrations, design work and decision speed. The migration part is usually shorter than the requirements, build and integration work around it. We give a timeline after the assessment, based on those factors.

Q: Should we replatform to Shopify, BigCommerce, Shopware or stay where we are?
A: It depends on your requirements, markets, integrations and budget. We compare the options against your must-have list and total cost of ownership, and staying put is a valid outcome.

Q: Can we replatform without losing SEO?
A: Rankings cannot be guaranteed. The risk is reduced with a full URL inventory, 301 redirects to the closest new pages, carried-over metadata, updated internal links and monitoring after launch.

### Managed ecommerce migration: one lead from audit to launch

URL: https://prevedshop.com/services/managed-migration
Language: en
Last reviewed: 2026-09-25

Managed migration is for stores that cannot afford to find out at launch what the export left behind. One named migration lead owns the whole move—source audit, data mapping, trial migration, SEO and redirects, integrations, launch and the first days after it—and asks you to sign off every trade-off instead of making it silently.

#### What a managed ecommerce migration includes

The scope is agreed in the assessment and written down, but a typical project covers the catalog (products, variants, categories, attributes, images), customer accounts, order history, content pages and blog posts, custom fields and metadata, the URL inventory and redirect map, and the functional decisions around apps, plugins and integrations. Storefront design is either rebuilt on the target platform or adapted to its constraints; which one is realistic is stated before work starts, not discovered afterwards.

What is explicitly out of scope is written down too. A migration that is vague about scope is the one that produces surprises in the last week.

#### Tools move records. A migration lead manages the project

Automated migration tools are good at copying standard entities between well-known platforms, and for a small, simple catalog they may be all you need. They do not decide what happens to a Magento attribute set with forty custom attributes, which WooCommerce plugin tables hold data the business still depends on, or how a multi-currency store should be modelled on the target. Those are decisions, and someone has to own them.

We use automation for what it is good at—extracting, comparing and re-checking thousands of rows—and a human makes and documents the production decisions.

#### How the project runs

1. Source audit: data volumes, custom fields, plugins/apps, integrations, URL structure, and the reason for the move.

2. Mapping: every important source field gets a destination, a transformation rule or an explicit decision to archive or drop it, approved by you.

3. Trial migration: a representative sample—including the awkward bundles, translated variants and old orders—runs into a staging store. You review it against agreed acceptance criteria.

4. Full migration and reconciliation: counts, relationships, prices, stock and totals are compared between source and target.

5. Launch: content freeze, delta migration of orders and customers created since the full run, redirect activation, DNS or domain switch and go-live checks.

6. Post-launch QA: buying journeys, redirects, crawl errors, integrations and feeds are watched during the first days, and issues are fixed or escalated.

#### Keeping the store selling during the move

The store does not have to stop trading for the length of the project. The full migration runs while the old store stays live; only the launch window needs a short, planned freeze on catalog edits, followed by a delta migration of new orders and customers. How long that window is depends on the two platforms, order volume and the integrations that must switch over, and it is agreed in the launch runbook in advance.

#### What you receive

A written migration plan and scope, the approved field mapping, trial-migration results with acceptance sign-off, reconciliation reports for the full run, the redirect map, a launch and rollback runbook, and a post-launch checklist with its results. If you later need to answer "where did this field go?", the answer is on paper.

#### When managed migration is the wrong choice

If you have a few hundred simple products, no order history worth keeping and no organic traffic to protect, a self-service tool or the target platform's own importer is usually cheaper and perfectly adequate. We will say so in the assessment. Managed migration earns its cost when the store has years of data, meaningful search visibility, custom functionality or integrations that must keep working on day one.

#### FAQ

Q: How long does a managed ecommerce migration take?
A: It depends on catalog size, data quality, custom functionality, integrations and how quickly decisions are approved. After the assessment you get a timeline built from those factors rather than a generic estimate; the trial migration and sign-off are the steps most often underestimated.

Q: What does a managed migration cost?
A: Managed migrations have a published starting price on our pricing page, and a paid assessment comes first. The final fixed price depends on the number of entities and custom fields to map, the state of the source data, the apps and integrations that need a decision and the size of the URL inventory. Once you approve the assessed scope, the implementation price is fixed.

Q: Can you migrate from a custom or legacy platform?
A: Yes, once we have inspected a database dump, API or representative export and written a source contract describing what it really contains. We do not assume a ready-made connector exists.

Q: Will our SEO rankings be preserved?
A: No one can guarantee rankings. What we control is URL continuity: every relevant old URL is inventoried, mapped and redirected with a 301, metadata is carried over where it is still accurate, and crawls before and after launch check the result.

Q: Who is our contact during the project?
A: Martin, the migration lead, from the assessment to post-launch QA. Automation supports the checking; it does not replace the person who answers your questions and approves production decisions.

### Ecommerce SEO migration and 301 redirect mapping

URL: https://prevedshop.com/services/seo-redirect-migration
Language: en
Last reviewed: 2026-09-25

A platform change almost always changes URLs, templates and internal links at the same time—the combination search engines notice most. Our SEO migration service plans that change from the old store's real URL inventory: every relevant address gets a destination, a 301 redirect and a check, before and after launch. We reduce avoidable risk; no one can honestly guarantee rankings.

#### Start with the URL inventory

The redirect map is only as good as the list it starts from. We build the inventory from the old store's sitemaps, a full crawl, the platform's own URL tables, Google Search Console landing pages and, where available, analytics and backlink data. That catches URLs that no sitemap lists: old campaign pages, filtered category URLs, image and PDF links, legacy paths from a previous migration.

#### Old-to-new mapping and 301 redirects

Each relevant old URL is mapped to its closest new equivalent—product to product, category to collection, article to article—not everything to the homepage. Pages without an equivalent get a documented decision: nearest relevant page or an intentional 404/410. The map is implemented as direct 301 redirects on the new platform and tested before launch: no redirect chains, no loops, no redirects to pages that are themselves redirected or blocked.

Platform constraints are part of the plan. Shopify, for example, uses fixed `/products/` and `/collections/` paths and applies its URL redirects only when the old path no longer exists on the store; other platforms allow custom URL structures, which changes what can be preserved.

#### Metadata, canonicals, robots and sitemaps

Titles, meta descriptions and headings move where they are still accurate for the new page. We check canonical tags point to the final URLs, that robots.txt and noindex settings from the staging store do not leak into production, that the new XML sitemap lists only canonical, indexable URLs, and that hreflang is correct for multilingual stores. Structured data for products and breadcrumbs is checked on the new templates.

#### Internal links and content

Redirects fix external links and bookmarks; they should not be the way your own site links to itself. Navigation, category descriptions, blog posts and footer links are updated to the new URLs so crawlers and customers are not bounced through redirects on every click.

#### Crawl before launch, crawl after launch

Before launch we crawl the staging store and test the redirect map against the inventory. On launch day the redirects go live with the new site, the new sitemap is submitted in Google Search Console and old URLs are spot-checked. In the following weeks we watch crawl errors, 404s, indexing and landing-page traffic against the pre-launch baseline and fix what the data shows.

#### What we can and cannot promise

We cannot guarantee rankings or traffic: they depend on search engines, competitors and many factors outside a migration. What we treat as a hard requirement is continuity—old links resolve to the right new page, the new site is crawlable and indexable, and the signals you had are carried over where the new platform allows.

#### FAQ

Q: How do you reduce the risk of losing Google rankings during a migration?
A: By mapping every relevant URL to its closest equivalent with a direct 301, carrying over accurate metadata, updating internal links, keeping the new site crawlable and indexable, and monitoring Search Console after launch. Risk is reduced, not eliminated.

Q: What happens to pages that don't exist on the new platform?
A: They get a documented decision: redirect to the closest relevant page, or return 404/410 if nothing relevant exists. Mass-redirecting everything to the homepage is avoided.

Q: Do you update internal links, not just redirects?
A: Yes. Navigation, content and product descriptions are updated to the new URLs so the site does not rely on its own redirects.

Q: Can you keep our existing URLs?
A: Sometimes. Platforms with configurable URL structures can preserve many paths; platforms with fixed patterns, such as Shopify, cannot, and then 301 redirects carry the continuity.

Q: Do you set up Google Search Console?
A: We work with your Search Console property: sitemap submission, monitoring crawl errors and indexing after launch. Access is agreed with you and kept least-privilege.

### Supplier Feed Integration

URL: https://prevedshop.com/services/supplier-feed-integration
Language: en
Last reviewed: 2026-07-20

Running your catalog off supplier feeds means dealing with inconsistent formats, duplicate SKUs across suppliers, and update timing that doesn't match your platform's expectations. We connect and normalize those feeds so your catalog stays accurate without manual upkeep.

#### What we normalize

Supplier feeds rarely share a format — field names, category structures, and even measurement units differ supplier to supplier. We map each feed to a consistent structure on your platform, so products behave the same way in your catalog regardless of source.

#### Duplicates and merging

When multiple suppliers carry the same product, we can merge listings, choose a preferred source, or keep them separate — depending on how you want pricing and stock handled. This is a decision we make with you, not a default we impose.

#### Keeping data current

Feed update frequency depends on what your suppliers actually provide and what your platform can reasonably absorb — we agree a realistic schedule rather than promising real-time updates a source feed can't support.

#### FAQ

Q: Can you combine feeds from multiple suppliers into one catalog?
A: Yes — merging, deduplicating and normalizing multiple supplier feeds into a single consistent catalog is a common part of this service.

Q: What happens when a supplier discontinues a product?
A: Depending on your preference, we can mark it unavailable, hide it, or keep it visible with a backorder status — configured once, applied automatically on future feed updates.

Q: Can supplier feeds be translated for other markets?
A: Yes, feed content can be translated, either through automated translation or a custom mapping you provide, depending on accuracy requirements.


## Čeština (cs)

### Platform profiles

### Migrace na Adobe Commerce (Magento) a z něj

URL: https://prevedshop.com/cs/platformy/adobe-commerce-magento
Language: cs
Last reviewed: 2026-07-21

Pod pojmem „Magento“ se dnes skrývá několik různých věcí: open-source platforma Magento Open Source, placená úroveň Adobe Commerce Cloud a starší instalace Magento 1, které jsou už za koncem životnosti. To, kterou z nich skutečně provozujete, výrazně mění plán migrace, takže zjištění přesné verze a edice je první krok bez ohledu na to, zda je Magento vaším zdrojem, nebo cílem.

#### Magento Open Source, Adobe Commerce a Magento 1 vs. 2

Magento Open Source je zdarma dostupný, samostatně hostovaný e-commerce software postavený na PHP; Adobe Commerce (dříve Magento Commerce) je placená úroveň s dalšími funkcemi pro B2B, staging obsahu a cloudový hosting, provozovaná na infrastruktuře spravované Adobe. Magento 1 dosáhlo konce životnosti už před lety a obchody, které na něm stále běží, migrují většinou právě z tohoto důvodu, nezávisle na jakémkoli srovnávání platforem.

Kvůli tomuto rozpětí může projekt „migrace Magenta“ znamenat přechod malého obchodu na Magento 1 na zcela jinou platformu, přechod z Magenta 1 na Magento 2 (stále Magento, ale přestavba na hlavní verzi), nebo odchod z Adobe Commerce Cloud na řešení s jinou nákladovou strukturou. Které z toho se týká vašeho případu, určíme dřív, než cokoli odhadujeme.

#### Datový model EAV a nastavení víceobchodového provozu

Magento ukládá produktová data pomocí struktury EAV (entity-attribute-value), která je silná pro vysoce konfigurovatelné katalogy bohaté na atributy, ale strukturně odlišná od jednodušších plochých produktových tabulek, jaké používá většina ostatních platforem. Konfigurovatelné produkty (obdoba variant v Magentu), sady vlastních atributů i vrstvená navigace řízená atributy vyžadují při přechodu na platformu bez ekvivalentu EAV výslovné mapování.

Víceobchodová/vícewebová architektura Magenta, provoz několika výloh, měn nebo lokalizací z jedné instalace, je další věc, kterou je třeba pečlivě namapovat, protože většina platforem řeší více obchodů jinak: samostatné obchody, jeden obchod s nastaveními specifickými pro daný trh, nebo žádný nativní ekvivalent.

#### Rozšíření, vlastní moduly a vývojáři Magenta

Obchody na Magentu se běžně spoléhají na rozšíření z marketplace a na zakázkově vytvořené moduly pro cokoli nad rámec základní funkcionality — platební metody, cenová pravidla pro B2B nebo katalogovou logiku specifickou pro daný byznys. Protože je Magento platforma náročná na vývojáře, podstatná část toho, co obchod „umí“, často žije ve vlastním kódu PHP, ne v nastaveních administrace, a tuto logiku je třeba identifikovat a buď znovu vybudovat, nebo nahradit — ne jen exportovat.

Stejné to je se šablonami: šablony Magenta jsou postavené na vlastním systému layout XML/bloků, který nemá jinde přímou obdobu, takže odchod z Magenta obvykle znamená stavbu výlohy na nové platformě od začátku.

#### SEO, URL adresy a jak řešíme migraci Magenta

Magento spravuje přepisy URL interně a podporuje poměrně flexibilní struktury URL adres, ale konkrétní podoba (cesty kategorií, přípony URL produktů, URL specifické pro pohled obchodu) se obchod od obchodu podle nastavení hodně liší. Právě kvůli této proměnlivosti začínáme auditem vašich skutečných živých vzorů URL, ne předpokládaným výchozím nastavením Magenta.

U migrace Magenta stavíme mapu URL a přesměrování podle toho, co váš obchod dnes skutečně dělá, řešíme varianty URL pro více obchodů, pokud jsou relevantní, a ověřujeme, že se metadata a kanonické značky přenesou správně. Podrobněji tento postup popisuje naše služba SEO a migrace přesměrování.

#### FAQ

Q: Stále jsem na Magentu 1. Umíte to migrovat?
A: Ano, odchod z Magenta 1 je jeden z běžnějších projektů, se kterými se setkáváme, obvykle vyvolaný koncem jeho životnosti, ne preferencí platformy. Řešíme to jako kompletní replatforming, protože Magento 1 a 2 mají odlišnou podkladovou architekturu.

Q: Co se stane s mými vlastními moduly pro Magento?
A: Zjistíme, co každý vlastní modul skutečně dělá — například platební integraci, cenové pravidlo nebo katalogovou funkci — a vyhodnotíme, zda má cílová platforma vestavěnou nebo rozšiřující obdobu, nebo zda je potřeba zakázkový vývoj.

Q: Dají se B2B funkce Adobe Commerce migrovat na neenterprise platformu?
A: Záleží na konkrétních funkcích. Firemní účty, workflow nabídek a vrstvené B2B ceny nemají přímou obdobu na každé platformě, takže to posuzujeme případ od případu už při vstupním posouzení, ne s předpokladem přesné shody.

Q: Jak ovlivňuje struktura atributů EAV délku migrace?
A: Katalogy s mnoha vlastními atributy a sadami atributů obecně vyžadují víc času na mapování než jednoduché ploché katalogy, protože u každého atributu je potřeba výslovně rozhodnout, kam na cílové platformě patří.

Sources:
- Adobe Commerce (Magento) – oficiální stránka produktu: https://business.adobe.com/products/magento/magento-commerce.html

### Migrace na BigCommerce a z BigCommerce

URL: https://prevedshop.com/cs/platformy/bigcommerce
Language: cs
Last reviewed: 2026-07-21

BigCommerce je hostovaná SaaS platforma, se kterou se setkáváme na obou stranách migrací: u obchodníků, kteří na ni přecházejí kvůli nativní struktuře kategorií a možnostem headless řešení, i u obchodníků, kteří z ní odcházejí, jakmile se změní jejich potřeby. Stejně jako u jiných uzavřených, API řízených platforem u migrace BigCommerce nejvíc záleží na tom, co zpřístupňuje API a datový model, ne jen na počtu přenášených produktů. Tato stránka shrnuje, na čem záleží, když je BigCommerce na jedné straně migrace.

#### Co je BigCommerce a kam patří

BigCommerce je hostovaná SaaS platforma pro e-commerce: o hosting, bezpečnostní záplaty a dostupnost se stará BigCommerce, vy obchod spravujete přes jeho administraci a API, ne přes server pod vlastní kontrolou. Tarify sahají od standardních úrovní pro malé a střední obchodníky až po Enterprise. Multi-Storefront je dostupný v různých tarifech s odlišnými limity počtu výloh; Enterprise může nabídnout vyšší limity API, úrovně podpory a další B2B funkce. BigCommerce nabízí i headless přístup, který umožňuje využít jeho backend a API se zakázkově postaveným frontendem místo vlastní vrstvy šablon.

Výlohy na standardní, ne-headless cestě se staví na šablonovém frameworku Stencil od BigCommerce, se šablonami z BigCommerce Theme Marketplace nebo vytvořenými na zakázku. Jako u každé uzavřené, hostované platformy probíhají migrace na BigCommerce a z BigCommerce v rámci jeho datového modelu a rozhraní API, ne přímou kopií databáze, takže to, co API zpřístupňuje pro produkty, objednávky a zákazníky, určuje, co se dá přenést automaticky.

#### Produkty, kategorie a datový model

Na rozdíl od platforem, které se spoléhají čistě na kolekce založené na štítcích, BigCommerce podporuje nativní, vnořený strom kategorií vedle produktů a jejich variant. To z něj dělá poměrně dobrou volbu pro katalogy s víceúrovňovou strukturou kategorií, protože hierarchii kategorií nemusíte zplošťovat do štítků nebo chytrých kolekcí tak, jako na některých jiných hostovaných platformách.

Zákazníci a historie objednávek se přenášejí přes REST a GraphQL API BigCommerce, ale stejně jako u jiné migrace platformy historické objednávky obvykle přistávají jako referenční záznamy, ne jako plně živé, znovu editovatelné objednávky. Vlastní produktová data se obvykle mapují na vlastní pole BigCommerce a cenové seznamy (mechanismus BigCommerce pro ceny podle skupiny zákazníků nebo měny) jsou jedna z prvních věcí, které kontrolujeme, když má zdrojová platforma vlastní systém vrstvených cen.

#### Aplikace, šablony a co se nepřenese automaticky

Fungující obchod na BigCommerce se běžně spoléhá na aplikace z BigCommerce App Marketplace — na recenze, předplatné, vyhledávání, marketingovou automatizaci nebo pravidla dopravy. Data uložená v aplikaci se při migraci platformy nepřenášejí; odchod z BigCommerce znamená exportovat vše uložené uvnitř aplikace zvlášť, a příchod na BigCommerce znamená znovu nainstalovat a nastavit ekvivalenty místo přenosu nastavení aplikací.

Šablony Stencil se nepřevádějí do šablonovacího systému jiné platformy, takže odchod z BigCommerce obvykle znamená znovu postavit design výlohy na nové platformě, a příchod na BigCommerce znamená upravit šablonu z marketplace nebo zadat zakázkový vývoj šablony. Pokud místo toho zvolíte headless cestu, frontend je od vrstvy šablon BigCommerce zcela oddělený, což mění, co „migrace designu“ vůbec znamená.

#### SEO, URL adresy a jak řešíme migraci BigCommerce

BigCommerce je ohledně struktury URL flexibilnější než někteří hostovaní konkurenti a umožňuje nastavit vlastní URL adresy pro produkty, kategorie a stránky místo vynucení jediného pevného vzoru. Tato flexibilita pomáhá, když migrujete na BigCommerce a chcete, aby se URL adresy podobaly těm starým, ale neděje se to automaticky, a odchod z BigCommerce stále znamená namapovat jeho vzory URL na to, co vyžaduje nová platforma.

V rámci řízené migrace porovnáme vaši stávající strukturu URL se strukturou BigCommerce, nastavíme přesměrování potřebná v obou směrech a přeneseme metadata, která jsou na nových URL adresách stále platná — stejným postupem, jaký popisujeme u služby SEO a migrace přesměrování, přizpůsobeným konkrétnímu API a omezením směrování BigCommerce.

#### FAQ

Q: Můžu si při přechodu na BigCommerce zachovat vnořenou strukturu kategorií?
A: Ano. BigCommerce podporuje nativní, víceúrovňový strom kategorií, takže hluboká struktura kategorií z jiné platformy se obvykle mapuje přímočařeji, než by se mapovala na platformu, která podporuje jen ploché štítky nebo kolekce.

Q: Co se stane s mými aplikacemi na BigCommerce, když odejdu?
A: Data specifická pro danou aplikaci je obecně třeba exportovat z každé aplikace zvlášť ještě před migrací. Migrujeme základní data obchodu, na kterých aplikace stojí, ale ne její interní konfiguraci nebo uložené záznamy.

Q: Mění headless možnost BigCommerce způsob, jakým migrace probíhá?
A: Mění to, co znamená migrace šablony, protože headless nastavení odděluje frontend od vlastní vrstvy šablon BigCommerce, ale podkladová data produktů, objednávek a zákazníků se přesouvají stejným způsobem přes API.

Q: Zůstanou mi URL adresy stejné, když přejdu na BigCommerce?
A: Jen pokud záměrně nastavíte odpovídající vlastní URL adresy, což BigCommerce umožňuje pro produkty, kategorie i stránky. Obvykle místo předpokladu přesné shody URL nastavujeme přesměrování.

Sources:
- BigCommerce – oficiální web: https://www.bigcommerce.com

### Migrace na OpenCart a z OpenCart

URL: https://prevedshop.com/cs/platformy/opencart
Language: cs
Last reviewed: 2026-07-21

OpenCart je open-source platforma pro e-commerce, se kterou se u migrací setkáváme pravidelně — obvykle u obchodníků, kteří s ní začínali kvůli nízké ceně a jednoduchosti a dnes už jim vlastní správa přestává stačit, nebo u obchodníků, kteří ji volí právě kvůli nenáročnosti. Protože je OpenCart open-source a samostatně hostovaný, složitost migrace obvykle závisí na tom, jak moc byl obchod upraven pomocí rozšíření, ne jen na počtu produktů v katalogu. Tato stránka shrnuje, na čem záleží, když je OpenCart na jedné straně migrace.

#### Co je OpenCart a kam patří

OpenCart je open-source software pro e-commerce postavený na PHP a MySQL, samostatně hostovaný na serveru, který spravujete vy nebo váš poskytovatel hostingu. Je známý poměrně odlehčeným jádrem a nižší vstupní bariérou než některé jiné open-source platformy, což ho dělá oblíbeným u menších obchodníků a agentur stavějících obchody s ohledem na rozpočet. Správa více obchodů z jedné administrace je vestavěná funkce, ne doplněk.

Výlohy používají vlastní systém šablon OpenCart, od verze OpenCart 3 založený na šablonovacím enginu Twig, se šablonami a rozšířeními dostupnými přes oficiální OpenCart Marketplace nebo vytvořenými na zakázku. Jako u každé samostatně hostované open-source platformy je množství vlastního kódu a rozšíření třetích stran, které obchod nese, jedna z prvních věcí, která určuje rozsah migrace.

#### Produkty, možnosti a datový model

Katalog OpenCart je postavený na produktech řazených do kategorií, přičemž produktové „možnosti“ (options) řeší varianty, jako velikost nebo barva, způsobem strukturně odlišným od vyhrazeného systému variant na úrovni SKU, jaký mají některé jiné platformy. Možnosti v OpenCart mohou upravovat cenu a množství, ale podkladový model není totožný se skutečnými variantami, což hraje roli při migraci katalogu, který jinde používá skutečné varianty, do OpenCart, nebo z OpenCart na platformu s přísnějším modelem variant.

Protože je OpenCart samostatně hostovaný, je pro export často k dispozici přímý přístup k databázi, což může zjednodušit získání dat o produktech, zákaznících a objednávkách. Obchody upravené pomocí rozšíření nebo se zásahy do jádra — běžný jev v ekosystému OpenCart, zejména u starších rozšíření založených na VQMod nebo OCMOD — ale vyžadují, aby se tyto úpravy identifikovaly dřív, než se spolehneme na čistý, standardní export.

#### Rozšíření, šablony a co se nepřenese automaticky

Fungující obchod na OpenCart často závisí na nainstalovaných rozšířeních — na platby, dopravu, marketingové nástroje nebo katalogové funkce nad rámec jádra OpenCart. Data a nastavení rozšíření se při migraci platformy nepřenášejí automaticky; odchod z OpenCart znamená zjistit, co každé rozšíření ukládá, a exportovat to zvlášť, a příchod na OpenCart znamená nainstalovat a nastavit ekvivalenty z OpenCart Marketplace nebo přes zakázkový vývoj.

Šablony OpenCart založené na Twig jsou specifické pro jeho šablonovací systém a nepřenášejí se na jiné platformy, takže odchod z OpenCart obvykle znamená znovu postavit design výlohy jinde, a příchod na OpenCart znamená upravit šablonu z marketplace nebo vytvořit vlastní. Starší instalace OpenCart, před verzí 3.0, mohou stále používat starší systém šablon, na což stojí za to upozornit hned na začátku, protože to ovlivňuje, jak se plánuje redesign.

#### SEO, URL adresy a jak řešíme migraci OpenCart

OpenCart podporuje SEO přívětivé přepisování URL adres pro produkty a kategorie, ale je třeba ho zapnout a nakonfigurovat, není to výchozí stav po instalaci, a starší nebo silně upravené instalace někdy stále běží s výchozími, nepřívětivými URL adresami. Odchod z OpenCart znamená zjistit, který režim URL adres se skutečně používá, dřív než se předpokládá čisté namapování na novou platformu.

V rámci řízené migrace provedeme audit vaší aktuální konfigurace URL v OpenCart (nebo naplánujeme cílovou, pokud na OpenCart přecházíte), sestavíme mapu přesměrování mezi starými a novými URL adresami a přeneseme metadata, která jsou stále platná — stejným postupem, jaký popisujeme u služby SEO a migrace přesměrování, aplikovaným na konkrétní nastavení OpenCart.

#### FAQ

Q: Je OpenCart zdarma?
A: Základní software OpenCart je open-source a zdarma ke stažení a samostatnému hostování. Průběžné náklady vznikají za hosting, čas vývojářů a případná placená rozšíření nebo šablony z OpenCart Marketplace.

Q: Jak se produktové možnosti OpenCart srovnávají s variantami na jiných platformách?
A: Možnosti v OpenCart mohou upravovat cenu a množství podle kombinace, ale nejsou strukturované úplně stejně jako vyhrazený systém variant na úrovni SKU, takže jejich mapování na platformu s přísnějším modelem variant, nebo z ní, vyžaduje pečlivé posouzení, ne přímé přiřazení polí.

Q: Umíte migrovat má rozšíření OpenCart a jejich data?
A: Migrujeme základní data obchodu, na kterých rozšíření stojí, ale nastavení a uložené záznamy specifické pro dané rozšíření je obvykle třeba získat samostatným exportem z tohoto rozšíření nebo je znovu vybudovat pomocí ekvivalentu na cílové platformě.

Q: Ovlivňuje verze OpenCart migraci?
A: Ano. Starší instalace OpenCart, zejména před verzí 3.0, se mohou výrazně lišit systémem šablon, formátem rozšíření i schématem databáze, takže vaši verzi ověřujeme hned na začátku posouzení.

Sources:
- OpenCart – oficiální web: https://www.opencart.com

### Migrace na PrestaShop a z PrestaShopu

URL: https://prevedshop.com/cs/platformy/prestashop
Language: cs
Last reviewed: 2026-07-21

PrestaShop je open-source platforma pro e-commerce, se kterou se u migrací setkáváme často, zejména u obchodníků v Evropě, kteří na ni přecházejí kvůli flexibilitě samostatně hostovaného řešení, nebo z ní odcházejí, jakmile jim vlastní správa přestane stačit. Protože je PrestaShop open-source a samostatně hostovaný (případně hostovaný přes vlastní cloudovou nabídku PrestaShop), o složitosti migrace obvykle rozhoduje struktura databáze a to, na jakých modulech obchod závisí, ne jen velikost katalogu. Tato stránka shrnuje, na čem záleží, když je PrestaShop na jedné straně migrace.

#### Co je PrestaShop a kam patří

PrestaShop je open-source software pro e-commerce postavený na PHP a MySQL, nejčastěji samostatně hostovaný, i když PrestaShop nabízí i vlastní cloudový hosting. Open-source znamená, že server, verzi PHP a databázi spravujete vy nebo váš poskytovatel hostingu přímo a máte plný přístup k podkladovému kódu, na rozdíl od uzavřených SaaS platforem. Zvlášť silné zastoupení má mezi obchodníky ve Francii, Španělsku a dalších evropských trzích.

Výlohy se staví ve vlastním systému šablon PrestaShop, přičemž šablony a moduly pocházejí buď z oficiálního PrestaShop Marketplace (Addons), nebo se vytvářejí na zakázku. Protože je kód otevřený, úpravy obchodu na PrestaShopu mohou sahat od jednoduché konfigurace až po hluboký, zakázkový vývoj modulů, a to, kolik vlastního kódu obchod nese, je jedna z prvních věcí, která formuje rozsah migrace.

#### Produkty, kategorie a datový model

Katalogový model PrestaShopu je postavený na produktech s kombinacemi (jeho označení pro varianty, jako velikost nebo barva), řazených do nativního stromu kategorií s neomezenou hloubkou, plus samostatných „vlastností“ a „atributů“ pro strukturovaná produktová data. Tento nativní strom kategorií dělá z PrestaShopu rozumný cíl pro katalogy s hlubokou hierarchickou strukturou a je to jedna z věcí, které pečlivě mapujeme při migraci stromu kategorií na něj, nebo z něj na platformu s plošším modelem.

Zákazníci a historie objednávek žijí přímo v databázi MySQL PrestaShopu, což u samostatně hostovaného obchodu znamená, že pro export je často k dispozici přímý přístup k databázi, ne jen to, co zpřístupní REST API. To může některé části migrace zjednodušit, ale zároveň to znamená, že úpravy databázového schématu specifické pro daný obchod, například kvůli vlastním modulům, je třeba identifikovat dřív, než se spolehneme, že standardní export zachytí úplně vše.

#### Moduly, šablony a co se nepřenese automaticky

Fungující obchod na PrestaShopu obvykle závisí na nainstalovaných modulech — na platby, výpočet dopravy, marketing nebo katalogové funkce, které nejsou součástí jádra PrestaShopu. Data a konfigurace modulů se při migraci platformy automaticky nepřenášejí; odchod z PrestaShopu znamená zjistit, co každý modul ukládá, a exportovat to zvlášť, a příchod na PrestaShop znamená nainstalovat a nastavit ekvivalentní moduly z marketplace Addons nebo je nechat vyvinout na zakázku.

Šablony PrestaShopu jsou svázané s jeho vlastním šablonovacím systémem a nepřevádějí se do jiných platforem, takže odchod z PrestaShopu obvykle znamená znovu postavit design výlohy na nové platformě, a příchod na PrestaShop znamená upravit šablonu z marketplace nebo zadat zakázkovou. Samostatně hostované obchody navíc někdy nesou vlastní kód na úrovni šablony, který je třeba posoudit odděleně od samotného vizuálního designu.

#### SEO, URL adresy a jak řešíme migraci PrestaShopu

PrestaShop umožňuje poměrně flexibilní, konfigurovatelné přepisování URL adres pro produkty, kategorie a CMS stránky, což pomáhá, když se snažíte při migraci zachovat strukturu URL, ale i tak je třeba ji nastavit záměrně, ne ji jen předpokládat. Odchod z PrestaShopu znamená namapovat jeho vzory URL, které se mohou obchod od obchodu výrazně lišit, protože jsou konfigurovatelné, na požadavky nové platformy.

V rámci řízené migrace zkontrolujeme vaši stávající konfiguraci URL v PrestaShopu (nebo cílovou, pokud na PrestaShop přecházíte), sestavíme mapu přesměrování mezi starými a novými URL adresami a přeneseme metadata, která jsou stále platná — stejným postupem, jaký popisujeme u služby SEO a migrace přesměrování, aplikovaným na konkrétní nastavení směrování PrestaShopu.

#### FAQ

Q: Je PrestaShop zdarma?
A: Základní software PrestaShop je open-source a zdarma ke stažení a samostatnému hostování. Náklady vznikají za hosting, čas vývojářů, placené moduly a šablony a případný cloudový hostingový plán PrestaShop místo samostatného hostování.

Q: Umíte migrovat mé moduly PrestaShop a jejich data?
A: Migrujeme základní data obchodu, na kterých modul stojí, ale konfiguraci a uložené záznamy specifické pro daný modul je obvykle třeba získat samostatným exportem z tohoto modulu nebo je znovu vybudovat pomocí ekvivalentu na cílové platformě.

Q: Přenáší se struktura kategorií PrestaShopu dobře na jiné platformy?
A: Záleží na cíli. Nativní strom kategorií PrestaShopu s neomezenou hloubkou se čistě mapuje na platformy s podobným modelem, ale na platformách, které nepodporují skutečně vnořené kategorie, je třeba ho přemapovat na štítky nebo kolekce.

Q: Na jaké verzi PrestaShopu záleží při migraci?
A: Záleží na tom docela dost, protože se databázové schéma i kompatibilita modulů může mezi hlavními verzemi lišit. Vaši verzi PrestaShopu potvrdíme během posouzení dřív, než finalizujeme přístup k migraci.

Sources:
- PrestaShop – oficiální web: https://www.prestashop.com

### Migrace na Shopify a ze Shopify

URL: https://prevedshop.com/cs/platformy/shopify
Language: cs
Last reviewed: 2026-07-21

Shopify patří mezi nejčastější cíle i výchozí body migrací, se kterými pracujeme. Protože jde o uzavřenou, hostovanou platformu, o tom, jak hladce migrace proběhne, rozhoduje hlavně to, co skutečně zpřístupňuje Shopify API — ne jen velikost vašeho katalogu. Tato stránka shrnuje, na čem záleží, když je Shopify na jedné straně migrace.

#### Co je Shopify a kam patří

Shopify je hostovaná SaaS platforma pro e-commerce: nespravujete servery, verze PHP ani zálohy databáze. O infrastrukturu se stará Shopify, vy obchod spravujete přes jeho administraci a pro hlubší úpravy přes API. Tarify sahají od standardních úrovní pro malé a střední obchodníky až po Shopify Plus, určený obchodníkům s vyšším objemem, kteří potřebují více možností úprav pokladny a vyšší limity API.

Výlohy obchodu se staví ve vlastním šablonovacím jazyce Shopify, Liquid, a šablony pocházejí buď z Shopify Theme Store, nebo ze zakázkového vývoje. Protože jde o uzavřenou, hostovanou platformu, pracujete v rámci datového modelu a rozšiřujících bodů Shopify, nikoli s úpravou jádra systému — a právě proto migrace na Shopify a ze Shopify stojí a padá na přístupu k API a konfiguraci aplikací, ne na přímé kopii databáze.

#### Produkty, objednávky a zákazníci: datový model

Produktový model Shopify je postavený na produktech a variantách (například tričko s variantami velikosti a barvy), řazených do ručních nebo automatických kolekcí místo volně strukturovaného stromu kategorií. Migrace katalogu do Shopify obvykle znamená přemapovat strukturu kategorií či atributů ze zdrojové platformy na model produkt/varianta/kolekce Shopify — u jednoduchých katalogů je to přímočaré, u platforem s hlubokými, víceúrovňovými kategoriemi nebo silně konfigurovatelnými produkty náročnější.

Data zákazníků a objednávek lze převádět podporovanými exporty, importy a API, ale dostupná pole, hloubka historie i chování po importu závisejí na směru migrace, přístupu k API a cílovém workflow. Proto před volbou metody stanovujeme akceptační kritéria pro historii objednávek. Metapole (mechanismus vlastních polí Shopify) jsou obvykle místo, kam směřují nestandardní produktová data, a namapování vašich stávajících vlastních polí na metapole je jedna z prvních věcí, které při posouzení řešíme.

#### Aplikace, šablony a co se nepřenese automaticky

Fungující obchod na Shopify obvykle závisí na několika nainstalovaných aplikacích — na recenze, předplatné, věrnostní programy, vyhledávání nebo pravidla dopravy. Data aplikací se při migraci platformy zpravidla nepřenášejí; pokud odcházíte ze Shopify, data uložená v aplikaci (jako harmonogramy předplatného nebo věrnostní body) je třeba exportovat zvlášť z dané aplikace, a pokud na Shopify přicházíte, budete instalovat ekvivalenty z Shopify App Store místo přenosu konfigurace aplikací.

Stejně je to se šablonami: šablona v Liquid se nepřevede do šablonovacího systému jiné platformy, takže odchod ze Shopify obvykle znamená znovu postavit design výlohy na nové platformě, a příchod na Shopify znamená buď upravit šablonu z Theme Store, nebo zadat zakázkový vývoj v Liquid.

#### SEO, URL adresy a jak řešíme migraci na Shopify

Shopify vynucuje vlastní vzory URL adres, například /products/{handle}, /collections/{handle} a /pages/{handle}, které se jen zřídka přesně shodují se strukturou URL jiné platformy. Přechod na Shopify nebo z něj téměř vždy znamená mapu přesměrování ze starých URL adres na nové, protože Shopify nedovolí plně replikovat libovolnou strukturu URL z jiného systému a jiné platformy zase automaticky neznají vaše handles ze Shopify.

V rámci řízené migrace namapujeme vaše stávající URL adresy proti struktuře Shopify (nebo naopak, pokud ze Shopify odcházíte), nastavíme přesměrování 301 a přeneseme metadata, která jsou na nových URL adresách stále platná — stejným postupem, jaký popisujeme u služby SEO a migrace přesměrování, jen zaměřeným konkrétně na konvence URL a omezení API Shopify.

#### FAQ

Q: Umíte migrovat mé aplikace na Shopify a jejich data?
A: Migrujeme data obchodu, na kterých tyto aplikace stojí, ale konfiguraci a uložená data konkrétní aplikace je obvykle třeba získat samostatným exportem z dané aplikace nebo je znovu vybudovat pomocí ekvivalentní aplikace na cílové platformě.

Q: Mění Shopify Plus způsob, jakým migrace probíhá?
A: Plus ovlivňuje hlavně úpravy pokladny a limity API. Podkladový datový model produktů a objednávek je stejný jako u standardního Shopify, takže se přístup k migraci zásadně nemění, i když vyšší limity API mohou zrychlit přenos velkých katalogů.

Q: Zůstanou mi URL adresy produktů stejné, když přejdu na Shopify?
A: Jen pokud vaše současné URL adresy už odpovídají vzoru Shopify /products/{handle}, což je neobvyklé. Ve většině případů v rámci migrace nastavíme přesměrování ze starých URL adres na strukturu vyžadovanou Shopify.

Q: Co se stane s mou šablonou, když odejdu ze Shopify?
A: Šablony v Liquid se nepřenášejí do šablonovacích systémů jiných platforem, takže se design výlohy znovu vybuduje na nové platformě a přizpůsobí vašemu stávajícímu designu tam, kde to nová platforma umožňuje.

Sources:
- Shopify – oficiální web: https://www.shopify.com

### Migrace na Shoptet a ze Shoptetu

URL: https://prevedshop.com/cs/platformy/shoptet
Language: cs
Last reviewed: 2026-07-21

Shoptet je hostovaná e-commerce platforma zaměřená konkrétně na český a slovenský trh a je běžným cílem migrací u obchodníků působících v tomto regionu — ať už na ni přecházejí kvůli místní podpoře a nastavení bez nutnosti kódovat, nebo z ní odcházejí, jakmile rostou nebo potřebují funkce, které platforma nenabízí. Protože je Shoptet uzavřená, hostovaná SaaS platforma, migrace na ni nebo z ní závisí na tom, co skutečně zpřístupňuje jeho administrace, exportní nástroje a API. Tato stránka shrnuje, na čem záleží, když je Shoptet na jedné straně migrace.

#### Co je Shoptet a kam patří

Shoptet je hostovaná SaaS platforma pro e-commerce postavená pro český a slovenský trh, s administračním rozhraním, dokumentací i podporou primárně v češtině. Stejně jako u jiných hostovaných platforem se o hosting a infrastrukturu stará Shoptet a obchodníci obchod spravují přes administraci, ne přes přístup k serveru. Cílí především na malé a střední regionální obchodníky, kteří chtějí provozovat obchod bez nutnosti sami spravovat kód nebo infrastrukturu.

Výlohy se staví pomocí vlastního systému šablon a úprav designu Shoptet, s doplňky dostupnými přes vlastní tržiště pro funkce jako účetní integrace, marketingové nástroje a regionální platební či dopravní metody běžné na trhu ČR/SR. Protože jde o uzavřenou, hostovanou platformu, migrace na Shoptet a z něj probíhají v rámci jeho vlastního datového modelu a možností exportu nebo API, ne přímou kopií databáze.

#### Produkty, kategorie a datový model

Katalogový model Shoptetu organizuje produkty do kategorií s podporou variant a parametrů pro strukturované atributy. Migrace katalogu do Shoptetu znamená namapovat strukturu kategorií a atributů zdrojové platformy na jeho model; skutečnou složitost určují varianty, parametry a integrace konkrétního obchodu.

Migrace ze Shoptetu stojí na exportech a přístupu k API dostupných pro konkrétní obchod a tarif. Pokrytí produktů, zákazníků a objednávek proto ověřujeme na vzorku exportu; rozsah polí a chování historických objednávek v cíli závisí na možnostech cílového importu, ne na univerzálním pravidle.

#### Doplňky, design a co se nepřenese automaticky

Fungující obchod na Shoptetu často závisí na nainstalovaných doplňcích — na účetnictví, marketing, feedy do srovnávačů cen, běžné u obchodníků z ČR/SR nabízejících zboží na službách jako Heureka nebo Zboží.cz, nebo na regionálních platebních integracích. Data a nastavení doplňků se při migraci platformy nepřenášejí automaticky; odchod ze Shoptetu znamená zjistit, co každý doplněk ukládá, a exportovat to zvlášť, a příchod na Shoptet znamená nastavit ekvivalenty z jeho vlastního tržiště doplňků.

Designové šablony Shoptetu jsou specifické pro jeho vlastní systém a nepřenášejí se na jiné platformy, takže odchod ze Shoptetu obvykle znamená znovu postavit design výlohy jinde, a příchod na Shoptet znamená přizpůsobit jednu z jeho šablon nebo pracovat v rámci jeho možností úpravy designu.

#### SEO, URL adresy a jak řešíme migraci Shoptetu

Shoptet umožňuje určitou úpravu struktury URL adres pro produkty a kategorie, ale stejně jako u jakéhokoli přechodu na jinou platformu se stávající vzory URL jen zřídka přesně shodují s požadavky nové platformy. To hraje roli zejména u obchodníků z ČR/SR, kteří často mají organickou viditelnost navázanou na aktuální URL adresy a nabídky v produktových feedech na regionálních srovnávačích zboží.

V rámci řízené migrace namapujeme vaše stávající URL adresy Shoptetu (nebo cílové platformy, pokud na Shoptet přecházíte) proti nové struktuře, nastavíme přesměrování a přeneseme metadata i konfiguraci feedů do srovnávačů, které jsou stále platné — stejným postupem, jaký popisujeme u služby SEO a migrace přesměrování, aplikovaným na konkrétní nastavení Shoptetu a regionální ekosystém feedů, na který se typicky napojuje.

#### FAQ

Q: Je Shoptet dostupný i mimo Českou republiku a Slovensko?
A: Shoptet je vyvíjený a podporovaný konkrétně pro český a slovenský trh, s administrací a dokumentací primárně v češtině. Není koncipovaný jako globální platforma tak, jako někteří hostovaní konkurenti, což stojí za zvážení, pokud expandujete mimo ČR/SR.

Q: Umíte migrovat mé produktové feedy Shoptetu pro Heureku nebo Zboží.cz?
A: Migrujeme podkladová produktová data, ze kterých se tyto feedy sestavují; samotnou konfiguraci feedu je obvykle třeba znovu vybudovat na nové platformě, nebo ji řešit přes naši službu Integrace dodavatelských feedů, podle toho, jak cílová platforma spravuje feedy do srovnávačů zboží.

Q: Umíte migrovat mé doplňky Shoptetu a jejich data?
A: Migrujeme základní data obchodu, na kterých doplněk stojí, ale nastavení a uložené záznamy specifické pro daný doplněk je obvykle třeba získat samostatným exportem z tohoto doplňku nebo je znovu vybudovat pomocí ekvivalentu na cílové platformě.

Q: Zůstanou mi URL adresy produktů stejné, když přejdu na Shoptet nebo z něj?
A: Obvykle ne přesně, protože struktura URL adres Shoptetu se jen zřídka shoduje s požadavky jiné platformy. Relevantní staré URL namapujeme na nové cíle, abychom zachovali kontinuitu adres a snížili zbytečné SEO riziko; konkrétní pozice nelze garantovat.

Sources:
- Shoptet – oficiální web: https://www.shoptet.cz

### Migrace na Shopware a ze Shopware

URL: https://prevedshop.com/cs/platformy/shopware-6
Language: cs
Last reviewed: 2026-07-21

Se Shopware se nejčastěji setkáváme u obchodníků z Německa, Rakouska a Švýcarska — buď na něj přecházejí kvůli otevřené architektuře a silné pozici v regionu DACH, nebo odcházejí ze starší instalace Shopware, jakmile se změní jejich potřeby. Dvojí povaha Shopware, tedy že jde o open-source software, který lze provozovat i jako hostovaný cloudový produkt, znamená, že správný přístup k migraci závisí na tom, kterou verzi a způsob nasazení skutečně používáte. Tato stránka shrnuje, na čem záleží, když je Shopware na jedné straně migrace.

#### Co je Shopware a kam patří

Shopware je e-commerce software postavený na PHP frameworku Symfony, dostupný jako samostatně hostovaný open-source software (Community Edition) nebo jako hostovaný cloudový produkt s komerčními edicemi, které přidávají funkce jako pokročilé B2B nástroje a cenotvorbu založenou na pravidlech. Shopware 6 je aktuální generace, postavená na jádru schopném headless provozu s oddělenou vrstvou výlohy a administrace, která nahradila starší, strukturně odlišný Shopware 5.

Protože Shopware zpřístupňuje Store API, podporuje vedle vlastní výchozí výlohy i headless a composable nastavení, což hraje roli u migrací, kde se frontend a backend řeší odděleně. Výlohy na standardní cestě používají vlastní systém šablon Shopware postavený na Twig, s pluginy a šablonami dostupnými přes Shopware Store.

#### Produkty, prodejní kanály a datový model

Shopware organizuje produkty pomocí „vlastností“ a konfigurátorových skupin pro varianty, uvnitř nativního stromu kategorií, a používá „prodejní kanály“ ke správě různých výloh nebo prezentací značky z jednoho backendu — koncept strukturně odlišný od toho, jak platformy s jedinou výlohou řeší nastavení pro více značek. Tento model prodejních kanálů je jedna z prvních věcí, které mapujeme, když obchodník provozuje více souvisejících obchodů z jedné instalace Shopware.

Cenotvorba založená na pravidlech, tedy odlišné ceny nebo akce spouštěné podle skupiny zákazníků, obsahu košíku nebo jiných podmínek, je funkce Shopware, na kterou stojí za to upozornit hned na začátku migrace, protože ne každá cílová platforma modeluje podmíněné ceny stejně. Data zákazníků a objednávek žijí ve vlastní databázové struktuře Shopware a u samostatně hostovaných instalací je často k dispozici přímý přístup k databázi, což může některé exporty zjednodušit, ale i tak je třeba nejdřív identifikovat jakákoli pole přidaná vlastními pluginy, než se spolehneme, že standardní export zachytí úplně vše.

#### Pluginy, šablony a co se nepřenese automaticky

Fungující obchod na Shopware se obvykle spoléhá na pluginy ze Shopware Store — na platby, dopravu, marketing nebo B2B funkce, které nejsou součástí jádra Shopware. Data a konfigurace pluginů se při migraci platformy automaticky nepřenášejí; odchod ze Shopware znamená zkontrolovat, co každý plugin ukládá, a exportovat to zvlášť, a příchod na Shopware znamená nainstalovat a nastavit ekvivalenty přes Shopware Store nebo zakázkový vývoj.

Šablony Shopware postavené na Twig jsou specifické pro jeho šablonovací systém a nepřenášejí se jinam, takže odchod ze Shopware obvykle znamená znovu postavit design výlohy na nové platformě, a příchod na Shopware znamená upravit šablonu ze Store nebo vytvořit vlastní. Migrace týkající se Shopware 5, který používá jinou podkladovou architekturu než Shopware 6, je třeba posuzovat jako samostatný případ, ne předpokládat, že fungují stejně jako migrace Shopware 6.

#### SEO, URL adresy a jak řešíme migraci Shopware

Shopware podporuje konfigurovatelné šablony SEO URL adres pro produkty, kategorie a další stránky, které lze přizpůsobit podle prodejního kanálu, ale skutečně používané vzory URL se obchod od obchodu liší podle toho, jak byly nastaveny. Odchod ze Shopware znamená zkontrolovat živou konfiguraci URL, ne předpokládat výchozí vzor.

V rámci řízené migrace zkontrolujeme vaše stávající nastavení URL ve Shopware (nebo naplánujeme cílové, pokud na Shopware přecházíte), sestavíme mapu přesměrování mezi starými a novými URL adresami podle prodejního kanálu, pokud je to relevantní, a přeneseme metadata, která jsou stále platná — stejným postupem, jaký popisujeme u služby SEO a migrace přesměrování, aplikovaným na konkrétní směrování a strukturu prodejních kanálů Shopware.

#### FAQ

Q: Záleží na tom, jestli mám Shopware 5, nebo Shopware 6?
A: Ano, a to podstatně. Shopware 6 má jinou podkladovou architekturu, systém pluginů i strukturu šablon než Shopware 5, takže migrace z každé verze řešíme jako odlišný případ, ne s předpokladem, že platí stejný přístup.

Q: Je Shopware zdarma?
A: Community Edition Shopware je open-source a zdarma k samostatnému hostování. Komerční edice a možnost cloudového hostingu přidávají licenční nebo předplatné náklady spolu s dalšími funkcemi, jako jsou pokročilé B2B nástroje.

Q: Jak prodejní kanály Shopware ovlivňují migraci?
A: Pokud provozujete více výloh nebo značek přes funkci prodejních kanálů Shopware, mapujeme každý kanál zvlášť, ne instalaci jako jeden plochý obchod, protože cílové platformy nemodelují nastavení více kanálů vždy stejně.

Q: Umíte migrovat mé pluginy Shopware a jejich data?
A: Migrujeme základní data obchodu, na kterých plugin stojí, ale nastavení a uložené záznamy specifické pro daný plugin je obvykle třeba získat samostatným exportem z tohoto pluginu nebo je znovu vybudovat pomocí ekvivalentu na cílové platformě.

Sources:
- Shopware – oficiální web: https://www.shopware.com

### Migrace na WooCommerce a z WooCommerce

URL: https://prevedshop.com/cs/platformy/woocommerce
Language: cs
Last reviewed: 2026-07-21

WooCommerce není platforma ve stejném smyslu jako hostovaný SaaS nástroj. Je to zdarma dostupný plugin, který ze samostatně hostovaného webu WordPress udělá obchod, takže migrace WooCommerce je ve skutečnosti migrace WordPressu spolu s databází. Tento rozdíl mění, co se vlastně musí přenést, a je to první věc, kterou u projektu WooCommerce na obou stranách řešíme.

#### Co je WooCommerce a kdo ho provozuje

WooCommerce je open-source plugin pro e-commerce určený pro WordPress, vyvíjený a udržovaný společností Automattic. Protože jde o samostatně hostované řešení, za server, verzi PHP, zálohy a aktualizace zodpovídáte vy (nebo váš poskytovatel hostingu). Neexistuje jediný dodavatel, který by řídil dostupnost tak, jako je to u SaaS platformy — to dává více kontroly, ale i více odpovědnosti za údržbu.

Oblíbený je u obchodníků, kteří už na WordPressu provozují obsah, nebo kteří chtějí plnou kontrolu nad hostingem, pluginy a kódem. Stejná flexibilita je také důvod, proč se obchody na WooCommerce enormně liší složitostí: štíhlý katalog s pár pluginy je zcela jiná migrace než silně upravená instalace s desítkami vzájemně provázaných pluginů.

#### Datový model: produkty jako obsah WordPressu

WooCommerce ukládá produkty jako vlastní typ obsahu WordPressu, přičemž varianty, atributy a ceny jsou uložené v souvisejících tabulkách a metadatech příspěvků, ne ve vyhrazeném e-commerce schématu. Kategorie a štítky využívají taxonomický systém WordPressu. V rámci WordPressu to funguje dobře, ale znamená to, že migrace do WooCommerce nezahrnuje mapování zdrojových dat jen na „produkty“, ale konkrétně na obsahový model WordPressu, a migrace z WooCommerce znamená extrakci e-commerce dat, která jsou prolnutá s obecným obsahem WordPressu.

Uložení objednávek závisí na verzi a konfiguraci WooCommerce: starší obchody používají příspěvky a metadata WordPressu, zatímco High-Performance Order Storage může ukládat objednávky a adresy do vyhrazených tabulek. Zákazníci zůstávají navázaní na uživatele WordPressu a rozšíření mohou přidávat další tabulky. Zda lze historii převést jako editovatelné objednávky, nebo jen jako referenční data, závisí na cílové platformě a metodě importu; před mapováním je proto nutná inventura zdrojového schématu.

#### Pluginy, šablony a kde žije vlastní logika

Fungující obchod na WooCommerce se běžně spoléhá na několik pluginů nad rámec samotného WooCommerce — na pravidla dopravy, platební brány, předplatné nebo vlastní pole přes nástroje jako Advanced Custom Fields. Data specifická pro plugin obvykle nemají přenositelný formát exportu, takže migrace z WooCommerce znamená zjistit, co každý plugin skutečně ukládá a zda má cílová platforma ekvivalent.

Šablony jsou šablony WordPressu, často spárované s page-buildery (Elementor, WPBakery a podobné), které ukládají data rozvržení způsobem, jenž se mimo WordPress nepřevádí. Odchod z WooCommerce obvykle znamená znovu postavit design výlohy na nové platformě, ne ho exportovat.

#### SEO, URL adresy a jak řešíme migraci WooCommerce

Strukturu URL adres WooCommerce řídí nastavení trvalých odkazů (permalinks) ve WordPressu, takže je flexibilní — ale právě tato flexibilita znamená, že URL adresy každého webu na WooCommerce jsou nastavené trochu jinak a neexistuje jediný pevný vzor, proti kterému by se dalo migrovat, jako je tomu u některých SaaS platforem. Oblíbené SEO pluginy (Yoast, Rank Math) navíc ukládají metadata a přesměrování ve vlastních tabulkách, což je třeba řešit odděleně od základních dat WooCommerce/WordPress.

V rámci řízené migrace namapujeme vaši skutečnou strukturu trvalých odkazů, ne předpokládaný výchozí stav, na vzor URL cílové platformy, natáhneme metadata z toho, jaký SEO plugin právě používáte, a nastavíme přesměrování, aby stávající pozice ve vyhledávání i příchozí odkazy dál fungovaly. Jak to funguje obecně, popisuje naše služba SEO a migrace přesměrování.

#### FAQ

Q: Zahrnují data WooCommerce i můj obsah WordPressu?
A: Jen to, o co nás požádáte. WooCommerce a obecný obsah WordPressu (příspěvky na blogu, stránky) žijí ve stejné databázi, takže před začátkem migrace přesně vymezíme, co se počítá jako „data obchodu“ a co jako obsah webu.

Q: Umíte migrovat obchod na WooCommerce s velkým množstvím vlastních pluginů?
A: Ano, ale vyžaduje to více času na posouzení. Zjistíme, co každý plugin skutečně ukládá a zda to má na nové platformě obdobu, nebo je třeba to postavit znovu od začátku.

Q: Co se stane s mými SEO daty z Yoast nebo Rank Math, když odejdu z WooCommerce?
A: Vytáhneme metadata a přesměrování, která tyto pluginy ukládají, a přeneseme to, co je stále platné, do odpovídajících polí na nové platformě, místo abychom vaše SEO metadata začínali od nuly.

Q: Můžu migrovat na WooCommerce ze SaaS platformy?
A: Ano, tohle je běžný směr, když obchodníci chtějí více kontroly nad hostingem a kódem. Namapujeme váš zdrojový katalog na model typů obsahu WordPressu a podle toho nastavíme WooCommerce.

Sources:
- WooCommerce – oficiální web: https://woocommerce.com

### Migration routes

### Migrace z Magenta na BigCommerce

URL: https://prevedshop.com/cs/migrace/magento-na-bigcommerce
Language: cs
Last reviewed: 2026-07-21
Route: adobe-commerce -> bigcommerce

Přechod z Adobe Commerce nebo Magento Open Source na BigCommerce znamená vyměnit samostatně hostovanou, na kódu založenou platformu za spravovanou SaaS platformu — v duchu podobně jako přechod na Shopify, ale s jinou sadou kompromisů. BigCommerce nativně podporuje více kombinací variant produktů a dává vám větší kontrolu nad strukturou URL adres než mnoho SaaS konkurentů, což z něj může udělat strukturně bližší volbu pro složitý katalog z Magenta — hosting, rozšíření a víceobchodové nastavení je ale i tak třeba znovu záměrně vybudovat, ne jen hromadně exportovat.

#### Proč obchodníci odcházejí z Magenta

Magento Open Source a Adobe Commerce dávají plnou kontrolu nad kódem, hostingem i pokladnou za cenu toho, že si tuto infrastrukturu musíte spravovat sami: bezpečnostní záplaty PHP a Magenta, server nebo cloudový hosting a shodu s PCI pro pokladnu, kterou hostujete. BigCommerce jako spravovaná SaaS platforma sejme vašemu týmu z beder hosting, shodu s PCI i bezpečnostní záplaty platformy výměnou za práci v rámci omezení dané platformy místo libovolného kódu.

Častým spouštěčem je totéž, co tlačí obchodníky směrem k Shopify: náklady na udržování vývojáře nebo agentury pro správu instance Magenta přestanou dávat smysl, jakmile růst obchodu už tuto zátěž neodůvodňuje — zvlášť u obchodů stále běžících na nezáplatované instanci Magenta 2 nebo přetrvávajících na Magentu 1 po konci životnosti.

#### Co se mění v datovém modelu

Katalogová struktura Magenta EAV (entity-attribut-hodnota) umožňuje definovat pro každý typ produktu prakticky libovolné vlastní atributy. Produktový model BigCommerce je strukturovanější než u Magenta, ale obecně flexibilnější v otázce variant než konkurenční SaaS platformy — nativně podporuje větší počet kombinací variant produktů, plus vlastní pole a modifikátory produktů pro atributy mimo strukturu variant. I tak je ale třeba sady atributů z Magenta záměrně namapovat na možnosti variant a vlastní pole BigCommerce, ne je kopírovat atribut po atributu.

Strom kategorií v Magentu umožňuje libovolné vnořování s nastavením zobrazení podle pohledu obchodu a produkt může patřit do mnoha kategorií najednou. Kategorie na BigCommerce jsou blíž tradičnímu stromu než plochý model kolekcí na Shopify, což dělá migraci hluboce vnořené struktury kategorií z Magenta o něco přímočařejší — přesto by se měla zkontrolovat a zjednodušit tam, kde struktura v Magentu rostla organicky roky, ne podle záměru.

#### URL adresy, přesměrování a čím se to tu liší od Shopify

Klíče URL adres a přepisy v Magentu jsou plně konfigurovatelné podle pohledu obchodu. BigCommerce na rozdíl od Shopify umožňuje vlastní cesty URL adres pro produkty, kategorie a stránky bez vynucené předpony `/products/` nebo `/collections/` — což může usnadnit zachování stávající struktury URL adres z Magenta. To ale neodstraňuje potřebu plánu přesměrování: každá URL adresa, která se přece jen změní, stále potřebuje výslovné přesměrování 301, a audit každé indexované URL adresy z Magenta proti jejímu novému protějšku na BigCommerce je třeba udělat tak jako tak, aby nedošlo k propadu pozic po migraci.

#### Rozšíření, pokladna a více výloh

Ekosystém rozšíření Magenta a jeho schopnost upravit pokladnu i administrativní procesy přímo v kódu nemají na BigCommerce přímou obdobu — BigCommerce používá tržiště aplikací plus vlastní API a přizpůsobení výlohy přes Stencil/Catalyst pro vlastní logiku. U každého aktivního rozšíření Magenta je třeba během posouzení výslovně rozhodnout: ekvivalentní aplikace na BigCommerce, zakázková stavba na API BigCommerce, nebo potvrzení, že už není potřeba. Model více webů/obchodů v Magentu je také třeba namapovat na možnosti více výloh BigCommerce, které fungují pod kapotou jinak, i když výsledek může vypadat podobně.

#### FAQ

Q: Zvládne BigCommerce vlastní produktové atributy z Magenta?
A: Kombinací možností variant a vlastních polí, ale BigCommerce nemá automatickou obdobu sad atributů EAV z Magenta. Vaše skutečné využití atributů namapujeme během posouzení, ne migrací každého atributu, který Magento náhodou má definovaný.

Q: Je migrace URL adres z Magenta na BigCommerce jednodušší než na Shopify?
A: Často o něco ano, protože BigCommerce umožňuje vlastní cesty URL adres bez povinné předpony, na rozdíl od pevné struktury Shopify. To snižuje počet URL adres, které se musí změnit, ale každá, která se přece jen změní, stále potřebuje výslovné přesměrování 301 — audit je třeba provést tak jako tak.

Q: Co se stane s mými rozšířeními a vlastními moduly z Magenta?
A: Každé se vyhodnotí zvlášť během posouzení: nahrazení existující aplikací na BigCommerce, přestavba na API BigCommerce, nebo potvrzení, že už není potřeba. Tento seznam vytváříme dřív, než stanovíme rozsah projektu, ne až po něm.

Q: Můžu si zachovat provoz více obchodů nebo webů?
A: Model více webů v Magentu se nepřevádí přímo na architekturu BigCommerce, i když BigCommerce také podporuje více výloh. Váš skutečný požadavek — samostatné značky, regiony nebo měny — namapujeme na správnou strukturu BigCommerce, ne s předpokladem přímého převodu jedna ku jedné.

Sources:
- Oficiální web a dokumentace BigCommerce: https://www.bigcommerce.com
- Dokumentace Adobe Commerce / Magento Open Source: https://experienceleague.adobe.com/en/docs/commerce

### Migrace z Magenta na Shopify

URL: https://prevedshop.com/cs/migrace/magento-na-shopify
Language: cs
Last reviewed: 2026-07-21
Route: adobe-commerce -> shopify

Přechod z Adobe Commerce nebo Magento Open Source na Shopify znamená vyměnit samostatně hostovanou, vysoce přizpůsobitelnou platformu na PHP za spravovanou SaaS platformu. Tato výměna vám sejme z beder údržbu serveru, verzí PHP a shodu s PCI, ale zároveň znamená, že datový model katalogu, strukturu URL adres a většinu rozšíření je třeba znovu vybudovat, ne jen zkopírovat. Uděláno záměrně je to dobře zvládnutelný krok; uděláno jako holý export/import je to přesně místo, kde se tiše rozbije SEO a vlastní logika obchodu.

#### Proč obchodníci odcházejí z Magenta

Magento Open Source a Adobe Commerce vám dávají plnou kontrolu nad kódem, hostingem i pokladnou — a právě proto je jejich provoz nákladný. Někdo musí instalovat bezpečnostní aktualizace PHP a Magenta, spravovat server nebo cloudovou infrastrukturu a udržovat shodu s PCI pro pokladnu, kterou hostujete sami. Shopify vašemu týmu sejme z beder hosting, shodu s PCI i bezpečnostní záplaty platformy výměnou za méně kontroly na nízké úrovni.

Častým spouštěčem je situace, kdy průběžné náklady na vývojáře nebo agenturu udržující instanci Magenta už neodpovídají velikosti obchodu — zvlášť jakmile Magento 1 (dávno za koncem životnosti) nebo stárnoucí instalace Magenta 2 začne hromadit nezáplatovaná rozšíření.

#### Co se skutečně mění v datovém modelu

Produktový katalog Magenta je postavený na struktuře EAV (entity-attribut-hodnota), která umožňuje definovat libovolné vlastní atributy pro každý typ produktu. Produktový model Shopify je jednodušší: produkt má pevnou sadu základních polí plus až tři rozměry variantních možností (jako velikost a barva) a metapole pro cokoli dalšího. Konfigurovatelné produkty a vlastní volby Magenta se mapují na varianty a metapole Shopify, ale mapování není 1:1 — sady atributů s mnoha vlastními atributy obvykle potřebují záměrně navržené schéma metapolí, ne automatický převod atribut po atributu.

Další skutečný rozdíl jsou kategorie: Magento umožňuje libovolně hluboké vnořování kategorií a přiřazení produktu do mnoha z nich s odlišným nastavením zobrazení podle pohledu obchodu. Kolekce na Shopify jsou plošší — ruční nebo pravidly řízené („chytré“) seznamy, ne skutečný strom kategorií — takže hluboce vnořený katalog z Magenta vyžaduje záměrně navrženou strukturu kolekcí, ne přímý export.

#### URL adresy, přesměrování a co se rozbije potichu

Klíče URL adres a přepisy v Magentu jsou plně konfigurovatelné podle pohledu obchodu. Shopify vynucuje vlastní vzory URL adres (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`, `/blogs/{blog}/{handle}`), které nelze libovolně přestavět. To znamená, že každá indexovaná URL adresa z Magenta potřebuje výslovné přesměrování na svůj protějšek na Shopify — to je jednoznačně nejčastější zdroj propadu pozic ve vyhledávání po migraci, a je mu úplně možné se vyhnout pořádnou mapou URL adres postavenou před spuštěním, ne záplatovanou až poté, co si Google všimne chyb 404.

#### Rozšíření, úpravy pokladny a víceobchodový provoz

Ekosystém rozšíření Magenta a jeho schopnost upravit pokladnu, cenová pravidla i administrativní procesy přímo v kódu nemají na Shopify přímou obdobu — Shopify používá App Store a na Shopify Plus navíc Checkout Extensibility a Shopify Functions pro vlastní logiku pokladny. U každého vlastního modulu Magenta je třeba výslovně rozhodnout: existuje ekvivalentní aplikace, je potřeba postavit vlastní aplikaci na API Shopify, nebo se funkce úplně vypustí. Totéž platí pro nastavení více webů/obchodů v Magentu, které se nepřevádí přímo na model Shopify s jedním obchodem plus Markets pro mezinárodní prodej.

Náš proces řízené migrace toto zmapuje už během posouzení — katalogizujeme vaše aktivní rozšíření a vlastní moduly dřív, než dáme nabídku na práci, ne až v průběhu migrace.

#### FAQ

Q: Zvládne Shopify vlastní produktové atributy z Magenta?
A: Ano, přes metapole, ale je třeba je záměrně definovat a namapovat — Shopify nemá automatickou obdobu sad atributů EAV z Magenta. Vaše skutečné využití atributů namapujeme během posouzení, ne migrací každého atributu, který Magento náhodou má definovaný.

Q: Přesměrují se mé URL adresy z Magenta automaticky?
A: Ne. Struktura URL adres na Shopify je pevná, takže každá relevantní URL adresa z Magenta potřebuje výslovné přesměrování 301 na svůj nový protějšek na Shopify. To je jádro plánu migrace, ne volitelný doplněk — viz naše služba SEO a migrace přesměrování.

Q: Co se stane s mými rozšířeními a vlastními moduly z Magenta?
A: Každé se vyhodnotí zvlášť během posouzení: nahrazení existující aplikací na Shopify, přestavba na vlastní aplikaci nebo úpravu šablony, nebo potvrzení, že už není potřeba. Tento seznam vytváříme dřív, než stanovíme rozsah projektu, ne až po něm.

Q: Můžu si zachovat provoz více obchodů nebo webů?
A: Model více webů v Magentu se nepřevádí přímo na Shopify. V závislosti na tom, co skutečně potřebujete — samostatné značky, samostatné regiony, samostatné měny —, může být správným řešením na Shopify funkce Markets, druhý obchod, nebo Shopify Plus Organization. Pomůžeme vám vybrat na základě skutečného požadavku, ne obecné odpovědi.

Sources:
- Shopify – Migrace obchodu na Shopify: https://www.shopify.com/migrate
- Dokumentace Adobe Commerce / Magento Open Source: https://experienceleague.adobe.com/en/docs/commerce

### Migrace z Magenta (Adobe Commerce) na Shoptet

URL: https://prevedshop.com/cs/migrace/magento-na-shoptet
Language: cs
Last reviewed: 2026-09-02
Route: adobe-commerce -> shoptet

Magento a Adobe Commerce jsou stavěné pro složité katalogy, více store views a rozsáhlé úpravy, za cenu drahého hostingu a vývoje. Shoptet je hostovaná platforma pro české a slovenské obchodníky s jednodušším pevným datovým modelem a vestavěnými místními integracemi. Migrace je hlavně konsolidace: zredukovat sady atributů, konfigurovatelné produkty, store views a vlastní moduly Magenta na to, co Shoptet umí reprezentovat, přenést zákazníky a historii objednávek a ochránit URL, které přinášejí organickou návštěvnost.

#### Kdo přechází z Magenta na Shoptet a proč

Obchodníci tento krok dělají, když se Magento stalo neúměrným velikosti byznysu: středně velký český nebo slovenský obchod platí hosting Magenta, bezpečnostní záplaty, licence rozšíření a hodiny agentury, které už nepotřebuje. Shoptet to nahrazuje měsíčním tarifem, nativními integracemi Zásilkovny, PPL, GoPay, Comgate, Heureky a Zboží.cz a spravovaným prostředím. Daní je hloubka: žádné sady atributů, žádná hierarchie více webů, žádná libovolná rozšíření. Pokud na nich váš byznys stojí, posouzení to řekne dřív, než začne jakákoli práce.

#### Sady atributů, konfigurovatelné produkty a kategorie

Sady atributů Magenta se stávají jedinou plochou sadou parametrů Shoptetu, překrývající se atributy z různých sad je proto nutné sloučit a konzistentně přejmenovat. Konfigurovatelné produkty se mapují na produkty Shoptetu s variantami; jednoduché podřízené produkty se stávají řádky variant s vlastními kódy, cenami a skladem. Bundle a grouped produkty nemají přímý ekvivalent a přestavují se jako samostatné produkty nebo sady. Stromy kategorií se přenášejí, anchor kategorie a vrstvenou navigaci Magenta ale nahrazují kategorie a parametrické filtry Shoptetu, což obvykle znamená zploštění hierarchie.

#### Store views, zákazníci a objednávky

Store views Magenta se často používají pro jazyky nebo značky. Shoptet podporuje jazykové mutace v rámci obchodu, ne nezávislé weby, každý store view proto potřebuje rozhodnutí: sloučit do jednoho Shoptetu, provozovat více obchodů na Shoptetu, nebo vypustit. Zákazníci a adresy se importují, skupiny zákazníků se mapují na cenové hladiny Shoptetu a hesla se v novém obchodě obnoví. Historie objednávek se importuje pro reporting. Vlastní moduly, konektory na ERP a B2B funkce se sepíší jednotlivě a přiřadí k nativním funkcím, doplňkům nebo vlastní integraci.

#### Přesměrování a přepnutí

URL rewrites Magenta a cesty kategorií v URL produktů se liší od vzorů Shoptetu, proto exportujeme všechny indexované URL, sestavíme kompletní mapu 301 a nahrajeme ji do Shoptetu před přepnutím DNS. Testovací import celého katalogu kontrolujeme na ceny, DPH, sklad a varianty, poté se znovu vygenerují feedy a odešle sitemapa. Přesměrování chrání kontinuitu URL a snižuje riziko; pozice žádná migrace negarantuje.

#### FAQ

Q: Lze konfigurovatelné produkty Magenta migrovat na Shoptet?
A: Ano. Každý konfigurovatelný produkt se stane produktem Shoptetu s variantami a jednoduché podřízené produkty se stanou řádky variant s vlastním kódem, cenou a skladem.

Q: Co se stane se sadami atributů Magenta?
A: Shoptet má jeden plochý seznam parametrů, sady atributů se proto sloučí. Duplicitní nebo konfliktní názvy atributů se před importem vyčistí a přejmenují.

Q: Jak se řeší store views Magenta?
A: O každém store view se rozhoduje zvlášť: sloučit do jednoho Shoptetu, provozovat více obchodů na Shoptetu, nebo vypustit. Shoptet podporuje jazykové mutace, ne nezávislé weby.

Q: Zůstanou mi zákazníci a historie objednávek?
A: Zákazníci, adresy a skupinové ceny se importují; hesla se obnoví. Objednávky se importují jako historie pro reporting, ne jako editovatelné živé objednávky.

Sources:
- Adobe Commerce - Přenos dat (import a export): https://experienceleague.adobe.com/en/docs/commerce-admin/systems/data-transfer/data-transfer
- Shoptet Developers - Import dat: https://developers.shoptet.com/shoptet-tools/data-import/

### Migrace z OpenCart na Shopify

URL: https://prevedshop.com/cs/migrace/opencart-na-shopify
Language: cs
Last reviewed: 2026-07-21
Route: opencart -> shopify

OpenCart je odlehčená, samostatně hostovaná, open-source platforma — jednodušší na provoz než Magento nebo PrestaShop, ale stále vyžaduje, abyste spravovali vlastní server, verzi PHP, bezpečnostní záplaty a shodu s PCI. Přechod na Shopify vyměňuje toto samostatně spravované nastavení za hostovanou, spravovanou platformu. Protože je datový model OpenCart poměrně jednoduchý, samotná migrace bývá obvykle přímočařejší než z těžší enterprise platformy, ale produktové možnosti, konfigurace multi-store a rozšíření i tak vyžadují záměrné mapování, ne holý export/import.

#### Proč obchodníci odcházejí z OpenCart

Přitažlivost OpenCart spočívá v tom, že je zdarma a odlehčený, ale to zároveň znamená, že jste sami odpovědní za hosting, bezpečnostní aktualizace, shodu s PCI a udržení kompatibility rozšíření napříč upgrady jádra. Mnoho obchodů na OpenCart provozují malé týmy bez vyhrazených vývojářů a průběžná zátěž spojená s aplikací bezpečnostních záplat a řešením konfliktů rozšíření se časem stává neúměrnou velikosti byznysu. Shopify tuto zátěž hostingu a bezpečnostních záplat odstraňuje výměnou za poplatek za spravovanou platformu.

Častým spouštěčem je ekosystém rozšíření: rozšíření OpenCart (postavená jako úpravy OCMOD nebo VQMOD) se liší kvalitou a často přestávají být udržovaná, což se stává rostoucím rizikem, jak se jádro platformy posouvá dál a stack rozšíření obchodu stárne.

#### Produktové možnosti, kategorie a datový model

OpenCart zobrazuje varianty produktů pomocí „možností“ — voleb jako velikost nebo barva připojených k produktu, z nichž každá může volitelně ovlivnit cenu a skladovou dostupnost. To je koncepčně blízké systému variant Shopify, což dělá základní mapování produktů přímočařejší než z platforem s plným modelem atributů EAV. Shopify přesto omezuje produkty na tři rozměry variantních možností, takže u produktů OpenCart s větším počtem skupin možností je třeba některé možnosti přesunout do metapolí místo variant.

Kategorie v OpenCart lze vnořovat a produkt může patřit do více kategorií, což je duchem podobné kolekcím Shopify, ale strukturně to funguje pod kapotou jinak — strom kategorií OpenCart se nemapuje jedna ku jedné na model ručních/chytrých kolekcí Shopify, takže strukturu kolekcí je obvykle třeba naplánovat, ne ji hromadně zkopírovat.

#### Multi-store, URL adresy a rozšíření

OpenCart podporuje provoz více výloh z jedné instalace, sdílejících jednu administraci a jeden produktový katalog napříč obchody s odlišným nastavením. Nejbližší obdobou na Shopify je funkce Markets pro regionální/měnovou variaci v rámci jednoho obchodu, nebo skutečně samostatné obchody na Shopify pro odlišné značky — ani jedno není přímou architektonickou obdobou, takže to, který přístup se hodí, závisí na tom, k čemu se nastavení více obchodů skutečně používá.

Nastavení SEO přívětivých URL v OpenCart je konfigurovatelné podle obchodu, takže relevantní indexované adresy je třeba namapovat na pevné vzory Shopify (`/products/{handle}`, `/collections/{handle}`) a při změně přesměrovat. Tím se snižuje zbytečné riziko ztráty viditelnosti, nelze však slíbit nezměněné pozice. Rozšíření OpenCart pro dopravu, platby nebo úpravy katalogu je také třeba vyhodnotit jednotlivě — náhrada aplikací na Shopify, zakázková stavba, nebo potvrzení, že už nejsou potřeba — během posouzení.

#### FAQ

Q: Mapuje se systém produktových možností z OpenCart čistě na varianty Shopify?
A: Čistěji než z platforem s plným modelem vlastních atributů, protože možnosti v OpenCart jsou koncepčně už blízko variantám Shopify. Produkty s víc než třemi skupinami možností potřebují některé možnosti namapovat na metapole Shopify místo variant.

Q: Co se stane s mým nastavením multi-store z OpenCart?
A: Na Shopify neexistuje přímá obdoba jedna ku jedné. V závislosti na tom, zda potřebujete sdílený katalog s regionální variací, nebo skutečně samostatné značky, vám pomůžeme vybrat mezi Shopify Markets a samostatnými obchody na Shopify podle vašich skutečných požadavků.

Q: Přesměrují se mé URL adresy z OpenCart automaticky?
A: Ne. Struktura URL adres na Shopify je pevná, takže každá indexovaná URL adresa z OpenCart potřebuje výslovné přesměrování 301 na svůj protějšek na Shopify — to plánujeme jako součást migrace, ne až po spuštění.

Q: Co se stane s mými rozšířeními z OpenCart?
A: Každé aktivní rozšíření se během posouzení vyhodnotí zvlášť: nahrazení aplikací na Shopify, přestavba na vlastní aplikaci nebo úpravu šablony, nebo vypuštění, pokud už není potřeba. Toto zjistíme dřív, než stanovíme rozsah projektu.

Sources:
- Shopify – Migrace obchodu na Shopify: https://www.shopify.com/migrate
- Oficiální web a dokumentace OpenCart: https://www.opencart.com

### Migrace z PrestaShopu na Shopify

URL: https://prevedshop.com/cs/migrace/prestashop-na-shopify
Language: cs
Last reviewed: 2026-07-21
Route: prestashop -> shopify

PrestaShop je samostatně hostovaná, open-source platforma oblíbená v celé Evropě, postavená na nativní podpoře více jazyků a měn a flexibilním systému „kombinací“ pro varianty produktů. Přechod na Shopify znamená vzdát se přímého přístupu k serveru a databázi výměnou za spravovaný hosting a shodu s PCI a znamená přehodnotit několik věcí, které PrestaShop řeší nativně — multistore, vícejazyčný obsah a kombinace produktů — v pojmech Shopify, ne s předpokladem přímého exportu jedna ku jedné.

#### Proč obchodníci odcházejí z PrestaShopu

Jako samostatně hostovaná platforma klade PrestaShop na váš tým správu serveru, upgrady verzí PHP, kompatibilitu modulů a shodu s PCI pro pokladnu. To je zvládnutelné u obchodu s vyhrazenými technickými kapacitami, ale stává se to skutečným nákladem — čas vývojáře, hosting, bezpečnostní záplaty — jakmile obchod běží s omezenými zdroji. Shopify na sebe bere hosting, shodu s PCI i bezpečnostní záplaty platformy výměnou za nižší kontrolu na nízké úrovni a předvídatelnou režii spravované platformy.

Častým spouštěčem je ekosystém modulů: moduly PrestaShopu se hodně liší kvalitou i mírou údržby, a obchod budovaný roky často nese několik modulů, které už nejsou aktivně podporované — což se stává rostoucím rizikem, jak se samotný PrestaShop posouvá dál.

#### Kombinace, kategorie a datový model

Produkty v PrestaShopu používají systém „kombinací“ — atributy jako velikost nebo barva generují řádky kombinací a PrestaShop klade jen málo pevných limitů na to, kolik atributů nebo kombinací může produkt mít. Model variant Shopify je omezenější: až tři rozměry možností na produkt, s metapoli dostupnými pro atributy, které se do modelu variant nevejdou. Produkty s mnoha kombinacemi atributů z PrestaShopu, nebo atributy používanými spíš jako popisná data než skutečné varianty, potřebují záměrný plán metapolí, ne přímé kopírování atribut po atributu.

Strom kategorií v PrestaShopu, podobně jako v Magentu, umožňuje libovolné vnořování a přiřazení produktu do více kategorií. Kolekce na Shopify jsou plošší — ruční nebo pravidly řízené seznamy — takže hluboce vnořený katalog z PrestaShopu potřebuje pro dobré fungování na Shopify přepracovanou strukturu kolekcí, ne doslovný export kategorií.

#### Multistore, více jazyků a více měn

Funkci multistore a nativní podporu více jazyků a měn v PrestaShopu běžně využívají obchodníci z EU prodávající na několika trzích z jedné instalace. Nejbližší obdobou na Shopify je funkce Markets pro variace měny, jazyka a regionální výlohy, nebo v některých případech samostatný obchod na Shopify pro každou značku či region. Ani jedno není přímou architektonickou obdobou multistore PrestaShopu, takže správný přístup závisí na tom, co obchod skutečně potřebuje — jednu výlohu obsluhující několik trhů, nebo skutečně samostatné výlohy — a toto rozhodnutí by mělo padnout záměrně dřív, než se stanoví rozsah migrace.

#### URL adresy, přesměrování a moduly

Nastavení přívětivých URL adres v PrestaShopu je konfigurovatelné, takže se stávající URL jen zřídka bez úprav shodují s pevnými vzory Shopify (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`). Každá relevantní indexovaná URL potřebuje výslovný cíl a při změně adresy přesměrování 301, které zachová kontinuitu URL a sníží zbytečné riziko ztráty organické viditelnosti.

Moduly PrestaShopu pro dopravu, platby, marketing a úpravy pokladny nemají na Shopify automatickou obdobu. U každého aktivního modulu je během posouzení třeba výslovně rozhodnout — nahradit aplikací na Shopify, přestavět jako vlastní aplikaci nebo úpravu šablony, nebo vypustit —, takže rozsah migrace je znám dřív, než práce začne, ne až se zjistí v jejím průběhu.

#### FAQ

Q: Zvládne Shopify kombinace produktů z PrestaShopu?
A: Standardní kombinace se mapují na varianty Shopify, ale Shopify omezuje produkty na tři rozměry variantních možností. Kombinace nad tento rámec, nebo atributy používané spíš jako popisná data, je třeba během posouzení záměrně namapovat na metapole.

Q: Co se stane s mým nastavením multistore z PrestaShopu?
A: Na Shopify neexistuje přímá architektonická obdoba. V závislosti na tom, zda potřebujete sdílený katalog s regionální variací, nebo skutečně samostatné značky, vám pomůžeme vybrat mezi Shopify Markets a samostatnými obchody podle vašich skutečných požadavků.

Q: Přesměrují se mé URL adresy z PrestaShopu na Shopify automaticky?
A: Ne. Shopify vynucuje vlastní strukturu URL adres, takže každá relevantní URL adresa z PrestaShopu potřebuje výslovné přesměrování 301 namapované na svůj protějšek na Shopify — to je jádro plánu migrace, ne volitelný doplněk.

Q: Co se stane s mými moduly z PrestaShopu?
A: Každý se vyhodnotí zvlášť: nahrazení existující aplikací na Shopify, přestavba na vlastní aplikaci nebo úpravu šablony, nebo potvrzení, že už není potřeba. Tento seznam vytváříme během posouzení, dřív než se stanoví rozsah projektu.

Sources:
- Shopify – Migrace obchodu na Shopify: https://www.shopify.com/migrate
- Oficiální web a dokumentace PrestaShop: https://www.prestashop.com

### Migrace z PrestaShopu na Shoptet

URL: https://prevedshop.com/cs/migrace/prestashop-na-shoptet
Language: cs
Last reviewed: 2026-09-02
Route: prestashop -> shoptet

PrestaShop je open-source platforma, kterou si hostujete a spravujete sami; Shoptet je hostovaný systém pro české a slovenské obchodníky s vestavěnou dopravou, platbami a feedy pro srovnávače. Migrace nahrazuje kombinace, vlastnosti a data modulů PrestaShopu variantami, parametry a doplňky Shoptetu, přenáší zákazníky i historii objednávek a každou indexovanou URL přestavuje na přesměrování 301, aby přechod nezahodil roky viditelnosti ve vyhledávačích.

#### Co obchodníci z PrestaShopu získají a čeho se vzdají

Shoptet odstraňuje správu serveru, upgrady PHP a řešení kompatibility modulů. Fakturace, DPH, Zásilkovna, PPL, GoPay, Comgate, Heureka i Zboží.cz jsou nativní, což často nahradí tucet modulů PrestaShopu. Vzdáváte se neomezené customizace: v PrestaShopu jde modulem nebo override změnit cokoli, Shoptet nabízí pevnou sadu polí, šablon a doplňků. Funkce z vlastních modulů PrestaShopu je nutné znovu posoudit, ne zkopírovat.

#### Kombinace, vlastnosti a kategorie

Kombinace PrestaShopu (sady atributů jako velikost a barva) se mapují na varianty Shoptetu; každá kombinace se stává řádkem varianty s vlastním kódem, cenou a skladem. Vlastnosti PrestaShopu používané k filtrování se stávají parametry Shoptetu, které se před importem založí. Zařazení do více kategorií podporují oba systémy, výchozí kategorii PrestaShopu je ale třeba explicitně zvolit jako hlavní kategorii v Shoptetu. Obrázky, popisy, meta titulky a popisky se přenášejí importem; pravidla specifických cen a ceny pro skupiny zákazníků vyžadují revizi, protože Shoptet modeluje slevy jinak.

#### Zákazníci, objednávky a přesměrování

Zákazníci s adresami a příslušností ke skupinám se importují; hesla přenést nelze, součástí komunikace při spuštění je proto obnovení hesla. Objednávky se importují jako historie pro reporting. URL PrestaShopu závisí na nastavení přátelských adres a často obsahují ID; Shoptet používá vlastní vzory cest, proto z sitemapy PrestaShopu a dat analytiky vytvoříme kompletní mapu 301 a před přepnutím DNS ji ověříme. Přesměrování chrání kontinuitu URL a snižuje riziko; pozice nejsou nikdy garantované.

#### Moduly, feedy a spuštění

Sepíšeme každý aktivní modul PrestaShopu a rozhodneme: nativní v Shoptetu, dostupné jako doplněk, vlastní integrace, nebo vypuštěno. Feedy pro srovnávače se znovu vygenerují ze Shoptetu. Samotné spuštění je testovací import, kontrola vzorku cen, DPH a skladu a pak přepnutí DNS, přičemž PrestaShop zůstane krátce jen pro čtení, dokud se mapa přesměrování nepotvrdí v Google Search Console.

#### FAQ

Q: Stanou se z kombinací PrestaShopu varianty Shoptetu?
A: Ano. Každá kombinace se stane variantou s vlastním kódem, cenou a skladem; skupiny atributů se stanou rozměry variant. Nekonzistentní pojmenování atributů v PrestaShopu se před importem vyčistí.

Q: Mohu si ponechat historii objednávek z PrestaShopu?
A: Objednávky se importují jako historie pro přehled a reporting. Nejsou to editovatelné živé objednávky a faktury zůstávají ve vašem účetním systému.

Q: Budou moduly PrestaShopu fungovat na Shoptetu?
A: Žádný modul se nepřenáší přímo. Každý namapujeme na nativní funkci Shoptetu, doplněk nebo vlastní integraci a ty nepotřebné vypustíme.

Q: Jak řešíte URL PrestaShopu s ID produktů?
A: Každá indexovaná URL dostane explicitní přesměrování 301 na ekvivalent v Shoptetu, vygenerované ze sitemapy a analytiky a ověřené před spuštěním.

Sources:
- PrestaShop - Dokumentace webservice: https://devdocs.prestashop-project.org/9/webservice/
- Shoptet Developers - Import dat: https://developers.shoptet.com/shoptet-tools/data-import/

### Migrace ze Shopify na WooCommerce

URL: https://prevedshop.com/cs/migrace/shopify-na-woocommerce
Language: cs
Last reviewed: 2026-09-02
Route: shopify -> woocommerce

Většina návodů popisuje jen přechod na Shopify. Opačný směr je stejně častý, když chce obchod plné vlastnictví dat, obsahově bohatý web na WordPressu nebo se zbavit transakčních poplatků a předplatných aplikací. Přechod ze Shopify na WooCommerce znamená převzít odpovědnost za hosting, bezpečnost a aktualizace výměnou za otevřený datový model a neomezené úpravy. Samotná migrace zahrnuje produkty, varianty, metapole, zákazníky, historii objednávek, obsah a kompletní mapu přesměrování.

#### Proč obchody odcházejí ze Shopify

Typickými důvody jsou opakované náklady na aplikace, transakční poplatky u cizích platebních bran, obtížně upravitelný checkout a přání provozovat obchod i obsah na jedné instalaci WordPressu. WooCommerce nemá platformový poplatek a celou databázi ukládá na vašem serveru, což je důležité pro obchodníky s přísnými požadavky na umístění dat nebo rozsáhlými B2B úpravami. Druhou stranou mince je provoz: výkon hostingu, zálohy, aktualizace pluginů a rozsah PCI jsou nyní na vás nebo vaší agentuře.

#### Produkty, varianty a metapole

Produkty Shopify s až třemi rozměry možností se čistě mapují na variabilní produkty WooCommerce s atributy a variantami. Výjimkou jsou metapole: WooCommerce nemá vestavěný ekvivalent, každé metapole se proto mapuje na atribut produktu, vlastní pole nebo datovou strukturu konkrétního pluginu. Kolekce se stávají kategoriemi nebo štítky podle toho, jak byly používány; chytré kolekce založené na pravidlech je nutné znovu vytvořit jako kategorie s ručním přiřazením nebo pomocí pluginu pro filtrování. Obrázky, SKU, hmotnosti a sklad se přenášejí CSV importérem nebo přímým procesem z API do databáze.

#### Zákazníci, objednávky a obsah

Zákazníky lze importovat s adresami a marketingovým souhlasem; hesla jsou na obou platformách hashována jinak a nikdy se nepřenášejí. Historie objednávek se importuje pro reporting a zákaznický servis, stavy se mapují na ekvivalenty WooCommerce. Stránky a články ze Shopify se stávají stránkami a příspěvky WordPressu, což je obvykle posun k větší flexibilitě úprav. Slevové kódy a dárkové karty vyžadují revizi, protože kupóny WooCommerce a pluginy pro dárkové karty přesně nekopírují pravidla Shopify.

#### URL, přesměrování a spuštění

Shopify vynucuje prefixy `/products/`, `/collections/` a `/pages/`; WordPress umožňuje trvalé odkazy nastavit libovolně, což je příležitost navrhnout čistší strukturu. Každá indexovaná URL ze Shopify se musí před přesunem domény mapovat na URL WooCommerce přesměrováním 301 obsluhovaným novým webem. Mapu přesměrování, rychlost stránek a checkout testujeme na staging serveru a pak přepínáme DNS, obchod na Shopify necháváme krátce otevřený. Přesměrování zachovává kontinuitu URL a snižuje riziko; pozice zaručit nelze.

#### FAQ

Q: Lze metapole Shopify migrovat do WooCommerce?
A: Ano, ale ne automaticky. Každé metapole se mapuje na atribut WooCommerce, vlastní pole nebo strukturu pluginu, kterou vaše šablona umí zobrazit.

Q: Zůstanou zákazníkům po přechodu na WooCommerce hesla?
A: Ne. Hashe hesel jsou specifické pro platformu. Zákazníci dostanou odkaz na obnovení hesla v novém obchodě, ideálně jako součást oznámení o spuštění.

Q: Jaký hosting WooCommerce po odchodu ze Shopify potřebuje?
A: Spravovaný WordPress hosting s PHP 8, objektovou cache a denními zálohami je praktické minimum pro obchod, který dosud běžel na infrastruktuře Shopify.

Q: Přijdu odchodem ze Shopify o SEO?
A: Vzory URL se mění, proto je kompletní mapa přesměrování 301 nutná. S přesměrováním, kanonickými tagy a znovu odeslanou sitemapou se riziko snižuje, ale žádná migrace nezaručuje nezměněné pozice.

Sources:
- WooCommerce - Import a export produktů v CSV: https://woocommerce.com/document/product-csv-importer-exporter/
- Shopify Help Center - Migrace na Shopify: https://help.shopify.com/en/manual/migrating-to-shopify

### Migrace ze Shoptetu na Shopify

URL: https://prevedshop.com/cs/migrace/shoptet-na-shopify
Language: cs
Last reviewed: 2026-07-21
Route: shoptet -> shopify

Shoptet je uzavřená, hostovaná SaaS platforma zaměřená na český a slovenský trh, takže tento přechod vypadá jinak než migrace ze samostatně hostovaného řešení na SaaS: obě platformy za vás řeší hosting i shodu s PCI. Skutečnými důvody bývají obvykle dosah za hranice trhu ČR/SK, větší globální ekosystém aplikací Shopify a větší flexibilita designu díky šablonovacímu systému Liquid na Shopify. Protože je Shoptet uzavřený zdroj, přístup k datům se odvíjí od jeho exportních nástrojů a API, ne od přímého přístupu k databázi, což ovlivňuje, jak je třeba samotnou migraci naplánovat.

#### Proč obchodníci odcházejí ze Shoptetu

Shoptet je solidní, snadno provozovatelná platforma pro obchodníky z ČR/SK, ale je regionálně zaměřená — jeho tržiště aplikací, platební a dopravní integrace i nástroje pro více měn a jazyků jsou postavené primárně kolem tohoto trhu. Obchodníci expandující mimo Česko a Slovensko často shledávají, že globální ekosystém aplikací Shopify, jeho nativní nástroje pro více měn a jazyků přes Shopify Markets a širší základna integrací třetích stran lépe vyhovují přeshraničnímu růstu.

Dalším běžným důvodem je flexibilita designu: úpravy šablon ve Shoptetu jsou omezenější než šablonovací systém Shopify založený na Liquid, takže obchodníci, kteří chtějí vysoce vlastní design výlohy nebo hlubší úpravy pokladny (dostupné obchodníkům na Shopify Plus), na Shopify často najdou víc prostoru postavit přesně to, co chtějí.

#### Jak dostat data z uzavřené platformy ven

Na rozdíl od open-source platforem, kde můžete dotazovat databázi přímo, Shoptet přímý přístup k databázi neposkytuje — data o produktech, objednávkách a zákaznících musí ven přes exportní nástroje Shoptetu (exporty CSV/XML) a jeho API. To znamená, že krok extrakce dat v migraci závisí na tom, co skutečně zpřístupňují exportní nástroje a API Shoptetu, a jakákoli data, která přes tyto kanály dostupná nejsou (některá vlastní pole, historická metadata objednávek), je třeba identifikovat brzy, protože je nelze jednoduše natáhnout z databázového dumpu tak, jako u samostatně hostované platformy.

#### Produktová data, kategorie a varianty

Produktový model Shoptetu, podobně jako u většiny SaaS platforem, používá parametry/varianty pro produktové volby jako velikost nebo barva. Namapování na systém variant Shopify (omezený na tři rozměry možností) je obvykle přímočařejší než migrace z platformy s libovolným modelem vlastních atributů, i když jakékoli parametry Shoptetu používané spíš pro popisné filtrování než jako skutečné varianty je lepší umístit do metapolí Shopify. Strukturu kategorií ve Shoptetu je také třeba zkontrolovat vůči plošší, kolekcemi řízené struktuře Shopify, ne ji zkopírovat jako doslovný strom.

#### URL adresy, lokalizace a aplikace

URL adresy ve Shoptetu se řídí vlastními konvencemi a je třeba je namapovat na pevné vzory Shopify (`/products/{handle}`, `/collections/{handle}`). Každá relevantní indexovaná stránka potřebuje dohodnutý cíl a při změně adresy přesměrování 301, které zachová kontinuitu URL a sníží zbytečné SEO riziko. Pokud obchod prodává ve více jazycích nebo měnách, musí se cílové nastavení Shopify Markets navrhnout a otestovat, protože funguje jinak než lokalizace Shoptetu. Aplikace a integrace z tržiště Shoptetu (platební brány, dopravci, marketingové nástroje) je také třeba jednotlivě porovnat s ekosystémem Shopify a potvrdit, zda existuje ekvivalent, nebo je potřeba zakázkové řešení.

#### FAQ

Q: Jak dostanu svá data o produktech a objednávkách ze Shoptetu ven?
A: Přes exportní nástroje CSV/XML Shoptetu a jeho API — přímý přístup k databázi není možný, protože jde o uzavřenou SaaS platformu. Brzy identifikujeme, které typy dat jsou skutečně exportovatelné, a upozorníme na vše, co ne, dřív, než stanovíme rozsah migrace.

Q: Přesměrují se mé URL adresy ze Shoptetu na Shopify automaticky?
A: Ne. Struktura URL adres na Shopify je pevná a liší se od Shoptetu, takže každá indexovaná URL adresa ze Shoptetu potřebuje výslovné přesměrování 301 na svůj protějšek na Shopify, což je obzvlášť důležité pro viditelnost ve vyhledávání na trhu ČR/SK budovanou dlouhodobě.

Q: Zvládne Shopify prodej ve více jazycích a měnách jako Shoptet?
A: Ano, přes Shopify Markets, ale nastavuje se jinak než vestavěná lokalizace Shoptetu — je třeba ho záměrně nastavit tak, aby replikoval vaše stávající nastavení pro více trhů, ne předpokládat, že bude fungovat stejně hned po instalaci.

Q: Proč přecházet ze Shoptetu na Shopify, když jsou obě hostované SaaS platformy?
A: Obvyklými důvody jsou dosah a flexibilita, ne zátěž hostingu — globální ekosystém aplikací Shopify, širší platební a dopravní integrace pro přeshraniční prodej a víc možností úprav šablon i pokladny pro obchody, kterým už nestačí regionálněji zaměřená sada nástrojů Shoptetu.

Sources:
- Shopify – Migrace obchodu na Shopify: https://www.shopify.com/migrate
- Oficiální web Shoptet: https://www.shoptet.cz

### Migrace ze Shopware na Shopify

URL: https://prevedshop.com/cs/migrace/shopware-na-shopify
Language: cs
Last reviewed: 2026-07-21
Route: shopware-6 -> shopify

Shopware je flexibilní e-commerce platforma postavená na Symfony, oblíbená v celém regionu DACH, dostupná jak k samostatnému hostování, tak jako spravovaná cloudová nabídka. Přechod na Shopify znamená vzdát se vysoce přizpůsobitelného systému entit a pluginů Shopware výměnou za omezenější, ale plně spravovanou platformu Shopify. Jádrem práce je namapovat flexibilní vlastnosti produktů a model prodejních kanálů Shopware na pevné produktové schéma a ekosystém aplikací Shopify, spolu s obvyklým plánováním URL adres a přesměrování, které vyžaduje každý přechod na jinou platformu.

#### Proč obchodníci odcházejí ze Shopware

Silná stránka Shopware — vysoce rozšiřitelná platforma postavená na Symfony, s flexibilním systémem entit a hlubokými možnostmi úprav přes pluginy a aplikace — přináší při samostatném hostování reálnou zátěž: správu serveru, upgrady verzí PHP a Shopware i shodu s PCI pro pokladnu nese váš tým. I cloudová varianta Shopware pořád znamená spravovat ekosystém pluginů, které musí zůstat kompatibilní napříč upgrady. Shopify vám zcela odejme odpovědnost za hosting a záplatování platformy, za cenu hlubších možností úprav na úrovni kódu, které Shopware nabízí.

Častým spouštěčem je totéž, co u jiných flexibilních open-source platforem: čas vývojáře potřebný na údržbu vlastních pluginů Shopware a jejich funkčnost napříč upgrady verzí přestává být úměrný tomu, co obchod potřebuje, zvlášť u obchodníků, kteří flexibilitu Shopware využívali méně, než čekali.

#### Vlastnosti produktů, varianty a datový model

Shopware zobrazuje varianty produktů pomocí „vlastností“ a „možností“, které generují kombinace variant, spolu s flexibilním systémem vlastních polí pro atributy mimo tuto strukturu. To je koncepčně blíž modelu variant Shopify než plný systém EAV, ale pevný limit tří rozměrů variantních možností na produkt na Shopify znamená, že produkty Shopware používající víc skupin vlastností potřebují některé z nich přesunout do metapolí Shopify místo variant.

Struktura kategorií ve Shopware, podobně jako u většiny platforem se skutečným stromem kategorií, umožňuje vnořené kategorie s flexibilním přiřazením. Kolekce na Shopify jsou plošší — ruční nebo pravidly řízené seznamy, ne vnořený strom — takže strukturu kategorií ze Shopware je třeba přepracovat na sadu kolekcí Shopify, ne ji přímo exportovat.

#### Prodejní kanály a více výloh

Koncept „prodejního kanálu“ ve Shopware umožňuje jedné instanci Shopware obsluhovat více výloh, aplikací nebo tržišť ze sdíleného katalogu, každou s vlastním nastavením. Nejbližší obdobou na Shopify jsou jeho vlastní více prodejních kanálů (online obchod, POS, tržiště) plus Shopify Markets pro regionální a měnovou variaci v rámci jednoho obchodu, nebo samostatné obchody na Shopify pro skutečně odlišné značky. Tyto koncepty se překrývají, ale nejsou přímou architektonickou obdobou, takže nastavení prodejních kanálů ze Shopware je třeba namapovat na správnou strukturu Shopify podle toho, k čemu se skutečně používá, ne s předpokladem přímého převodu jedna ku jedné.

#### URL adresy, pluginy a specifika pro EU

SEO URL adresy ve Shopware jsou konfigurovatelné podle prodejního kanálu, takže stávající URL adresy potřebují výslovná přesměrování 301 namapovaná na pevné vzory Shopify (`/products/{handle}`, `/collections/{handle}`), aby přechod ochránil pozice ve vyhledávání. Pluginy a aplikace Shopware pro dopravu, platby a úpravy pokladny nemají na Shopify automatickou obdobu a je třeba je jednotlivě vyhodnotit — aplikace na Shopify, zakázková stavba, nebo potvrzení, že funkce už není potřeba.

Shopware se hojně používá v celé EU a má vestavěné nástroje pro zpracování DPH a požadavky na data související s GDPR, běžné pro tento trh. Shopify pokrývá podobnou oblast přes Shopify Tax a vlastní nástroje pro shodu s předpisy, ale konkrétní nastavení — registraci k dani, formátování faktur, nastavení zpracování dat — je třeba pro Shopify zkontrolovat a znovu nakonfigurovat, ne předpokládat, že se přenese automaticky.

#### FAQ

Q: Mapují se vlastnosti produktů ze Shopware čistě na varianty Shopify?
A: Pro standardní použití variant celkem dobře, protože vlastnosti Shopware jsou koncepčně podobné variantním možnostem Shopify. Produkty používající víc než tři skupiny vlastností potřebují některé z nich přesunout do metapolí Shopify, protože Shopify omezuje produkty na tři rozměry variantních možností.

Q: Co se stane s mými prodejními kanály ze Shopware?
A: Přesná obdoba na Shopify neexistuje — vlastní více prodejních kanálů Shopify, Shopify Markets a samostatné obchody každý pokrývají část toho, co umí nastavení prodejních kanálů Shopware. Váš skutečný případ použití (regiony, značky, tržiště) namapujeme na správnou strukturu Shopify během posouzení.

Q: Přesměrují se mé URL adresy ze Shopware na Shopify automaticky?
A: Ne. Struktura URL adres na Shopify je pevná, takže každá indexovaná URL adresa ze Shopware potřebuje výslovné přesměrování 301 na svůj protějšek na Shopify — je to součást plánu migrace, ne dodatečná záležitost.

Q: Přenese se nastavení DPH pro EU a GDPR ze Shopware na Shopify?
A: Ne automaticky. Shopify má vlastní nástroje pro daně a shodu s předpisy (Shopify Tax a související nastavení), ale registraci k dani, formátování faktur a konfiguraci zpracování dat je třeba zkontrolovat a nastavit konkrétně pro Shopify, ne předpokládat, že se přenesou ze Shopware.

Sources:
- Shopify – Migrace obchodu na Shopify: https://www.shopify.com/migrate
- Oficiální web a dokumentace Shopware: https://www.shopware.com

### Migrace z WooCommerce na BigCommerce

URL: https://prevedshop.com/cs/migrace/woocommerce-na-bigcommerce
Language: cs
Last reviewed: 2026-07-21
Route: woocommerce -> bigcommerce

WooCommerce běží jako plugin WordPressu, takže jeho data, hosting i výkon jsou svázané s vaší instalací WordPressu. Přechod na BigCommerce oddělí obchod od vašeho obsahového stacku WordPressu a předá hosting, shodu s PCI i bezpečnostní záplaty platformy BigCommerce — a zároveň vám dá větší nativní flexibilitu variant a kontrolu nad URL adresami než většina SaaS konkurentů. Práce spočívá v namapování produktových a obsahových dat WooCommerce založených na WordPressu na strukturu BigCommerce, aniž by se cestou ztratila hodnota SEO nebo rozbila funkčnost závislá na pluginech.

#### Proč obchodníci odcházejí z WooCommerce

Samotný WooCommerce je zdarma, ale jeho provoz znamená vlastnit aktualizace jádra WordPressu a pluginů, výkon hostingu, zabezpečení na úrovni serveru a shodu s PCI pro pokladnu. Jak obchod roste, konflikty pluginů a dopad narůstajícího množství pluginů na rychlost stránky se stávají skutečnými, opakujícími se náklady — nemluvě o čase vývojáře nebo agentury potřebném k udržení všeho záplatovaného a kompatibilního. BigCommerce jako spravovaná SaaS platforma tuto zátěž hostingu a záplatování odstraňuje výměnou za práci v rámci omezení dané platformy.

Obchody, kterým už nestačí jejich nastavení hostingu WordPressu, nebo které už omrzela křehkost stacku pluginů s růstem webu, jsou nejčastějšími kandidáty na tento přechod.

#### Produktová data: bližší shoda, než byste čekali

WooCommerce ukládá produkty jako vlastní typ obsahu WordPressu, přičemž varianty a atributy jsou postavené na taxonomiích WordPressu — flexibilní řešení, protože WordPress klade na vlastní pole jen málo pevných omezení. Produktový model BigCommerce je strukturovanější, ale nápadně vstřícnější k variantám než někteří SaaS konkurenti — podporuje nativně větší počet kombinací variant na produkt spolu s vlastními poli a modifikátory produktů pro atributy, které se do struktury variant nevejdou. I tak ale produkty WooCommerce s velkým využitím ACF (Advanced Custom Fields) nebo mnoha vlastními atributy potřebují záměrný plán mapování na vlastní pole BigCommerce, ne slepé kopírování.

Kategorie a štítky WooCommerce jsou taxonomie WordPressu, které lze volně vnořovat a křížově přiřazovat. Strom kategorií BigCommerce je blíž tradiční hierarchii než ploché kolekce na Shopify, což dělá převod struktury kategorií z WooCommerce o něco přímočařejší, i tak ale stojí za to ji zkontrolovat, ne exportovat beze změny.

#### URL adresy, obsah a pluginy

Trvalé odkazy WordPressu jsou plně konfigurovatelné, takže URL adresy WooCommerce se ve výchozím stavu jen zřídka shodují s nějakým pevným vzorem. BigCommerce na rozdíl od některých SaaS platforem umožňuje vlastní cesty URL adres bez povinné předpony, což může usnadnit zachování stávající struktury URL adres z WooCommerce — ale každá URL adresa, která se přece jen změní, stále potřebuje výslovné přesměrování 301, a každou indexovanou URL adresu z WooCommerce je tak jako tak potřeba zkontrolovat proti jejímu protějšku na BigCommerce.

Je tu i otázka obsahu WordPressu: mnoho obchodů na WooCommerce se spoléhá na WordPress jako plnohodnotný CMS pro obsah blogu a vstupních stránek, což nemá uvnitř omezenějších nástrojů pro obsah na BigCommerce přímou obdobu. Obchody s podstatným množstvím obsahu WordPressu potřebují plán — migrovat ho do stránek BigCommerce, nebo si ponechat WordPress běžící samostatně pro obsah, zatímco BigCommerce obstarává obchod. Pluginy WooCommerce pro dopravu, předplatné nebo vlastní pole v pokladně je také třeba vyhodnotit jednotlivě: ekvivalentní aplikace na BigCommerce, zakázková stavba, nebo potvrzení, že už nejsou potřeba.

#### FAQ

Q: Podporuje BigCommerce nastavení variant a atributů z WooCommerce?
A: BigCommerce podporuje více kombinací variant na produkt než někteří SaaS konkurenti, což pomáhá u složitých katalogů z WooCommerce, ale stále neexistuje automatická obdoba vlastních polí WordPressu nebo dat z ACF — ta je třeba záměrně namapovat na vlastní pole BigCommerce.

Q: Co se stane s mým blogem a vstupními stránkami na WordPressu?
A: Automaticky se nemigrují, protože nástroje pro obsah na BigCommerce jsou omezenější než ve WordPressu. Příspěvky a stránky můžete migrovat do BigCommerce, nebo si ponechat WordPress běžící samostatně pro obsah, zatímco BigCommerce obstarává obchod — pomůžeme vám rozhodnout podle toho, kolik návštěvnosti tento obsah přináší.

Q: Budou se muset mé URL adresy z WooCommerce na BigCommerce měnit?
A: Méně, než byste čekali při přechodu na některé jiné SaaS platformy, protože BigCommerce umožňuje vlastní cesty URL adres bez povinné předpony. Každá URL adresa, která se přece jen změní, stále potřebuje výslovné přesměrování 301, a tak jako tak před spuštěním zkontrolujeme každou indexovanou URL adresu z WooCommerce.

Q: Dokáže BigCommerce nahradit všechny mé pluginy z WooCommerce?
A: Většina má obdobu v podobě aplikace na BigCommerce, ale ne všechny — některá funkčnost pluginů potřebuje zakázkovou stavbu nad API BigCommerce a některá se vypustí, pokud už není potřeba. Vaše aktivní pluginy katalogizujeme během posouzení dřív, než stanovíme rozsah práce.

Sources:
- Oficiální web a dokumentace BigCommerce: https://www.bigcommerce.com
- Dokumentace WooCommerce: https://woocommerce.com/documentation/

### Migrace z WooCommerce na Shopify

URL: https://prevedshop.com/cs/migrace/woocommerce-na-shopify
Language: cs
Last reviewed: 2026-07-21
Route: woocommerce -> shopify

WooCommerce běží jako plugin nad WordPressem, takže data, hosting i výkon vašeho obchodu jsou provázané s vaší instalací WordPressu. Přechod na Shopify oddělí obchod od obsahu: získáte spravovanou, PCI kompatibilní hostovanou platformu a účelně navržený model produktů a pokladny, ale zároveň přijdete o nativní flexibilitu WordPressu pro obsah a o přímou obdobu pluginů v podobě aplikací, kterou byste možná čekali. Jádrem práce je namapovat datový model WooCommerce založený na WordPressu na pevné schéma Shopify, aniž byste ztratili hodnotu SEO nebo cestou rozbili vlastní funkčnost.

#### Proč obchodníci odcházejí z WooCommerce

Instalace WooCommerce je zdarma, ale jeho dobrý provoz ne: zodpovídáte za aktualizace jádra WordPressu a pluginů, výkon hostingu, zabezpečení na úrovni serveru a shodu s PCI pro vše, co se dotýká platebních dat. Jak obchod roste, konflikty pluginů, problémy s rychlostí stránky kvůli narůstajícímu množství pluginů a opakující se náklady na vývojáře nebo agenturu udržující vše záplatované se stávají skutečnou cenou „zdarma“ dostupného softwaru. Shopify vyměňuje tuto průběžnou zátěž údržby za pevný poplatek za platformu a spravované, PCI kompatibilní prostředí.

Častým spouštěčem je měřítko: výkon WooCommerce silně závisí na kvalitě hostingu a disciplíně u pluginů, a obchody, které začínaly malé, se často dostanou do bodu, kdy provoz nebo velikost katalogu předběhne to, na co bylo jejich nastavení hostingu WordPressu stavěné.

#### Co se mění v datovém modelu

WooCommerce ukládá produkty jako vlastní typ obsahu WordPressu, přičemž varianty, atributy a kategorie jsou postavené na taxonomiích WordPressu — flexibilní struktura, protože WordPress klade na vlastní pole jen málo omezení. Produktový model Shopify je omezenější: pevná sada základních polí, až tři rozměry variantních možností a metapole pro cokoli dalšího. Produkty s mnoha vlastními atributy WooCommerce nebo daty z ACF (Advanced Custom Fields) potřebují záměrně naplánovanou strukturu metapolí, ne slepé kopírování pole po poli.

Kategorie a štítky produktů ve WooCommerce jsou taxonomie WordPressu a lze je volně vnořovat a křížově přiřazovat. Kolekce na Shopify jsou buď ruční seznamy, nebo pravidly řízené („chytré“) kolekce, ne skutečný strom taxonomie, takže hlubokou strukturu kategorií z WooCommerce je obvykle třeba přepracovat na plošší sadu kolekcí, ne ji exportovat tak, jak je.

#### URL adresy, přesměrování a otázka obsahu

Trvalé odkazy WordPressu jsou plně konfigurovatelné, takže URL adresy produktů a kategorií ve WooCommerce mohou vypadat prakticky jakkoli, podle toho, jak si je web nastavil. Shopify vynucuje vlastní vzory (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`, `/blogs/{blog}/{handle}`), takže každá změněná indexovaná URL z WooCommerce potřebuje přesměrování 301, které zachová kontinuitu adresy a sníží riziko ztráty organické viditelnosti. Přesměrování jsou zásadní, žádná migrace však nemůže zaručit stejné pozice.

U této dvojice platforem je tu i otázka obsahu: WordPress je plnohodnotný CMS a mnoho obchodů na WooCommerce se na něj spoléhá kvůli obsahu blogu, vstupním stránkám a vlastním šablonám stránek. Nástroje Shopify pro blog a stránky jsou jednodušší než ve WordPressu. Obchody s podstatným množstvím obsahu WordPressu potřebují pro tento obsah plán — migrovat ho do stránek/blogu Shopify, nebo si ponechat samostatnou instanci WordPressu pro obsah, zatímco Shopify obstarává obchod — a rozhodnout se pro to záměrně, ne to zjistit až po přechodu.

#### Pluginy, pokladna a platební brány

Ekosystém pluginů WooCommerce pokrývá vše od kalkulaček dopravy přes fakturaci předplatného až po vlastní pole v pokladně, často přes pluginy třetích stran bez přímé obdoby na Shopify. U každého aktivního pluginu je během migrace třeba výslovně rozhodnout: ekvivalentní aplikace na Shopify, vlastní aplikace nebo úprava šablony, nebo potvrzení, že funkce už není potřeba. Přenastavit je třeba i platební brány — WooCommerce podporuje širokou škálu pluginů pro platební brány, zatímco Shopify centralizuje platby přes Shopify Payments nebo podporovanou bránu třetí strany, takže jakoukoli vlastní logiku pokladny navázanou na konkrétní platební plugin WooCommerce je třeba znovu vybudovat pro model pokladny Shopify.

#### FAQ

Q: Jak snížit SEO riziko při přechodu z WooCommerce na Shopify?
A: Mohou, ale jen se záměrným mapováním přesměrování. Trvalé odkazy WordPressu a pevná struktura URL adres Shopify se jen zřídka přesně shodují, takže každá indexovaná URL adresa z WooCommerce potřebuje před spuštěním výslovné přesměrování 301 na svůj protějšek na Shopify — viz naše služba SEO a migrace přesměrování.

Q: Co se stane s mým blogem a vstupními stránkami na WordPressu?
A: Automaticky se nemigrují, protože nástroje pro obsah na Shopify jsou omezenější než ve WordPressu. Příspěvky a stránky můžete migrovat do Shopify, nebo si ponechat samostatnou instanci WordPressu pro obsah, zatímco Shopify obstarává obchod — pomůžeme vám rozhodnout podle toho, kolik vaší návštěvnosti na tomto obsahu závisí.

Q: Dokáže Shopify nahradit všechny mé pluginy z WooCommerce?
A: Většina má obdobu v podobě aplikace na Shopify, ale ne všechny — některá funkčnost pluginů WooCommerce potřebuje na Shopify vlastní aplikaci nebo úpravu šablony a některá se vypustí, pokud už není potřeba. Vaše aktivní pluginy katalogizujeme během posouzení dřív, než stanovíme rozsah práce.

Q: Co se stane s variantami produktů a vlastními atributy z WooCommerce?
A: Standardní varianty se mapují na systém variant Shopify, omezený na tři rozměry možností. Vlastní atributy WooCommerce a pole z ACF nad tento rámec je třeba záměrně namapovat na metapole Shopify — z vlastních polí WordPressu neexistuje automatický převod jedna ku jedné.

Sources:
- Shopify – Migrace obchodu na Shopify: https://www.shopify.com/migrate
- Dokumentace WooCommerce: https://woocommerce.com/documentation/

### Migrace z WooCommerce na Shoptet

URL: https://prevedshop.com/cs/migrace/woocommerce-na-shoptet
Language: cs
Last reviewed: 2026-09-02
Route: woocommerce -> shoptet

Shoptet je hostovaná platforma stavěná pro české a slovenské obchodníky, s nativní podporou místních dopravců, platebních bran, fakturačních pravidel a feedů pro srovnávače. Přechod z WooCommerce znamená opustit vlastní WordPress hosting a přejít na spravovaný systém s pevným datovým modelem. Samotná migrace je hlavně o překladu produktů, taxonomií a dat z pluginů do importní struktury Shoptetu, o zachování historie zákazníků a objednávek tam, kde dává smysl, a o ochraně URL adres, které nesou vaši návštěvnost z vyhledávačů.

#### Proč obchodníci přecházejí z WooCommerce na Shoptet

Většina obchodů přechází proto, že provoz WordPressu stojí čas: aktualizace pluginů, výkon hostingu, bezpečnostní záplaty i odpovědnost za PCI leží na obchodníkovi. Shoptet to nahrazuje měsíčním poplatkem a spravovaným prostředím, které už umí Zásilkovnu, PPL, GoPay, Comgate, Heureku i Zboží.cz. Pokud jsou vaši zákazníci v Česku nebo na Slovensku, vestavěné integrace obvykle nahradí několik pluginů najednou. Daní je flexibilita: produktový a obsahový model Shoptetu je užší než WordPress, takže cokoli vlastního potřebuje předem určené místo.

#### Mapování produktů, variant a parametrů

WooCommerce ukládá produkty jako příspěvky WordPressu s atributy, variantami a kategoriemi postavenými na taxonomiích. Shoptet očekává strukturovaný import, kde jsou produkty, varianty, parametry, kategorie a dostupnost definovány v jeho vlastních polích. Varianty se převádějí na varianty Shoptetu, pokud je struktura možností konzistentní; atributy používané pro filtrování se stávají parametry, které je třeba před importem založit a pojmenovat. Stromy kategorií mohou být vnořené v obou systémech, Shoptet ale funguje nejlépe s čistou, mělkou hierarchií. Vlastní pole z ACF nebo pluginů nemají automatický cíl a rozhoduje se o nich jednotlivě: text popisu, parametr, nebo vypuštění.

#### Zákazníci, objednávky a přesměrování URL

Zákaznické účty lze importovat s kontakty a adresami; hesla přenést nelze, zákazníci si je proto v novém obchodě obnoví. Historie objednávek se importuje pro přehled a reporting, ne jako znovu editovatelné živé objednávky. Nejcitlivější částí jsou URL: trvalé odkazy WordPressu jsou libovolné, zatímco Shoptet používá vlastní vzory cest, takže každý indexovaný produkt, kategorie i stránka potřebuje před spuštěním přesměrování 301 na ekvivalent v Shoptetu. Přesměrování zachovává kontinuitu URL a snižuje riziko; žádná migrace nemůže zaručit nezměněné pozice.

#### Přepnutí a první dny na Shoptetu

Doporučujeme provozovat obchod na Shoptetu nejdřív v testovacím režimu s kompletním importovaným katalogem, zkontrolovat vzorek produktů, cen, sazeb DPH a variant a teprve poté přepnout DNS. Feedy pro Heureku a Zboží.cz je třeba znovu vygenerovat ze Shoptetu a odeslat, Google Search Console má v den spuštění dostat novou sitemapu. WordPress ponechte krátce dostupný jen pro čtení, aby se nic neztratilo, dokud není mapa přesměrování potvrzená.

#### FAQ

Q: Lze migrovat objednávky a zákazníky z WooCommerce na Shoptet?
A: Zákazníky včetně adres importovat lze. Objednávky se importují jako historie pro přehled, nestávají se editovatelnými živými objednávkami. Hesla nelze přenést nikdy, zákazník si při prvním přihlášení nastaví nové.

Q: Budou moje URL z WooCommerce na Shoptetu fungovat?
A: Jen s explicitní mapou přesměrování 301. Vzory URL WordPressu a Shoptetu se liší, mapování proto stavíme z vašich indexovaných adres a před spuštěním ho ověřujeme.

Q: Co se stane s pluginy WooCommerce?
A: Každý plugin projdeme. Řada funkcí pro český trh je v Shoptetu nativní, některé mají doplňky a zbytek vyžaduje vlastní řešení nebo se po dohodě vypustí.

Q: Jak dlouho migrace z WooCommerce na Shoptet trvá?
A: Typický malý až střední katalog zabere dva až čtyři týdny včetně testovacího běhu, přesměrování a spuštění; složité parametry nebo velká historie objednávek trvají déle.

Sources:
- Shoptet Developers - Import dat: https://developers.shoptet.com/shoptet-tools/data-import/
- WooCommerce - Import a export produktů v CSV: https://woocommerce.com/document/product-csv-importer-exporter/

### Guides

### Jak vybrat e-shopovou platformu, než začnete migrovat

URL: https://prevedshop.com/cs/pruvodci/jak-vybrat-eshopovou-platformu
Language: cs
Last reviewed: 2026-09-02

Výběr platformy je rozhodnutí, které určuje náklady každé pozdější migrace. Seznamy funkcí od dodavatelů pomáhají málo, protože většina moderních platforem pokrývá základ. Užitečné otázky se týkají struktury katalogu, trhu, na který prodáváte, systémů, které musíte napojit, míry vlastnictví, kterou chcete, a toho, co bude vyžadovat samotná migrace. Tento průvodce projde těchto pět otázek a končí krátkým seznamem varovných signálů, které by měly rozhodnutí zastavit.

#### Začněte katalogem, ne seznamem funkcí

Spočítejte produkty, varianty a parametry a podívejte se, jak spolu souvisejí. Tři rozměry možností s čistou sadou filtrovacích atributů se vejdou téměř do jakékoli platformy. Sady atributů odlišné podle typu produktu, bundly, konfigurátory, B2B ceníky nebo tisíce variant zužují výběr na platformy s bohatším datovým modelem, jako je Adobe Commerce, Shopware nebo composable řešení. Sepište pět nejproblematičtějších produktů ve vašem katalogu a zeptejte se každé kandidátské platformy, jak by je uložila; odpovědi prozradí víc než jakákoli srovnávací tabulka.

#### Trh, jazyk a integrace

Obchod prodávající českým a slovenským zákazníkům potřebuje místní dopravce, platební brány, feedy pro srovnávače a fakturační pravidla. Shoptet nebo Upgates je nabízejí nativně; globální SaaS platforma to zvládne přes aplikace za cenu dalších nákladů a údržby. Prodej do více zemí otevírá jiné otázky: jazykové mutace, měny, DPH a zda je správným tvarem jeden obchod, nebo několik. Sepište systémy, které musí zůstat napojené - ERP, účetnictví, sklad, PIM, feedy pro tržiště - a ověřte, zda má každý kandidát udržovaný konektor, nebo jen API, proti kterému byste museli stavět sami.

#### Vlastnictví, náklady a cesta migrace

Hostované platformy vyměňují kontrolu za pohodlí: do databáze nesáhnete, ale také nikdy nezáplatujete server. Open-source platformy vám dávají data i odpovědnost. Celkové náklady zahrnují licenci nebo tarif, hosting, aplikace nebo rozšíření, hodiny agentury a interní čas strávený aktualizacemi. Nakonec naceňte samotnou migraci: kolik dat přenášíte, zda záleží na historii objednávek a zákaznických účtech, kolik URL potřebuje přesměrování a které vlastní funkce se musí přestavět. Platforma, která vypadá na papíře levněji, může po přičtení migrace vyjít dráž.

#### Varovné signály, které by měly rozhodnutí zastavit

Buďte opatrní, když platforma neumí ukázat, jak bude reprezentován konkrétní typ dat z vašeho současného obchodu, když nezbytná integrace existuje jen jako aplikace třetí strany s nejasnou údržbou, když dodavatel slibuje, že se pozice po migraci nezmění, nebo když nikdo neumí vysvětlit, jak byste platformu později opustili. Krátká discovery fáze se skutečnými vzorky vašich dat většinu těchto otázek vyřeší dřív, než cokoli podepíšete.

#### FAQ

Q: Mám platformu vybrat před posouzením migrace, nebo až po něm?
A: Ideálně posouzení volbu ovlivní. Krátká discovery se skutečnými vzorky produktů, zákazníků a objednávek ukáže, jak by každý kandidát uložil vaše data a kolik přestavby by migrace vyžadovala.

Q: Je hostovaná platforma vždy levnější než open source?
A: Ne vždy. Hostované platformy mají předvídatelné poplatky, ale náklady na aplikace rostou; open source nemá licenční poplatek, ale vyžaduje hosting, aktualizace a čas vývojářů. Porovnejte celkové náklady na tři roky včetně migrace.

Q: Jak důležitá je e-shopová platforma pro SEO?
A: Méně než samotný proces migrace. Každá běžná platforma se může dobře umísťovat; o viditelnost připravuje chybějící mapa přesměrování, změněný obsah nebo pomalé stránky po přechodu.

Q: Mohu později platformu znovu změnit?
A: Ano, pokud zůstanou data exportovatelná. Před výběrem ověřte, že produkty, zákazníky, objednávky a obsah lze exportovat ve strukturovaném formátu, aby další migrace šla bez pomoci dodavatele.

Sources:
- Google Search Central: Přesun webu se změnou URL: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### Kontrolní seznam pro kontrolu po spuštění

URL: https://prevedshop.com/cs/pruvodci/kontrola-po-spusteni-eshopu
Language: cs
Last reviewed: 2026-07-21

Migrace není hotová ve chvíli, kdy nový obchod jde naživo — je hotová, až záměrně potvrdíte, že vše, na čem závisí zákazníci i vyhledávače, skutečně funguje v reálných podmínkách. Testovací prostředí zachytí většinu problémů, ale hrstka se projeví až s živým provozem, skutečnými platebními procesory a opětovným procházením webu vyhledávači. Tento kontrolní seznam shrnuje, co ověřit ve dnech a týdnech po spuštění, bez ohledu na to, jaké platformy byly zapojené.

#### Ověřte celý proces pokladny od začátku do konce, v reálných podmínkách

Proveďte kompletní nákup sami na živém webu — ne na testovacím prostředí — a projděte cesty, které zákazníci skutečně používají: pokladnu jako host i pokladnu po přihlášení, alespoň jeden produkt s variantami a jakékoli aktuálně platné slevové kódy nebo akce. Zkontrolujte, že se e-maily s potvrzením objednávky odesílají správně a že se objednávka poté správně zobrazí ve vaší administraci/systému objednávek.

Nepředpokládejte, že se pokrytí z testovacího prostředí automaticky přenese. Živé platební brány, živé daňové služby a živá API pro dopravní sazby se někdy chovají jinak než jejich testovací nebo sandboxové obdoby, a přesně proto je potřeba skutečná kontrola v živých podmínkách, ne spoléhání na to, co prošlo na testovacím prostředí.

#### Potvrďte, že platební brány jsou plně živé a správně nakonfigurované

Ověřte, že zpracování plateb běží v živém (ne testovacím/sandboxovém) režimu, že jsou zapnuté a funkční všechny platební metody, které obchod dřív podporoval, a že se skutečná transakce od začátku do konce správně vypořádá — že peníze skutečně dorazí, ne že se jen změní stav objednávky. Zkontrolujte i funkčnost vratek, protože se používá méně často než pokladna a snadno se na ni zapomene.

Pokud podporujete více platebních metod nebo měn, otestujte každou zvlášť, místo abyste předpokládali, že když funguje jedna metoda, ostatní jsou nastavené stejně.

#### Zkontrolujte pravidla daní a dopravy na skutečných objednávkách

Logika daní a dopravy se při migraci snadno jemně pokazí, protože obojí často závisí na konfiguraci, která se mezi platformami nemapuje čistě. Zadejte testovací objednávky do svých nejběžnějších destinací dopravy a potvrďte, že se daň počítá správně a že sazby a dostupné metody dopravy odpovídají tomu, co jste zamýšleli — ne jen tomu, co nová platforma nastavila jako výchozí.

Zvláštní pozornost věnujte jakýmkoli speciálním případům, na kterých váš byznys závisí: daňovým výjimkám, prahům pro dopravu zdarma, regionálně specifickým pravidlům nebo omezením dopravy u určitých produktů. Přesně tyto detaily konfigurace se při migraci nejsnáze ztratí nebo nastaví na výchozí hodnotu nesprávně.

#### Namátkově zkontrolujte přesměrování, ne jen ta, na která si vzpomenete

I s kompletní mapou přesměrování sestavenou před spuštěním po přechodu namátkově zkontrolujte skutečný vzorek URL adres: vaše stránky s nejvyšší návštěvností, hrstku s nižší návštěvností a několik záměrných výjimek (ukončené produkty, sloučené kategorie). Potvrďte, že se každá přesměrovává na správný cíl jedním skokem, bez řetězení nebo smyček.

Zkontrolujte také vzorek URL adres, které by na starém webu neměly existovat — překlepy, staré URL adresy založené na parametrech, cokoli, co mohl prohledávač náhodně zaindexovat —, abyste se ujistili, že se rozlišují rozumně, ne s chybou, která by vypadala jako širší problém.

#### Potvrďte kontinuitu analytiky a sledování

Ověřte, že vaše analytická platforma, sledování konverzí a jakékoli reklamní pixely na novém webu správně odesílají data — zadaná testovací objednávka by se měla objevit ve vaší analytice a reportech reklamní platformy stejně jako dřív. Sledovací kód se při změně platformy snadno potichu ztratí, protože chybějící nebo špatně nastavený pixel nevyvolá chybovou hlášku; jen přestane odesílat data.

Porovnávejte první čísla z analytiky po spuštění s výchozím stavem před migrací pro stejný typ dne (všední den vs. víkend, podobné zdroje návštěvnosti), ne s hrubým porovnáním před/po, protože normální výkyvy návštěvnosti jinak mohou skutečný problém se sledováním zamaskovat nebo napodobit.

#### Zkontrolujte přístup k zákaznickým účtům a historii objednávek

Nechte pár skutečných (nebo testovacích) zákaznických účtů potvrdit, že se dokážou přihlásit, vidí správnou historii objednávek a mají přístup ke všem funkcím účtu, na které byli zvyklí — uložené adresy, uložené platební metody tam, kde jsou relevantní, věrnostní nebo bodové zůstatky, pokud je váš obchod má. Problémy s přístupem k účtu jsou pro zákazníky, kteří na ně narazí, velmi viditelné a přímo ovlivňují důvěru, takže stojí za záměrné ověření, ne za předpoklad, že migrace účtů „asi fungovala“.

Pokud migrace hesel nebyla součástí technického přenosu (běžné, když platformy používají nekompatibilní hashování hesel), ujistěte se, že zákazníci mají jasnou cestu k obnovení hesla a že je o ní informujete, ne že je jen technicky dostupná.

#### Sledujte pokrytí v Search Console i v následujících týdnech

Sledujte Search Console (nebo obdobu pro jiné vyhledávače) i dlouho po dni spuštění — chyby procházení, stav indexace a jakýkoli nárůst hlášených chyb 404 jsou nejranější signály problému s přesměrováním nebo kanonickou značkou, který testování nezachytilo. Porovnávejte to s výchozím stavem před migrací, abyste dokázali rozlišit skutečnou regresi od normálního krátkodobého výkyvu po změně webu.

Toto sledovací období je také chvíle, kdy stojí za to znovu odeslat mapu webu, pokud jste to ještě neudělali, a potvrdit, že stránky, u nichž očekáváte indexaci, se v následujících týdnech skutečně objevují ve výsledcích vyhledávání, ne jen že jsou procházené.

#### FAQ

Q: Jak dlouho by mělo pokračovat testování po spuštění?
A: Aktivní, denní kontrola obvykle záleží nejvíc první jeden až dva týdny, kdy vyplave většina problémů s konfigurací a přesměrováním. Opětovná indexace vyhledávači a stabilizace vzorců návštěvnosti trvá déle, takže lehčí sledování (Search Console, trendy v analytice) se vyplatí udržovat déle — běžné je několik týdnů — místo aby se zastavilo, jakmile první týden vypadá čistě.

Q: Co je jednoznačně nejdůležitější zkontrolovat hned po spuštění?
A: Skutečný, živý test pokladny a plateb, protože přímo ovlivňuje tržby a je to jediný proces, kterého se dotkne úplně každý zákazník. Na problémech s přesměrováním a sledováním také záleží, ale rozbitá pokladna je nejnákladnější problém, který lze nechat neodhalený i jen na pár hodin.

Q: Je normální, že pozice ve vyhledávání hned po migraci lehce poklesnou?
A: Určitý krátkodobý výkyv je běžný i u dobře provedené migrace, protože vyhledávače potřebují čas na opětovné procházení a vyhodnocení nových URL adres. Co normální není, je trvalý pokles nebo nárůst chyb procházení — to je signál zkontrolovat mapu přesměrování a kanonické značky kvůli skutečné chybě, ne to jen vyčkat.

Q: Kdo v týmu by měl mít testování po spuštění na starosti?
A: Ideálně někdo s přehledem napříč celým obchodem, ne jen technický migrační tým — protože u několika z těchto kontrol (jestli daňová pravidla sedí, chování zákaznického účtu, jestli čísla ve sledování vypadají normálně) pomáhá byznysový kontext, ne jen technické ověření, že daná funkce existuje.

Sources:
- Google Search Central: Přesun webu se změnou URL adres: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### Čištění produktových dat před migrací

URL: https://prevedshop.com/cs/pruvodci/cisteni-produktovych-dat-pred-migraci
Language: cs
Last reviewed: 2026-07-21

Migrace platformy zkopíruje přesně to, co jí dáte — sama po vás neuklízí. Duplicitní SKU, osiřelé obrázky, nekonzistentní kategorie a neodpovídající struktury variant, které se roky potichu hromadily, se na novou platformu přenesou přesně tak, jak jsou, pokud se jimi někdo nejdřív nezabývá. Udělat tento úklid před migrací je mnohem levnější než po ní, kdy už se na výsledek spoléhají zákazníci i vyhledávače. Tento průvodce shrnuje, na co se zaměřit a jak to postupně vyřešit.

#### Najděte a vyřešte duplicitní SKU a téměř duplicitní produkty

Nejdřív exportujte celý seznam produktů a zkontrolujte přesné duplicity SKU — obvykle jde o chybu při zadávání dat nebo importu a jakmile je najdete, je snadné je sloučit. Pak hledejte téměř duplicitní produkty: stejný produkt znovu vytvořený pod jiným SKU, často výsledek opětovného importu dodavatelského feedu, který se nespároval s existujícími záznamy, nebo produkt, který byl po systémové změně ručně znovu vytvořen místo upraven.

U každé dvojice duplicit rozhodněte, který záznam je ten „skutečný“ — obvykle ten s kompletnějšími daty, delší historií objednávek nebo lepšími SEO signály jako zpětné odkazy či recenze — a ten druhý do něj sloučit nebo na něj přesměrovat, místo abyste migrovali oba a řešili to až později na nové platformě.

#### Vypátrejte osiřelé obrázky a média

Osiřelá média — obrázky a soubory nahrané do vaší knihovny médií, na které už žádný produkt, kategorie ani obsahová stránka neodkazuje — se přirozeně nahromadí za roky aktualizací produktů, sezónních kampaní a změn platforem. Na nové platformě nepřinášejí žádnou hodnotu a jen prodlužují čas migrace a zabírají úložiště, takže se vyplatí je identifikovat a vyloučit.

Pozor si dejte i na opačný případ: obrázky, na které se odkazuje, ale které jsou nefunkční (chybějící soubor, mrtvá externí URL adresa), stojí za odhalení už teď, protože nefunkční obrázek na stránce produktu je malý, ale reálný problém pro důvěryhodnost — a je mnohem snazší ho opravit u vašich současných, dobře známých dat než až po přechodu.

#### Sjednoťte kategorie a atributy

Roky nahodilých přidávání mají tendenci nechat kategorie a atributy nekonzistentní: stejný pojem napsaný nebo psaný velkými písmeny jinak u různých produktů, kategorie, které se překrývají nebo duplikují, atributy používané pro jeden účel u jedné produktové řady a pro jiný účel u jiné. Tato nekonzistence obvykle na staré platformě nezpůsobuje viditelné problémy, protože se ji zaměstnanci naučili obcházet, ale stává se skutečnou zátěží, jakmile se mechanicky namapuje na datový model nové platformy.

Před migrací sestavte (nebo potvrďte) čistou, odsouhlasenou taxonomii — definovaný strom kategorií a definovaný seznam atributů s konzistentním pojmenováním — a svá skutečná data proti ní sesouhlaste. Je to také chvíle, kdy stojí za to se zeptat, které atributy jsou pro zákazníky nebo interní provoz stále smysluplné a které existují jen proto, že je nikdo neodstranil.

#### Sesouhlaste neshody ve struktuře variant

Struktury variant (velikost, barva, materiál a to, jak se kombinují do konkrétních prodejných SKU) řeší každá platforma jinak a nekonzistentní zdrojová data to jen zhoršují. Hledejte produkty, kde variantní možnosti nedodržují konzistentní vzorec — u některých variant velikosti pojmenovaných „S/M/L“ a u jiných v rámci stejné produktové řady „Small/Medium/Large“, nebo produkty, kde kombinace variant v systému existuje, ale nemá za sebou platnou cenu ani skladovou dostupnost.

Rozhodněte cílový model variant před migrací, ne během ní. Vědět předem, zda nová platforma řeší kombinace variant stejně jako ta stará — a kde ne — určuje, jestli se vaše stávající data o variantách dají namapovat přímo, nebo je nejdřív potřeba restrukturalizovat.

#### Rozhodněte, co se skutečně musí přenést

Ne všechno ve vašem současném katalogu si zaslouží místo na nové platformě. Ukončené produkty bez zbývající skladové zásoby, testovací nebo zástupné záznamy a starší pole, u nichž už nikdo nedokáže vysvětlit původní účel, jsou vhodnými kandidáty na to zůstat vzadu — s zdokumentovaným rozhodnutím, ne tichým vypuštěním. Migrovat méně, ale záměrně, je často lepší než migrovat všechno a řešit to až později na neznámém novém systému.

U čehokoli, co se rozhodnete nemigrovat, ale co má stále indexovanou URL adresu, se ujistěte, že je to zahrnuté ve vašem plánu přesměrování (viz průvodce mapováním přesměrování), místo aby to omylem skončilo na chybě 404.

#### FAQ

Q: Kolik času máme vyhradit na čištění dat před migrací?
A: Hodně záleží na velikosti katalogu a tom, jak nepořádná data skutečně jsou — malý, dobře udržovaný katalog potřebuje mnohem méně času než katalog s desítkami tisíc SKU a roky importů z dodavatelských feedů. Skutečný rozsah vám řekne až audit dat; přeskočení auditu a odhad je způsob, jak se čas na čištění podcení.

Q: Máme čistit data před projektem migrace, nebo během něj?
A: Před ním, nebo přinejmenším jako výslovnou samostatnou fázi s vlastním krokem kontroly — ne smíchané s technickým přenosem dat. Rozhodnutí o čištění (co je duplicita, co je bezpečné vypustit, k čemu bylo záhadné vlastní pole) obvykle vyžadují vstup od někoho, kdo zná historii katalogu, a to je jiný druh práce než samotné technické mapování a přenos.

Q: Co když si nejsme jistí, jestli je duplicita skutečně duplicita?
A: Označte to, místo abyste hádali jedním nebo druhým směrem. Téměř duplicitní produkt s odlišnou cenou, odlišnými variantními možnostmi nebo odlišnou historií objednávek může být legitimní samostatný produkt, který jen vypadá podobně. V nejistotě ponechte oba a vraťte se k tomu po dokončení auditu, místo abyste je slučovali na základě odhadu.

Q: Může čištění dat probíhat, když starý obchod stále běží a přijímá objednávky?
A: Ano, u většiny práce na auditu a plánování — kontrola exportů, rozhodování o sloučeních a stavba cílové taxonomie nevyžadují zásah do živého obchodu. Skutečné provedení změn (sloučení záznamů, mazání osiřelých médií) je obvykle bezpečnější dělat na kopii nebo exportu a vyčištěnou sadu dat pak přinést do migrace, ne upravovat živý katalog uprostřed auditu.

### Kontrolní seznam pro replatforming e-shopu

URL: https://prevedshop.com/cs/pruvodci/checklist-zmeny-eshopove-platformy
Language: cs
Last reviewed: 2026-07-21

Replatforming online obchodu je projekt, ne tlačítko, na které stačí zmáčknout. Na tom, jaké platformy jsou zapojené, záleží méně, než si většina lidí myslí — co skutečně rozhoduje o tom, zda migrace proběhne hladce, je to, jestli jste v pořádném pořadí udělali ty nezáživné části: zaudituovali, co máte, záměrně to namapovali, naplánovali přesměrování, otestovali na testovacím prostředí a po spuštění obchod pečlivě sledovali. Tento kontrolní seznam prochází přesně touto posloupností, takže ho můžete použít bez ohledu na to, ze které platformy odcházíte a na kterou přecházíte.

#### 1. Začněte průzkumem a auditem, ne srovnáváním nástrojů

Než začnete srovnávat cílové platformy, zaudituovali, co skutečně máte na té současné: kolik produktů a variant, kolik zákaznických účtů a jak dlouhou historii objednávek, která vlastní pole se aktivně používají a která jsou opuštěné pozůstatky, na jakých aplikacích nebo integracích výloha závisí a které URL adresy dnes generují smysluplnou návštěvnost. Tento audit je to, co promění „migrujeme“ v projekt s jasně daným rozsahem a skutečným seznamem toho, co se musí přenést.

Buďte v této fázi upřímní ohledně kvality dat. Pokud váš katalog má známé duplicity, osiřelé kategorie nebo nekonzistentní atributy, zapište si to hned teď — vyčistit to je levnější před přechodem než po něm, a přeskočení auditu je přesně to, jak týmy tyto problémy objeví až uprostřed migrace.

#### 2. Namapujte datový model dřív, než namapujete jediné pole

Každá platforma strukturuje produkty, varianty, kategorie i zákaznická data trochu jinak. Než přesunete jakákoli data, sestavte výslovné mapování: které zdrojové pole jde na které cílové pole, které zdrojové koncepty (vlastní atribut, štítek, typ balíčku) nemají přímý cílový ekvivalent a vyžadují rozhodnutí, a která pole je bezpečné úplně vypustit, protože na nich už nic nezávisí.

Toto mapování zdokumentujte někde trvalém — v tabulce nebo sdíleném dokumentu, ne v něčí paměti. Stane se referenčním bodem, který si všichni kontrolují během testování, a je to první věc, kterou budete chtít, jakmile po spuštění něco nebude sedět.

#### 3. Naplánujte přesměrování a strukturu URL adres brzy

Struktura URL adres je jedno z nejčastějších míst, kde migrace potichu poškodí SEO a rozbije záložky. Sestavte úplný seznam svých současných URL adres — stránky produktů, kategorie, blog nebo obsahové stránky a jakékoli vlastní vstupní stránky — a ještě před spuštěním rozhodněte novou URL adresu pro každou z nich. Stránky bez čistého ekvivalentu na nové platformě potřebují výslovné rozhodnutí (obvykle přesměrování na nejbližší odpovídající kategorii nebo rozcestník), ne tiché chyby 404.

Toto plánování probíhá dlouho před spuštěním, ideálně souběžně s prací na mapování dat, protože obě věci spolu souvisí: způsob, jakým mapujete kategorie a produkty, často určuje, jak budou vypadat nové URL adresy. Celý postup najdete v samostatném průvodci mapováním přesměrování, na který odkazujeme níže.

#### 4. Vybudujte testovací prostředí a proveďte skutečné testování

Nikdy neberte první import jako finální. Nahrajte namapovaná data na testovací nebo zkušební instanci cílové platformy a obchod skutečně používejte: procházejte kategorie, prohlížejte stránky produktů, kontrolujte výběr variant a ceny, otestujte košík a proces objednávky a ověřte, že se zákaznické účty a historie objednávek zobrazují správně. Zapojte někoho mimo migrační tým — čerstvý pohled odhalí věci, kterých si lidé, kteří mapování stavěli, přestanou všímat.

Berte tuto fázi jako iterativní. Je normální na první průchod najít problémy s mapováním; cílem je zachytit a opravit je tady, na testovacím prostředí, kde chyba stojí opakovaný import, ne úsek výpadku naživo nebo chybu viditelnou pro zákazníky.

#### 5. Naplánujte okno spuštění jako operaci, ne přepnutí vypínače

Písemně si rozhodněte, co se stane během spuštění: jak se řeší nové objednávky na staré platformě, pokud migrace zabere čas (dočasné zmrazení objednávek, stránka s údržbou, nebo pokračující provoz až do definovaného finálního sesynchronizování), kdo provede finální synchronizaci dat, kdo ověří DNS a SSL na nové platformě a kdo má pravomoc vrátit se zpět nebo pozastavit spuštění, pokud něco nebude v pořádku.

Dejte týmu sdílený kontrolní seznam na samotný den, ne jen plán v něčí hlavě. Uspěchané nebo nejasné spuštění je přesně místo, kde jinak dobře připravené migrace ztratí data — třeba hrstku objednávek podaných v mezeře mezi finální synchronizací a spuštěním naživo — takže na tuto mezeru záměrně naplánujte, ne doufejte, že na ní nezáleží.

#### 6. Sledujte dění po spuštění — migrace nekončí uvedením do provozu

Dny a týdny po spuštění jsou přesně ta doba, kdy se objeví problémy, které testovací prostředí nezachytilo: špatně nakonfigurovaná platební brána pro živý provoz, pravidlo pro daně nebo dopravu, které se u skutečných objednávek chová jinak, přesměrování, která fungují pro stránky, jež jste testovali, ale ne pro okrajové případy, nebo sledovací pixel, který potichu přestal odesílat data. Nastavte si záměrnou rutinu sledování místo předpokladu, že ticho znamená úspěch.

Náš kontrolní seznam pro kontrolu po spuštění (odkaz níže) tuto fázi pokrývá podrobně — ověření pokladny a plateb, namátkovou kontrolu přesměrování, kontinuitu analytiky a sledování Search Console —, protože si zaslouží vlastní, vyhrazený proces, ne uspěchanou dodatečnou myšlenku, až se pozornost týmu přesune jinam.

#### FAQ

Q: Jak dlouho trvá projekt replatformingu?
A: Hodně záleží na velikosti katalogu, složitosti dat a počtu zapojených vlastních integrací. Malý, čistý katalog se obvykle přenáší rychleji než katalog s desítkami tisíc SKU, roky nahromaděných vlastních polí a mnoha propojenými aplikacemi. Reálný odhad získáte až po auditu vašeho konkrétního obchodu, ne z obecného harmonogramu.

Q: Máme migrovat všechno najednou, nebo po fázích?
A: Oba přístupy fungují v závislosti na obchodu. Jednorázové spuštění je jednodušší na plánování a vyhne se souběžnému provozu dvou platforem, ale koncentruje riziko do jednoho okna. Fázový přístup (například nejdřív obsah a design, pak katalog, pak transakční data) riziko rozprostírá, ale vyžaduje pečlivější koordinaci toho, co je v každé fázi „naživo“ kde. Správná volba závisí na velikosti katalogu, vaší toleranci k odstávce a míře provázanosti vašich systémů.

Q: Co je nejčastější příčinou problémů při migraci?
A: Přeskočení nebo uspěchání fází auditu a mapování. Týmy, které se pustí rovnou do přesunu dat, aniž by nejdřív pochopily, co skutečně mají — duplicitní produkty, nezdokumentovaná vlastní pole, URL adresy, se kterými nikdo nepočítal — tyto problémy obvykle objeví naživo, po spuštění, místo na testovacím prostředí, kde je levné je opravit.

Q: Musíme starý obchod během migrace zmrazit?
A: Ne nutně po celou dobu projektu, ale potřebujete jasný plán pro finální okno spuštění — obvykle krátké zmrazení nebo definovaný bod finální synchronizace —, aby se mezi posledním stažením dat a spuštěním nového obchodu neztratily žádné objednávky ani změny u zákazníků. Jak dlouhé toto okno musí být, závisí na objemu objednávek a způsobu řešení finální synchronizace.

Sources:
- Google Search Central: Přesun webu se změnou URL adres: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### SEO bezpečné mapování přesměrování pro migrace e-shopů

URL: https://prevedshop.com/cs/pruvodci/mapovani-presmerovani-bez-ztraty-seo
Language: cs
Last reviewed: 2026-07-21

Pozice ve vyhledávání a organická návštěvnost jsou pro zavedený obchod cenné a neopatrná migrace je může poškodit. Kontinuita URL je jedna z částí, které lze přímo řídit: sepište staré adresy, zvolte relevantní cíle, správně implementujte přesměrování a sledujte reakci vyhledávačů. Průvodce prochází celý proces bez ohledu na použité platformy a bez slibu nezměněných pozic.

#### Nejdřív sestavte kompletní inventář URL adres

Než začnete cokoli mapovat, potřebujete úplný seznam URL adres, které se aktuálně používají — ne jen ty, které si pamatujete, ale úplně každou stránku produktu, kategorie a kolekce, blog nebo obsahovou stránku a jakékoli vlastní vstupní stránky existující na současném webu. Získejte tento seznam ze své mapy webu (sitemapy), z přehledů stránek ve vašem analytickém nástroji a z procházení živého webu, a všechny tři zdroje vzájemně zkontrolujte, protože každý má tendenci nezachytit něco, co zachytí ty ostatní.

Zvláštní pozornost věnujte URL adresám s organickou návštěvností nebo externími zpětnými odkazy, i když jde o stránky, které byste jinak považovali za nedůležité. Příspěvek na blogu s nízkou návštěvností, ale hrstkou kvalitních zpětných odkazů, stojí za správné namapování; jeho tichá ztráta je malá, ale zbytečná.

#### Namapujte každou URL adresu na její nový ekvivalent — a výjimky rozhodněte záměrně

U každé URL adresy ve vašem inventáři rozhodněte její cílovou adresu na nové platformě. Většina stránek produktů a kategorií bude mít poměrně přímý ekvivalent, jakmile bude hotové mapování dat. Stránky bez čistého ekvivalentu (ukončený produkt, jednorázová vstupní stránka, kategorie, která už neexistuje) i tak potřebují výslovné rozhodnutí — obvykle přesměrování na nejbližší odpovídající kategorii, relevantní rozcestník, nebo ve vzácných případech záměrnou, akceptovanou chybu 404 — místo toho, aby se ve výchozím stavu přesměrovaly na domovskou stránku nebo omylem skončily na 404.

Plošné „přesměrovat všechno na domovskou stránku“ je běžná zkratka, která vám aktivně škodí: ředí signály relevance a dává uživatelům horší zážitek, než kdyby přistáli na nejbližší relevantní stránce.

#### Implementujte přesměrování 301 a kontrolujte řetězení a smyčky

Používejte trvalá přesměrování (301) pro URL adresy, které se skutečně natrvalo přesunuly — to je signál, který vyhledávačům řekne, aby přenesly signály pro pozice na novou URL adresu. Jakmile jsou vaše přesměrování živá, aktivně kontrolujte řetězení přesměrování (URL A → B → C, když by stačilo A → C) a smyčky (A → B → A), protože obojí je běžný vedlejší produkt postupných úprav mapy přesměrování a obojí plýtvá crawl budgetem a přidává zpoždění. Cílem je jednoskokové přesměrování z každé staré URL adresy přímo na její finální nový cíl.

Po spuštění ručně otestujte reprezentativní vzorek přesměrování — namátkově zkontrolujte stránky s vysokou návštěvností, hrstku těch s nízkou návštěvností a několik záměrných výjimek — místo předpokladu, že mapa je správná jen proto, že prošla validací v tabulce.

#### Řešte kanonické značky záměrně

Kanonické značky říkají vyhledávačům, která URL adresa je autoritativní verzí, když je podobný obsah dostupný z více adres. Po migraci se ujistěte, že kanonická značka každé stránky ukazuje na její vlastní živou, správnou novou URL adresu — ne na pozůstatek staré URL adresy a omylem ani na URL adresu jiné stránky kvůli zkopírované šabloně. Chyba v tomto kroku dokáže vyhledávače zmást ohledně toho, kterou verzi stránky mají indexovat, i když jsou samotná přesměrování v pořádku.

Pokud nová platforma generuje kanonické značky automaticky, ověřte její výchozí chování, místo abyste předpokládali, že je pro vaše nastavení správné — automatická kanonikalizace občas ukazuje na neočekávané URL adresy u parametrizovaných nebo stránkovaných stránek.

#### Znovu odešlete XML mapu webu a aktualizujte interní odkazy

Jakmile je nový web živý s funkčními přesměrováními, vygenerujte a odešlete čerstvou XML mapu webu odrážející novou strukturu URL adres přes Google Search Central a nástroje pro webmastery dalších vyhledávačů, aby prohledávače mohly nové stránky objevit efektivně, ne se spoléhat výhradně na sledování přesměrování ze starých URL adres.

Současně aktualizujte interní odkazy napříč webem — navigaci, patičku, odkazy na související produkty, obsah blogu —, aby ukazovaly přímo na nové URL adresy, ne přes přesměrování. Interní odkazy, které stále ukazují na staré URL adresy, přidávají zbytečné skoky přesměrování u každého kliknutí a je snadné je přehlédnout, protože nic viditelně nerozbijí; jen fungují méně efektivně.

#### Sledujte stav procházení a indexace po spuštění

SEO práce spojená s migrací nekončí spuštěním. V týdnech po spuštění sledujte Search Console (nebo obdobný nástroj pro jiné vyhledávače) kvůli chybám procházení, náhlému nárůstu chyb 404, stránkám, které se neindexují, nebo poklesu zobrazení/prokliků u stránek, které by měly fungovat normálně. Porovnávejte to s výchozím stavem před migrací, abyste zachytili skutečné regrese, ne normální krátkodobé výkyvy.

Buďte trpěliví, ale ne pasivní: opětovná indexace nějakou dobu trvá i při správném nastavení všeho, ale chyba v přesměrování nebo kanonické značce přehlédnutá týdny je mnohem nákladnější opravit než ta zachycená v prvních dnech po spuštění.

#### FAQ

Q: Poškodí migrace určitě mé pozice ve vyhledávání?
A: Ne nutně, ale pozice se mohou změnit i při dobře provedené migraci. Úplná mapa přesměrování, správné canonical značky, aktualizované interní odkazy a znovu odeslaná sitemap snižují zbytečné riziko. Konkrétní pozice nelze garantovat, protože výkon ve vyhledávání závisí na více faktorech než jen na migraci.

Q: Mám použít přesměrování 301, nebo 302?
A: Pro URL adresy, které se natrvalo přesunuly, což je běžný případ u migrace platformy, používejte trvalá přesměrování (301). Dočasná přesměrování (302) signalizují, že přesun není trvalý, a vyhledávače nemusí přenést signály pro pozice stejným způsobem, takže jsou pro mapu přesměrování dokončené migrace špatnou volbou.

Q: Co když by dvě staré URL adresy měly ukazovat na stejnou novou stránku?
A: To je v pořádku a běžné — například dvě staré URL adresy kategorií, které se na nové platformě sloučily do jedné. Obě staré URL adresy přesměrujte přímo na jedinou novou URL adresu. Čemu je třeba se vyhnout, je opak: jedna stará URL adresa, u které není jasné, na jakou novou stránku by se měla mapovat, což obvykle znamená, že rozhodnutí o mapování ještě ve skutečnosti nepadlo.

Q: Jak dlouho mám ponechat stará přesměrování v provozu?
A: Pokud je to prakticky možné, natrvalo. Zpětné odkazy, záložky a staré výsledky vyhledávání odkazující na předchozí URL adresy mohou přetrvávat dlouho po migraci a udržovat pravidlo přesměrování v provozu stojí jen málo. Příliš brzké odstranění přesměrování je běžný způsob, jak se z toho, co má být jednorázový náklad migrace, stane opakující se zdroj nefunkčních odkazů.

Sources:
- Google Search Central: Přesměrování 301: https://developers.google.com/search/docs/crawling-indexing/301-redirects
- Google Search Central: Sjednocení duplicitních URL adres (kanonikalizace): https://developers.google.com/search/docs/crawling-indexing/canonicalization
- Google Search Central: Vytvoření a odeslání mapy webu: https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap

### Shopify vs WooCommerce: na kterou platformu migrovat?

URL: https://prevedshop.com/cs/pruvodci/shopify-vs-woocommerce
Language: cs
Last reviewed: 2026-09-02

Shopify a WooCommerce jsou dvě platformy, na které a ze kterých migrujeme nejčastěji, a volba mezi nimi je málokdy o funkcích. Shopify je hostovaný systém s pevným modelem, který odstraňuje provozní práci; WooCommerce je otevřený plugin pro WordPress, který vám dává databázi i odpovědnost. Toto srovnání se dívá na rozdíly, které migraci skutečně mění: datový model, vlastnictví, strukturu nákladů, práci s obsahem a SEO, a pak popisuje, které obchody bývají spokojenější na které straně.

#### Datový model: pevný versus otevřený

Produkty Shopify mají pevné schéma s až třemi rozměry možností a metapoli pro všechno ostatní; kolekce jsou ruční nebo pravidlové seznamy, ne strom taxonomie. Produkty WooCommerce jsou příspěvky WordPressu s neomezenými atributy, vlastními poli a vnořenými taxonomiemi. Přechod na Shopify je proto konsolidace - rozhodování, kde bude bydlet každé vlastní pole - zatímco přechod na WooCommerce je většinou mapování malého, úhledného modelu do většího. Obchody s velmi strukturovanými katalogy obvykle migrují snáz směrem k Shopify; obchody s neobvyklými daty ztrácejí méně směrem k WooCommerce.

#### Vlastnictví, hosting a náklady

Shopify účtuje tarif plus transakční poplatky u cizích bran a předplatné aplikací; na oplátku není žádný server, žádné záplatování a žádný rozsah PCI na vaší straně. WooCommerce nemá licenční poplatek, platíte ale spravovaný WordPress hosting, licence pluginů a čas vývojáře, který udržuje aktualizace bezpečné. Za tři roky jsou součty často blíž, než obě strany tvrdí. Skutečný rozdíl je v tom, kde sedí riziko: na Shopify může platforma změnit pravidla a ceny; na WooCommerce může zanedbaná sada pluginů obchod rozbít.

#### Obsah a SEO

WordPress je plnohodnotné CMS, obchody na WooCommerce s velkými blogy, landing pages a vlastními šablonami tak mají všechno na jednom místě. Stránky a blog Shopify jsou jednodušší a obsahově bohaté obchody často provozují WordPress pro obsah vedle Shopify pro prodej. V SEO jsou platformy při dobrém nastavení rovnocenné; při migraci záleží na změně URL. Shopify vynucuje cesty `/products/` a `/collections/`, trvalé odkazy WordPressu jsou libovolné, každá migrace mezi nimi tedy potřebuje kompletní mapu přesměrování 301. Přesměrování snižuje riziko; pozice nejsou nikdy zaručené.

#### Které obchody se hodí na kterou platformu

Shopify obvykle vyhovuje obchodům, které chtějí předvídatelný provoz, prodávají do více zemí přes Markets, používají standardní logistiku a mají katalog, který se vejde do tří rozměrů možností. WooCommerce vyhovuje obchodům, které potřebují vlastní logiku checkoutu, B2B ceny, neobvyklé struktury produktů, hlubokou integraci obsahu nebo přísné umístění dat. Pokud ani jeden popis není jasně váš, krátká discovery se skutečnými vzorky produktů a objednávek to zodpoví rychleji než jakákoli srovnávací tabulka.

#### FAQ

Q: Je Shopify lepší než WooCommerce pro SEO?
A: Ani jedna platforma nemá vrozenou výhodu. Viditelnost po migraci závisí na mapě přesměrování, shodě obsahu a rychlosti stránek, ne na názvu platformy.

Q: Co je levnější, Shopify nebo WooCommerce?
A: Záleží na měřítku a míře úprav. Shopify má předvídatelné poplatky plus aplikace a transakční poplatky; WooCommerce má hosting, licence pluginů a čas vývojářů. Porovnejte tříleté součty včetně migrace.

Q: Mohu přejít ze Shopify na WooCommerce, ne jen opačně?
A: Ano. Migrujeme oběma směry; trasa Shopify → WooCommerce je popsaná zvlášť a jde hlavně o mapování metapolí a přestavbu chytrých kolekcí.

Q: Ovlivňuje volba délku migrace?
A: Částečně. Přechod na Shopify trvá déle u katalogů s mnoha vlastními poli, protože každé potřebuje rozhodnutí o metapoli; přechod na WooCommerce trvá déle, když je nutné nahradit mnoho aplikací pluginy.

Sources:
- Shopify Help Center - Migrace na Shopify: https://help.shopify.com/en/manual/migrating-to-shopify
- WooCommerce - Import a export produktů v CSV: https://woocommerce.com/document/product-csv-importer-exporter/

### Glossary

### Přesměrování 301

URL: https://prevedshop.com/cs/slovnik/presmerovani-301
Language: cs
Last reviewed: 2026-07-21

Přesměrování 301 říká prohlížečům i vyhledávačům, že se stránka trvale přesunula na novou URL adresu, a každého — člověka i prohledávač —, kdo požaduje starou adresu, pošle rovnou na tu novou. „301“ je kód stavu HTTP, který vrací server: je to standardní, trvalý způsob, jak říct „tento obsah teď žije jinde“, na rozdíl od dočasného přesměrování (302).

#### Co přesměrování 301 skutečně dělá

Když někdo požaduje starou URL adresu, server odpoví stavovým kódem HTTP 301 a novým umístěním. Prohlížeč to automaticky sleduje, takže si toho návštěvník často ani nevšimne — přistane na nové stránce, ne na chybě. Vyhledávače reagují na stejný signál: 301 jim říká, aby postupně přenesly hodnotu pozic staré URL adresy na tu novou, místo aby novou stránku považovaly za nesouvisející, zcela nový obsah.

To se liší od přesměrování 302 (dočasného), které prohledávačům říká, že přesun není trvalý a hodnota z vyhledávání by se neměla přenášet plně. Liší se to i od ruční úpravy odkazů na vlastním webu — přesměrování 301 zachytí úplně každého, kdo má starou URL adresu uloženou v záložkách, odkazovanou z jiného webu nebo zaindexovanou ve výsledcích vyhledávání, ne jen lidi klikající na odkazy, které máte pod kontrolou.

#### Proč na přesměrování 301 záleží při migraci platformy

Přechod na novou platformu téměř vždy mění strukturu URL adres, i když se ji snažíte zachovat blízkou — URL adresy produktů, cesty kategorií i příspěvky na blogu často skončí v jiné podobě než dřív. Každá stará URL adresa, kterou mají vyhledávače zaindexovanou a na kterou odkazují jiné weby, potřebuje přesměrování 301 na svůj nový ekvivalent, jinak ztratíte nahromaděný signál pro pozice dané stránky a návštěvníky pošlete do slepé uličky.

Riziko není hypotetické: spustíte-li nový obchod bez plánu přesměrování, obvykle během pár dní od spuštění uvidíte hromadit se chyby 404, přestanou fungovat příchozí odkazy a klesne organická návštěvnost, protože vyhledávače navštěvují zaindexované URL adresy rychle. Plán přesměrování sestavený před spuštěním, ne narychlo poslepovaný poté, co návštěvnost klesne, je to, co tomu zabrání.

#### Udělat přesměrování správně, ne jen je mít

Mít přesměrování 301 samo o sobě nestačí — musí ukazovat na správný cíl. Přesměrování každé staré URL adresy na novou domovskou stránku odkaz technicky „vyřeší“, ale zahazuje konkrétní relevanci, kterou vyhledávač nebo návštěvník čekal. Namapujeme staré URL adresy na jejich nejbližší skutečný ekvivalent na nové platformě a stránky bez čisté shody označíme, místo abychom hádali.

Kontrolujeme také řetězení přesměrování (URL A na B na C) a smyčky, které přidávají zpoždění a mohou způsobit, že prohledávače přestanou řetěz sledovat úplně. Čistá migrace končí jedním skokem na URL adresu, ne třemi.

#### FAQ

Q: Je přesměrování 301 totéž co změna URL adresy?
A: Ne — změna URL adresy bez přesměrování starý odkaz jednoduše rozbije. Přesměrování 301 je instrukce, která propojí starou URL adresu s novou, takže kdokoli (nebo cokoli), kdo požaduje starou adresu, je automaticky poslán na novou stránku.

Q: Zachová přesměrování 301 mé pozice ve vyhledávání úplně?
A: Zachová většinu signálu pro pozice spojeného se starou URL adresou, ale ne automaticky každou pozici pro každé klíčové slovo — pořád platí i jiné faktory jako kvalita webu a konkurence. Co 301 spolehlivě udělá, je říct vyhledávačům, že se obsah přesunul, místo aby novou URL adresu považovaly za nesouvisející.

Q: Jak dlouho musím přesměrování udržovat v provozu?
A: Natrvalo, nebo co nejblíže tomu, jak je to prakticky možné. Staré odkazy z jiných webů, uložené záložky a tištěné materiály mohou posílat návštěvnost na staré URL adresy ještě roky a vyhledávačům může trvat, než plně zpracují velkou dávku přesměrování.

Q: Jaký je rozdíl mezi přesměrováním 301 a 302?
A: 301 signalizuje trvalý přesun a přenáší signál pro pozice na novou URL adresu; 302 signalizuje dočasný přesun a vyhledávače jsou opatrnější ohledně přenosu tohoto signálu. U migrace platformy, kde se stará URL adresa nevrátí, je 301 téměř vždy správná volba.

Sources:
- Google Search Central: Přesměrování a Google Vyhledávání: https://developers.google.com/search/docs/crawling-indexing/301-redirects

### Kanonická značka

URL: https://prevedshop.com/cs/slovnik/kanonicka-znacka
Language: cs
Last reviewed: 2026-07-21

Kanonická značka (`<link rel="canonical">`) je HTML značka, která vyhledávačům říká, která URL adresa je autoritativní verzí stránky, když je stejný nebo velmi podobný obsah dostupný z více než jedné adresy. Nikam návštěvníky nepřesměrovává — je to signál pro prohledávače o tom, která URL adresa má dostat zásluhu a zobrazovat se ve výsledcích vyhledávání.

#### Co kanonická značka skutečně dělá

E-commerce platformy běžně nabízejí stejný produkt nebo kategorii přes více URL adres — s koncovým lomítkem a bez něj, s různými parametry řazení nebo filtrování v dotazu, nebo dostupné z více než jedné cesty kategorie. Bez kanonické značky musí vyhledávače hádat, kterou verzi zaindexovat, což může rozdělit signál pro pozice napříč téměř duplicitními URL adresami místo jeho soustředění na jednu.

Kanonická značka sídlí v `<head>` stránky a ukazuje na jedinou URL adresu, která by se měla považovat za hlavní kopii. Každá duplicitní nebo téměř duplicitní varianta nese kanonickou značku ukazující zpět na tuto jednu URL adresu; hlavní URL adresa má typicky kanonickou značku ukazující sama na sebe.

#### Proč na tom záleží při migraci platformy

Nové platformy často zavádí vlastní vzory URL adres pro filtrování, stránkování nebo řazení, které na staré platformě neexistovaly, a je snadné skončit s neúmyslným duplicitním obsahem, pokud se kanonické značky nenastaví správně hned od začátku. Chyba tady obvykle nezpůsobí dramatický propad jako chybějící přesměrování, ale potichu ředí signál pro pozice napříč téměř duplicitními stránkami místo jeho soustředění — pomalejší, hůř diagnostikovatelný problém.

Migrace jsou také přirozená příležitost opravit už existující problémy s kanonikalizací ze staré platformy, ne je beze změny přenést dál.

#### Kanonické značky vs. přesměrování

Kanonická značka a přesměrování řeší různé problémy. Přesměrování (viz přesměrování 301) je pro URL adresu, která už vůbec neexistuje — posílá návštěvníky i prohledávače na novou adresu. Kanonická značka je pro URL adresy, které stále existují a jsou stále dostupné, ale neměly by mezi sebou soupeřit ve výsledcích vyhledávání — obě zůstávají živé, jedna je jen označená jako referenční verze.

#### FAQ

Q: Přesměrovává kanonická značka návštěvníky na hlavní URL adresu?
A: Ne. Návštěvníci mohou pořád přistát na nekanonické URL adrese a ta se normálně načte — kanonická značka jen signalizuje vyhledávačům, kterou verzi mají zaindexovat a hodnotit, chování prohlížeče nemění.

Q: Potřebuji kanonické značky, i když nemám duplicitní obsah?
A: Je pořád běžnou praxí, aby každá stránka měla kanonickou značku odkazující sama na sebe, což odstraní nejednoznačnost, pokud se duplicita někdy později objeví — třeba kvůli sledovacímu parametru nebo nové URL adrese s filtrem.

Q: Může kanonická značka ukazovat na stránku na jiné doméně?
A: Ano, kanonické značky napříč doménami jsou platné a někdy se používají záměrně, ale u migrace platformy to obvykle není to, co chcete — každá nová URL adresa by se typicky měla kanonikalizovat sama na sebe, přičemž starou doménu nebo staré URL adresy by měla řešit přesměrování, ne kanonické značky.

Q: Co se stane, když mé kanonické značky ukazují na špatnou URL adresu?
A: Vyhledávače mohou skončit s indexací a hodnocením špatné verze stránky, nebo váš kanonický signál úplně ignorovat, pokud se zdá nekonzistentní s jinými signály (jako interní odkazy nebo mapa webu). Kanonické značky kontrolujeme jako součást testování migrace, ne s předpokladem, že je nová platforma nastaví správně ve výchozím stavu.

Sources:
- Google Search Central: Sjednocení duplicitních URL adres: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

### Migrace dat

URL: https://prevedshop.com/cs/slovnik/migrace-dat
Language: cs
Last reviewed: 2026-07-21

Migrace dat je proces přenosu informací vašeho obchodu — produktů, zákazníků, objednávek, obsahu a všeho s nimi souvisejícího — z jedné platformy na druhou, v podobě, kterou nová platforma dokáže skutečně správně použít. Je to jádro technické práce při přechodu na platformu, odlišné od designu, plánování přesměrování nebo práce na integracích, které ji obklopují, i když všechny tyto části závisí na tom, aby migrace dat byla přesná.

#### Co se skutečně migruje

Nad rámec zjevného produktového katalogu plná migrace dat obvykle pokrývá zákaznické účty a jejich historii objednávek, existující objednávky (otevřené i historické), obsah jako příspěvky na blogu nebo statické stránky, recenze, pokud jsou uložené přímo na platformě, a jakákoli vlastní pole nebo metadata specifická pro váš byznys. Ne všechno se nutně musí přenést — některá historická data se mohou archivovat místo aktivní migrace, což je rozhodnutí o rozsahu učiněné během posouzení, ne výchozí předpoklad.

#### Proč přímý export/import nestačí

Dvě platformy jen zřídka modelují data identicky — plochý seznam produktů jedné platformy může být hierarchický systém kategorií a atributů na druhé; jednoduchý zákaznický záznam jedné platformy může na nové platformě potřebovat rozdělit napříč několika typy objektů. Doslovné kopírování pole po poli z exportního souboru často vyprodukuje data, která jsou technicky přítomná, ale strukturně špatná — rozbité vztahy variant, ztracená vlastní pole nebo zákaznické záznamy, které se správně nenapojí na svou historii objednávek. Skutečná migrace dat znamená záměrně namapovat každý typ dat, ne jen přesunout soubory.

#### Jak k tomu přistupujeme

Začínáme auditem dat — pochopením toho, co skutečně existuje ve starém systému, včetně nesrovnalostí, které se v čase nahromadily (duplicitní zákazníci, osiřelé záznamy, nekonzistentní kategorizace) — dřív, než rozhodneme, jak se to namapuje na novou platformu. Čištění se často odehrává jako součást tohoto kroku, ne až po něm, protože věrná migrace špatných dat jen reprodukuje stejné problémy na nové platformě. Jak to zapadá do řízené migrace, popisuje Čištění a mapování dat.

#### FAQ

Q: Zahrnuje migrace dat i historii mých objednávek?
A: Může — zda se historické objednávky aktivně migrují do nové platformy, nebo se archivují zvlášť, je rozhodnutí o rozsahu, protože ne každá platforma nebo byznys potřebuje živou historii objednávek v novém systému. Toto řešíme během posouzení.

Q: Přenesou se má vlastní pole automaticky?
A: Ne automaticky — vlastní pole potřebují na nové platformě výslovný ekvivalent (často metapole nebo vlastní atributy) a toto mapování je třeba definovat, ne předpokládat, že existuje samo od sebe.

Q: Můžu si data migrovat sám pomocí pluginu nebo importního nástroje?
A: U malých, jednoduchých katalogů to může fungovat. U obchodů s podstatnými úpravami, historií objednávek nebo problémy s kvalitou dat obecný importní nástroj obvykle nedokáže udělat úsudková rozhodnutí, která vyžaduje pořádný audit a mapování dat — jen přesune to, co je v souboru, včetně chyb.

Q: Jak zabráníte ztrátě dat během migrace?
A: Auditem a mapováním dřív, než cokoli přesuneme, otestováním migrace nejdřív na testovacím prostředí a ověřením počtu záznamů i namátkovou kontrolou dat po přesunu, ne předpokladem, že import proběhl správně.

### Headless commerce

URL: https://prevedshop.com/cs/slovnik/headless-commerce
Language: cs
Last reviewed: 2026-07-21

Headless commerce je architektura, ve které se výloha (to, co zákazníci vidí a s čím pracují) staví odděleně od backendu obchodu (produktový katalog, košík, pokladna, správa objednávek) a obě části spolu komunikují přes API, ne jako jeden pevně provázaný systém. „Headless“ (bez hlavy) odkazuje na to, že výloha — prezentační vrstva — je oddělená od backendu, který pak může obsluhovat více různých „hlav“ (web, mobilní aplikaci, kiosek v prodejně) z jednoho zdroje pravdy.

#### Headless vs. tradiční (monolitické) platformy

Tradiční e-commerce platforma spojuje šablony výlohy a backend dohromady — šablony Liquid na Shopify nebo šablony WordPressu ve WooCommerce jsou příklady toho, že výlohu generuje přímo samotná platforma. V headless nastavení je výloha samostatná aplikace (často postavená na frameworku jako Next.js nebo podobném) a data načítá z API backendové platformy, místo aby platforma stránky vykreslovala přímo. Některé platformy (Shopify, commercetools a několik dalších) podporují jak tradiční, tak headless režim.

#### Proč to mění migraci

Migrace do headless nastavení nebo z něj je jiný druh projektu než migrace mezi dvěma tradičními platformami. Přesun obchodu z tradiční platformy na headless architekturu obvykle znamená postavit novou výlohu od nuly (ne přenést existující šablonu), zatímco migrace backendu/katalogu se řídí stejnými principy mapování dat jako každý jiný přechod. Přesun mezi dvěma headless backendy bývá na straně výlohy často méně náročný, protože frontend lze někdy jen přesměrovat na nové API místo úplného přestavění — ale katalogová, objednávková a zákaznická data backendu i tak potřebují stejně pečlivé mapování jako u jakékoli migrace.

#### Kdy je headless (a kdy není) správná volba

Headless architektury obecně vyměňují víc implementačního a průběžného vývojářského úsilí za víc flexibility v zážitku výlohy — vlastní interakce, kanály mimo web (aplikace, kiosky) nebo požadavky na výkon, které šablonová výloha nesplní. Pro obchod bez této konkrétní potřeby je tradiční platforma obvykle jednodušší na provoz i migraci. Toto rozhodnutí stojí za to udělat záměrně během posouzení, ne se automaticky přiklonit k jedné nebo druhé možnosti.

#### FAQ

Q: Je headless commerce vždy rychlejší než tradiční výloha?
A: Ne automaticky — výkon závisí na tom, jak je headless výloha postavená, ne jen na volbě architektury. Špatně postavený headless frontend může být pomalejší než dobře optimalizovaná tradiční šablona.

Q: Potřebuji vlastní vývojáře na provoz headless obchodu?
A: Obecně ano, průběžně — headless výloha nepřichází s editorem šablon a možnostmi úprav přes tržiště aplikací, jaké nabízí tradiční platforma, takže změny obvykle procházejí zakázkovým vývojem místo vizuálního editoru.

Q: Můžu migrovat z tradiční platformy na headless bez ztráty SEO?
A: Ano, ale vyžaduje to stejné plánování přesměrování a struktury URL adres jako každá migrace, plus konkrétní pozornost tomu, jak nový headless frontend vykresluje obsah pro vyhledávače (tady záleží na server-side renderingu) — nestane se to automaticky jen proto, že se zachová backendová data.

Q: Které platformy podporují headless commerce?
A: Několik velkých platforem nabízí headless/API-first režim vedle tradiční výlohy nebo místo ní — správná volba závisí na vašich konkrétních požadavcích na backend, což vám pomůžeme vyhodnotit, ne se automaticky přiklánět k tomu, co je zrovna populární.

### Hreflang

URL: https://prevedshop.com/cs/slovnik/hreflang
Language: cs
Last reviewed: 2026-07-21

Hreflang je atribut HTML (a odpovídající hlavička HTTP nebo záznam v mapě webu), který vyhledávačům říká, pro jaký jazyk a volitelně jakou zemi je stránka určená, a odkazuje na odpovídající stránku v jiných jazycích nebo regionech. Je to způsob, jakým vícejazyčný web řekne Googlu „tady je španělská verze, tady německá“, místo aby nechal vyhledávače hádat.

#### Co hreflang skutečně dělá

Stránka se značením hreflang uvádí sadu alternativních URL adres, každou označenou kódem jazyka (a volitelně regionem, jako `es` vs. `es-MX`), plus speciální záznam `x-default` pro návštěvníky, kteří neodpovídají žádnému uvedenému jazyku. Vyhledávače to používají k tomu, aby danému hledajícímu servírovaly správnou jazykovou verzi vašeho webu a aby vaše přeložené stránky nepovažovaly navzájem za duplicitní obsah.

Každá stránka v této skupině musí odkazovat na všechny ostatní stránky ve skupině, včetně sebe sama — běžným zdrojem chyb je jednosměrný odkaz (stránka A odkazuje na stránku B, ale B neodkazuje zpět na A).

#### Proč na tom záleží při migraci platformy

Pokud váš obchod funguje ve více jazycích, migrace je přesně ta chvíle, kdy má hreflang tendenci se rozbít — struktury URL adres se mění podle lokality a je snadné, aby mechanismus přepínání jazyků na nové platformě automaticky nesestavil správné skupiny hreflang pro každou trasu, zvlášť u tras, které ještě nemají živý překlad. Neúplné nebo nekonzistentní nastavení hreflang může způsobit, že se ve špatné zemi zobrazí špatná jazyková verze, nebo zředit signál pro pozice napříč téměř duplicitními lokalizovanými stránkami.

Hreflang by se měl ověřit pro každý vzor URL adresy v nové informační architektuře, ne jen na domovské stránce — pokud jsou vícejazyčné, potřebují ho stránky produktů, kategorií i jakékoli obsahové stránky.

#### Časté chyby

Nejčastějšími problémy jsou chybějící zpětné odkazy (A odkazuje na B, B neodkazuje zpět), nasměrování hreflang na URL adresu, která vrací přesměrování nebo chybu 404 místo živé stránky, a použití špatného formátu kódu jazyka/regionu. Žádná z těchto chyb obvykle nezpůsobí přímý postih, ale znamenají, že vyhledávače nemusí signál vůbec respektovat, čímž se míjí smysl jeho přidání.

#### FAQ

Q: Je hreflang totéž co přepínač jazyků na mém webu?
A: Ne — přepínač jazyků je prvek uživatelského rozhraní pro návštěvníky; hreflang je signál pro vyhledávače, obvykle pro návštěvníky neviditelný, který žije v hlavičce HTML stránky, HTTP hlavičce nebo mapě webu. Web může mít jedno bez druhého, i když mít obojí je standardní praxe.

Q: Potřebuji záznam x-default?
A: Doporučuje se, pokud máte záložní stránku pro návštěvníky, jejichž jazyk/region neodpovídá žádné z vašich konkrétních verzí — obvykle ukazuje na vaši výchozí jazykovou stránku.

Q: Ovlivňuje hreflang přímo mé pozice ve vyhledávání?
A: Nefunguje jako posílení pozic — ovlivňuje, která z vašich stránek se zobrazí hledajícím v daném jazyce/regionu, a pomáhá zabránit tomu, aby se vaše přeložené stránky navzájem považovaly za nežádoucí duplicity.

Q: Dá se hreflang nastavit v mapě webu místo na stránce?
A: Ano, podle dokumentace vyhledávačů jsou platné oba způsoby — některé weby preferují hreflang v mapě webu, protože se snáz programově generuje a validuje pro velké množství URL adres, což je přístup, který obecně používáme u migrovaných webů.

Sources:
- Google Search Central: Informujte Google o lokalizovaných verzích stránky: https://developers.google.com/search/docs/specialty/international/localized-versions

### Produktový feed

URL: https://prevedshop.com/cs/slovnik/produktovy-feed
Language: cs
Last reviewed: 2026-07-21

Produktový feed je strukturovaný export vašeho katalogu — typicky CSV, XML nebo JSON — postavený pro to, aby ho podle harmonogramu četl jiný systém: dodavatel vám posílá svůj katalog, nebo váš obchod posílá svůj katalog na tržiště, srovnávač cen nebo reklamní platformu (jako feed Google Nákupy). Každý feed se řídí konkrétním formátem, který přijímající systém očekává: určitá pole, v určité struktuře, někdy s vlastními povinnými identifikátory.

#### Příchozí vs. odchozí feedy

Příchozí feed přichází od dodavatele nebo distributora do vašeho obchodu — nové stavy skladu, ceny a produktová data, která vaše platforma musí podle harmonogramu zpracovat. Odchozí feed jde opačným směrem — katalog vašeho obchodu naformátovaný pro tržiště, srovnávač zboží nebo reklamní platformu, aby ho mohly zpracovat. Migrace se obvykle týká obojího: vaše nová platforma musí dál přijímat dodavatelské feedy v jakémkoli formátu, ve kterém je dodavatelé už posílají, a musí vytvářet odchozí feedy ve formátu, který každý cíl očekává, což nemusí být vždy stejné jako to, co produkovala vaše stará platforma.

#### Proč se feedy při migraci rozbijí

Formáty feedů málokdy odpovídají univerzálnímu standardu — dodavatelský feed může používat názvy polí, kódy kategorií nebo identifikátory, které byla integrace vaší staré platformy postavená na míru zpracovávat. Přechod na novou platformu znamená, že tuto logiku zpracování je třeba znovu vybudovat, ne předpokládat, že se přenese sama, i když se samotný soubor feedu nemění. Totéž platí obráceně: odchozí feed, na kterém závisí váš účet na tržišti nebo v reklamě, musí dál odpovídat požadovanému formátu daného kanálu po přechodu, jinak ho kanál může odmítnout nebo špatně přečíst.

#### Co kontroluje řízená migrace

Během posouzení namapujeme každý aktivní příchozí i odchozí feed — v jakém je formátu, na jaká pole se mapuje a jak často běží —, aby se po spuštění nic potichu nerozbilo. Dodavatelský feed, který se přestane správně zpracovávat, většinou nevyvolá chybu; jen potichu přestane aktualizovat sklad nebo ceny, což je horší než zjevná chyba, protože si toho lze dlouho nevšimnout.

#### FAQ

Q: Bude feed od mého dodavatele fungovat na nové platformě automaticky?
A: Ne automaticky — nová platforma potřebuje postavenou (nebo znovu použitou, pokud existuje kompatibilní konektor) integraci pro zpracování formátu tohoto konkrétního feedu. Každý dodavatelský feed vyhodnocujeme jednotlivě během posouzení, ne s předpokladem, že si s ním poradí obecný import.

Q: Co se stane s mým feedem pro Google Nákupy nebo tržiště během migrace?
A: Musí i po přechodu dál odpovídat požadovanému formátu cíle. Odchozí feedy kontrolujeme jako součást plánu migrace, aby kanál po spuštění váš katalog neodmítl nebo nezobrazoval neaktuální data.

Q: Je produktový feed totéž co export do CSV?
A: Export do CSV může být produktový feed, ale „feed“ obvykle znamená opakující se, automatizovanou výměnu podle harmonogramu, ne jednorázový ruční export — i když podkladový formát souboru může být identický.

Q: Můžou dva systémy pro stejná data používat úplně jiné formáty feedu?
A: Ano, to je běžné — stejná katalogová data se mohou exportovat jako jedna struktura XML pro jedno tržiště a jiná struktura CSV pro druhé, nebo používat úplně jiné názvy polí a taxonomie kategorií, což vyžaduje samostatné mapování pro každý z nich.

### Replatforming

URL: https://prevedshop.com/cs/slovnik/replatforming
Language: cs
Last reviewed: 2026-07-21

Replatforming znamená přesun e-shopu z jedné platformy na druhou — ne redesign na stejné platformě a ne drobný upgrade verze, ale skutečnou změnu podkladového systému, který váš obchod pohání. Je to zastřešující pojem pro celý projekt: migrace dat, plánování přesměrování, přestavba šablony/výlohy a opětovné propojení integrací jsou všechno součásti replatformingu.

#### Co se počítá jako replatforming (a co ne)

Přechod z Magenta na Shopify je replatforming. Upgrade z Magenta 1 na Magento 2 je dá se říct také replatforming, protože podkladové systémy jsou dost odlišné na to, aby vyžadovaly skutečnou migraci, ne jen aktualizaci. Redesign šablony na stejné platformě, nebo přidání nové aplikace/pluginu, replatforming není — podkladový systém a váš datový model zůstávají stejné.

#### Časté důvody, proč obchody přecházejí na jinou platformu

Spouštěčem bývá obvykle jeden nebo více z těchto důvodů: současná platforma nezvládá funkci nebo škálování, které byznys potřebuje, průběžné náklady na údržbu samostatně hostované platformy (hosting, bezpečnostní záplaty, shoda s PCI) už nedávají smysl, platforma se blíží konci životnosti nebo ztrácí podporu dodavatele, nebo byznys přerostl to, co dokáže šablonová výloha. Málokdy jde o jediný důvod — obvykle jde o nahromadění tření, které nakonec převáží náklady a riziko přechodu.

#### Proč se k replatformingu přistupuje jako k projektu, ne úkolu

Nejrizikovější částí replatformingu není výběr nové platformy — je to všechno, co se musí správně přenést, aby byznys neztratil data, pozice v SEO nebo provozní kontinuitu: katalog, zákaznické záznamy, historii objednávek, strukturu URL adres a jejich přesměrování, dodavatelské feedy a jakoukoli vlastní logiku, kterou stará platforma provozovala. Přistupovat k tomu jako k jedinému úkolu importu místo naplánovaného projektu je přesně to, odkud pochází většina skutečného rizika migrace.

#### FAQ

Q: Jak dlouho replatforming obvykle trvá?
A: Hodně záleží na velikosti katalogu, složitosti dat, počtu existujících integrací a míře vlastní funkčnosti, kterou je třeba znovu vybudovat — univerzální harmonogram neexistuje. Reálný odhad dáme až po posouzení konkrétního obchodu, ne obecné číslo.

Q: Musím přejít na jinou platformu, jen když chci nový design?
A: Ne — redesign na vaší současné platformě je obvykle jednodušší a méně rizikový než replatforming a nevyžaduje migraci dat ani přestavbu integrací. Replatforming dává smysl, když je omezením samotná platforma, ne jen její vzhled.

Q: Jaké je největší riziko projektu replatformingu?
A: Ztráta pozic v SEO kvůli nefunkčním přesměrováním a problémy s kvalitou dat (rozbité vztahy variant, ztracené zákaznické záznamy, neodpovídající historie objednávek) z neúplné nebo naivní migrace dat — oběma se dá s pořádným plánováním vyhnout, a obě jsou běžné, když se s nimi nepočítá.

Q: Můžu přejít na jinou platformu bez odstávky?
A: Odstávku lze minimalizovat pečlivým plánováním spuštění (testovací prostředí, načasování přepnutí DNS/provozu, finální synchronizace dat), ale slíbit nulovou odstávku jako záruku není něco, co jsme ochotni prohlašovat bez znalosti vašeho konkrétního nastavení — jak k této otázce přistupujeme na rovinu, popisuje naše stránka o bezpečnosti.

### Mapování SKU

URL: https://prevedshop.com/cs/slovnik/mapovani-sku
Language: cs
Last reviewed: 2026-07-21

Mapování SKU je proces spárování každého identifikátoru produktu (SKU — skladové číslo) ze starého systému s jeho správným ekvivalentem na novém, aby objednávky, sklad i dodavatelské feedy před migrací i po ní dál odkazovaly na stejný fyzický produkt. Zní to mechanicky, ale je to jedno z míst, kde se migrace nejčastěji pokazí, pokud se to zautomatizuje naslepo místo kontroly.

#### Proč se SKU nepřenášejí vždy čistě

V ideální migraci se každé SKU na staré platformě mapuje 1:1 na stejné SKU na nové a nic se nemění. V praxi mají platformy často odlišná pravidla pro to, co může SKU obsahovat, jinak řeší SKU na úrovni varianty vs. produktu, nebo má stará platforma historii duplicitních či opakovaně použitých SKU, kterou je třeba vyřešit, ne ji beze změny přenést dál. Přímý export databáze tyto nesrovnalosti může přenést dál místo toho, aby je opravil.

#### Kde se mapování SKU propojuje s dalšími systémy

Vaše SKU je často spojovacím klíčem mezi vaším obchodem a vším kolem něj — dodavatelskými feedy, skladovým nebo fulfillmentovým systémem, účetním softwarem, nabídkami na tržištích. Pokud se SKU během migrace změní formátem nebo hodnotou, aniž by se aktualizoval každý propojený systém, tyto integrace přestanou produkty správně spárovávat, i když samotný obchod vypadá v pořádku. Mapování musí brát v úvahu i tyto navazující systémy, ne jen samotnou novou platformu.

#### Co kontrolujeme před migrací SKU

Před rozhodnutím, zda SKU zachovat beze změny, nebo je na nové platformě normalizovat, zaudituovali existující sadu SKU kvůli duplicitám, nekonzistentnímu formátování a osiřelým SKU (odkazovaným v objednávce nebo feedu, ale bez aktivního produktu). Zachování stávajících SKU je obvykle výhodnější, pokud na nich závisí navazující systémy; normalizace dává smysl, když byl problémem samotný starý systém SKU.

#### FAQ

Q: Mám si zachovat přesně stejná SKU na nové platformě?
A: Obvykle ano, pokud na nich závisí jakýkoli dodavatelský feed, fulfillmentový systém nebo nabídka na tržišti — změna SKU tyto integrace rozbije, pokud se současně neaktualizují. Toto hodnotíme případ od případu, ne s automatickým přiklonem k jedné nebo druhé možnosti.

Q: Co se stane s duplicitními SKU během migrace?
A: Musí se vyřešit před migrací nebo během ní, ne přenést dál — většina platforem skutečné duplicity SKU nepovoluje, a nechat automatizovaný import hádat, jak je sloučit, riskuje sloučení nebo vypuštění špatného produktu.

Q: Ovlivňuje mapování SKU mou historii objednávek?
A: Může, pokud historické objednávky odkazují na SKU, která se mění — počítáme s tím, aby se staré záznamy objednávek po přechodu stále správně spárovaly se správným produktem, ne jen s mapováním živého katalogu.

Q: Je mapování SKU automatizované, nebo ruční?
A: Je to kombinace — přímočaré shody 1:1 lze zautomatizovat a rychle ověřit, ale nejednoznačné případy (duplicity, nekonzistentní formáty, chybějící SKU) potřebují lidské rozhodnutí, ne algoritmus fungující na nejlepší odhad.

### Strukturovaná data

URL: https://prevedshop.com/cs/slovnik/strukturovana-data
Language: cs
Last reviewed: 2026-07-21

Strukturovaná data jsou značení přidané ke stránce (nejčastěji podle slovníku schema.org, ve formátu JSON-LD), které strojově čitelným způsobem popisuje její obsah — označí stránku jako Product s cenou a dostupností, nebo Organization s názvem a URL adresou, místo aby to vyhledávače musely odvozovat z viditelného textu. Právě to umožňuje, aby se ve výsledcích vyhledávání zobrazily rozšířené prvky jako hvězdičkové hodnocení, cena nebo rozbalovací FAQ přímo ve výsledcích.

#### Co strukturovaná data skutečně umožňují

Vyhledávače často dokážou obyčejnému obsahu stránky porozumět dost dobře, ale strukturovaná data odstraňují nejednoznačnost a odemykají konkrétní prvky prezentace — rozšířené produktové výsledky s cenou/dostupností/hodnocením, akordeony FAQ zobrazené přímo ve výsledcích vyhledávání, drobečkovou navigaci v úryvku výsledku a další. Nic z toho není zaručené (vyhledávače samy rozhodují, kdy to použít), ale bez značení tyto prvky obecně nejsou dostupné vůbec.

#### Proč to při migraci vyžaduje pozornost

Strukturovaná data negeneruje automaticky každá platforma, a ty, které je generují, to nedělají všechny stejně — schéma produktu, schéma FAQ a schéma drobečkové navigace musí odrážet to, co je na stránce skutečně přítomné. Migrace je běžné místo, kde strukturovaná data buď úplně vypadnou (nová šablona je neobsahuje), nebo se stanou nepřesnými (označená data už neodpovídají viditelnému obsahu stránky), což mohou vyhledávače spíš penalizovat než odměnit.

#### Označte jen to, co je skutečně pravdivé

Nejdůležitější pravidlo strukturovaných dat je, že by měla popisovat něco skutečného a viditelného na stránce — značení FAQPage jen tam, kde je FAQ skutečně zobrazené, značení Review/rating jen pro recenze, které skutečně existují, značení Product se skutečnou cenou a skutečnou dostupností. Značení, které neodpovídá viditelné stránce, porušuje vlastní pravidla vyhledávačů a může vést k tomu, že se strukturovaná data ignorují nebo je stránka penalizována, ne jen že „nepomůžou“.

#### FAQ

Q: Zaručí strukturovaná data rozšířené výsledky ve vyhledávání?
A: Ne — umožňují rozšířené výsledky, ale vyhledávače samostatně rozhodují, zda je zobrazí, podle relevance a vlastních kontrol kvality. Konkrétní rozšířený výsledek nelze zaručit.

Q: Přidá má nová platforma strukturovaná data automaticky?
A: Některé platformy generují základní strukturovaná data (jako značení Product) ve výchozím stavu; jiné je potřebují přidat výslovně přes šablonu nebo aplikaci. Kontrolujeme, co nová platforma nabízí hned po instalaci, a doplňujeme mezery, ne s předpokladem, že je to vyřešené.

Q: Může přidání strukturovaných dat poškodit mé SEO?
A: Jen pokud jsou nepřesná nebo manipulativní — značení, které neodpovídá skutečnému obsahu stránky, porušuje pravidla vyhledávačů. Přesná strukturovaná data odrážející skutečný obsah stránky toto riziko nenesou.

Q: Jaká je nejčastější chyba se strukturovanými daty při migraci?
A: Jejich úplná ztráta, když je nová šablona nepřenese tak, jak je měla stará platforma, nebo ponechání zastaralého značení, které už neodpovídá redesignované stránce — obojí kontrolujeme v rámci testování migrace.

Sources:
- Google Search Central: Jak fungují strukturovaná data: https://developers.google.com/search/docs/appearance/structured-data/sd-policies

### URL slug

URL: https://prevedshop.com/cs/slovnik/url-slug
Language: cs
Last reviewed: 2026-07-21

URL slug je lidsky čitelná část adresy stránky, která ji identifikuje — v `prevedshop.com/platforms/shopify` je slugem „shopify“. Obvykle se odvozuje z názvu produktu nebo stránky, převádí se na malá písmena a bezpečnou podobu pro URL adresu, a je to přesně to, co návštěvníci i vyhledávače skutečně vidí a na co odkazují, když na stránku odkazují nebo si ji ukládají do záložek.

#### Proč na slugu záleží víc než jen kvůli čitelnosti

Jasný, popisný slug pomáhá návštěvníkům pochopit, o čem stránka je, ještě než na ni kliknou, a vyhledávače relevantním slovům v URL adrese skutečně přikládají určitou váhu. Ale větší význam slugu je strukturální: je součástí trvalé adresy stránky, na kterou odkazuje každý interní i externí odkaz, uložená záložka a zaindexovaný výsledek vyhledávání.

#### Proč migrace často mění slugy, záměrně i nezáměrně

Každá platforma má vlastní pravidla pro to, jak se slugy generují a strukturují — limity délky, povolené znaky, jestli jsou slugy produktů vnořené pod cestou kategorie nebo ploché, jak se řeší stejnojmenné produkty. Přechod na novou platformu často změní přinejmenším některé slugy, někdy proto, že nová platforma vynucuje jiný vzor, někdy proto, že jde o příležitost opravit nepořádné, starší slugy ze starého systému. Tak či onak, změněný slug znamená změněnou URL adresu a změněná URL adresa potřebuje přesměrování (viz přesměrování 301) ze staré adresy.

#### Udržení slugů stabilních tam, kde na tom záleží

U stránek se smysluplnými existujícími pozicemi ve vyhledávání nebo velkým počtem příchozích odkazů zachování přesně stejného slugu na nové platformě (pokud to platforma umožňuje) zcela odstraní potřebu přesměrování a je to často nejjednodušší způsob, jak zachovat postavení dané stránky. Tam, kde se slug musí změnit, je to, co udrží přechod čistý, naplánovat nový slug spolu s jeho přesměrováním společně — místo aby ho platforma automaticky vygenerovala a URL adresa se řešila až dodatečně.

#### FAQ

Q: Můžu si na nové platformě zachovat přesně staré URL slugy?
A: Často ano, pokud to pravidla URL adres nové platformy umožňují a nastavíte je záměrně místo přijetí automaticky vygenerovaných — to je jeden z nejjednodušších způsobů, jak se pro danou stránku úplně vyhnout potřebě přesměrování.

Q: Poškodí změna slugu SEO?
A: Ne, pokud je spárovaná s pořádným přesměrováním 301 ze starého slugu na nový — přesměrování přenese většinu nahromaděného signálu pro pozice dál. SEO poškozuje změna slugu bez přesměrování, ne samotná změna slugu.

Q: Mám jako slug použít přesně název produktu?
A: Obecně ano, zjednodušený tak, aby byl bezpečný pro URL adresu (malá písmena, spojovníky místo mezer, bez speciálních znaků) — slugy nacpané nesouvisejícími klíčovými slovy nad rámec skutečného tématu stránky nepřinášejí žádný extra přínos a působí na návštěvníky i vyhledávače jako spam.

Q: Co se stane, když by dva produkty generovaly stejný slug?
A: Platforma potřebuje pravidlo pro rozlišení — obvykle připojení čísla nebo dalšího identifikátoru. Toto při migraci kontrolujeme, protože kolize duplicitních slugů jinak mohou způsobit, že stránka jednoho produktu potichu přepíše URL adresu druhého.

### Services

### Migrace a mapování dat e-shopu

URL: https://prevedshop.com/cs/sluzby/cisteni-a-mapovani-dat
Language: cs
Last reviewed: 2026-07-20

Staré katalogy si postupně nahromadí duplicitní produkty, nekonzistentní kategorie a pole, jejichž účel si už nikdo nepamatuje. Tohle vyčistíme a to, co zůstane, namapujeme na skutečný datový model nové platformy — místo abychom nepořádek jen zkopírovali.

#### Co hledáme

Duplicitní nebo téměř duplicitní produkty, osiřelé kategorie, nekonzistentní pojmenování atributů, prázdná nebo poškozená pole a stará vlastní pole, která už nic smysluplného nereprezentují. Co najdeme, s vámi projdeme a domluvíme se, co opravit, sloučit nebo zahodit.

#### Mapování, ne hádání

Každé zdrojové pole dostane výslovné mapování na cílové pole — nebo výslovné rozhodnutí, že se nemapuje a potřebuje jiné místo (vlastní pole, štítek, nebo nikam). Toto mapování dokumentujeme, aby bylo možné jej zpětně ověřit, ne aby zůstalo černou skříňkou.

#### Proč na tom záleží ještě před spuštěním

Vyčištění a mapování dat před migrací je mnohem levnější než jejich oprava po spuštění, kdy už se na ně spoléhají zákazníci i vyhledávače. Přeskočení tohoto kroku je jeden z nejčastějších důvodů, proč později migrace naráží na potíže.

#### FAQ

Q: Smažete data bez mého souhlasu?
A: Ne — co vypadá jako problém, s vámi projdeme a na dalším postupu se domluvíme dřív, než se cokoliv sloučí nebo odstraní.

Q: Umíte odstranit duplicity napříč více starými importy?
A: Ano, to je jeden z nejčastějších požadavků při čištění — starší e-shopy, které za ta léta prošly několika importy dodavatelských feedů, mívají skutečné duplicity.

Q: Řešíte i vlastní pole bez jasného účelu?
A: Prozkoumáme, k čemu pole pravděpodobně sloužilo (na základě vzorců v datech a případně i vašich informací), než rozhodneme, zda ho namapovat, využít jinak, nebo zrušit.

### Změna e-shopové platformy od rozhodnutí po spuštění

URL: https://prevedshop.com/cs/sluzby/zmena-eshopove-platformy
Language: cs
Last reviewed: 2026-09-25

Změna platformy (replatforming) je nejdřív obchodní rozhodnutí a teprve potom migrace dat. Měníte systém, na kterém běží katalog, pokladna, integrace i organická návštěvnost – obvykle proto, že ten současný je příliš drahý, omezující nebo rizikový. Pomůžeme vám rozhodnout se na základě faktů a pak přechod naplánujeme a provedeme tak, aby nová platforma startovala s daty, URL i integracemi.

#### Kdy se změna platformy vyplatí a kdy ne

Oprávněné důvody: platforma skončila podporu nebo nedostává bezpečnostní aktualizace (Magento 1, Shopware 5); hosting, záplaty a údržba rozšíření stojí víc, než e-shop unese; platforma brání v tom, co firma potřebuje – nové trhy, B2B ceny, headless frontend, moderní pokladna; nebo tým tráví čas udržováním systému místo prodeje.

Slabé důvody jsou zastaralá šablona, jedna chybějící funkce, kterou by vyřešil doplněk, nebo prezentace obchodníka. Redesign nebo cílená integrace často vyjde levněji. Když je to tak, řekneme vám to.

#### Nejdřív požadavky, pak výběr platformy

Vycházíme z toho, co e-shop skutečně dělá: struktura katalogu a typy produktů, cenová pravidla a zákaznické skupiny, trhy, jazyky a měny, napojení na ERP, sklad a dopravce, srovnávače a feedy, obsah a SEO a vlastní funkce, za které kdysi někdo zaplatil. Každý požadavek označíme jako nutný, nahraditelný nebo k vyřazení. S tímto seznamem pak porovnáváme kandidátní platformy.

#### Co se při změně platformy rozbije

Datový model se málokdy shoduje: atributy, varianty, sady a stromy kategorií se v cíli chovají jinak. Mění se struktura URL, takže každá důležitá adresa potřebuje cíl a přesměrování 301. Doplňky a aplikace se nepřenášejí – jejich data a funkce potřebují náhradu, přestavbu nebo rozhodnutí o vyřazení. Integrace s ERP, účetnictvím, dopravci a tržišti je nutné přepojit a otestovat. Hesla zákazníků se na hostované platformy obvykle převést nedají.

#### Celkové náklady, ne jen cena licence

Porovnejte celý obraz na několik let: předplatné nebo licence, hosting a bezpečnost, platební poplatky, aplikace a rozšíření, vývoj, samotnou migraci a interní čas na provoz. Levnější tarif s pěti placenými doplňky a vlastní integrací může ve výsledku stát víc. Srovnání vám pomůžeme sestavit z vašich požadavků; licence platforem neprodáváme.

#### Od rozhodnutí ke spuštění

Po výběru cíle se změna platformy stává řízenou migrací: audit zdroje, mapování dat, zkušební migrace a schválení, plán SEO a přesměrování, přepojení integrací, zmrazení obsahu, rozdílová migrace, spuštění a kontrola po spuštění. Větší e-shopy často přecházejí po etapách, aby šel každý krok ověřit.

#### FAQ

Q: Jaký je rozdíl mezi změnou platformy a migrací?
A: Změna platformy je rozhodnutí a projekt přechodu firmy na nový e-shopový systém. Migrace je jeho část, která přenáší data, URL a obsah. Každá změna platformy zahrnuje migraci, ale ne každá migrace vyžaduje nové rozhodnutí o platformě.

Q: Jak dlouho změna platformy trvá?
A: Záleží na složitosti katalogu, integracích, grafice a rychlosti rozhodování. Termín stanovíme po posouzení podle těchto faktorů.

Q: Přejít na Shopify, Shoptet, Shopware, nebo zůstat?
A: Záleží na vašich požadavcích, trzích, integracích a rozpočtu. Možnosti porovnáme s vaším seznamem nutných požadavků a celkovými náklady; zůstat na současné platformě je legitimní výsledek.

Q: Dá se platforma změnit bez ztráty SEO?
A: Pozice nelze zaručit. Riziko snižuje kompletní soupis URL, přesměrování 301 na nejbližší nové stránky, převzatá metadata, upravené interní odkazy a sledování po spuštění.

### Řízená migrace e-shopu: jeden člověk od auditu po spuštění

URL: https://prevedshop.com/cs/sluzby/rizena-migrace
Language: cs
Last reviewed: 2026-07-20

Jeden odpovědný vedoucí migrace naplánuje, provede a ověří váš přechod: produkty, varianty, zákazníky, objednávky, média, obsah i design obchodu — jako jeden koordinovaný projekt, ne hromadu nesouvisejících exportů.

#### Co je součástí

Řízená migrace pokrývá celý katalog — produkty, varianty, kategorie a atributy —, zákaznické účty a historii objednávek, média a obsah, vlastní pole i plán URL/přesměrování. Design obchodu se přenáší nebo znovu vytváří na cílové platformě jako součást stejného projektu, ne jako pozdější nemilé překvapení na faktuře.

Rozsah přesně určíme už při posouzení, takže nemusíte hádat, co „migrace“ zahrnuje, až do doby, kdy přijde faktura.

#### Jak funguje přenos designu

Tam, kde to cílová platforma reálně umožňuje, design znovu vytvoříme. Tam, kde jsou platformy příliš odlišné na přesnou kopii, vám to řekneme předem a navrhneme postup — přizpůsobení designu možnostem nové platformy, ne předstírání, že jde o jednoduché zkopírování.

#### Jeden vedoucí od začátku do konce

Jmenovaný vedoucí migrace nese odpovědnost za celý projekt — posouzení, mapování, testovací migraci, validaci, spuštění i kontroly po spuštění. Opakovatelné automatické kontroly pomáhají prověřit data a označit nesrovnalosti, každou fázi však před pokračováním kontroluje a schvaluje vedoucí.

#### FAQ

Q: Jak dlouho řízená migrace trvá?
A: Záleží na velikosti katalogu, složitosti dat a počtu vlastních polí či integrací — reálný harmonogram vám dáme až po posouzení, ne obecný odhad.

Q: Co když moje současná platforma nemá čistý export?
A: Pracujeme s tím, co máte — databázové exporty, přístup k API, XML/CSV feedy nebo jejich kombinaci. Nepřehlednější zdroje si vyžádají více času na posouzení, se kterým počítáme předem.

Q: Migrujete i nainstalované aplikace a integrace?
A: Migrujeme data, na kterých tyto aplikace stojí, ale konfiguraci konkrétní aplikace je obvykle třeba znovu sestavit v ekvivalentu na cílové platformě, pokud existuje. Na to upozorníme už při posouzení, ne až při spuštění.

### SEO migrace e-shopu a mapa přesměrování 301

URL: https://prevedshop.com/cs/sluzby/seo-a-presmerovani
Language: cs
Last reviewed: 2026-07-20

Struktura URL jen málokdy přežije změnu platformy beze změny. Relevantní staré adresy mapujeme na nové cíle a přesměrování připravujeme jako plánovanou součást migrace, která omezuje nefunkční odkazy a zbytečné SEO riziko, ale neslibuje stejné pozice.

#### Mapování URL, ne hádání

Sestavíme výslovnou mapu z každé smysluplné staré URL na její nový ekvivalent — produktové stránky, kategorie, blog či obsahové stránky i vlastní vstupní stránky. Stránky bez čistého ekvivalentu dostanou zdokumentované rozhodnutí, ne tichou chybu 404.

#### Přesměrování a metadata

301 přesměrování implementujeme na nové platformě ještě před spuštěním a metadata (titulky, popisy, kanonické značky) přebíráme tam, kde jsou pro novou URL skutečně stále přesná. Kontrolujeme řetězení a smyčky přesměrování, místo abychom předpokládali, že mapa 1:1 je automaticky čistá.

#### Co můžeme a nemůžeme slíbit

Konkrétní pozice ve vyhledávání nemůžeme garantovat — to poctivě nedokáže nikdo, protože pozice závisí na mnoha faktorech mimo samotnou migraci. Co ale kontrolujeme a bereme jako pevný požadavek, je kontinuita URL: aby staré odkazy a záložky vedly na správnou novou stránku, ne do slepé uličky.

#### FAQ

Q: Jak při migraci snížit riziko propadu pozic v Google?
A: Přesné mapování URL, jednoskoková přesměrování, konzistentní canonical značky, aktualizované interní odkazy a následné kontroly jsou důležité nástroje. Bereme je jako klíčový výstup, ale konkrétní pozice garantovat nelze, protože závisí i na faktorech mimo migraci.

Q: Co se stane se stránkami, které na nové platformě neexistují?
A: Označíme je už ve fázi mapování a domluvíme se s vámi na nejlepším cíli přesměrování — obvykle nejbližší odpovídající kategorii nebo relevantní rozcestník, ne obecné přesměrování na hlavní stránku.

Q: Aktualizujete i interní odkazy, nejen externí přesměrování?
A: Pokud je to prakticky možné, ano — interní odkazy vedoucí na staré vzory URL aktualizujeme v rámci migrace, protože řetězení přesměrování zpomaluje načítání a oslabuje hodnotu odkazu.

### Napojení dodavatelských feedů

URL: https://prevedshop.com/cs/sluzby/napojeni-dodavatelskych-feedu
Language: cs
Last reviewed: 2026-07-20

Provoz katalogu na dodavatelských feedech znamená řešit nekonzistentní formáty, duplicitní SKU napříč dodavateli i časování aktualizací, které neodpovídá očekáváním vaší platformy. Tyto feedy napojíme a sjednotíme, aby zůstal katalog přesný bez ruční údržby.

#### Co sjednocujeme

Dodavatelské feedy málokdy sdílejí formát — názvy polí, strukturu kategorií i měrné jednotky se liší dodavatel od dodavatele. Každý feed namapujeme na jednotnou strukturu ve vaší platformě, aby se produkty v katalogu chovaly stejně bez ohledu na zdroj.

#### Duplicity a slučování

Pokud stejný produkt nabízí více dodavatelů, umíme nabídky sloučit, zvolit preferovaný zdroj, nebo je ponechat oddělené — podle toho, jak chcete řešit cenu a dostupnost. Toto rozhodnutí děláme s vámi, ne jako výchozí nastavení, které vám vnutíme.

#### Udržení aktuálnosti dat

Frekvence aktualizace feedů závisí na tom, co dodavatelé skutečně nabízejí a co dokáže platforma rozumně zpracovat — domluvíme reálný harmonogram, místo abychom slibovali aktualizace v reálném čase, které zdrojový feed neumí podporovat.

#### FAQ

Q: Umíte sloučit feedy od více dodavatelů do jednoho katalogu?
A: Ano — sloučení, odstranění duplicit a sjednocení více dodavatelských feedů do jednoho konzistentního katalogu je běžnou součástí této služby.

Q: Co se stane, když dodavatel produkt vyprodá?
A: Podle vašich preferencí ho můžeme označit jako nedostupný, skrýt, nebo ponechat viditelný se stavem předobjednávky — nastaví se jednou a při dalších aktualizacích feedu se uplatní automaticky.

Q: Lze dodavatelské feedy přeložit pro jiné trhy?
A: Ano, obsah feedu lze přeložit, ať už automatickým překladem, nebo podle vlastního mapování, které nám poskytnete, podle požadované přesnosti.


## Slovenčina (sk)

### Platform profiles

### Migrácia na Adobe Commerce (Magento) a z neho

URL: https://prevedshop.com/sk/platformy/adobe-commerce-magento
Language: sk
Last reviewed: 2026-07-21

Pod pojmom „Magento“ sa dnes skrýva niekoľko rôznych vecí: platforma s otvoreným zdrojovým kódom Magento Open Source, platená úroveň Adobe Commerce Cloud a staršie inštalácie Magento 1, ktoré už majú ukončenú podporu. To, ktorú z nich skutočne prevádzkujete, výrazne mení plán migrácie, takže presné určenie verzie a edície je prvý krok bez ohľadu na to, či je Magento váš zdroj alebo cieľ.

#### Magento Open Source, Adobe Commerce a Magento 1 vs. 2

Magento Open Source je bezplatný, samostatne hosťovaný e-commerce softvér postavený na PHP; Adobe Commerce (predtým Magento Commerce) je platená úroveň s doplnkovými B2B funkciami, staging obsahu a cloudovým hostingom, prevádzkovaná na infraštruktúre spravovanej Adobe. Magento 1 dosiahlo koniec podpory pred rokmi a obchody, ktoré na ňom stále bežia, migrujú väčšinou práve z tohto dôvodu, nezávisle od akéhokoľvek porovnávania platforiem.

Práve pre tento rozsah môže „migrácia z/na Magento“ znamenať presun malého obchodu na Magento 1 na úplne inú platformu, presun z Magento 1 na Magento 2 (stále Magento, ale prestavba na hlavnú verziu), alebo odchod z Adobe Commerce Cloud na riešenie s inou nákladovou štruktúrou. Ktorá z týchto možností platí, si určíme skôr, než čokoľvek odhadneme.

#### EAV dátový model a nastavenie s viacerými obchodmi

Magento ukladá produktové dáta v štruktúre EAV (entity-attribute-value), ktorá je silná pri vysoko konfigurovateľných, atribútmi bohatých katalógoch, no štrukturálne odlišná od jednoduchších plochých tabuliek produktov, aké používa väčšina ostatných platforiem. Konfigurovateľné produkty (obdoba variantov v Magento), vlastné sady atribútov a vrstvená navigácia riadená atribútmi si pri presune na platformu bez ekvivalentu EAV vyžadujú explicitné mapovanie.

Architektúra Magento s viacerými obchodmi/webmi, teda prevádzka viacerých vitrín, mien alebo lokalít z jednej inštalácie, je ďalšia vec, ktorú treba starostlivo namapovať, keďže väčšina platforiem rieši viacero obchodov odlišne: samostatné obchody, jeden obchod s nastaveniami pre konkrétny trh, alebo žiadny natívny ekvivalent.

#### Rozšírenia, vlastné moduly a vývojári Magento

Obchody na Magento sa bežne spoliehajú na rozšírenia z marketplace a zákazkovo vytvorené moduly pri všetkom nad rámec základnej funkcionality — pri platobných metódach, B2B cenových pravidlách alebo katalógovej logike špecifickej pre daný biznis. Keďže Magento je platforma náročná na vývojárov, značná časť toho, čo obchod „robí“, často žije vo vlastnom PHP kóde, nie v nastaveniach administrácie, a túto logiku treba identifikovať a buď znovu vybudovať, alebo nahradiť — nie len exportovať.

Rovnako je to so šablónami: šablóny Magento sú postavené na vlastnom systéme layout XML/blokov, ktorý nemá priamy ekvivalent inde, takže odchod z Magento zvyčajne znamená vybudovanie vitríny na novej platforme od základov.

#### SEO, URL adresy a ako riešime migráciu Magento

Magento interne spravuje prepisovanie URL adries a podporuje pomerne flexibilné štruktúry URL, no konkrétne detaily (cesty kategórií, prípony URL produktov, URL adresy špecifické pre jednotlivé obchody) sa medzi obchodmi výrazne líšia podľa konfigurácie. Práve táto rôznorodosť je dôvod, prečo začíname auditom vašich skutočných živých vzorov URL, nie predpokladom predvoleného nastavenia Magento.

Pri migrácii Magento budujeme mapu URL adries a presmerovaní podľa toho, čo váš obchod skutočne robí dnes, riešime varianty URL pre viacero obchodov tam, kde je to relevantné, a overujeme, že metadáta a kanonické značky sa prenesú správne. Podrobnejšie to popisuje naša služba SEO a migrácia presmerovaní.

#### FAQ

Q: Stále mám Magento 1. Viete to migrovať?
A: Áno, odchod z Magento 1 je jeden z bežnejších projektov, s ktorými sa stretávame, väčšinou vyvolaný ukončenou podporou, nie preferenciou platformy. Riešime to ako kompletný replatforming, keďže Magento 1 a 2 majú odlišnú podkladovú architektúru.

Q: Čo sa stane s mojimi vlastnými modulmi Magento?
A: Zistíme, čo každý vlastný modul skutočne robí — napríklad platobnú integráciu, cenové pravidlo alebo katalógovú funkciu — a preveríme, či má cieľová platforma vstavaný alebo rozšíriteľný ekvivalent, alebo či je potrebný zákazkový vývoj.

Q: Dajú sa B2B funkcie Adobe Commerce migrovať na neenterprise platformu?
A: Závisí od konkrétnej funkcie. Firemné účty, workflow pre cenové ponuky a viacúrovňové B2B ceny nemajú priamy ekvivalent na každej platforme, takže to posudzujeme individuálne pri určovaní rozsahu, nie s predpokladom presnej zhody jedna k jednej.

Q: Ako ovplyvňuje štruktúra atribútov EAV dĺžku migrácie?
A: Katalógy s množstvom vlastných atribútov a sád atribútov si vo všeobecnosti vyžadujú viac času na mapovanie než jednoduché ploché katalógy, keďže pri každom atribúte treba explicitne rozhodnúť, kam na cieľovej platforme patrí.

Sources:
- Adobe Commerce (Magento) – oficiálna stránka produktu: https://business.adobe.com/products/magento/magento-commerce.html

### Migrácia na BigCommerce a z BigCommerce

URL: https://prevedshop.com/sk/platformy/bigcommerce
Language: sk
Last reviewed: 2026-07-21

BigCommerce je hostovaná SaaS platforma, ktorá sa objavuje na oboch stranách migrácií, ktoré riešime: obchodníci na ňu prechádzajú kvôli natívnej štruktúre kategórií a headless možnostiam, a iní ju opúšťajú, keď sa zmenia ich potreby. Tak ako pri iných uzavretých, na API postavených platformách, aj pri migrácii BigCommerce najviac záleží na tom, čo sprístupňuje jeho API a dátový model, nie len na počte produktov, ktoré presúvate. Táto stránka sa venuje tomu, na čom skutočne záleží, keď je BigCommerce na jednej strane migrácie.

#### Čo je BigCommerce a kam zapadá

BigCommerce je hostovaná SaaS platforma pre e-commerce: BigCommerce spravuje hosting, bezpečnostné záplaty aj dostupnosť, a vy obchod spravujete cez jeho administráciu a API, nie cez server pod vašou kontrolou. Plány siahajú od štandardných úrovní pre malých a stredných obchodníkov až po Enterprise. Multi-Storefront je dostupný vo viacerých plánoch s rozdielnymi limitmi počtu vitrín; Enterprise môže ponúknuť vyššie limity API, úrovne podpory a ďalšie B2B funkcie. BigCommerce ponúka aj headless prístup, ktorý umožňuje využiť jeho backend a API so zákazkovo vytvoreným frontendom namiesto vlastnej vrstvy šablón.

Vitríny na štandardnej, neheadless ceste sa stavajú v rámci šablónovacieho frameworku Stencil od BigCommerce, so šablónami z BigCommerce Theme Marketplace alebo zo zákazkového vývoja. Tak ako pri každej uzavretej, hostovanej platforme, migrácie na BigCommerce a z neho prebiehajú v rámci jeho dátového modelu a rozhrania API, nie priamou kópiou databázy — takže to, čo API sprístupňuje pre produkty, objednávky a zákazníkov, určuje, čo sa dá presunúť automaticky.

#### Produkty, kategórie a dátový model

Na rozdiel od platforiem, ktoré sa spoliehajú výlučne na kolekcie založené na štítkoch, BigCommerce podporuje natívny, vnorený strom kategórií popri produktoch a ich variantoch. To z neho robí pomerne dobrú voľbu pre katalógy s viacúrovňovou štruktúrou kategórií, keďže hierarchiu kategórií nemusíte splošťovať do štítkov alebo inteligentných kolekcií tak, ako by ste museli na niektorých iných hostovaných platformách.

Zákazníci a história objednávok sa prenášajú cez REST a GraphQL API BigCommerce, no tak ako pri každej migrácii platformy, historické objednávky zvyčajne pristanú ako referenčné záznamy, nie ako plne živé, znovu editovateľné objednávky. Vlastné produktové dáta sa zvyčajne mapujú na vlastné polia BigCommerce, a cenníky (mechanizmus BigCommerce pre ceny podľa zákazníckej skupiny alebo meny) sú jedna z prvých vecí, ktoré kontrolujeme, ak má zdrojová platforma vlastné nastavenie viacúrovňových cien.

#### Aplikácie, šablóny a čo sa neprenesie automaticky

Funkčný obchod na BigCommerce sa bežne spolieha na aplikácie z BigCommerce App Marketplace — na recenzie, predplatné, vyhľadávanie, marketingovú automatizáciu alebo pravidlá dopravy. Dáta uložené v aplikáciách sa v rámci migrácie platformy neprenášajú; odchod z BigCommerce znamená exportovať čokoľvek uložené v aplikácii samostatne, a príchod na BigCommerce znamená znovu nainštalovať a nastaviť ekvivalenty namiesto prenosu nastavení aplikácie.

Šablóny Stencil sa neprenášajú do šablónovacieho systému inej platformy, takže odchod z BigCommerce zvyčajne znamená vybudovanie dizajnu vitríny na novej platforme od základov, a príchod na BigCommerce znamená úpravu šablóny z marketplace alebo zákazkový vývoj na mieru. Ak zvolíte headless prístup, frontend sa od vrstvy šablón BigCommerce úplne oddelí, čo mení, čo vlastne „migrácia dizajnu“ znamená.

#### SEO, URL adresy a ako riešime migráciu BigCommerce

BigCommerce je pri štruktúre URL flexibilnejší než niektorí hostovaní konkurenti a umožňuje nastaviť vlastné URL adresy pre produkty, kategórie aj stránky namiesto vynucovania jedného pevného vzoru. Táto flexibilita pomáha, keď migrujete na BigCommerce a chcete, aby sa URL adresy podobali tým starým, no nedeje sa to automaticky, a odchod z BigCommerce stále znamená namapovanie jeho vzorov URL na to, čo vyžaduje nová platforma.

V rámci riadenej migrácie porovnáme vašu existujúcu štruktúru URL so štruktúrou BigCommerce, nastavíme potrebné presmerovania v oboch smeroch a prenesieme metadáta, ktoré sú na nových URL adresách stále presné — rovnakým postupom, aký popisujeme pri službe SEO a migrácia presmerovaní, prispôsobeným konkrétnym obmedzeniam API a smerovania BigCommerce.

#### FAQ

Q: Zachovám si vnorenú štruktúru kategórií pri prechode na BigCommerce?
A: Áno. BigCommerce podporuje natívny, viacúrovňový strom kategórií, takže hlboká štruktúra kategórií z inej platformy sa zvyčajne namapuje priamejšie, než by to bolo na platforme, ktorá podporuje len ploché štítky alebo kolekcie.

Q: Čo sa stane s mojimi aplikáciami BigCommerce, ak odídem preč?
A: Dáta špecifické pre jednotlivé aplikácie je vo všeobecnosti potrebné exportovať samostatne z každej aplikácie pred migráciou. Migrujeme jadrové dáta obchodu, na ktorých aplikácia stavia, no nie jej internú konfiguráciu ani uložené záznamy.

Q: Mení headless možnosť BigCommerce spôsob, akým migrácia prebieha?
A: Mení to, čo znamená migrácia šablóny, keďže headless nastavenie oddeľuje frontend od vlastnej vrstvy šablón BigCommerce, no podkladové dáta o produktoch, objednávkach a zákazníkoch sa cez API stále prenášajú rovnako.

Q: Zostanú mi URL adresy rovnaké, ak prejdem na BigCommerce?
A: Len ak si zámerne nastavíte zhodné vlastné URL adresy, čo BigCommerce umožňuje pre produkty, kategórie aj stránky. Zvyčajne namiesto predpokladu presnej zhody 1:1 nastavujeme presmerovania.

Sources:
- BigCommerce – oficiálna stránka: https://www.bigcommerce.com

### Migrácia na OpenCart a z OpenCart

URL: https://prevedshop.com/sk/platformy/opencart
Language: sk
Last reviewed: 2026-07-21

OpenCart je e-commerce platforma s otvoreným zdrojovým kódom, s ktorou sa pri migráciách stretávame pravidelne, zvyčajne u obchodníkov, ktorí s ňou začali kvôli nízkym nákladom a jednoduchosti a teraz prerastajú možnosti samostatnej správy, alebo naopak u tých, ktorí si ju vyberajú práve pre jej odľahčenosť. Keďže OpenCart je open-source a samostatne hostovaný, zložitosť migrácie zvyčajne závisí od toho, ako veľmi bol obchod upravený rozšíreniami, nie len od počtu produktov v katalógu. Táto stránka sa venuje tomu, na čom skutočne záleží, keď je OpenCart na jednej strane migrácie.

#### Čo je OpenCart a kam zapadá

OpenCart je e-commerce softvér s otvoreným zdrojovým kódom postavený na PHP a MySQL, samostatne hostovaný na serveri, ktorý spravujete vy alebo váš hostingový poskytovateľ. Je známy pomerne odľahčeným jadrom a nižšou vstupnou bariérou než niektoré iné open-source platformy, čo ho robí obľúbeným medzi menšími obchodníkmi a agentúrami budujúcimi obchody s dôrazom na rozpočet. Správa viacerých obchodov z jednej administrácie je vstavaná funkcia, nie doplnok.

Vitríny využívajú vlastný šablónovací systém OpenCart, od verzie OpenCart 3 postavený na šablónovacom engine Twig, so šablónami a rozšíreniami dostupnými cez oficiálny OpenCart Marketplace alebo zo zákazkového vývoja. Tak ako pri každej samostatne hostovanej open-source platforme, množstvo vlastného kódu a rozšírení tretích strán, ktoré obchod nesie, je jedna z prvých vecí určujúcich rozsah migrácie.

#### Produkty, možnosti a dátový model

Katalóg OpenCart je postavený na produktoch usporiadaných do kategórií, pričom produktové „možnosti“ (options) riešia varianty, napríklad veľkosť alebo farbu, spôsobom, ktorý sa štrukturálne líši od dedikovaného systému variantov na úrovni SKU na niektorých iných platformách. Možnosti v OpenCart dokážu upraviť cenu a množstvo, no podkladový model nie je identický so skutočnými variantmi, čo je dôležité pri migrácii katalógu, ktorý inde používa skutočné varianty, do OpenCart, alebo z OpenCart na platformu s prísnejším modelom variantov.

Keďže je OpenCart samostatne hostovaný, na exporty je často k dispozícii priamy prístup k databáze, čo môže zjednodušiť získanie dát o produktoch, zákazníkoch a objednávkach. No obchody upravené rozšíreniami alebo so zmenenými jadrovými súbormi — bežný vzor v ekosystéme OpenCart, najmä pri starších rozšíreniach založených na VQMod alebo OCMOD — si vyžadujú identifikáciu týchto úprav skôr, než predpokladáme čistý, štandardný export.

#### Rozšírenia, šablóny a čo sa neprenesie automaticky

Funkčný obchod na OpenCart často závisí od nainštalovaných rozšírení — na platby, dopravu, marketingové nástroje alebo katalógové funkcie nad rámec jadra OpenCart. Dáta a nastavenia rozšírení sa pri migrácii platformy automaticky neprenášajú; odchod z OpenCart znamená overiť, čo každé rozšírenie ukladá, a exportovať to samostatne, a príchod na OpenCart znamená inštaláciu a nastavenie ekvivalentov z OpenCart Marketplace alebo cez zákazkový vývoj.

Šablóny OpenCart postavené na Twig sú viazané na jeho šablónovací systém a neprenášajú sa na iné platformy, takže odchod z OpenCart zvyčajne znamená vybudovanie dizajnu vitríny inde od základov, a príchod na OpenCart znamená úpravu šablóny z marketplace alebo zákazkový vývoj na mieru. Staršie inštalácie OpenCart, pred verziou 3.0, môžu stále používať skorší systém šablón, na čo treba upozorniť už na začiatku, keďže to ovplyvňuje rozsah redizajnu.

#### SEO, URL adresy a ako riešime migráciu OpenCart

OpenCart podporuje SEO priateľské prepisovanie URL adries pre produkty a kategórie, no treba ho zapnúť a nakonfigurovať — nie je to predvolený stav priamo po inštalácii — a staršie alebo silne upravené inštalácie niekedy stále bežia s predvolenými, neprívetivými URL adresami. Odchod z OpenCart znamená overiť, ktorý režim URL sa skutočne používa, skôr než predpokladáme čisté mapovanie na novú platformu.

V rámci riadenej migrácie zaudítujeme vašu súčasnú konfiguráciu URL v OpenCart (alebo naplánujeme cieľovú, ak na OpenCart prichádzate), vybudujeme mapu presmerovaní medzi starými a novými URL adresami a prenesieme metadáta, ktoré sú stále presné — rovnakým postupom, aký popisujeme pri službe SEO a migrácia presmerovaní, aplikovaným na konkrétne nastavenie OpenCart.

#### FAQ

Q: Je OpenCart bezplatný?
A: Jadro softvéru OpenCart je open-source a bezplatné na stiahnutie a samostatné hostovanie. Priebežné náklady vznikajú z hostingu, práce vývojárov a prípadných platených rozšírení či šablón z OpenCart Marketplace.

Q: Ako sa produktové možnosti OpenCart porovnávajú s variantmi na iných platformách?
A: Možnosti v OpenCart dokážu upraviť cenu a množstvo pre jednotlivé kombinácie, no nie sú štruktúrované identicky ako dedikovaný systém variantov na úrovni SKU, takže ich mapovanie na platformu s prísnejším modelom variantov, alebo z nej, si vyžaduje starostlivé posúdenie, nie priamu zhodu polí.

Q: Viete migrovať moje rozšírenia OpenCart a ich dáta?
A: Migrujeme jadrové dáta obchodu, na ktorých rozšírenie stavia, no nastavenia a uložené záznamy špecifické pre dané rozšírenie je zvyčajne potrebné získať samostatným exportom z tohto rozšírenia, alebo ich znovu vybudovať pomocou ekvivalentu na cieľovej platforme.

Q: Ovplyvňuje moja verzia OpenCart migráciu?
A: Áno. Staršie inštalácie OpenCart, najmä pred verziou 3.0, sa môžu výrazne líšiť v systéme šablón, formáte rozšírení a dokonca aj databázovej schéme, takže vašu verziu potvrdíme už na začiatku posúdenia.

Sources:
- OpenCart – oficiálna stránka: https://www.opencart.com

### Migrácia na PrestaShop a z PrestaShop

URL: https://prevedshop.com/sk/platformy/prestashop
Language: sk
Last reviewed: 2026-07-21

PrestaShop je e-commerce platforma s otvoreným zdrojovým kódom, s ktorou sa pri migráciách stretávame často, najmä u obchodníkov v Európe, ktorí na ňu prechádzajú kvôli flexibilite samostatného hostingu, alebo ju naopak opúšťajú, keď prerastú možnosti spravovania si obchodu sami. Keďže PrestaShop je open-source a samostatne hostovaná (alebo hostovaná cez vlastnú cloudovú ponuku PrestaShop), zložitosť migrácie zvyčajne určuje štruktúra databázy a to, od akých modulov obchod závisí, nie len veľkosť katalógu. Táto stránka sa venuje tomu, na čom skutočne záleží, keď je PrestaShop na jednej strane migrácie.

#### Čo je PrestaShop a kam zapadá

PrestaShop je e-commerce softvér s otvoreným zdrojovým kódom postavený na PHP a MySQL, najčastejšie samostatne hostovaný, hoci PrestaShop ponúka aj vlastný cloudový hosting. Otvorený zdrojový kód znamená, že vy alebo váš hostingový poskytovateľ priamo spravujete server, verziu PHP aj databázu a máte plný prístup k podkladovému kódu, na rozdiel od uzavretých SaaS platforiem. Má obzvlášť silnú pozíciu medzi obchodníkmi vo Francúzsku, Španielsku a na ďalších európskych trhoch.

Vitríny sa stavajú vo vlastnom šablónovacom systéme PrestaShop, so šablónami a modulmi z oficiálneho marketplace PrestaShop Addons alebo zo zákazkového vývoja. Keďže je kód otvorený, úpravy obchodu na PrestaShop môžu siahať od jednoduchej konfigurácie až po hlboký, zákazkový vývoj modulov, a to, koľko vlastného kódu obchod nesie, je jedna z prvých vecí, ktorá formuje rozsah migrácie.

#### Produkty, kategórie a dátový model

Katalógový model PrestaShop je postavený na produktoch s kombináciami (jeho termín pre varianty, napríklad veľkosť alebo farbu), usporiadaných do natívneho stromu kategórií s neobmedzenou hĺbkou, plus samostatných „vlastností“ a „atribútov“ pre štruktúrované produktové dáta. Práve tento natívny strom kategórií robí z PrestaShop rozumný cieľ pre katalógy s hlbokou hierarchickou štruktúrou, a je to jedna z vecí, ktoré starostlivo mapujeme pri presune stromu kategórií na PrestaShop, alebo z neho na platformu s plochejším modelom.

Zákazníci a história objednávok žijú priamo v databáze MySQL PrestaShop, čo pri samostatne hosťovanom obchode často znamená, že na exporty je k dispozícii priamy prístup k databáze, nie len to, čo sprístupňuje REST API. To môže niektoré časti migrácie zjednodušiť, no zároveň to znamená, že úpravy databázovej schémy špecifické pre daný obchod, napríklad z vlastných modulov, treba identifikovať skôr, než predpokladáme, že štandardný export zachytí úplne všetko.

#### Moduly, šablóny a čo sa neprenesie automaticky

Funkčný obchod na PrestaShop zvyčajne závisí od nainštalovaných modulov — na platby, výpočet dopravy, marketing alebo katalógové funkcie, ktoré nie sú súčasťou jadra PrestaShop. Dáta a konfigurácia modulov sa pri migrácii platformy automaticky neprenášajú; odchod z PrestaShop znamená zistiť, čo každý modul ukladá, a exportovať to samostatne, a príchod na PrestaShop znamená inštaláciu a nastavenie ekvivalentných modulov z marketplace Addons alebo cez zákazkový vývoj.

Šablóny PrestaShop sú viazané na jeho vlastný šablónovací systém a neprenášajú sa na iné platformy, takže odchod z PrestaShop zvyčajne znamená vybudovanie dizajnu vitríny na novej platforme od základov, a príchod na PrestaShop znamená úpravu šablóny z marketplace alebo zákazku na mieru. Samostatne hostované obchody niekedy nesú aj vlastný kód na úrovni šablóny, ktorý treba posúdiť oddelene od samotného vizuálneho dizajnu.

#### SEO, URL adresy a ako riešime migráciu PrestaShop

PrestaShop umožňuje pomerne flexibilné, konfigurovateľné prepisovanie URL adries pre produkty, kategórie a CMS stránky, čo je užitočné pri snahe zachovať štruktúru URL počas migrácie, no aj tak si to vyžaduje zámerné nastavenie, nie predpoklad. Odchod z PrestaShop znamená namapovať jeho vzory URL, ktoré sa môžu medzi obchodmi výrazne líšiť, keďže sú konfigurovateľné, na požiadavky novej platformy.

V rámci riadenej migrácie preveríme vašu existujúcu konfiguráciu URL v PrestaShop (alebo cieľovú, ak na PrestaShop prichádzate), vybudujeme mapu presmerovaní medzi starými a novými URL adresami a prenesieme metadáta, ktoré sú stále presné — rovnakým postupom, aký popisujeme pri službe SEO a migrácia presmerovaní, aplikovaným na konkrétne smerovanie PrestaShop.

#### FAQ

Q: Je PrestaShop bezplatný?
A: Jadro softvéru PrestaShop je open-source a bezplatné na stiahnutie a samostatné hostovanie. Náklady vznikajú z hostingu, práce vývojárov, platených modulov a šablón a prípadného cloudového hostingu PrestaShop namiesto vlastného.

Q: Viete migrovať moje moduly PrestaShop a ich dáta?
A: Migrujeme jadrové dáta obchodu, na ktorých modul stavia, no konfiguráciu a uložené záznamy špecifické pre daný modul je zvyčajne potrebné získať samostatným exportom z tohto modulu, alebo ich znovu vybudovať pomocou ekvivalentu na cieľovej platforme.

Q: Prenesie sa štruktúra kategórií PrestaShop dobre na iné platformy?
A: Závisí od cieľa. Natívny strom kategórií PrestaShop s neobmedzenou hĺbkou sa čisto namapuje na platformy s podobným modelom, no na platformách, ktoré nepodporujú skutočné vnorené kategórie, ho treba premapovať na štítky alebo kolekcie.

Q: Na ktorej verzii PrestaShop záleží pri migrácii?
A: Záleží pomerne dosť, keďže databázová schéma a kompatibilita modulov sa medzi hlavnými verziami môžu líšiť. Vašu verziu PrestaShop potvrdíme počas posúdenia, ešte pred finalizáciou postupu migrácie.

Sources:
- PrestaShop – oficiálna stránka: https://www.prestashop.com

### Migrácia na Shopify a zo Shopify

URL: https://prevedshop.com/sk/platformy/shopify
Language: sk
Last reviewed: 2026-07-21

Shopify je jeden z najčastejších cieľov migrácie, s ktorými pracujeme — objavuje sa na oboch stranách projektu, ako platforma, na ktorú sa obchody sťahujú, aj ako tá, ktorú opúšťajú. Keďže ide o uzavretú, hostovanú platformu, plynulosť presunu do veľkej miery určuje to, čo skutočne sprístupňuje Shopify API, nie len veľkosť vášho katalógu. Táto stránka sa venuje tomu, na čom skutočne záleží, keď je Shopify na jednej strane migrácie.

#### Čo je Shopify a kam zapadá

Shopify je hostovaná SaaS platforma pre e-commerce: nespravujete servery, verzie PHP ani zálohy databázy. Infraštruktúru prevádzkuje Shopify a vy obchod spravujete cez jeho administráciu a — pri hlbšej úprave — cez jeho API. Plány siahajú od štandardných úrovní pre malých a stredných obchodníkov až po Shopify Plus, určený pre obchodníkov s vyšším objemom, ktorí potrebujú väčšiu úpravu pokladne a vyššie limity API.

Vitríny sa stavajú vo vlastnom šablónovacom jazyku Shopify, Liquid, a šablóny pochádzajú z Shopify Theme Store alebo zo zákazkového vývoja. Keďže platforma je uzavretého zdroja a hostovaná, pracujete v rámci dátového modelu a rozšíriteľných bodov Shopify, nie úpravou jadrového kódu — presne preto migrácie na Shopify a z neho stoja a padajú na prístupe k API a konfigurácii aplikácií, nie na priamej kópii databázy.

#### Produkty, objednávky a zákazníci: dátový model

Produktový model Shopify je postavený na produktoch a variantoch (napríklad tričko s variantmi veľkosti/farby), usporiadaných do manuálnych alebo automatizovaných kolekcií namiesto voľného stromu kategórií. Migrácia katalógu do Shopify zvyčajne znamená premapovanie štruktúry kategórií alebo atribútov zo zdrojovej platformy na model produkt/variant/kolekcia — pri jednoduchých katalógoch je to priamočiare, pri platformách s hlbokými viacúrovňovými kategóriami alebo silne konfigurovateľnými produktmi náročnejšie.

Zákazníci a história objednávok sa prenášajú cez Admin API, no dáta o objednávkach sú viazané na vlastný model objednávok a vybavovania Shopify, takže historické objednávky sa zvyčajne migrujú ako referenčné záznamy, nie ako plne živé, editovateľné objednávky. Metapolia (mechanizmus Shopify pre vlastné polia) sú miesto, kam zvyčajne smerujú neštandardné produktové dáta, a mapovanie vašich existujúcich vlastných polí na metapolia je jedna z prvých vecí, ktoré pri posúdení riešime.

#### Aplikácie, šablóny a čo sa neprenesie automaticky

Funkčný obchod na Shopify zvyčajne závisí od niekoľkých nainštalovaných aplikácií — na recenzie, predplatné, vernostné programy, vyhľadávanie alebo pravidlá dopravy. Dáta aplikácií sa pri migrácii platformy vo všeobecnosti neprenášajú; ak odchádzate zo Shopify, dáta uložené v aplikácii (napríklad plány predplatného alebo vernostné body) si vyžadujú samostatný export z danej aplikácie, a ak prichádzate na Shopify, budete znovu inštalovať ekvivalenty z Shopify App Store namiesto prenosu konfigurácie aplikácie.

Rovnako je to so šablónami: šablóna v Liquid sa nedá preniesť do šablónovacieho systému inej platformy, takže odchod zo Shopify zvyčajne znamená znovuvytvorenie dizajnu vitríny na novej platforme, a príchod na Shopify znamená buď úpravu šablóny z Theme Store, alebo zákazkový vývoj v Liquid.

#### SEO, URL adresy a ako riešime migráciu Shopify

Shopify vynucuje vlastné vzory URL adries, napríklad /products/{handle}, /collections/{handle} a /pages/{handle}, ktoré sa málokedy presne zhodujú so štruktúrou URL inej platformy. Presun na Shopify alebo z neho takmer vždy znamená mapu presmerovaní zo starých URL adries na nové, keďže Shopify vám nedovolí plne replikovať ľubovoľnú štruktúru URL z iného systému a iné platformy automaticky nepoznajú vaše handle zo Shopify.

V rámci riadenej migrácie namapujeme vaše existujúce URL adresy voči štruktúre Shopify (alebo naopak, ak zo Shopify odchádzate), nastavíme 301 presmerovania a prenesieme metadáta, ktoré sú na nových URL adresách stále presné — rovnakým postupom, aký popisujeme pri službe SEO a migrácia presmerovaní, len prispôsobeným konkrétnym konvenciám URL a obmedzeniam API Shopify.

#### FAQ

Q: Viete migrovať moje aplikácie Shopify a ich dáta?
A: Migrujeme dáta obchodu, na ktorých tieto aplikácie stavajú, no špecifickú konfiguráciu a uložené dáta danej aplikácie je zvyčajne potrebné získať samostatným exportom z danej aplikácie, alebo ich znovu vybudovať pomocou ekvivalentnej aplikácie na cieľovej platforme.

Q: Mení Shopify Plus spôsob, akým migrácia prebieha?
A: Plus ovplyvňuje najmä úpravu pokladne a limity API. Podkladový dátový model produktov a objednávok je rovnaký ako pri štandardnom Shopify, takže prístup k migrácii sa zásadne nemení, hoci vyššie limity API môžu urýchliť presun veľkých katalógov.

Q: Zostanú mi URL adresy produktov rovnaké, ak prejdem na Shopify?
A: Len ak vaše súčasné URL adresy už zodpovedajú vzoru Shopify /products/{handle}, čo je nezvyčajné. Vo väčšine prípadov v rámci migrácie nastavíme presmerovania zo starých URL adries na štruktúru vyžadovanú Shopify.

Q: Čo sa stane s mojou šablónou, ak migrujem zo Shopify preč?
A: Šablóny v Liquid sa neprenášajú do šablónovacích systémov iných platforiem, takže dizajn vitríny sa znovu vytvorí na novej platforme, prispôsobený vášmu súčasnému dizajnu tam, kde to nová platforma umožňuje.

Sources:
- Shopify – oficiálna stránka: https://www.shopify.com

### Migrácia na Shoptet a zo Shoptetu

URL: https://prevedshop.com/sk/platformy/shoptet
Language: sk
Last reviewed: 2026-07-21

Shoptet je hostená e-commerce platforma zameraná špecificky na český a slovenský trh a je bežným koncovým bodom migrácií pre obchodníkov pôsobiacich v tomto regióne — či už prechádzajú na Shoptet kvôli lokálnej podpore a nastaveniu bez nutnosti programovania, alebo z neho odchádzajú, keď expandujú alebo potrebujú možnosti, ktoré platforma neponúka. Keďže je Shoptet uzavretá, hostená SaaS platforma, migrácia na ňu alebo z nej závisí od toho, čo skutočne sprístupňuje jej administrácia, exportné nástroje a API. Táto stránka sa venuje tomu, na čom skutočne záleží, keď je Shoptet na jednej strane migrácie.

#### Čo je Shoptet a kam zapadá

Shoptet je hostená SaaS e-commerce platforma vybudovaná pre český a slovenský trh, s administračným rozhraním, dokumentáciou aj podporou primárne v češtine. Podobne ako iné hostené platformy Shoptet spravuje hosting a infraštruktúru a obchodníci spravujú svoj obchod cez jeho administračný panel, nie prístupom k serveru. Je zameraný najmä na malých a stredných regionálnych obchodníkov, ktorí chcú prevádzkovať obchod bez toho, aby si sami spravovali kód alebo infraštruktúru.

Vitríny sa budujú pomocou vlastného systému šablón a úpravy dizajnu Shoptetu, s doplnkami dostupnými cez jeho vlastné trhovisko pre funkcie ako účtovné integrácie, marketingové nástroje a regionálne spôsoby platby či dopravy bežné na trhu CZ/SK. Keďže je uzavretého zdroja a hostovaný, migrácie na Shoptet alebo z neho fungujú v rámci jeho vlastného dátového modelu a možností exportu či API, nie priamou kópiou databázy.

#### Produkty, kategórie a dátový model

Katalógový model Shoptetu organizuje produkty do kategórií s podporou variantov produktov a parametrov pre štruktúrované atribúty. Migrácia katalógu na Shoptet vo všeobecnosti znamená namapovanie štruktúry kategórií alebo atribútov zdrojovej platformy na model Shoptetu, čo je pri katalógoch strednej zložitosti zvyčajne priamočiare.

Shoptet ponúka možnosti exportu dát aj API na stiahnutie dát o produktoch, objednávkach a zákazníkoch, na čom stojí migrácia z platformy preč. Podobne ako pri iných hostených platformách sa historické objednávky zvyčajne prenášajú ako referenčné záznamy, nie ako plne živé, editovateľné objednávky na novej platforme.

#### Doplnky, dizajn a čo sa neprenesie automaticky

Funkčný obchod na Shoptete často závisí od nainštalovaných doplnkov — na účtovníctvo, marketing, feedy porovnávačov cien, bežné pre obchodníkov na CZ/SK trhu inzerujúcich na službách ako Heureka či Zboží.cz, alebo regionálne platobné integrácie. Dáta a nastavenia doplnkov sa pri migrácii platformy neprenášajú automaticky; odchod zo Shoptetu znamená overiť, čo každý doplnok ukladá, a exportovať to samostatne, a príchod na Shoptet znamená nastaviť ekvivalenty z jeho vlastného trhoviska doplnkov.

Dizajnové šablóny Shoptetu sú špecifické pre jeho vlastný systém a neprenášajú sa na iné platformy, takže odchod zo Shoptetu zvyčajne znamená znovuvytvorenie dizajnu vitríny inde, a príchod na Shoptet znamená prispôsobenie jednej z jeho šablón alebo prácu v rámci jeho možností úpravy dizajnu.

#### SEO, URL adresy a ako riešime migráciu Shoptetu

Shoptet umožňuje istú mieru úpravy štruktúry URL adries pre produkty a kategórie, no rovnako ako pri každej zmene platformy sa existujúce vzory URL adries málokedy presne zhodujú s požiadavkami novej platformy. Toto je obzvlášť dôležité pre obchodníkov na CZ/SK trhu, ktorí často majú organickú viditeľnosť naviazanú na súčasné URL adresy a inzeráty v produktových feedoch na regionálnych porovnávačoch cien.

V rámci riadenej migrácie namapujeme vaše existujúce URL adresy zo Shoptetu, alebo cieľovej platformy, ak prechádzate na Shoptet, voči novej štruktúre, nastavíme presmerovania a prenesieme metadáta aj konfiguráciu porovnávacích feedov, ktoré sú stále presné — rovnakým postupom, aký popisujeme pri službe SEO a migrácia presmerovaní, len prispôsobeným konkrétnemu nastaveniu Shoptetu a regionálnemu ekosystému feedov, na ktorý sa typicky napája.

#### FAQ

Q: Je Shoptet dostupný aj mimo Česka a Slovenska?
A: Shoptet je vybudovaný a podporovaný špecificky pre český a slovenský trh, s administráciou aj dokumentáciou primárne v češtine. Nie je pozicionovaný ako globálna platforma tak, ako niektorí hostení konkurenti, čo je faktor, ktorý sa oplatí zvážiť, ak expandujete mimo CZ/SK.

Q: Viete migrovať moje produktové feedy zo Shoptetu pre Heureku alebo Zboží.cz?
A: Migrujeme podkladové produktové dáta, z ktorých tieto feedy vychádzajú; samotnú konfiguráciu feedu je zvyčajne potrebné znovu vybudovať na novej platforme, alebo ju riešime cez našu službu Integrácia dodávateľských feedov, v závislosti od toho, ako cieľová platforma spravuje feedy pre porovnávače cien.

Q: Viete migrovať moje doplnky zo Shoptetu a ich dáta?
A: Migrujeme dáta obchodu, na ktorých doplnok stavia, no nastavenia a uložené záznamy špecifické pre daný doplnok si zvyčajne vyžadujú samostatný export z tohto doplnku, alebo ich treba znovu vybudovať pomocou ekvivalentu na cieľovej platforme.

Q: Zostanú mi URL adresy produktov rovnaké, ak prejdem na Shoptet alebo z neho?
A: Zvyčajne nie presne, keďže štruktúra URL adries Shoptetu sa málokedy zhoduje s požiadavkami inej platformy. V rámci migrácie nastavíme presmerovania zo starých URL adries na nové, aby sa ochránili existujúce pozície vo vyhľadávaní.

Sources:
- Shoptet – oficiálna stránka: https://www.shoptet.cz

### Migrácia na Shopware a z Shopware

URL: https://prevedshop.com/sk/platformy/shopware-6
Language: sk
Last reviewed: 2026-07-21

So Shopware sa najčastejšie stretávame u obchodníkov z Nemecka, Rakúska a Švajčiarska — buď na neho prechádzajú kvôli otvorenej architektúre a silnej pozícii v regióne DACH, alebo opúšťajú staršiu inštaláciu Shopware, keď sa zmenia ich potreby. Dvojaká povaha Shopware, softvér s otvoreným zdrojovým kódom, ktorý sa dá prevádzkovať aj ako hostovaný cloudový produkt, znamená, že správny postup migrácie závisí od toho, akú verziu a nasadenie skutočne používate. Táto stránka sa venuje tomu, na čom skutočne záleží, keď je Shopware na jednej strane migrácie.

#### Čo je Shopware a kam zapadá

Shopware je e-commerce softvér postavený na PHP frameworku Symfony, dostupný ako samostatne hostovaný softvér s otvoreným zdrojovým kódom (Community Edition), alebo ako hostovaný cloudový produkt s komerčnými edíciami, ktoré pridávajú funkcie ako pokročilé B2B nástroje a cenotvorbu založenú na pravidlách. Shopware 6 je súčasná generácia, postavená okolo headless jadra s oddelenou vitrínou a administratívnou vrstvou, ktorá nahradila staršie, štrukturálne odlišné Shopware 5.

Keďže Shopware sprístupňuje Store API, podporuje headless a kompozitné nastavenia popri vlastnej predvolenej vitríne, čo je dôležité pri migráciách, kde sa frontend a backend riešia oddelene. Vitríny na štandardnej ceste využívajú vlastný šablónovací systém Shopware postavený na Twig, s pluginmi a šablónami dostupnými cez Shopware Store.

#### Produkty, predajné kanály a dátový model

Shopware organizuje produkty pomocou „vlastností“ a konfigurátorových skupín pre varianty, v rámci natívneho stromu kategórií, a na správu rôznych vitrín alebo prezentácií značky z jedného backendu využíva „predajné kanály“ — koncept štrukturálne odlišný od toho, ako platformy s jednou vitrínou riešia nastavenie viacerých značiek. Práve tento model predajných kanálov je jedna z prvých vecí, ktoré mapujeme, keď obchodník prevádzkuje viacero prepojených obchodov z jednej inštalácie Shopware.

Cenotvorba založená na pravidlách, teda rôzne ceny alebo akcie spúšťané zákazníckou skupinou, obsahom košíka alebo inými podmienkami, je funkcia Shopware, na ktorú treba upozorniť už na začiatku migrácie, keďže nie každá cieľová platforma modeluje podmienené ceny rovnako. Zákaznícke a objednávkové dáta žijú vo vlastnej databázovej štruktúre Shopware, a pri samostatne hostovaných inštaláciách je často k dispozícii priamy prístup k databáze, čo môže niektoré exporty zjednodušiť, no aj tak je potrebné identifikovať vlastné polia pridané pluginmi skôr, než predpokladáme, že štandardný export zachytí úplne všetko.

#### Pluginy, šablóny a čo sa neprenesie automaticky

Funkčný obchod na Shopware zvyčajne závisí od pluginov zo Shopware Store — na platby, dopravu, marketing alebo B2B funkcie, ktoré nie sú súčasťou jadra Shopware. Dáta a konfigurácia uložené v pluginoch sa pri migrácii platformy automaticky neprenášajú; odchod zo Shopware znamená overiť, čo každý plugin ukladá, a exportovať to samostatne, a príchod na Shopware znamená inštaláciu a nastavenie ekvivalentov cez Shopware Store alebo zákazkový vývoj.

Šablóny Shopware postavené na Twig sú viazané na jeho šablónovací systém a neprenášajú sa inde, takže odchod zo Shopware zvyčajne znamená vybudovanie dizajnu vitríny na novej platforme od základov, a príchod na Shopware znamená úpravu šablóny zo Store alebo zákazkový vývoj. Migrácie zahŕňajúce Shopware 5, ktoré využíva odlišnú podkladovú architektúru než Shopware 6, treba posudzovať ako samostatný prípad, nie predpokladať, že fungujú rovnako ako migrácia Shopware 6.

#### SEO, URL adresy a ako riešime migráciu Shopware

Shopware podporuje konfigurovateľné SEO šablóny URL adries pre produkty, kategórie a ďalšie stránky, ktoré je možné prispôsobiť pre jednotlivé predajné kanály, no skutočné vzory URL v používaní sa v jednotlivých obchodoch líšia podľa toho, ako boli nakonfigurované. Odchod zo Shopware znamená overiť živú konfiguráciu URL, nie predpokladať predvolený vzor.

V rámci riadenej migrácie preveríme vašu existujúcu konfiguráciu URL v Shopware (alebo naplánujeme cieľovú, ak na Shopware prichádzate), vybudujeme mapu presmerovaní medzi starými a novými URL adresami podľa predajného kanála tam, kde je to relevantné, a prenesieme metadáta, ktoré sú stále presné — rovnakým postupom, aký popisujeme pri službe SEO a migrácia presmerovaní, aplikovaným na konkrétnu štruktúru smerovania a predajných kanálov Shopware.

#### FAQ

Q: Záleží na tom, či mám Shopware 5 alebo Shopware 6?
A: Áno, výrazne. Shopware 6 má odlišnú podkladovú architektúru, systém pluginov aj štruktúru šablón než Shopware 5, takže migrácie z každej verzie riešime ako samostatné prípady, nie s predpokladom rovnakého postupu.

Q: Je Shopware bezplatný?
A: Community Edition od Shopware je open-source a bezplatná na samostatné hostovanie. Komerčné edície a cloudový hosting pridávajú licenčné alebo predplatné náklady spolu s ďalšími funkciami, napríklad pokročilými B2B nástrojmi.

Q: Ako ovplyvňujú predajné kanály Shopware migráciu?
A: Ak cez funkciu predajných kanálov Shopware prevádzkujete viacero vitrín alebo značiek, namapujeme každú samostatne, namiesto toho, aby sme inštaláciu považovali za jeden plochý obchod — keďže cieľové platformy nie vždy modelujú nastavenia s viacerými kanálmi rovnako.

Q: Viete migrovať moje pluginy Shopware a ich dáta?
A: Migrujeme jadrové dáta obchodu, na ktorých plugin stavia, no nastavenia a uložené záznamy špecifické pre daný plugin je zvyčajne potrebné získať samostatným exportom z tohto pluginu, alebo ich znovu vybudovať pomocou ekvivalentu na cieľovej platforme.

Sources:
- Shopware – oficiálna stránka: https://www.shopware.com

### Migrácia na WooCommerce a z WooCommerce

URL: https://prevedshop.com/sk/platformy/woocommerce
Language: sk
Last reviewed: 2026-07-21

WooCommerce nie je platforma v rovnakom zmysle ako hostovaný SaaS nástroj. Je to bezplatný plugin, ktorý zo samostatne hosťovanej stránky na WordPresse urobí obchod, takže migrácia WooCommerce je v skutočnosti migráciou WordPressu spolu s databázou. Tento rozdiel mení, čo sa naozaj musí presunúť, a je to prvá vec, ktorú si pri projekte s WooCommerce na oboch stranách presne určujeme.

#### Čo je WooCommerce a kto ho prevádzkuje

WooCommerce je plugin s otvoreným zdrojovým kódom pre e-commerce na WordPresse, ktorý vyvíja a spravuje Automattic. Keďže ide o samostatne hosťované riešenie, za server, verziu PHP, zálohy a aktualizácie zodpovedáte vy (alebo váš hosting). Neexistuje jeden dodávateľ, ktorý by riadil dostupnosť tak, ako je to pri SaaS platforme — to prináša viac kontroly, ale aj viac zodpovednosti za údržbu.

Je obľúbený medzi obchodníkmi, ktorí už na WordPresse prevádzkujú obsah, alebo ktorí chcú mať plnú kontrolu nad hostingom, pluginmi a kódom. Práve táto flexibilita je aj dôvodom, prečo sa obchody na WooCommerce dramaticky líšia zložitosťou: štíhly katalóg s pár pluginmi je úplne iná migrácia než silne prispôsobená inštalácia s desiatkami vzájomne prepojených pluginov.

#### Dátový model: produkty ako obsah WordPressu

WooCommerce ukladá produkty ako vlastný typ obsahu WordPressu, pričom varianty, atribúty a ceny sú uložené v prepojených tabuľkách a post meta, nie v dedikovanej e-commerce schéme. Kategórie a štítky využívajú taxonómiu systému WordPress. To v rámci WordPressu funguje dobre, no znamená to, že migrácia do WooCommerce si vyžaduje mapovanie vašich zdrojových dát nielen na „produkty“, ale konkrétne na obsahový model WordPressu, a migrácia z WooCommerce znamená extrakciu e-commerce dát, ktoré sú premiešané so všeobecným obsahom WordPressu.

Uloženie objednávok závisí od verzie a konfigurácie WooCommerce: staršie obchody používajú príspevky a post meta WordPressu, zatiaľ čo High-Performance Order Storage môže ukladať objednávky a adresy do vyhradených tabuliek. Zákazníci zostávajú naviazaní na používateľov WordPressu a rozšírenia môžu pridávať ďalšie tabuľky. Či možno históriu preniesť ako upraviteľné objednávky alebo iba ako referenčné dáta, závisí od cieľovej platformy a spôsobu importu; pred mapovaním je preto nutná inventúra zdrojovej schémy.

#### Pluginy, šablóny a kde žije vlastná logika

Funkčný obchod na WooCommerce zvyčajne závisí od viacerých pluginov nad rámec samotného WooCommerce — na pravidlá dopravy, platobné brány, predplatné alebo vlastné polia cez nástroje ako Advanced Custom Fields. Dáta špecifické pre plugin zvyčajne nemajú prenositeľný exportný formát, takže migrácia z WooCommerce znamená zistiť, čo daný plugin skutočne ukladá a či má cieľová platforma ekvivalent.

Šablóny sú štandardné WordPress šablóny, často v kombinácii s page builder nástrojmi (Elementor, WPBakery a podobne), ktoré ukladajú dáta o rozložení spôsobom, ktorý sa mimo WordPressu nedá preniesť. Odchod z WooCommerce zvyčajne znamená znovuvytvorenie dizajnu vitríny na novej platforme, nie jeho export.

#### SEO, URL adresy a ako riešime migráciu WooCommerce

Štruktúru URL adries vo WooCommerce riadi nastavenie trvalých odkazov (permalinks) vo WordPresse, takže je flexibilná — no práve táto flexibilita znamená, že URL adresy sú na každom webe s WooCommerce nakonfigurované mierne inak a neexistuje jeden pevný vzor, voči ktorému by sa dalo migrovať tak ako pri niektorých SaaS platformách. Populárne SEO pluginy (Yoast, Rank Math) navyše ukladajú metadáta a presmerovania vo vlastných tabuľkách, čo treba riešiť oddelene od jadrových dát WooCommerce/WordPress.

V rámci riadenej migrácie namapujeme vašu skutočnú štruktúru trvalých odkazov, nie predpokladaný predvolený tvar, na vzor URL adries cieľovej platformy, natiahneme metadáta z toho SEO pluginu, ktorý používate, a nastavíme presmerovania, aby existujúce hodnotenia aj vstupné odkazy naďalej fungovali. Ako to funguje vo všeobecnosti, popisuje naša služba SEO a migrácia presmerovaní.

#### FAQ

Q: Zahŕňajú dáta WooCommerce aj môj obsah na WordPresse?
A: Len to, o čo nás požiadate. WooCommerce a všeobecný obsah WordPressu (články, stránky) žijú v tej istej databáze, takže presne určíme, čo sa počíta ako „dáta obchodu“ a čo ako obsah stránky, ešte pred začiatkom migrácie.

Q: Viete migrovať obchod na WooCommerce s množstvom vlastných pluginov?
A: Áno, no vyžaduje si to viac času na posúdenie. Zistíme, čo každý plugin skutočne ukladá a či to má ekvivalent na novej platforme, alebo je potrebné to znovu vybudovať od základov.

Q: Čo sa stane s mojimi SEO dátami z Yoast alebo Rank Math, ak odídem z WooCommerce?
A: Extrahujeme metadáta a presmerovania, ktoré tieto pluginy ukladajú, a prenesieme to, čo je stále presné, do zodpovedajúcich polí na novej platforme, namiesto toho, aby ste svoje SEO metadáta začínali od nuly.

Q: Môžem migrovať do WooCommerce zo SaaS platformy?
A: Áno, ide o bežný smer, keď obchodníci chcú väčšiu kontrolu nad hostingom a kódom. Namapujeme váš zdrojový katalóg na obsahový model WordPressu a podľa toho nastavíme WooCommerce.

Sources:
- WooCommerce – oficiálna stránka: https://woocommerce.com

### Migration routes

### Migrácia z Magenta na BigCommerce

URL: https://prevedshop.com/sk/migracie/magento-na-bigcommerce
Language: sk
Last reviewed: 2026-07-21
Route: adobe-commerce -> bigcommerce

Presun z Adobe Commerce alebo Magento Open Source na BigCommerce vymieňa samostatne hostenú, kódom riadenú platformu za spravovanú SaaS platformu — v princípe podobne ako presun na Shopify, no s inou sadou kompromisov. BigCommerce natívne podporuje viac kombinácií produktových variantov a dáva vám väčšiu kontrolu nad štruktúrou URL adries než mnohí SaaS konkurenti, čo z neho môže urobiť štrukturálne bližšiu voľbu pre zložitý magentový katalóg — hosting, rozšírenia aj nastavenie viacerých obchodov sa však aj tak musia zámerne prebudovať, nie hromadne exportovať.

#### Prečo obchodníci opúšťajú Magento

Magento Open Source a Adobe Commerce dávajú plnú kontrolu nad kódom, hostingom aj pokladňou, za cenu toho, že si musíte túto infraštruktúru spravovať sami: bezpečnostné záplaty PHP a Magenta, server či cloudový hosting a súlad s PCI pre pokladňu, ktorú hostíte vy sami. BigCommerce ako spravovaná SaaS platforma z vášho tímu sníma hosting, súlad s PCI aj bezpečnostné záplaty platformy, výmenou za prácu v rámci obmedzení platformy namiesto ľubovoľného kódu.

Častým spúšťačom je ten istý dôvod, ktorý obchodníkov tlačí smerom k Shopify: náklady na udržiavanie vývojára alebo agentúry na zmluve kvôli údržbe inštancie Magento prestanú dávať zmysel vo chvíli, keď rast obchodu už túto réžiu neodôvodňuje, najmä pri obchodoch, ktoré stále bežia na nezáplatovanej inštancii Magento 2 alebo zotrvávajú na Magento 1 po konci jeho životnosti.

#### Čo sa mení v dátovom modeli

Katalógová štruktúra EAV (Entity-Attribute-Value) v Magente umožňuje definovať prakticky ľubovoľné vlastné atribúty pre každý typ produktu. Produktový model BigCommerce je štruktúrovanejší než v Magente, no vo všeobecnosti flexibilnejší v otázke variantov než konkurenčné SaaS platformy — natívne podporuje väčší počet kombinácií produktových variantov, plus vlastné polia a produktové modifikátory pre atribúty mimo štruktúry variantov. Napriek tomu treba sady atribútov z Magenta zámerne namapovať na možnosti variantov a vlastné polia BigCommerce, nie skopírovať atribút po atribúte.

Strom kategórií v Magente umožňuje ľubovoľné vnorenie s nastaveniami zobrazenia pre jednotlivé pohľady obchodu, pričom produkt môže patriť súčasne do viacerých kategórií. Kategórie v BigCommerce sú bližšie k tradičnému stromu než plochý model kolekcií Shopify, čo migráciu hlboko vnorenej štruktúry kategórií z Magenta robí o niečo priamočiarejšou — aj tak by sa však mala prekontrolovať a zjednodušiť tam, kde štruktúra Magenta rástla roky organicky, nie podľa zámeru.

#### URL adresy, presmerovania a čím sa to tu líši od Shopify

Kľúče URL adries aj prepisy v Magente sú plne nastaviteľné pre každý pohľad obchodu. BigCommerce, na rozdiel od Shopify, umožňuje vlastné cesty URL adries pre produkty, kategórie aj stránky bez vynúteného prefixu `/products/` alebo `/collections/` — vďaka čomu môže byť jednoduchšie zachovať existujúcu štruktúru URL adries z Magenta. To však neruší potrebu plánu presmerovaní: každá URL adresa, ktorá sa aj tak zmení, potrebuje explicitné 301 presmerovanie, a audit každej indexovanej URL adresy z Magenta voči jej novému ekvivalentu na BigCommerce sa musí urobiť v každom prípade, aby sa predišlo poklesu hodnotenia po migrácii.

#### Rozšírenia, pokladňa a viacero vitrín

Ekosystém rozšírení Magenta a jeho schopnosť upravovať pokladňu aj administračné procesy priamo v kóde nemajú na BigCommerce priamy ekvivalent — BigCommerce používa trhovisko aplikácií plus vlastné API a úpravu vitríny cez Stencil/Catalyst pre vlastnú logiku. Každé aktívne rozšírenie Magenta si vyžaduje explicitné rozhodnutie počas posúdenia: ekvivalentná aplikácia BigCommerce, vlastné riešenie postavené na API BigCommerce, alebo potvrdenie, že už nie je potrebné. Model viacerých webov/obchodov v Magente treba tiež namapovať na možnosti viacerých vitrín v BigCommerce, ktoré fungujú odlišne pod kapotou, aj keď výsledok pôsobí podobne.

#### FAQ

Q: Zvládne BigCommerce vlastné atribúty produktov z Magenta?
A: Cez kombináciu možností variantov a vlastných polí, ale BigCommerce nemá automatický ekvivalent sád atribútov EAV z Magenta. Vaše skutočné využitie atribútov namapujeme počas posúdenia, namiesto migrácie každého atribútu, ktorý Magento náhodou má definovaný.

Q: Je migrácia URL adries z Magenta na BigCommerce jednoduchšia než na Shopify?
A: Často do istej miery áno, pretože BigCommerce umožňuje vlastné cesty URL adries bez povinného prefixu, na rozdiel od pevnej štruktúry Shopify. To znižuje počet URL adries, ktoré sa musia zmeniť, ale každá, ktorá sa aj tak zmení, potrebuje explicitné 301 presmerovanie — audit treba urobiť tak či tak.

Q: Čo sa stane s mojimi rozšíreniami a vlastnými modulmi z Magenta?
A: Každé sa vyhodnotí individuálne počas posúdenia: nahradenie existujúcou aplikáciou BigCommerce, prebudovanie na API BigCommerce, alebo potvrdenie, že už nie je potrebné. Tento zoznam označíme ešte pred stanovením rozsahu projektu, nie až po ňom.

Q: Môžem si zachovať funkčnosť viacerých obchodov či webov?
A: Model viacerých webov v Magente sa nemapuje priamo na architektúru BigCommerce, hoci aj BigCommerce podporuje viacero vitrín. Vašu skutočnú požiadavku — samostatné značky, regióny alebo meny — namapujeme na správnu štruktúru BigCommerce, namiesto toho, aby sme predpokladali priamy prevod jedna k jednej.

Sources:
- BigCommerce – oficiálna stránka a dokumentácia: https://www.bigcommerce.com
- Dokumentácia Adobe Commerce / Magento Open Source: https://experienceleague.adobe.com/en/docs/commerce

### Migrácia z Magenta na Shopify

URL: https://prevedshop.com/sk/migracie/magento-na-shopify
Language: sk
Last reviewed: 2026-07-21
Route: adobe-commerce -> shopify

Presun z Adobe Commerce alebo Magento Open Source na Shopify vymieňa samostatne hostenú, vysoko prispôsobiteľnú PHP platformu za spravovanú SaaS platformu. Táto výmena z vášho tímu sníma údržbu servera, verzie PHP aj súlad s PCI, no zároveň znamená, že dátový model katalógu, štruktúru URL adries aj väčšinu rozšírení treba prebudovať, nie skopírovať. Pri zámernom prístupe je to dobre zdokumentovaný presun; pri surovom exporte/importe je to presne miesto, kde sa potichu pokazí SEO aj vlastná logika.

#### Prečo obchodníci opúšťajú Magento

Magento Open Source a Adobe Commerce vám dávajú plnú kontrolu nad kódom, hostingom aj pokladňou — presne preto je ich nákladné udržiavať v prevádzke. Niekto musí záplatovať bezpečnostné vydania PHP a Magenta, spravovať server či cloudovú infraštruktúru a udržiavať aktuálny súlad s PCI pre pokladňu, ktorú hostíte sami. Shopify z vášho tímu sníma hosting, súlad s PCI aj bezpečnostné záplaty platformy, výmenou za menšiu kontrolu na nízkej úrovni.

Bežným spúšťačom je to, že priebežné náklady na vývojára či agentúru na údržbu inštancie Magento už nezodpovedajú veľkosti obchodu, najmä keď sa na Magento 1 (dávno po konci životnosti) alebo starnúcej inštancii Magento 2 začnú hromadiť nezáplatované rozšírenia.

#### Čo sa v dátovom modeli skutočne mení

Produktový katalóg Magenta je postavený na štruktúre EAV (Entity-Attribute-Value), ktorá umožňuje definovať ľubovoľné vlastné atribúty pre každý typ produktu. Produktový model Shopify je jednoduchší: produkt má pevnú sadu základných polí plus až tri dimenzie možností variantov (napríklad veľkosť a farba) a metapolia pre všetko ostatné. Konfigurovateľné produkty a vlastné voľby z Magenta sa mapujú na varianty a metapolia Shopify, no mapovanie nie je 1:1 — sady atribútov s množstvom vlastných atribútov zvyčajne potrebujú zámerne navrhnutú schému metapolí, nie automatický prevod atribút po atribúte.

Ďalším reálnym rozdielom sú kategórie: Magento umožňuje ľubovoľne hlboké vnorenie kategórií a priradenie produktu do mnohých z nich s odlišnými nastaveniami zobrazenia pre každý pohľad obchodu. Kolekcie Shopify sú plochejšie — ručné alebo pravidlami riadené („smart“) zoznamy, nie skutočný strom kategórií —, takže hlboko vnorený katalóg z Magenta si vyžaduje zámerne navrhnutú štruktúru kolekcií, nie priamy export.

#### URL adresy, presmerovania a čo sa pokazí potichu

Kľúče URL adries aj prepisy v Magente sú plne nastaviteľné pre každý pohľad obchodu. Shopify vynucuje vlastné vzory URL adries (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`, `/blogs/{blog}/{handle}`), ktoré nemôžete ľubovoľne prestavať. To znamená, že každá indexovaná URL adresa z Magenta potrebuje explicitné presmerovanie na svoj ekvivalent na Shopify — toto je jednoznačne najčastejší zdroj poklesu hodnotenia po migrácii, a je úplne odstrániteľný poriadnou mapou URL adries pripravenou pred spustením, nie doplnenou dodatočne, keď si Google všimne chyby 404.

#### Rozšírenia, úpravy pokladne a viacero obchodov

Ekosystém rozšírení Magenta a jeho schopnosť upravovať pokladňu, cenové pravidlá aj administračné procesy priamo v kóde nemajú na Shopify priamy ekvivalent — Shopify používa App Store a na Shopify Plus aj Checkout Extensibility a Shopify Functions pre vlastnú logiku pokladne. Každý vlastný modul Magenta si vyžaduje explicitné rozhodnutie: existuje ekvivalentná aplikácia, treba vlastnú aplikáciu postavenú na API Shopify, alebo sa funkcionalita vypúšťa. Rovnako to platí pre nastavenia viacerých webov/obchodov v Magente, ktoré sa priamo neprekladajú na model jedného obchodu plus Markets pre medzinárodný predaj v Shopify.

Náš proces riadenej migrácie toto mapuje už počas posúdenia — zoznam aktívnych rozšírení a vlastných modulov spisujeme pred stanovením ceny práce, nie objavujeme uprostred migrácie.

#### FAQ

Q: Zvládne Shopify vlastné atribúty produktov z Magenta?
A: Áno, cez metapolia, ale treba ich zámerne definovať a namapovať — Shopify nemá automatický ekvivalent sád atribútov EAV z Magenta. Vaše skutočné využitie atribútov namapujeme počas posúdenia, namiesto migrácie každého atribútu, ktorý Magento náhodou má definovaný.

Q: Presmerujú sa moje URL adresy z Magenta automaticky?
A: Nie. Štruktúra URL adries Shopify je pevná, takže každá zmysluplná URL adresa z Magenta potrebuje explicitné 301 presmerovanie na svoj nový ekvivalent na Shopify. Toto je jadro plánu migrácie, nie voliteľný doplnok — pozrite si našu službu SEO a migrácia presmerovaní.

Q: Čo sa stane s mojimi rozšíreniami a vlastnými modulmi z Magenta?
A: Každé sa vyhodnotí individuálne počas posúdenia: nahradenie existujúcou aplikáciou Shopify, prebudovanie ako vlastná aplikácia alebo úprava šablóny, alebo potvrdenie, že už nie je potrebné. Tento zoznam označíme ešte pred stanovením rozsahu projektu, nie až po ňom.

Q: Môžem si zachovať funkčnosť viacerých obchodov či webov?
A: Model viacerých webov v Magente sa nemapuje priamo na Shopify. V závislosti od toho, čo skutočne potrebujete — samostatné značky, samostatné regióny, samostatné meny —, správnym ekvivalentom na Shopify môže byť Shopify Markets, druhý obchod alebo Shopify Plus Organization. Pomôžeme vám vybrať na základe skutočnej potreby, nie univerzálnej odpovede.

Sources:
- Shopify – Migrácia obchodu na Shopify: https://www.shopify.com/migrate
- Dokumentácia Adobe Commerce / Magento Open Source: https://experienceleague.adobe.com/en/docs/commerce

### Migrácia z Magenta (Adobe Commerce) na Shoptet

URL: https://prevedshop.com/sk/migracie/magento-na-shoptet
Language: sk
Last reviewed: 2026-09-02
Route: adobe-commerce -> shoptet

Magento a Adobe Commerce sú stavané pre zložité katalógy, viac store views a rozsiahle úpravy, za cenu drahého hostingu a vývoja. Shoptet je hostovaná platforma pre českých a slovenských obchodníkov s jednoduchším pevným dátovým modelom a vstavanými miestnymi integráciami. Migrácia je najmä konsolidácia: zredukovať sady atribútov, konfigurovateľné produkty, store views a vlastné moduly Magenta na to, čo Shoptet vie reprezentovať, preniesť zákazníkov a históriu objednávok a ochrániť URL, ktoré prinášajú organickú návštevnosť.

#### Kto prechádza z Magenta na Shoptet a prečo

Obchodníci tento krok robia, keď sa Magento stalo neúmerným veľkosti biznisu: stredne veľký český alebo slovenský obchod platí hosting Magenta, bezpečnostné záplaty, licencie rozšírení a hodiny agentúry, ktoré už nepotrebuje. Shoptet to nahrádza mesačným tarifom, natívnymi integráciami Zásielkovne, Packety, GoPay, Comgate a Heureky a spravovaným prostredím. Daňou je hĺbka: žiadne sady atribútov, žiadna hierarchia viacerých webov, žiadne ľubovoľné rozšírenia. Ak na nich váš biznis stojí, posúdenie to povie skôr, než začne akákoľvek práca.

#### Sady atribútov, konfigurovateľné produkty a kategórie

Sady atribútov Magenta sa stávajú jedinou plochou sadou parametrov Shoptetu, prekrývajúce sa atribúty z rôznych sád preto treba zlúčiť a konzistentne premenovať. Konfigurovateľné produkty sa mapujú na produkty Shoptetu s variantmi; jednoduché podradené produkty sa stávajú riadkami variantov s vlastnými kódmi, cenami a skladom. Bundle a grouped produkty nemajú priamy ekvivalent a prestavujú sa ako samostatné produkty alebo sady. Stromy kategórií sa prenášajú, anchor kategórie a vrstvenú navigáciu Magenta však nahrádzajú kategórie a parametrické filtre Shoptetu, čo zvyčajne znamená sploštenie hierarchie.

#### Store views, zákazníci a objednávky

Store views Magenta sa často používajú pre jazyky alebo značky. Shoptet podporuje jazykové mutácie v rámci obchodu, nie nezávislé weby, každý store view preto potrebuje rozhodnutie: zlúčiť do jedného Shoptetu, prevádzkovať viac obchodov na Shoptete, alebo vypustiť. Zákazníci a adresy sa importujú, skupiny zákazníkov sa mapujú na cenové hladiny Shoptetu a heslá sa v novom obchode obnovia. História objednávok sa importuje pre reporting. Vlastné moduly, konektory na ERP a B2B funkcie sa spíšu jednotlivo a priradia k natívnym funkciám, doplnkom alebo vlastnej integrácii.

#### Presmerovania a prepnutie

URL rewrites Magenta a cesty kategórií v URL produktov sa líšia od vzorov Shoptetu, preto exportujeme všetky indexované URL, zostavíme kompletnú mapu 301 a nahráme ju do Shoptetu pred prepnutím DNS. Testovací import celého katalógu kontrolujeme na ceny, DPH, sklad a varianty, potom sa znovu vygenerujú feedy a odošle sitemapa. Presmerovania chránia kontinuitu URL a znižujú riziko; pozície žiadna migrácia negarantuje.

#### FAQ

Q: Dajú sa konfigurovateľné produkty Magenta migrovať na Shoptet?
A: Áno. Každý konfigurovateľný produkt sa stane produktom Shoptetu s variantmi a jednoduché podradené produkty sa stanú riadkami variantov s vlastným kódom, cenou a skladom.

Q: Čo sa stane so sadami atribútov Magenta?
A: Shoptet má jeden plochý zoznam parametrov, sady atribútov sa preto zlúčia. Duplicitné alebo konfliktné názvy atribútov sa pred importom vyčistia a premenujú.

Q: Ako sa riešia store views Magenta?
A: O každom store view sa rozhoduje zvlášť: zlúčiť do jedného Shoptetu, prevádzkovať viac obchodov na Shoptete, alebo vypustiť. Shoptet podporuje jazykové mutácie, nie nezávislé weby.

Q: Zostanú mi zákazníci a história objednávok?
A: Zákazníci, adresy a skupinové ceny sa importujú; heslá sa obnovia. Objednávky sa importujú ako história pre reporting, nie ako editovateľné živé objednávky.

Sources:
- Adobe Commerce - Prenos dát (import a export): https://experienceleague.adobe.com/en/docs/commerce-admin/systems/data-transfer/data-transfer
- Shoptet Developers - Import dát: https://developers.shoptet.com/shoptet-tools/data-import/

### Migrácia z OpenCart na Shopify

URL: https://prevedshop.com/sk/migracie/opencart-na-shopify
Language: sk
Last reviewed: 2026-07-21
Route: opencart -> shopify

OpenCart je odľahčená, samostatne hostená open-source platforma — jednoduchšia na prevádzku než Magento alebo PrestaShop, no aj tak si vyžaduje, aby ste si sami spravovali server, verziu PHP, bezpečnostné záplaty aj súlad s PCI. Presun na Shopify vymieňa toto samostatne spravované nastavenie za hostenú, spravovanú platformu. Keďže je dátový model OpenCart pomerne jednoduchý, samotná migrácia je zvyčajne priamočiarejšia než z ťažšej podnikovej platformy, no možnosti produktov, nastavenie viacerých obchodov aj rozšírenia si aj tak vyžadujú zámerné mapovanie, nie surový export/import.

#### Prečo obchodníci opúšťajú OpenCart

Príťažlivosť OpenCart spočíva v tom, že je zadarmo a odľahčený, no zároveň to znamená, že ste sami zodpovední za hosting, bezpečnostné aktualizácie, súlad s PCI aj udržiavanie kompatibility rozšírení naprieč upgradmi jadra. Mnohé obchody na OpenCart prevádzkujú malé tímy bez vlastných vývojárov, a priebežná záťaž spojená s aplikovaním bezpečnostných záplat a riešením konfliktov rozšírení sa časom stáva neúmernou k veľkosti biznisu. Shopify túto záťaž s hostingom a záplatovaním odstraňuje výmenou za poplatok za spravovanú platformu.

Častým spúšťačom je ekosystém rozšírení: rozšírenia OpenCart (vytvorené ako úpravy OCMOD alebo VQMOD) sa výrazne líšia v kvalite a často sa prestanú aktívne udržiavať, čo predstavuje rastúce riziko, keď samotná platforma ide dopredu a sada rozšírení obchodu starne.

#### Možnosti produktov, kategórie a dátový model

OpenCart reprezentuje varianty produktov cez „možnosti“ — voľby ako veľkosť alebo farba priradené k produktu, každá voliteľne ovplyvňujúca cenu a stav skladu. Koncepčne je to blízke systému variantov Shopify, čo robí základné mapovanie produktov priamočiarejším než z platforiem s plným atribútovým modelom EAV. Shopify však aj tak obmedzuje produkty na tri dimenzie možností variantov, takže pri produktoch OpenCart s väčším počtom skupín možností treba niektoré možnosti presunúť do metapolí namiesto variantov.

Kategórie v OpenCart môžu byť vnorené a produkt môže patriť do viacerých kategórií naraz, čo je koncepčne blízke kolekciám Shopify, no pod kapotou štruktúrované inak — strom kategórií OpenCart sa nemapuje jedna k jednej na model ručných/inteligentných kolekcií Shopify, takže štruktúru kolekcií treba zvyčajne naplánovať, nie hromadne skopírovať.

#### Viacero obchodov, URL adresy a rozšírenia

OpenCart podporuje prevádzku viacerých vitrín z jednej inštalácie, so zdieľanou administráciou a spoločným produktovým katalógom medzi obchodmi s rôznymi nastaveniami. Najbližšími ekvivalentmi na Shopify sú Shopify Markets pre regionálne/menové variácie v rámci jedného obchodu, alebo v niektorých prípadoch skutočne samostatné obchody Shopify pre jednotlivé značky — ani jedno nie je priama architektonická zhoda, takže vhodný prístup závisí od toho, na čo sa nastavenie viacerých obchodov skutočne používa.

Nastavenia priateľských URL adries v OpenCart sú konfigurovateľné pre každý obchod, takže existujúce URL adresy treba namapovať s explicitnými 301 presmerovaniami na pevné vzory URL adries Shopify (`/products/{handle}`, `/collections/{handle}`), aby sa neprišlo o viditeľnosť vo vyhľadávaní. Rozšírenia OpenCart pre dopravu, platby alebo úpravu katalógu si tiež vyžadujú individuálne vyhodnotenie počas posúdenia — náhradu aplikáciou Shopify, vlastné riešenie, alebo potvrdenie, že už nie sú potrebné.

#### FAQ

Q: Mapuje sa systém možností produktov OpenCart čisto na varianty Shopify?
A: Čistejšie než z platforiem s plným modelom vlastných atribútov, keďže možnosti OpenCart sú koncepčne už blízke variantom Shopify. Produkty s viac než tromi skupinami možností potrebujú niektoré možnosti namapované na metapolia Shopify namiesto variantov.

Q: Čo sa stane s mojím nastavením viacerých obchodov v OpenCart?
A: Priamy ekvivalent jedna k jednej na Shopify neexistuje. V závislosti od toho, či potrebujete zdieľaný katalóg s regionálnymi variáciami alebo skutočne samostatné značky, vám pomôžeme vybrať medzi Shopify Markets a samostatnými obchodmi Shopify na základe vašich skutočných požiadaviek.

Q: Presmerujú sa moje URL adresy z OpenCart automaticky?
A: Nie. Štruktúra URL adries Shopify je pevná, takže každá indexovaná URL adresa z OpenCart potrebuje explicitné 301 presmerovanie na svoj ekvivalent na Shopify — toto sa plánuje ako súčasť migrácie, nenecháva sa na obdobie po spustení.

Q: Čo sa stane s mojimi rozšíreniami z OpenCart?
A: Každé aktívne rozšírenie sa vyhodnotí individuálne počas posúdenia: nahradenie aplikáciou Shopify, prebudovanie ako vlastná aplikácia alebo úprava šablóny, alebo vypustenie, ak už nie je potrebné. Toto označíme ešte pred stanovením rozsahu projektu.

Sources:
- Shopify – Migrácia obchodu na Shopify: https://www.shopify.com/migrate
- OpenCart – oficiálna stránka a dokumentácia: https://www.opencart.com

### Migrácia z PrestaShop na Shopify

URL: https://prevedshop.com/sk/migracie/prestashop-na-shopify
Language: sk
Last reviewed: 2026-07-21
Route: prestashop -> shopify

PrestaShop je samostatne hostená open-source platforma populárna naprieč Európou, postavená na natívnej podpore viacerých jazykov a mien a flexibilnom systéme „kombinácií“ pre varianty produktov. Presun na Shopify znamená vzdať sa priameho prístupu k serveru a databáze výmenou za spravovaný hosting a súlad s PCI, a znamená to znovu premyslieť niekoľko vecí, ktoré PrestaShop rieši natívne — multistore, viacjazyčný obsah aj kombinácie produktov — v pojmoch Shopify, nie predpokladať priamy export jedna k jednej.

#### Prečo obchodníci opúšťajú PrestaShop

Ako samostatne hostená platforma kladie PrestaShop správu servera, upgrady verzie PHP, kompatibilitu modulov aj súlad s PCI pre pokladňu na plecia vášho tímu. To je zvládnuteľné pre obchod s vlastnými technickými kapacitami, ale postupom času sa to stáva reálnym nákladom — čas vývojárov, hosting, bezpečnostné záplaty — akonáhle obchod beží na štíhlejšom tíme. Shopify preberá hosting, súlad s PCI aj bezpečnostné záplaty platformy, výmenou za menšiu kontrolu na nízkej úrovni za predvídateľnú réžiu spravovanej platformy.

Častým spúšťačom je ekosystém modulov: moduly PrestaShop sa výrazne líšia kvalitou aj mierou údržby, a obchod budovaný roky často nesie viacero modulov, ktoré už nie sú aktívne podporované, čo sa stáva rastúcou záťažou, ako sa samotný PrestaShop posúva dopredu.

#### Kombinácie, kategórie a dátový model

Produkty v PrestaShop používajú systém „kombinácií“ — atribúty ako veľkosť alebo farba generujú riadky kombinácií a PrestaShop kladie len málo pevných limitov na to, koľko atribútov či kombinácií môže mať produkt. Model variantov Shopify je obmedzenejší: až tri dimenzie možností na produkt, s metapoľami dostupnými pre atribúty, ktoré sa do modelu variantov nezmestia. Produkty s množstvom kombinácií atribútov z PrestaShop, alebo atribúty používané skôr ako popisné dáta než skutočné varianty, si vyžadujú zámerne navrhnutý plán metapolí, nie priamu kópiu atribút po atribúte.

Strom kategórií v PrestaShop, podobne ako v Magente, umožňuje ľubovoľné vnorenie a priradenie produktu do viacerých kategórií. Kolekcie Shopify sú plochejšie — ručné alebo pravidlami riadené zoznamy —, takže hlboko vnorený katalóg z PrestaShop si na Shopify vyžaduje prepracovanú štruktúru kolekcií, nie doslovný export kategórií.

#### Multistore, viacjazyčnosť a viacero mien

Funkciu multistore v PrestaShop a jeho natívnu podporu viacerých jazykov a mien bežne využívajú európski obchodníci predávajúci na viacerých trhoch z jednej inštalácie. Najbližším ekvivalentom na Shopify je Shopify Markets pre variácie meny, jazyka a regionálnej vitríny, alebo v niektorých prípadoch samostatný obchod Shopify pre každú značku či región. Ani jedno nie je priama architektonická zhoda pre multistore PrestaShop, takže správny prístup závisí od toho, čo obchod skutočne potrebuje — jednu vitrínu obsluhujúcu viacero trhov, alebo skutočne samostatné vitríny —, a toto rozhodnutie by malo padnúť zámerne ešte pred stanovením rozsahu migrácie.

#### URL adresy, presmerovania a moduly

Nastavenia priateľských URL adries v PrestaShop sú plne konfigurovateľné, takže existujúce URL adresy PrestaShop málokedy od základu zodpovedajú pevným vzorom Shopify (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`). Každá indexovaná URL adresa z PrestaShop potrebuje explicitné presmerovanie na svoj ekvivalent na Shopify, aby sa počas presunu ochránili pozície vo vyhľadávaní.

Moduly PrestaShop pre dopravu, platby, marketing a úpravu pokladne nemajú na Shopify automatický ekvivalent. Každý aktívny modul si vyžaduje explicitné rozhodnutie počas posúdenia — nahradenie aplikáciou Shopify, prebudovanie ako vlastná aplikácia alebo úprava šablóny, alebo vypustenie —, aby bol rozsah migrácie známy ešte pred začiatkom práce, nie objavený uprostred projektu.

#### FAQ

Q: Zvládne Shopify kombinácie produktov z PrestaShop?
A: Štandardné kombinácie sa mapujú na varianty Shopify, ale Shopify obmedzuje produkty na tri dimenzie možností variantov. Kombinácie nad tento rámec, alebo atribúty používané skôr ako popisné dáta, treba počas posúdenia zámerne namapovať na metapolia.

Q: Čo sa stane s mojím nastavením multistore v PrestaShop?
A: Priamy architektonický ekvivalent na Shopify neexistuje. V závislosti od toho, čo skutočne potrebujete — zdieľaný katalóg naprieč regiónmi, samostatné meny, alebo skutočne samostatné značky —, môže byť správnou štruktúrou na Shopify buď Shopify Markets, alebo samostatné obchody. Pomôžeme vám vybrať na základe vašich požiadaviek, nie predvolenej odpovede.

Q: Presmerujú sa moje URL adresy z PrestaShop na Shopify automaticky?
A: Nie. Shopify vynucuje vlastnú štruktúru URL adries, takže každá zmysluplná URL adresa z PrestaShop potrebuje explicitné 301 presmerovanie namapované na svoj ekvivalent na Shopify — toto je jadro plánu migrácie, nie voliteľný doplnok.

Q: Čo sa stane s mojimi modulmi z PrestaShop?
A: Každý sa vyhodnotí individuálne: nahradenie existujúcou aplikáciou Shopify, prebudovanie ako vlastná aplikácia alebo úprava šablóny, alebo potvrdenie, že už nie je potrebný. Tento zoznam označíme počas posúdenia, ešte pred stanovením rozsahu projektu.

Sources:
- Shopify – Migrácia obchodu na Shopify: https://www.shopify.com/migrate
- PrestaShop – oficiálna stránka a dokumentácia: https://www.prestashop.com

### Migrácia z PrestaShopu na Shoptet

URL: https://prevedshop.com/sk/migracie/prestashop-na-shoptet
Language: sk
Last reviewed: 2026-09-02
Route: prestashop -> shoptet

PrestaShop je open-source platforma, ktorú si hostujete a spravujete sami; Shoptet je hostovaný systém pre českých a slovenských obchodníkov so vstavanou dopravou, platbami a feedmi pre porovnávače. Migrácia nahrádza kombinácie, vlastnosti a dáta modulov PrestaShopu variantmi, parametrami a doplnkami Shoptetu, prenáša zákazníkov aj históriu objednávok a každú indexovanú URL prestavuje na presmerovanie 301, aby prechod nezahodil roky viditeľnosti vo vyhľadávačoch.

#### Čo obchodníci z PrestaShopu získajú a čoho sa vzdajú

Shoptet odstraňuje správu servera, upgrady PHP a riešenie kompatibility modulov. Fakturácia, DPH, Zásielkovňa, Packeta, GoPay, Comgate aj Heureka sú natívne, čo často nahradí tucet modulov PrestaShopu. Vzdávate sa neobmedzenej customizácie: v PrestaShope sa dá modulom alebo override zmeniť čokoľvek, Shoptet ponúka pevnú sadu polí, šablón a doplnkov. Funkcie z vlastných modulov PrestaShopu treba znovu posúdiť, nie skopírovať.

#### Kombinácie, vlastnosti a kategórie

Kombinácie PrestaShopu (sady atribútov ako veľkosť a farba) sa mapujú na varianty Shoptetu; každá kombinácia sa stáva riadkom variantu s vlastným kódom, cenou a skladom. Vlastnosti PrestaShopu používané na filtrovanie sa stávajú parametrami Shoptetu, ktoré sa pred importom založia. Zaradenie do viacerých kategórií podporujú oba systémy, predvolenú kategóriu PrestaShopu však treba explicitne zvoliť ako hlavnú kategóriu v Shoptete. Obrázky, popisy, meta titulky a popisky sa prenášajú importom; pravidlá špecifických cien a ceny pre skupiny zákazníkov vyžadujú revíziu, pretože Shoptet modeluje zľavy inak.

#### Zákazníci, objednávky a presmerovania

Zákazníci s adresami a príslušnosťou k skupinám sa importujú; heslá preniesť nemožno, súčasťou komunikácie pri spustení je preto obnovenie hesla. Objednávky sa importujú ako história pre reporting. URL PrestaShopu závisia od nastavenia priateľských adries a často obsahujú ID; Shoptet používa vlastné vzory ciest, preto zo sitemapy PrestaShopu a dát analytiky vytvoríme kompletnú mapu 301 a pred prepnutím DNS ju overíme. Presmerovania chránia kontinuitu URL a znižujú riziko; pozície nie sú nikdy garantované.

#### Moduly, feedy a spustenie

Spíšeme každý aktívny modul PrestaShopu a rozhodneme: natívny v Shoptete, dostupný ako doplnok, vlastná integrácia, alebo vypustený. Feedy pre porovnávače sa znovu vygenerujú zo Shoptetu. Samotné spustenie je testovací import, kontrola vzorky cien, DPH a skladu a potom prepnutie DNS, pričom PrestaShop zostane krátko len na čítanie, kým sa mapa presmerovaní nepotvrdí v Google Search Console.

#### FAQ

Q: Stanú sa z kombinácií PrestaShopu varianty Shoptetu?
A: Áno. Každá kombinácia sa stane variantom s vlastným kódom, cenou a skladom; skupiny atribútov sa stanú rozmermi variantov. Nekonzistentné pomenovanie atribútov v PrestaShope sa pred importom vyčistí.

Q: Môžem si ponechať históriu objednávok z PrestaShopu?
A: Objednávky sa importujú ako história pre prehľad a reporting. Nie sú to editovateľné živé objednávky a faktúry zostávajú vo vašom účtovnom systéme.

Q: Budú moduly PrestaShopu fungovať na Shoptete?
A: Žiadny modul sa neprenáša priamo. Každý namapujeme na natívnu funkciu Shoptetu, doplnok alebo vlastnú integráciu a tie nepotrebné vypustíme.

Q: Ako riešite URL PrestaShopu s ID produktov?
A: Každá indexovaná URL dostane explicitné presmerovanie 301 na ekvivalent v Shoptete, vygenerované zo sitemapy a analytiky a overené pred spustením.

Sources:
- PrestaShop - Dokumentácia webservice: https://devdocs.prestashop-project.org/9/webservice/
- Shoptet Developers - Import dát: https://developers.shoptet.com/shoptet-tools/data-import/

### Migrácia zo Shopify na WooCommerce

URL: https://prevedshop.com/sk/migracie/shopify-na-woocommerce
Language: sk
Last reviewed: 2026-09-02
Route: shopify -> woocommerce

Väčšina návodov opisuje len prechod na Shopify. Opačný smer je rovnako častý, keď chce obchod plné vlastníctvo dát, obsahovo bohatý web na WordPresse alebo sa zbaviť transakčných poplatkov a predplatných aplikácií. Prechod zo Shopify na WooCommerce znamená prevziať zodpovednosť za hosting, bezpečnosť a aktualizácie výmenou za otvorený dátový model a neobmedzené úpravy. Samotná migrácia zahŕňa produkty, varianty, metapolia, zákazníkov, históriu objednávok, obsah a kompletnú mapu presmerovaní.

#### Prečo obchody odchádzajú zo Shopify

Typickými dôvodmi sú opakované náklady na aplikácie, transakčné poplatky pri cudzích platobných bránach, ťažko upraviteľný checkout a želanie prevádzkovať obchod aj obsah na jednej inštalácii WordPressu. WooCommerce nemá platformový poplatok a celú databázu ukladá na vašom serveri, čo je dôležité pre obchodníkov s prísnymi požiadavkami na umiestnenie dát alebo rozsiahlymi B2B úpravami. Druhou stranou mince je prevádzka: výkon hostingu, zálohy, aktualizácie pluginov a rozsah PCI sú teraz na vás alebo vašej agentúre.

#### Produkty, varianty a metapolia

Produkty Shopify s až tromi rozmermi možností sa čisto mapujú na variabilné produkty WooCommerce s atribútmi a variantmi. Výnimkou sú metapolia: WooCommerce nemá vstavaný ekvivalent, každé metapole sa preto mapuje na atribút produktu, vlastné pole alebo dátovú štruktúru konkrétneho pluginu. Kolekcie sa stávajú kategóriami alebo štítkami podľa toho, ako sa používali; inteligentné kolekcie založené na pravidlách treba znovu vytvoriť ako kategórie s ručným priradením alebo pomocou pluginu na filtrovanie. Obrázky, SKU, hmotnosti a sklad sa prenášajú CSV importérom alebo priamym procesom z API do databázy.

#### Zákazníci, objednávky a obsah

Zákazníkov možno importovať s adresami a marketingovým súhlasom; heslá sú na oboch platformách hashované inak a nikdy sa neprenášajú. História objednávok sa importuje pre reporting a zákaznícky servis, stavy sa mapujú na ekvivalenty WooCommerce. Stránky a články zo Shopify sa stávajú stránkami a príspevkami WordPressu, čo je zvyčajne posun k väčšej flexibilite úprav. Zľavové kódy a darčekové karty vyžadujú revíziu, pretože kupóny WooCommerce a pluginy pre darčekové karty presne nekopírujú pravidlá Shopify.

#### URL, presmerovania a spustenie

Shopify vynucuje prefixy `/products/`, `/collections/` a `/pages/`; WordPress umožňuje trvalé odkazy nastaviť ľubovoľne, čo je príležitosť navrhnúť čistejšiu štruktúru. Každá indexovaná URL zo Shopify sa musí pred presunom domény mapovať na URL WooCommerce presmerovaním 301 obsluhovaným novým webom. Mapu presmerovaní, rýchlosť stránok a checkout testujeme na staging serveri a potom prepíname DNS, obchod na Shopify nechávame krátko otvorený. Presmerovania zachovávajú kontinuitu URL a znižujú riziko; pozície zaručiť nemožno.

#### FAQ

Q: Dajú sa metapolia Shopify migrovať do WooCommerce?
A: Áno, ale nie automaticky. Každé metapole sa mapuje na atribút WooCommerce, vlastné pole alebo štruktúru pluginu, ktorú vaša šablóna vie zobraziť.

Q: Zostanú zákazníkom po prechode na WooCommerce heslá?
A: Nie. Hashe hesiel sú špecifické pre platformu. Zákazníci dostanú odkaz na obnovenie hesla v novom obchode, ideálne ako súčasť oznámenia o spustení.

Q: Aký hosting WooCommerce po odchode zo Shopify potrebuje?
A: Spravovaný WordPress hosting s PHP 8, objektovou cache a dennými zálohami je praktické minimum pre obchod, ktorý doteraz bežal na infraštruktúre Shopify.

Q: Prídem odchodom zo Shopify o SEO?
A: Vzory URL sa menia, preto je kompletná mapa presmerovaní 301 nutná. S presmerovaniami, kanonickými tagmi a znovu odoslanou sitemapou sa riziko znižuje, ale žiadna migrácia nezaručuje nezmenené pozície.

Sources:
- WooCommerce - Import a export produktov v CSV: https://woocommerce.com/document/product-csv-importer-exporter/
- Shopify Help Center - Migrácia na Shopify: https://help.shopify.com/en/manual/migrating-to-shopify

### Migrácia zo Shoptetu na Shopify

URL: https://prevedshop.com/sk/migracie/shoptet-na-shopify
Language: sk
Last reviewed: 2026-07-21
Route: shoptet -> shopify

Shoptet je uzavretá, hostená SaaS platforma zameraná na český a slovenský trh, takže tento presun vyzerá inak než migrácia zo samostatne hostenej platformy na SaaS: obe platformy za vás riešia hosting aj súlad s PCI. Skutočnými dôvodmi bývajú zvyčajne dosah mimo trhu CZ/SK, väčší globálny ekosystém aplikácií Shopify a väčšia flexibilita dizajnu vďaka šablónovaciemu systému Liquid na Shopify. Keďže je Shoptet uzavretého zdroja, prístup k dátam sa opiera o jeho exportné nástroje a API, nie o priamy prístup k databáze, čo ovplyvňuje, ako sa musí samotná migrácia naplánovať.

#### Prečo obchodníci opúšťajú Shoptet

Shoptet je solídna, jednoducho prevádzkovateľná platforma pre obchodníkov na CZ/SK trhu, no je regionálne zameraná — jeho trhovisko aplikácií, platobné a dopravné integrácie aj nástroje pre viacero mien/jazykov sú budované primárne okolo tohto trhu. Obchodníci expandujúci mimo Česka a Slovenska často zisťujú, že globálny ekosystém aplikácií Shopify, jeho natívne nástroje pre viacero mien a jazykov cez Shopify Markets a širšia základňa integrácií tretích strán lepšie vyhovujú cezhraničnému rastu.

Ďalším bežným dôvodom je flexibilita dizajnu: úprava šablón v Shoptete je obmedzenejšia než šablónovací systém Shopify založený na Liquide, takže obchodníci, ktorí chcú výrazne vlastný dizajn vitríny alebo hlbšiu úpravu pokladne (dostupnú obchodníkom na Shopify Plus), často zisťujú, že im Shopify dáva viac priestoru vybudovať presne to, čo chcú.

#### Ako dostať dáta z uzavretej platformy

Na rozdiel od open-source platforiem, kde môžete priamo dotazovať databázu, Shoptet priamy prístup k databáze neponúka — dáta o produktoch, objednávkach aj zákazníkoch treba získať cez exportné nástroje Shoptetu (exporty CSV/XML) a jeho API. To znamená, že krok extrakcie dát pri migrácii závisí od toho, čo exportné a API rozhranie Shoptetu skutočne sprístupňuje, a akékoľvek dáta, ktoré cez tieto kanály nie sú dostupné (isté vlastné polia, historické metadáta objednávok), treba identifikovať už včas, keďže sa nedajú jednoducho stiahnuť z databázového dumpu tak, ako pri samostatne hostenej platforme.

#### Produktové dáta, kategórie a varianty

Produktový model Shoptetu, podobne ako väčšina SaaS platforiem, používa parametre/varianty pre voľby produktu ako veľkosť či farba. Namapovanie na systém variantov Shopify (obmedzený na tri dimenzie možností) je zvyčajne priamočiarejšie než migrácia z platformy s ľubovoľným modelom vlastných atribútov, hoci akékoľvek parametre Shoptetu používané skôr na popisné filtrovanie než ako skutočné varianty patria lepšie do metapolí Shopify. Štruktúru kategórií v Shoptete treba tiež prekontrolovať voči plochejšiemu modelu kolekcií Shopify, nie skopírovať ako doslovný strom.

#### URL adresy, lokalizácia a aplikácie

URL adresy v Shoptete sa riadia vlastnými konvenciami platformy a treba ich namapovať na pevné vzory URL adries Shopify (`/products/{handle}`, `/collections/{handle}`) s explicitnými 301 presmerovaniami pre každú indexovanú stránku, aby sa ochránila existujúca viditeľnosť vo vyhľadávaní — čo je obzvlášť dôležité pre SEO na CZ/SK trhu budované roky. Ak obchod predáva vo viacerých jazykoch alebo menách, treba nastaviť Shopify Markets tak, aby zopakoval toto nastavenie, keďže funguje pod kapotou inak než vstavaná lokalizácia Shoptetu. Akékoľvek aplikácie či integrácie z trhoviska Shoptetu (platobné brány, dopravcovia, marketingové nástroje) si tiež vyžadujú individuálne vyhodnotenie voči App Store Shopify, aby sa potvrdilo, či existuje ekvivalent, alebo je potrebné vlastné riešenie.

#### FAQ

Q: Ako dostanem svoje dáta o produktoch a objednávkach zo Shoptetu?
A: Cez exportné nástroje CSV/XML v Shoptete a jeho API — priamy prístup k databáze nie je možný, keďže ide o uzavretú SaaS platformu. Ešte pred stanovením rozsahu migrácie identifikujeme, ktoré typy dát sú skutočne exportovateľné, a označíme všetko, čo nie je.

Q: Presmerujú sa moje URL adresy zo Shoptetu na Shopify automaticky?
A: Nie. Štruktúra URL adries Shopify je pevná a odlišná od Shoptetu, takže každá indexovaná URL adresa zo Shoptetu potrebuje explicitné 301 presmerovanie na svoj ekvivalent na Shopify, čo je obzvlášť dôležité pre viditeľnosť vo vyhľadávaní na CZ/SK trhu budovanú roky.

Q: Zvláda Shopify predaj vo viacerých jazykoch a menách rovnako ako Shoptet?
A: Áno, cez Shopify Markets, ale nastavuje sa inak než vstavaná lokalizácia Shoptetu — treba ho nastaviť zámerne tak, aby zopakoval vaše existujúce nastavenie pre viacero trhov, nie predpokladať, že bude fungovať rovnako od základu.

Q: Prečo prejsť zo Shoptetu na Shopify, keď sú obe hostené SaaS platformy?
A: Zvyčajnými dôvodmi sú skôr dosah a flexibilita než záťaž hostingu — globálny ekosystém aplikácií Shopify, širšie platobné a dopravné integrácie pre cezhraničný predaj a viac možností úpravy šablóny aj pokladne pre obchody, ktoré prerástli regionálnejšie zameraný nástrojový set Shoptetu.

Sources:
- Shopify – Migrácia obchodu na Shopify: https://www.shopify.com/migrate
- Shoptet – oficiálna stránka: https://www.shoptet.cz

### Migrácia zo Shopware na Shopify

URL: https://prevedshop.com/sk/migracie/shopware-na-shopify
Language: sk
Last reviewed: 2026-07-21
Route: shopware-6 -> shopify

Shopware je flexibilná commerce platforma postavená na Symfony, populárna v regióne DACH, dostupná ako samostatne hostená aj ako spravovaná cloudová služba. Presun na Shopify znamená vzdať sa vysoko prispôsobiteľného systému entít a pluginov Shopware výmenou za obmedzenejšiu, no plne spravovanú platformu Shopify. Jadrom práce je namapovanie flexibilných vlastností produktov a modelu predajných kanálov Shopware na pevnú schému produktov a ekosystém aplikácií Shopify, popri bežnom plánovaní URL adries a presmerovaní, ktoré vyžaduje každý presun platformy.

#### Prečo obchodníci opúšťajú Shopware

Silná stránka Shopware — vysoko rozšíriteľná platforma postavená na Symfony, s flexibilným systémom entít a hlbokou úpravou cez pluginy/aplikácie — prináša pri samostatnom hostovaní reálnu réžiu: správa servera, upgrady verzie PHP aj Shopware a súlad s PCI pre pokladňu ležia na vašom tíme. Aj cloudová verzia Shopware stále znamená spravovať ekosystém pluginov, ktoré musia zostať kompatibilné naprieč upgradmi. Shopify z vašich povinností úplne odstraňuje hosting aj záplatovanie platformy, za cenu hlbších možností úpravy na úrovni kódu, ktoré Shopware ponúka.

Častým spúšťačom je ten istý dôvod, ktorý vidno pri iných flexibilných open-source platformách: čas vývojárov potrebný na údržbu vlastných pluginov Shopware a ich udržiavanie funkčných naprieč upgradmi verzií prestáva byť úmerný tomu, čo obchod skutočne potrebuje, najmä pri obchodníkoch, ktorí flexibilitu Shopware využívali menej, než čakali.

#### Vlastnosti produktov, varianty a dátový model

Shopware reprezentuje variácie produktov cez „vlastnosti“ a „možnosti“, ktoré generujú kombinácie variantov, popri flexibilnom systéme vlastných polí pre atribúty mimo tejto štruktúry. Koncepčne je to bližšie k modelu variantov Shopify než plný systém EAV, no pevný limit troch dimenzií možností variantov na produkt v Shopify znamená, že pri produktoch Shopware s väčším počtom skupín vlastností treba niektoré vlastnosti presunúť do metapolí Shopify namiesto variantov.

Štruktúra kategórií v Shopware, ako pri väčšine platforiem so skutočným stromom kategórií, umožňuje vnorené kategórie s flexibilným priradením. Kolekcie Shopify sú plochejšie — ručné alebo pravidlami riadené zoznamy namiesto vnoreného stromu —, takže štruktúru kategórií zo Shopware treba prepracovať ako sadu kolekcií Shopify, nie priamo exportovať.

#### Predajné kanály a viacero vitrín

Koncept „Sales Channel“ v Shopware umožňuje jednej inštancii Shopware obsluhovať viacero vitrín, aplikácií alebo trhovísk zo zdieľaného katalógu, každé s vlastnými nastaveniami. Najbližšími ekvivalentmi na Shopify sú jeho vlastné viaceré predajné kanály (online obchod, POS, trhoviská) plus Shopify Markets pre regionálne a menové variácie v rámci jedného obchodu, alebo samostatné obchody Shopify pre skutočne odlišné značky. Koncepty sa prekrývajú, no nie sú priamou architektonickou zhodou, takže nastavenie predajných kanálov zo Shopware treba namapovať na správnu štruktúru Shopify podľa toho, na čo sa skutočne používa, nie predpokladať prevod jedna k jednej.

#### URL adresy, pluginy a špecifiká pre EÚ

SEO URL adresy v Shopware sú konfigurovateľné pre každý predajný kanál, takže existujúce URL adresy potrebujú explicitné 301 presmerovania namapované na pevné vzory Shopify (`/products/{handle}`, `/collections/{handle}`), aby sa počas presunu ochránili pozície vo vyhľadávaní. Pluginy a aplikácie Shopware pre dopravu, platby a úpravu pokladne nemajú na Shopify automatický ekvivalent a vyžadujú si individuálne vyhodnotenie — aplikáciu Shopify, vlastné riešenie, alebo potvrdenie, že funkcionalita už nie je potrebná.

Shopware sa hojne používa naprieč EÚ a má vstavané nástroje pre spracovanie DPH a požiadavky súvisiace s GDPR bežné na tomto trhu. Shopify pokrýva podobnú oblasť cez Shopify Tax a vlastné nástroje pre súlad s predpismi, no konkrétne nastavenie — daňová registrácia, formát faktúr, nastavenia spracovania dát — treba pre Shopify prekontrolovať a znovu nakonfigurovať, nie predpokladať, že sa prenesie automaticky.

#### FAQ

Q: Mapujú sa vlastnosti produktov zo Shopware čisto na varianty Shopify?
A: Pri štandardnom použití variantov pomerne dobre, keďže vlastnosti Shopware sú koncepčne podobné možnostiam variantov Shopify. Produkty s viac než tromi skupinami vlastností potrebujú niektoré vlastnosti presunuté do metapolí Shopify, keďže Shopify obmedzuje produkty na tri dimenzie možností variantov.

Q: Čo sa stane s mojimi predajnými kanálmi (Sales Channels) zo Shopware?
A: Presný ekvivalent na Shopify neexistuje — vlastné viaceré predajné kanály Shopify, Shopify Markets aj samostatné obchody spolu pokrývajú časť toho, čo dokáže nastavenie Sales Channel v Shopware. Váš skutočný prípad použitia (regióny, značky, trhoviská) namapujeme počas posúdenia na správnu štruktúru Shopify.

Q: Presmerujú sa moje URL adresy zo Shopware na Shopify automaticky?
A: Nie. Štruktúra URL adries Shopify je pevná, takže každá indexovaná URL adresa zo Shopware potrebuje explicitné 301 presmerovanie na svoj ekvivalent na Shopify — je to súčasť plánu migrácie, nie dodatočný nápad.

Q: Prenesie sa nastavenie DPH a GDPR zo Shopware na Shopify?
A: Nie automaticky. Shopify má vlastné nástroje pre dane a súlad s predpismi (Shopify Tax a súvisiace nastavenia), no daňovú registráciu, formát faktúr aj nastavenia spracovania dát treba prekontrolovať a nastaviť špecificky pre Shopify, nie predpokladať, že sa prenesú zo Shopware.

Sources:
- Shopify – Migrácia obchodu na Shopify: https://www.shopify.com/migrate
- Shopware – oficiálna stránka a dokumentácia: https://www.shopware.com

### Migrácia z WooCommerce na BigCommerce

URL: https://prevedshop.com/sk/migracie/woocommerce-na-bigcommerce
Language: sk
Last reviewed: 2026-07-21
Route: woocommerce -> bigcommerce

WooCommerce beží ako plugin WordPressu, takže jeho dáta, hosting aj výkon sú prepojené s vašou inštaláciou WordPressu. Presun na BigCommerce oddelí commerce od vášho WordPress obsahového stacku a hosting, súlad s PCI aj bezpečnosť platformy prenechá BigCommerce — pričom vám dá aj väčšiu natívnu flexibilitu variantov a kontrolu nad URL adresami než väčšina SaaS konkurentov. Prácou je namapovanie produktových a obsahových dát WooCommerce založených na WordPresse na štruktúru BigCommerce bez straty SEO hodnoty alebo poškodenia funkčnosti závislej na pluginoch.

#### Prečo obchodníci opúšťajú WooCommerce

Samotný WooCommerce je zadarmo, no jeho prevádzka znamená vlastniť aktualizácie jadra WordPressu aj pluginov, výkon hostingu, bezpečnosť na úrovni servera a súlad s PCI pre pokladňu. S rastom obchodu sa konflikty pluginov a vplyv narastajúceho stacku pluginov na rýchlosť stránky stávajú reálnymi, opakujúcimi sa nákladmi — nehovoriac o čase vývojára či agentúry potrebnom na udržanie všetkého záplatovaného a kompatibilného. BigCommerce ako spravovaná SaaS platforma túto záťaž s hostingom a záplatovaním odstraňuje výmenou za prácu v rámci obmedzení jej platformy.

Obchody, ktoré prerástli svoje nastavenie WordPress hostingu, alebo sú unavené z krehkosti stacku pluginov pri raste webu, sú najčastejšími kandidátmi na tento presun.

#### Produktové dáta: bližšia zhoda, než by ste čakali

WooCommerce ukladá produkty ako vlastný typ príspevku WordPressu, s variáciami a atribútmi postavenými na taxonómiách WordPressu — flexibilne, keďže WordPress kladie na vlastné polia len málo pevných limitov. Produktový model BigCommerce je štruktúrovanejší, no citeľne benevolentnejší v otázke variantov než niektorí SaaS konkurenti, podporuje väčší počet kombinácií variantov na produkt popri vlastných poliach a produktových modifikátoroch pre atribúty, ktoré sa do štruktúry variantov nezmestia. Napriek tomu produkty WooCommerce s intenzívnym využitím ACF (Advanced Custom Fields) alebo množstvom vlastných atribútov potrebujú zámerný plán mapovania na vlastné polia BigCommerce, nie slepú kópiu.

Kategórie a štítky WooCommerce sú taxonómie WordPressu, ktoré sa dajú voľne vnárať a krížovo priraďovať. Strom kategórií BigCommerce je bližšie k tradičnej hierarchii než ploché kolekcie Shopify, čo prevod štruktúry kategórií z WooCommerce robí o niečo priamočiarejším, aj tak sa však oplatí ju prekontrolovať, nie exportovať nezmenenú.

#### URL adresy, obsah a pluginy

Trvalé odkazy WordPressu sú plne konfigurovateľné, takže URL adresy WooCommerce málokedy predvolene zodpovedajú akémukoľvek pevnému vzoru. BigCommerce, na rozdiel od niektorých SaaS platforiem, umožňuje vlastné cesty URL adries bez povinného prefixu, čo môže zachovanie existujúcej štruktúry URL adries WooCommerce uľahčiť — no každá URL adresa, ktorá sa aj tak zmení, potrebuje explicitné 301 presmerovanie, a každú indexovanú URL adresu WooCommerce treba v každom prípade preveriť voči jej ekvivalentu na BigCommerce.

Je tu aj otázka obsahu WordPressu: mnohé obchody na WooCommerce sa spoliehajú na WordPress ako plnohodnotný CMS pre blog aj vstupné stránky, čo nemá priamy ekvivalent v obmedzenejších obsahových nástrojoch BigCommerce. Obchody s podstatným množstvom obsahu vo WordPresse potrebujú plán — migrovať ho do stránok BigCommerce, alebo ponechať WordPress bežať samostatne pre obsah, zatiaľ čo BigCommerce rieši commerce. Pluginy WooCommerce pre dopravu, predplatné alebo vlastné polia pokladne si tiež vyžadujú individuálne vyhodnotenie: ekvivalentnú aplikáciu BigCommerce, vlastné riešenie, alebo potvrdenie, že už nie sú potrebné.

#### FAQ

Q: Podporuje BigCommerce nastavenie variantov a atribútov z WooCommerce?
A: BigCommerce podporuje viac kombinácií variantov na produkt než niektorí SaaS konkurenti, čo pomáha pri zložitých katalógoch WooCommerce, no stále neexistuje automatický ekvivalent vlastných polí WordPressu ani dát ACF — tie treba zámerne namapovať na vlastné polia BigCommerce.

Q: Čo sa stane s mojím blogom a vstupnými stránkami vo WordPresse?
A: Automaticky sa nemigrujú, keďže obsahové nástroje BigCommerce sú užšie než vo WordPresse. Blogové príspevky a stránky môžete migrovať do BigCommerce, alebo ponechať WordPress bežať samostatne pre obsah, zatiaľ čo BigCommerce rieši commerce — pomôžeme vám rozhodnúť na základe toho, koľko návštevnosti tento obsah generuje.

Q: Budú sa musieť moje URL adresy z WooCommerce na BigCommerce meniť?
A: Menej, než by ste čakali pri presune na niektoré iné SaaS platformy, keďže BigCommerce umožňuje vlastné cesty URL adries bez povinného prefixu. Každá URL adresa, ktorá sa aj tak zmení, potrebuje explicitné 301 presmerovanie, a pred spustením v každom prípade preveríme každú indexovanú URL adresu WooCommerce.

Q: Dokáže BigCommerce nahradiť všetky moje pluginy WooCommerce?
A: Väčšina má ekvivalentnú aplikáciu BigCommerce, no nie všetky — časť funkcionality pluginov si vyžaduje vlastné riešenie postavené na API BigCommerce a časť sa vypúšťa, ak už nie je potrebná. Vaše aktívne pluginy zaznamenáme počas posúdenia ešte pred stanovením rozsahu práce.

Sources:
- BigCommerce – oficiálna stránka a dokumentácia: https://www.bigcommerce.com
- Dokumentácia WooCommerce: https://woocommerce.com/documentation/

### Migrácia z WooCommerce na Shopify

URL: https://prevedshop.com/sk/migracie/woocommerce-na-shopify
Language: sk
Last reviewed: 2026-07-21
Route: woocommerce -> shopify

WooCommerce beží ako plugin nad WordPressom, čo znamená, že dáta, hosting aj výkon vášho obchodu sú previazané s vašou inštaláciou WordPressu. Presun na Shopify oddelí commerce od obsahu: získate spravovanú, s PCI súladnú hostingovú platformu a účelovo navrhnutý model produktu/pokladne, no zároveň prídete o natívnu flexibilitu WordPressu pre obsah aj o priamu zhodu plugin-aplikácia, akú by ste možno čakali. Jadrom práce je namapovanie dátového modelu WooCommerce založeného na WordPresse na pevnú schému Shopify bez straty SEO hodnoty alebo poškodenia vlastnej funkcionality.

#### Prečo obchodníci opúšťajú WooCommerce

Inštalácia WooCommerce je zadarmo, no jeho dobrá prevádzka nie je: ste zodpovední za aktualizácie jadra WordPressu aj pluginov, výkon hostingu, bezpečnosť na úrovni servera a súlad s PCI pre všetko, čo sa dotýka platobných dát. S rastom obchodu sa skutočnou cenou „bezplatného“ softvéru stávajú konflikty pluginov, problémy s rýchlosťou stránky spôsobené narastajúcim stackom pluginov a opakujúce sa náklady na vývojára či agentúru, ktorí udržiavajú všetko záplatované. Shopify túto priebežnú záťaž s údržbou vymieňa za pevný poplatok za platformu a spravované, s PCI súladné prostredie.

Bežným spúšťačom je škálovanie: výkon WooCommerce výrazne závisí od kvality hostingu a disciplíny s pluginmi, a obchody, ktoré začínali malé, často narazia na bod, kde návštevnosť alebo veľkosť katalógu prerastie to, na čo bolo ich nastavenie WordPress hostingu postavené.

#### Čo sa mení v dátovom modeli

WooCommerce ukladá produkty ako vlastný typ príspevku WordPressu, s variáciami, atribútmi aj kategóriami postavenými na taxonómiách WordPressu — flexibilná štruktúra, keďže WordPress kladie na vlastné polia len málo obmedzení. Produktový model Shopify je obmedzenejší: pevná sada základných polí, až tri dimenzie možností variantov a metapolia pre všetko ostatné. Produkty s množstvom vlastných atribútov WooCommerce alebo dátami ACF (Advanced Custom Fields) potrebujú zámerne naplánovanú štruktúru metapolí, nie slepú kópiu pole po poli.

Kategórie a štítky produktov WooCommerce sú taxonómie WordPressu a dajú sa voľne vnárať a krížovo priraďovať. Kolekcie Shopify sú buď ručné zoznamy, alebo pravidlami riadené („smart“) kolekcie, nie skutočný strom taxonómie, takže hlbokú štruktúru kategórií z WooCommerce treba zvyčajne prepracovať na plochejšiu sadu kolekcií, nie exportovať v pôvodnej podobe.

#### URL adresy, presmerovania a otázka obsahu

Trvalé odkazy WordPressu sú plne konfigurovateľné, takže URL adresy produktov aj kategórií WooCommerce môžu vyzerať takmer akokoľvek, ako si to daný web nastavil. Shopify vynucuje vlastné vzory (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`, `/blogs/{blog}/{handle}`), takže každá indexovaná URL adresa WooCommerce, ktorá im ešte nezodpovedá, potrebuje 301 presmerovanie, aby presun prežila bez straty pozícií vo vyhľadávaní.

Pri tejto dvojici platforiem je tu aj otázka obsahu: WordPress je plnohodnotný CMS a mnohé obchody na WooCommerce sa naň spoliehajú pri blogovom obsahu, vstupných stránkach aj vlastných šablónach stránok. Nástroje na blog a stránky v Shopify sú jednoduchšie než vo WordPresse. Obchody s podstatným množstvom obsahu vo WordPresse potrebujú pre tento obsah plán — migrovať ho do stránok/blogu Shopify, alebo ponechať samostatnú inštanciu WordPressu pre obsah, zatiaľ čo Shopify rieši commerce — a toto rozhodnutie treba urobiť zámerne, nie objaviť po prepnutí.

#### Pluginy, pokladňa a platobné brány

Ekosystém pluginov WooCommerce pokrýva všetko od kalkulátorov dopravy cez fakturáciu predplatného až po vlastné polia pokladne, často cez pluginy tretích strán bez priameho náprotivku na Shopify. Každý aktívny plugin si vyžaduje explicitné rozhodnutie počas migrácie: ekvivalentnú aplikáciu Shopify, vlastnú aplikáciu alebo úpravu šablóny, alebo potvrdenie, že funkcionalita už nie je potrebná. Prekonfigurovať treba aj platobné brány — WooCommerce podporuje široký rozsah pluginov brán, zatiaľ čo Shopify centralizuje platby cez Shopify Payments alebo podporovanú bránu tretej strany, takže akúkoľvek vlastnú logiku pokladne naviazanú na konkrétny platobný plugin WooCommerce treba pre model pokladne Shopify prebudovať.

#### FAQ

Q: Prežijú moje SEO pozície z WooCommerce presun na Shopify?
A: Môžu, ale len so zámerným mapovaním presmerovaní. Trvalé odkazy WordPressu a pevná štruktúra URL adries Shopify sa málokedy zhodujú presne, takže každá indexovaná URL adresa WooCommerce potrebuje pred spustením explicitné 301 presmerovanie na svoj ekvivalent na Shopify — pozrite si našu službu SEO a migrácia presmerovaní.

Q: Čo sa stane s mojím blogom a vstupnými stránkami vo WordPresse?
A: Automaticky sa nemigrujú, pretože obsahové nástroje Shopify sú užšie než vo WordPresse. Blogové príspevky a stránky môžete migrovať do Shopify, alebo ponechať samostatnú inštanciu WordPressu pre obsah, zatiaľ čo Shopify rieši commerce — pomôžeme vám rozhodnúť na základe toho, koľko vašej návštevnosti od tohto obsahu závisí.

Q: Dokáže Shopify nahradiť všetky moje pluginy WooCommerce?
A: Väčšina má ekvivalentnú aplikáciu Shopify, no nie všetky — časť funkcionality pluginov WooCommerce si vyžaduje vlastnú aplikáciu alebo úpravu šablóny na Shopify, a časť sa vypúšťa, ak už nie je potrebná. Vaše aktívne pluginy zaznamenáme počas posúdenia ešte pred stanovením rozsahu práce.

Q: Čo sa stane s variáciami produktov a vlastnými atribútmi z WooCommerce?
A: Štandardné variácie sa mapujú na systém variantov Shopify, obmedzený na tri dimenzie možností. Vlastné atribúty WooCommerce a polia ACF nad týmto rámcom treba zámerne namapovať na metapolia Shopify — automatický prevod vlastných polí WordPressu jedna k jednej neexistuje.

Sources:
- Shopify – Migrácia obchodu na Shopify: https://www.shopify.com/migrate
- Dokumentácia WooCommerce: https://woocommerce.com/documentation/

### Migrácia z WooCommerce na Shoptet

URL: https://prevedshop.com/sk/migracie/woocommerce-na-shoptet
Language: sk
Last reviewed: 2026-09-02
Route: woocommerce -> shoptet

Shoptet je hostovaná platforma postavená pre českých a slovenských obchodníkov, s natívnou podporou miestnych dopravcov, platobných brán, fakturačných pravidiel a feedov pre porovnávače. Prechod z WooCommerce znamená opustiť vlastný WordPress hosting a prejsť na spravovaný systém s pevným dátovým modelom. Samotná migrácia je najmä o preklade produktov, taxonómií a dát z pluginov do importnej štruktúry Shoptetu, o zachovaní histórie zákazníkov a objednávok tam, kde to má zmysel, a o ochrane URL adries, ktoré nesú vašu návštevnosť z vyhľadávačov.

#### Prečo obchodníci prechádzajú z WooCommerce na Shoptet

Väčšina obchodov prechádza preto, že prevádzka WordPressu stojí čas: aktualizácie pluginov, výkon hostingu, bezpečnostné záplaty aj zodpovednosť za PCI ležia na obchodníkovi. Shoptet to nahrádza mesačným poplatkom a spravovaným prostredím, ktoré už vie Zásielkovňu, Packetu, GoPay, Comgate, Heureku aj ďalšie lokálne služby. Ak sú vaši zákazníci v Česku alebo na Slovensku, vstavané integrácie zvyčajne nahradia niekoľko pluginov naraz. Daňou je flexibilita: produktový a obsahový model Shoptetu je užší než WordPress, takže čokoľvek vlastné potrebuje vopred určené miesto.

#### Mapovanie produktov, variantov a parametrov

WooCommerce ukladá produkty ako príspevky WordPressu s atribútmi, variantmi a kategóriami postavenými na taxonómiách. Shoptet očakáva štruktúrovaný import, kde sú produkty, varianty, parametre, kategórie a dostupnosť definované v jeho vlastných poliach. Varianty sa prevádzajú na varianty Shoptetu, ak je štruktúra možností konzistentná; atribúty používané na filtrovanie sa stávajú parametrami, ktoré treba pred importom založiť a pomenovať. Stromy kategórií môžu byť vnorené v oboch systémoch, Shoptet však funguje najlepšie s čistou, plytkou hierarchiou. Vlastné polia z ACF alebo pluginov nemajú automatický cieľ a rozhoduje sa o nich jednotlivo: text popisu, parameter, alebo vypustenie.

#### Zákazníci, objednávky a presmerovania URL

Zákaznícke účty možno importovať s kontaktmi a adresami; heslá preniesť nemožno, zákazníci si ich preto v novom obchode obnovia. História objednávok sa importuje pre prehľad a reporting, nie ako znovu editovateľné živé objednávky. Najcitlivejšou časťou sú URL: trvalé odkazy WordPressu sú ľubovoľné, zatiaľ čo Shoptet používa vlastné vzory ciest, takže každý indexovaný produkt, kategória aj stránka potrebuje pred spustením presmerovanie 301 na ekvivalent v Shoptete. Presmerovania zachovávajú kontinuitu URL a znižujú riziko; žiadna migrácia nemôže zaručiť nezmenené pozície.

#### Prepnutie a prvé dni na Shoptete

Odporúčame prevádzkovať obchod na Shoptete najskôr v testovacom režime s kompletným importovaným katalógom, skontrolovať vzorku produktov, cien, sadzieb DPH a variantov a až potom prepnúť DNS. Feedy pre Heureku a ďalšie porovnávače treba znovu vygenerovať zo Shoptetu a odoslať, Google Search Console má v deň spustenia dostať novú sitemapu. WordPress nechajte krátko dostupný len na čítanie, aby sa nič nestratilo, kým nie je mapa presmerovaní potvrdená.

#### FAQ

Q: Dajú sa migrovať objednávky a zákazníci z WooCommerce na Shoptet?
A: Zákazníkov vrátane adries importovať možno. Objednávky sa importujú ako história pre prehľad, nestávajú sa editovateľnými živými objednávkami. Heslá sa preniesť nedajú nikdy, zákazník si pri prvom prihlásení nastaví nové.

Q: Budú moje URL z WooCommerce na Shoptete fungovať?
A: Iba s explicitnou mapou presmerovaní 301. Vzory URL WordPressu a Shoptetu sa líšia, mapovanie preto staviame z vašich indexovaných adries a pred spustením ho overujeme.

Q: Čo sa stane s pluginmi WooCommerce?
A: Každý plugin prejdeme. Mnohé funkcie pre český a slovenský trh sú v Shoptete natívne, niektoré majú doplnky a zvyšok vyžaduje vlastné riešenie alebo sa po dohode vypustí.

Q: Ako dlho trvá migrácia z WooCommerce na Shoptet?
A: Typický malý až stredný katalóg zaberie dva až štyri týždne vrátane testovacieho behu, presmerovaní a spustenia; zložité parametre alebo veľká história objednávok trvajú dlhšie.

Sources:
- Shoptet Developers - Import dát: https://developers.shoptet.com/shoptet-tools/data-import/
- WooCommerce - Import a export produktov v CSV: https://woocommerce.com/document/product-csv-importer-exporter/

### Guides

### Ako vybrať e-shopovú platformu, kým začnete migrovať

URL: https://prevedshop.com/sk/sprievodcovia/ako-vybrat-eshopovu-platformu
Language: sk
Last reviewed: 2026-09-02

Výber platformy je rozhodnutie, ktoré určuje náklady každej neskoršej migrácie. Zoznamy funkcií od dodávateľov pomáhajú málo, pretože väčšina moderných platforiem pokrýva základ. Užitočné otázky sa týkajú štruktúry katalógu, trhu, na ktorý predávate, systémov, ktoré musíte napojiť, miery vlastníctva, ktorú chcete, a toho, čo bude vyžadovať samotná migrácia. Tento sprievodca prejde týchto päť otázok a končí krátkym zoznamom varovných signálov, ktoré by mali rozhodnutie zastaviť.

#### Začnite katalógom, nie zoznamom funkcií

Spočítajte produkty, varianty a parametre a pozrite sa, ako spolu súvisia. Tri rozmery možností s čistou sadou filtrovacích atribútov sa zmestia takmer do akejkoľvek platformy. Sady atribútov odlišné podľa typu produktu, bundly, konfigurátory, B2B cenníky alebo tisíce variantov zužujú výber na platformy s bohatším dátovým modelom, ako je Adobe Commerce, Shopware alebo composable riešenie. Spíšte päť najproblematickejších produktov vo vašom katalógu a spýtajte sa každej kandidátskej platformy, ako by ich uložila; odpovede prezradia viac než akákoľvek porovnávacia tabuľka.

#### Trh, jazyk a integrácie

Obchod predávajúci českým a slovenským zákazníkom potrebuje miestnych dopravcov, platobné brány, feedy pre porovnávače a fakturačné pravidlá. Shoptet alebo Upgates ich ponúkajú natívne; globálna SaaS platforma to zvládne cez aplikácie za cenu ďalších nákladov a údržby. Predaj do viacerých krajín otvára iné otázky: jazykové mutácie, meny, DPH a či je správnym tvarom jeden obchod, alebo niekoľko. Spíšte systémy, ktoré musia zostať napojené - ERP, účtovníctvo, sklad, PIM, feedy pre trhoviská - a overte, či má každý kandidát udržiavaný konektor, alebo len API, proti ktorému by ste museli stavať sami.

#### Vlastníctvo, náklady a cesta migrácie

Hostované platformy vymieňajú kontrolu za pohodlie: do databázy nesiahnete, ale ani nikdy nezáplatujete server. Open-source platformy vám dávajú dáta aj zodpovednosť. Celkové náklady zahŕňajú licenciu alebo tarif, hosting, aplikácie alebo rozšírenia, hodiny agentúry a interný čas strávený aktualizáciami. Nakoniec naceňte samotnú migráciu: koľko dát prenášate, či záleží na histórii objednávok a zákazníckych účtoch, koľko URL potrebuje presmerovanie a ktoré vlastné funkcie sa musia prestavať. Platforma, ktorá vyzerá na papieri lacnejšie, môže po pripočítaní migrácie vyjsť drahšie.

#### Varovné signály, ktoré by mali rozhodnutie zastaviť

Buďte opatrní, keď platforma nevie ukázať, ako bude reprezentovaný konkrétny typ dát z vášho súčasného obchodu, keď nevyhnutná integrácia existuje len ako aplikácia tretej strany s nejasnou údržbou, keď dodávateľ sľubuje, že sa pozície po migrácii nezmenia, alebo keď nikto nevie vysvetliť, ako by ste platformu neskôr opustili. Krátka discovery fáza so skutočnými vzorkami vašich dát väčšinu týchto otázok vyrieši skôr, než čokoľvek podpíšete.

#### FAQ

Q: Mám platformu vybrať pred posúdením migrácie, alebo až po ňom?
A: Ideálne posúdenie voľbu ovplyvní. Krátka discovery so skutočnými vzorkami produktov, zákazníkov a objednávok ukáže, ako by každý kandidát uložil vaše dáta a koľko prestavby by migrácia vyžadovala.

Q: Je hostovaná platforma vždy lacnejšia než open source?
A: Nie vždy. Hostované platformy majú predvídateľné poplatky, ale náklady na aplikácie rastú; open source nemá licenčný poplatok, ale vyžaduje hosting, aktualizácie a čas vývojárov. Porovnajte celkové náklady na tri roky vrátane migrácie.

Q: Aká dôležitá je e-shopová platforma pre SEO?
A: Menej než samotný proces migrácie. Každá bežná platforma sa môže dobre umiestňovať; o viditeľnosť pripravuje chýbajúca mapa presmerovaní, zmenený obsah alebo pomalé stránky po prechode.

Q: Môžem neskôr platformu znovu zmeniť?
A: Áno, ak zostanú dáta exportovateľné. Pred výberom overte, že produkty, zákazníkov, objednávky a obsah možno exportovať v štruktúrovanom formáte, aby ďalšia migrácia išla bez pomoci dodávateľa.

Sources:
- Google Search Central: Presun webu so zmenou URL: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### Kontrolný zoznam QA po spustení

URL: https://prevedshop.com/sk/sprievodcovia/kontrola-po-spusteni-eshopu
Language: sk
Last reviewed: 2026-07-21

Migrácia nie je hotová v momente, keď nový obchod ide naostro — je hotová vtedy, keď ste zámerne overili, že všetko, na čo sa zákazníci aj vyhľadávače spoliehajú, naozaj funguje v reálnych podmienkach. Testovacie prostredie odchytí väčšinu problémov, ale zopár sa prejaví až pri živej návštevnosti, skutočných platobných bránach a opätovnom prehľadávaní webu vyhľadávačmi. Tento kontrolný zoznam pokrýva, čo overiť v dňoch a týždňoch po prepnutí, bez ohľadu na to, akých platforiem sa migrácia týkala.

#### Overte celý proces pokladne v reálnych podmienkach

Vykonajte kompletný nákup sami na živom webe — nie na testovacom prostredí — a prejdite cesty, ktoré zákazníci skutočne používajú: nákup ako hosť aj po prihlásení, aspoň jeden produkt s variantmi a akékoľvek zľavové kódy či akcie, ktoré práve bežia. Skontrolujte, že sa správne odošlú potvrdzujúce e-maily o objednávke a že sa objednávka následne správne zobrazí vo vašom administračnom/objednávkovom systéme.

Nepredpokladajte, že sa pokrytie z testovacieho prostredia automaticky prenesie. Živé platobné brány, živé daňové služby a živé API na výpočet dopravy sa niekedy správajú inak než ich testovacie či sandboxové ekvivalenty — presne preto je potrebná reálna kontrola v živých podmienkach, nie spoliehanie sa na to, čo prešlo na testovacom prostredí.

#### Potvrďte, že platobné brány sú plne živé a správne nastavené

Overte, že spracovanie platieb beží v živom (nie testovacom/sandboxovom) režime, že sú zapnuté a funkčné všetky spôsoby platby, ktoré obchod predtým podporoval, a že sa reálna transakcia korektne zúčtuje od začiatku do konca — teda že peniaze skutočne dorazia, nielen že sa zmení stav objednávky. Skontrolujte aj funkčnosť vrátenia platby, keďže sa používa menej často než pokladňa a ľahko sa stane, že zostane neoverená.

Ak podporujete viacero spôsobov platby alebo mien, otestujte každý samostatne, namiesto toho, aby ste predpokladali, že keď funguje jeden spôsob, ostatné sú nastavené rovnako.

#### Skontrolujte pravidlá pre dane a dopravu na reálnych objednávkach

Logika daní a dopravy sa pri migrácii ľahko pokazí nenápadným spôsobom, keďže obe často závisia od nastavení, ktoré sa medzi platformami nemapujú čisto. Zadajte testovacie objednávky na svoje najčastejšie doručovacie destinácie a overte, že sa daň počíta správne a že sadzby aj dostupné spôsoby dopravy zodpovedajú tomu, čo ste zamýšľali — nielen tomu, čo nová platforma nastavila predvolene.

Osobitnú pozornosť venujte akýmkoľvek špeciálnym prípadom, na ktoré sa váš biznis spolieha: daňové výnimky, prahy pre dopravu zdarma, pravidlá špecifické pre región alebo obmedzenia dopravy pri určitých produktoch. Práve tieto detaily nastavenia sa pri migrácii najčastejšie stratia alebo nastavia nesprávne predvolene.

#### Namátkovo skontrolujte presmerovania, nielen tie, na ktoré si spomeniete

Aj s kompletnou mapou presmerovaní pripravenou pred spustením namátkovo skontrolujte po prepnutí reálnu vzorku URL adries: stránky s najvyššou návštevnosťou, zopár stránok s nižšou návštevnosťou a niekoľko zámerných výnimiek (vyradené produkty, zlúčené kategórie). Overte, že sa každá presmeruje na správny cieľ jedným skokom, bez reťazcov alebo slučiek.

Skontrolujte tiež vzorku URL adries, ktoré by na starom webe nemali existovať — preklepy, staré URL adresy s parametrami, čokoľvek, čo mohol robot náhodou indexovať —, aby ste sa uistili, že sa vyriešia zmysluplne, a nie chybou, ktorá by pôsobila ako širší problém.

#### Potvrďte kontinuitu analytiky a merania

Overte, že vaša analytická platforma, meranie konverzií aj akékoľvek reklamné pixely na novom webe fungujú správne — zadaná testovacia objednávka by sa mala v reportoch analytiky aj reklamnej platformy zobraziť rovnako ako predtým. Meracie kódy sa pri zmene platformy ľahko potichu stratia, pretože chýbajúci alebo nesprávne nastavený pixel nevyhodí chybové hlásenie — jednoducho prestane odosielať dáta.

Skoré čísla z analytiky po spustení porovnávajte s vaším predmigračným základom pre rovnaký typ dňa (pracovný deň verzus víkend, podobné zdroje návštevnosti), nie s hrubým porovnaním pred/po, keďže bežné výkyvy návštevnosti inak môžu skutočný problém s meraním prekryť alebo napodobniť.

#### Skontrolujte prístup k zákazníckym účtom a históriu objednávok

Nechajte zopár reálnych (alebo testovacích) zákazníckych účtov potvrdiť, že sa vedia prihlásiť, vidia svoju správnu históriu objednávok a majú prístup ku všetkým funkciám účtu, na ktoré boli zvyknuté predtým — uložené adresy, uložené spôsoby platby tam, kde to platí, zostatky vernostných bodov, ak ich obchod ponúka. Problémy s prístupom k účtu sú pre zákazníkov, ktorí na ne narazia, veľmi viditeľné a priamo ovplyvňujú dôveru, preto sa oplatí overiť ich zámerne, nie predpokladať, že migrácia účtov „asi fungovala“.

Ak migrácia hesiel nebola súčasťou technického prenosu (bežné pri platformách s nekompatibilným hashovaním hesiel), uistite sa, že zákazníci majú jasnú cestu na obnovu hesla a že o nej vedia, nielen že je technicky dostupná.

#### Sledujte pokrytie v Search Console počas nasledujúcich týždňov

Sledujte Search Console (alebo ekvivalent pre iné vyhľadávače) ešte dlho po dni spustenia — chyby pri prehľadávaní, stav indexovania a akýkoľvek nárast hlásených chýb 404 sú najskoršími signálmi problému s presmerovaním alebo canonical tagom, ktorý testovanie prehliadlo. Porovnávajte to s vaším predmigračným základom, aby ste vedeli odlíšiť skutočný regres od bežných krátkodobých výkyvov po zmene webu.

Toto obdobie sledovania je tiež vhodná chvíľa na opätovné odoslanie mapy webu, ak ste tak ešte neurobili, a na potvrdenie, že stránky, ktoré očakávate v indexe, sa v nasledujúcich týždňoch naozaj objavujú vo výsledkoch vyhľadávania, nielen že boli prehľadané.

#### FAQ

Q: Ako dlho by malo QA po spustení pokračovať?
A: Aktívna, takmer denná kontrola je zvyčajne najdôležitejšia počas prvého jedného až dvoch týždňov, keď sa prejaví väčšina problémov s nastavením a presmerovaniami. Opätovné indexovanie vyhľadávačmi a ustálenie vzorcov návštevnosti trvá dlhšie, takže miernejšie sledovanie (Search Console, trendy v analytike) sa oplatí udržiavať dlhšie — bežných je aj niekoľko týždňov — namiesto toho, aby ste prestali hneď, ako prvý týždeň vyzerá čisto.

Q: Čo je najdôležitejšie skontrolovať ako prvé po spustení?
A: Reálny, živý test pokladne a platby, keďže priamo ovplyvňuje tržby a je to jediný proces, ktorého sa dotkne každý zákazník. Aj problémy s presmerovaniami a meraním sú dôležité, ale nefunkčná pokladňa je najnákladnejší problém, ktorý môže zostať neodhalený hoci len pár hodín.

Q: Je normálne, že pozície vo vyhľadávaní tesne po migrácii mierne klesnú?
A: Určitý krátkodobý výkyv je bežný aj pri dobre vykonanej migrácii, keďže vyhľadávače potrebujú čas na opätovné prehľadanie a vyhodnotenie nových URL adries. Nenormálny je pretrvávajúci pokles alebo nárast chýb pri prehľadávaní — to je signál, že treba skontrolovať mapu presmerovaní a canonical tagy, či nedošlo ku skutočnej chybe, namiesto čakania, kým to samo prejde.

Q: Kto v tíme by mal mať zodpovednosť za QA po spustení?
A: Ideálne niekto s prehľadom o celom obchode, nielen technický tím migrácie — pretože viaceré z týchto kontrol (či daňové pravidlá pôsobia správne, správanie zákazníckych účtov, či čísla merania vyzerajú normálne) profitujú z biznisového kontextu, nielen z technického overenia, že daná funkcia existuje.

Sources:
- Google Search Central: presun webu so zmenou URL adries: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### Čistenie produktových dát pred migráciou

URL: https://prevedshop.com/sk/sprievodcovia/cistenie-produktovych-dat-pred-migraciou
Language: sk
Last reviewed: 2026-07-21

Migrácia platformy skopíruje presne to, čo jej dáte — po vás neupratuje. Duplicitné SKU, osirotené obrázky, nekonzistentné kategórie a nesúladné štruktúry variantov, ktoré sa potichu hromadili roky, sa na novú platformu prenesú presne v pôvodnej podobe, pokiaľ sa nimi niekto nezaoberá vopred. Takéto čistenie pred migráciou je oveľa lacnejšie než po nej, keď sa na výsledok už spoliehajú zákazníci aj vyhľadávače. Tento návod pokrýva, na čo sa zamerať a ako to postupne riešiť.

#### Nájdite a vyriešte duplicitné SKU a takmer duplicitné produkty

Exportujte celý zoznam produktov a najprv skontrolujte presné duplicity SKU — zvyčajne ide o chybu pri zadávaní dát alebo importe a po nájdení sa dajú jednoducho zlúčiť. Potom hľadajte takmer duplicity: rovnaký produkt znovu vytvorený pod iným SKU, čo je často výsledok opätovného importu dodávateľského feedu, ktorý sa nezhodoval s existujúcimi záznamami, alebo produkt, ktorý bol po systémovej zmene ručne vytvorený nanovo namiesto upravenia.

Pre každý duplicitný pár rozhodnite, ktorý záznam je ten „skutočný“ — zvyčajne ten s úplnejšími dátami, dlhšou históriou objednávok alebo lepšími SEO signálmi ako spätné odkazy či recenzie — a druhý zlúčte alebo presmerujte doňho, namiesto toho, aby ste migrovali oba a riešili to až na novej platforme.

#### Vypátrajte osirotené obrázky a médiá

Osirotené médiá — obrázky a súbory nahrané do knižnice médií, na ktoré už neodkazuje žiadny produkt, kategória ani obsahová stránka — sa prirodzene hromadia počas rokov aktualizácií produktov, sezónnych kampaní a zmien platformy. Na novej platforme neprinášajú žiadnu hodnotu a len predlžujú migráciu a zaberajú úložisko, preto sa oplatí ich identifikovať a vylúčiť.

Dajte si pozor aj na opačný prípad: obrázky, na ktoré sa odkazuje, ale sú nefunkčné (chýbajúci súbor, mŕtva externá URL adresa), sa oplatí zachytiť teraz, keďže nefunkčný obrázok na stránke produktu je malý, ale reálny problém s dôveryhodnosťou, ktorý sa oveľa ľahšie opravuje na vašich aktuálnych, dobre známych dátach než až po presune.

#### Zjednoťte kategórie a atribúty

Roky ad hoc doplnkov zvyčajne zanechajú kategórie a atribúty nekonzistentné: rovnaký pojem naprieč produktmi napísaný alebo napísaný veľkými písmenami inak, kategórie, ktoré sa prekrývajú alebo duplikujú, atribúty použité na jeden účel v jednej produktovej línii a na iný účel v druhej. Táto nekonzistentnosť zvyčajne nespôsobuje viditeľné problémy na starej platforme, kde sa zamestnanci naučili s ňou pracovať, ale stáva sa skutočnou záťažou, akonáhle sa mechanicky namapuje na dátový model novej platformy.

Ešte pred migráciou vybudujte (alebo potvrďte) čistú, odsúhlasenú taxonómiu — definovaný strom kategórií a definovaný zoznam atribútov s konzistentným pomenovaním — a porovnajte s ňou svoje skutočné dáta. Toto je zároveň vhodná chvíľa opýtať sa, ktoré atribúty sú stále zmysluplné pre zákazníkov alebo interné procesy a ktoré existujú len preto, že ich nikto neodstránil.

#### Zosúlaďte nesúlad v štruktúre variantov

Štruktúry variantov (veľkosť, farba, materiál a ich kombinovanie do konkrétnych predajných SKU) sa medzi platformami spracúvajú odlišne a nekonzistentné zdrojové dáta to ešte zhoršujú. Hľadajte produkty, kde možnosti variantov nesledujú konzistentný vzor — niektoré varianty veľkosti pomenované „S/M/L“ a iné pri tej istej produktovej línii „Small/Medium/Large“, alebo produkty, kde kombinácia variantov v systéme existuje, ale nemá za sebou platnú cenu ani stav skladu.

Cieľový model variantov si rozhodnite pred migráciou, nie počas nej. To, či nová platforma spracúva kombinácie variantov rovnako ako stará — a kde nie —, rozhoduje o tom, či sa vaše existujúce dáta o variantoch dajú namapovať priamo, alebo si najprv vyžadujú prestavbu.

#### Rozhodnite, čo sa má naozaj presunúť

Nie všetko vo vašom súčasnom katalógu si zaslúži miesto na novej platforme. Vyradené produkty bez zostávajúceho skladu, testovacie či zástupné záznamy a staršie polia, ktorých pôvodný účel už nikto nevie vysvetliť, sú kandidátmi na to, aby zostali za vami — s zdokumentovaným rozhodnutím, nie tichým vypustením. Migrovať menej, zámerne, je často lepšie než migrovať všetko a riešiť to až potom na neznámom novom systéme.

Pri všetkom, čo sa rozhodnete nemigrovať a čo má stále indexovanú URL adresu, sa uistite, že to zahrniete do plánu presmerovaní (pozri návod na mapovanie presmerovaní), namiesto toho, aby ste to náhodne nechali skončiť na chybe 404.

#### FAQ

Q: Koľko času máme vyhradiť na čistenie dát pred migráciou?
A: Výrazne to závisí od veľkosti katalógu a od toho, ako neusporiadané dáta skutočne sú — malý, dobre udržiavaný katalóg potrebuje oveľa menej času než ten s desiatkami tisíc SKU a rokmi importov z dodávateľských feedov. Skutočný rozsah ukáže až audit dát; preskočenie auditu a hádanie je spôsob, ako sa čas na čistenie podcení.

Q: Máme dáta čistiť pred projektom migrácie, alebo počas neho?
A: Pred ním, alebo prinajmenšom ako výslovnú skorú fázu s vlastným krokom kontroly — nie zamiešané do technického prenosu dát. Rozhodnutia pri čistení (čo je duplicita, čo sa dá bezpečne vypustiť, na čo slúžilo záhadné vlastné pole) zvyčajne potrebujú vstup od niekoho, kto pozná históriu katalógu, a to je iný druh práce než samotné technické mapovanie a prenos.

Q: Čo ak si nie sme istí, či je duplicita naozaj duplicitou?
A: Označte to, namiesto toho, aby ste hádali jedným alebo druhým smerom. Takmer duplicitný produkt s inou cenou, inými možnosťami variantov alebo inou históriou objednávok môže byť legitímny samostatný produkt, ktorý len vyzerá podobne. V prípade pochybností ponechajte oba a vráťte sa k tomu po dokončení auditu, namiesto zlúčenia na základe odhadu.

Q: Dá sa čistenie dát robiť, kým starý obchod stále beží a prijíma objednávky?
A: Áno, pre väčšinu auditu a plánovacej práce — prezeranie exportov, rozhodovanie o zlučovaní a budovanie cieľovej taxonómie si nevyžaduje zásah do živého obchodu. Samotné uplatnenie zmien (zlučovanie záznamov, mazanie osirotených médií) je zvyčajne bezpečnejšie robiť na kópii alebo exporte a vyčistenú sadu dát priniesť do migrácie, namiesto úpravy živého katalógu uprostred auditu.

### Kontrolný zoznam pre replatforming e-shopu

URL: https://prevedshop.com/sk/sprievodcovia/checklist-zmeny-eshopovej-platformy
Language: sk
Last reviewed: 2026-07-21

Zmena platformy online obchodu je projekt, nie tlačidlo, ktoré stlačíte. Na tom, aké platformy sú do toho zapojené, záleží menej, než väčšina ľudí predpokladá — o tom, či migrácia prebehne hladko, rozhoduje to, či ste v poriadku urobili nudné časti: preverili, čo máte, zámerne to namapovali, naplánovali presmerovania, otestovali na testovacom prostredí a po prepnutí obchod pozorne sledovali. Tento kontrolný zoznam prevedie touto postupnosťou bez ohľadu na to, z akej platformy odchádzate alebo na akú prichádzate.

#### 1. Začnite prieskumom a auditom, nie porovnávaním nástrojov

Ešte pred porovnávaním cieľových platforiem preverte, čo skutočne máte na tej súčasnej: koľko produktov a variantov, koľko zákazníckych účtov a akú históriu objednávok, ktoré vlastné polia sa aktívne používajú a ktoré sú opustenými zvyškami, na ktorých aplikáciách či integráciách vitrína závisí a ktoré URL adresy majú v súčasnosti zmysluplnú návštevnosť. Práve tento audit mení vetu „migrujeme“ na projekt s presne stanoveným rozsahom a reálnym zoznamom toho, čo sa musí presunúť.

V tejto fáze buďte úprimní ohľadom kvality dát. Ak má váš katalóg známe duplicity, osirotené kategórie alebo nekonzistentné atribúty, zapíšte si to už teraz — vyčistiť to je lacnejšie pred presunom než po ňom, a preskočenie auditu je spôsob, ako tímy tieto problémy objavia až uprostred migrácie.

#### 2. Namapujte dátový model ešte pred prvým políčkom

Každá platforma štruktúruje produkty, varianty, kategórie aj zákaznícke dáta mierne odlišne. Pred presunom akýchkoľvek dát vybudujte explicitné mapovanie: ktoré zdrojové pole ide na ktoré cieľové pole, ktoré zdrojové koncepty (vlastný atribút, štítok, typ balíka) nemajú priamy ekvivalent na cieli a vyžadujú rozhodnutie, a ktoré polia sa dajú bezpečne úplne vypustiť, pretože na nich už nič nezávisí.

Toto mapovanie zdokumentujte niekde trvanlivom — v tabuľke či zdieľanom dokumente, nie len v niekoho pamäti. Stane sa referenciou, ku ktorej sa všetci vracajú počas QA, a je to prvá vec, ktorú budete chcieť, keď po spustení niečo nebude vyzerať v poriadku.

#### 3. Naplánujte presmerovania a štruktúru URL adries včas

Štruktúra URL adries je jedno z najčastejších miest, kde migrácia potichu poškodí SEO a poruší záložky. Zostavte si úplný zoznam súčasných URL adries — stránky produktov, kategórií a kolekcií, blogové či obsahové stránky a akékoľvek vlastné vstupné stránky — a pred spustením čohokoľvek rozhodnite novú URL adresu pre každú z nich. Stránky bez čistého ekvivalentu na novej platforme si vyžadujú explicitné rozhodnutie (zvyčajne presmerovanie na najbližšiu zodpovedajúcu kategóriu alebo hlavnú stránku), nie tichú chybu 404.

Toto plánovanie prebieha dávno pred prepnutím, ideálne paralelne s prácou na mapovaní dát, keďže obe veci spolu súvisia: to, ako mapujete kategórie a produkty, často určuje, ako budú vyzerať nové URL adresy. Celý postup nájdete v samostatnom návode na mapovanie presmerovaní, odkazovanom nižšie.

#### 4. Vybudujte testovacie prostredie a vykonajte skutočné QA

Nikdy neberte prvý import ako finálny. Nahrajte namapované dáta na testovaciu alebo skúšobnú inštanciu cieľovej platformy a obchod naozaj používajte: prechádzajte kategórie, prezerajte stránky produktov, kontrolujte výber variantov a ceny, otestujte košík aj proces pokladne a potvrďte, že sa zákaznícke účty a história objednávok zobrazujú správne. Zapojte niekoho mimo migračného tímu — čerstvý pohľad odhalí veci, ktoré si tí, čo mapovanie budovali, prestali všímať.

Berte túto fázu ako iteratívnu. Je normálne, že sa pri prvom prechode nájdu problémy s mapovaním; cieľom je zachytiť a opraviť ich práve tu, na testovacom prostredí, kde chyba stojí len opätovný import, nie výpadok naostro či chybu viditeľnú pre zákazníkov.

#### 5. Naplánujte okno prepnutia ako operáciu, nie ako preklopenie vypínača

Písomne rozhodnite, čo sa počas prepnutia stane: ako sa naložia s novými objednávkami na starej platforme, ak migrácia trvá dlhšie (dočasné zmrazenie objednávok, stránka údržby, alebo pokračovanie prevádzky až do definovanej finálnej synchronizácie), kto vykoná finálnu synchronizáciu dát, kto overí DNS aj SSL na novej platforme a kto má právomoc vrátiť zmeny späť alebo pozastaviť spustenie, ak niečo nebude v poriadku.

Dajte tímu na daný deň zdieľaný kontrolný zoznam, nie len plán v niečej hlave. Uponáhľané alebo nejasné prepnutie je presne miesto, kde inak dobre pripravené migrácie strácajú dáta — napríklad zopár objednávok zadaných v medzere medzi finálnou synchronizáciou a spustením naostro — preto na túto medzeru plánujte explicitne, namiesto toho, aby ste dúfali, že nebude záležať.

#### 6. Sledujte dianie aj po spustení — migrácia nekončí prepnutím

Dni a týždne po prepnutí sú presne obdobie, keď sa prejavia problémy, ktoré testovacie prostredie nezachytilo: nesprávne nastavená platobná brána pre živú návštevnosť, pravidlo dane či dopravy, ktoré sa pri reálnych objednávkach správalo inak, presmerovania fungujúce pre stránky, ktoré ste testovali, ale nie pre okrajové prípady, alebo meraci pixel, ktorý potichu prestal fungovať. Nastavte si zámerný proces sledovania namiesto toho, aby ste predpokladali, že ticho znamená úspech.

Náš kontrolný zoznam QA po spustení (odkazovaný nižšie) túto fázu pokrýva podrobne — overenie pokladne a platieb, namátkovú kontrolu presmerovaní, kontinuitu analytiky aj sledovanie Search Console —, keďže si zaslúži vlastný, dedikovaný proces, nie uponáhľaný dodatočný nápad vo chvíli, keď sa pozornosť tímu už presunula inam.

#### FAQ

Q: Ako dlho trvá projekt replatformingu?
A: Výrazne to závisí od veľkosti katalógu, zložitosti dát a počtu vlastných integrácií. Malý, čistý katalóg sa zvyčajne presunie rýchlejšie než ten s desiatkami tisíc SKU, rokmi nahromadených vlastných polí a viacerými napojenými aplikáciami. Reálny odhad dostanete po audite konkrétneho obchodu, nie zo všeobecného harmonogramu.

Q: Máme migrovať všetko naraz, alebo po fázach?
A: Oba prístupy fungujú v závislosti od obchodu. Jednorazové prepnutie sa jednoduchšie plánuje a vyhýba sa paralelnej prevádzke dvoch platforiem, ale sústreďuje riziko do jedného okna. Fázový prístup (napríklad najprv presun obsahu a dizajnu, potom katalógu, potom transakčných dát) riziko rozkladá, ale vyžaduje starostlivejšiu koordináciu toho, čo je „naostro“ kde v danej fáze. Správna voľba závisí od veľkosti katalógu, tolerancie k oknu údržby a od toho, ako tesne sú vaše systémy prepojené.

Q: Čo je najčastejšou príčinou problémov pri migrácii?
A: Preskočenie alebo uponáhľanie fáz auditu a mapovania. Tímy, ktoré sa vrhnú rovno na presun dát bez toho, aby najprv pochopili, čo skutočne majú — duplicitné produkty, nezdokumentované vlastné polia, URL adresy, s ktorými nikto nepočítal —, majú tendenciu tieto problémy objaviť naostro, po prepnutí, namiesto toho, aby ich zachytili na testovacom prostredí, kde sú lacné na opravu.

Q: Musíme počas migrácie zmraziť starý obchod?
A: Nie nutne počas celého projektu, ale potrebujete jasný plán pre finálne okno prepnutia — zvyčajne krátke zmrazenie alebo definovaný bod finálnej synchronizácie —, aby sa medzi posledným stiahnutím dát a spustením nového obchodu nestratili žiadne objednávky ani zmeny u zákazníkov. Dĺžka tohto okna závisí od objemu objednávok a od toho, ako je riešená finálna synchronizácia.

Sources:
- Google Search Central: presun webu so zmenou URL adries: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### SEO bezpečné mapovanie presmerovaní pri migrácii e-shopu

URL: https://prevedshop.com/sk/sprievodcovia/mapovanie-presmerovani-bez-straty-seo
Language: sk
Last reviewed: 2026-07-21

Pozície vo vyhľadávaní a organická návštevnosť patria medzi najcennejšie veci, ktoré má zabehnutý obchod, a zároveň sú jedny z najľahšie poškoditeľných pri nedbalej migrácii. Dobrou správou je, že kontinuita URL adries je riešiteľný, mechanický problém: pripravte poriadnu mapu presmerovaní, správne ju implementujte a sledujte, ako na ňu vyhľadávače reagujú. Tento návod prevedie celým procesom od začiatku do konca, bez ohľadu na to, akých platforiem sa migrácia týka.

#### Najprv zostavte úplný inventár URL adries

Skôr než čokoľvek namapujete, potrebujete úplný zoznam URL adries, ktoré sa aktuálne používajú — nielen tie, na ktoré si spomeniete, ale úplne každú stránku produktu, kategórie a kolekcie, blogovú či obsahovú stránku a akékoľvek vlastné vstupné stránky existujúce na súčasnom webe. Získajte ich z mapy webu, z reportov stránok vo vašom analytickom nástroji aj z prehľadania živého webu, a všetky tri zdroje si navzájom skrížte, keďže každý z nich má tendenciu prehliadnuť niečo, čo zachytia ostatné.

Osobitnú pozornosť venujte URL adresám, ktoré majú organickú návštevnosť alebo externé spätné odkazy, aj keď by ste ich inak považovali za menej dôležité. Blogový príspevok s nízkou návštevnosťou, no s niekoľkými kvalitnými spätnými odkazmi, sa oplatí namapovať správne; jeho tichá strata je malá, ale zbytočná.

#### Namapujte každú URL adresu na jej nový ekvivalent — a výnimky riešte zámerne

Pre každú URL adresu vo vašom inventári rozhodnite jej cieľ na novej platforme. Väčšina stránok produktov a kategórií bude mať pomerne priamy ekvivalent, akonáhle je mapovanie dát uzavreté. Stránky bez čistého ekvivalentu (vyradený produkt, jednorazová vstupná stránka, kategória, ktorá už neexistuje) si aj tak vyžadujú explicitné rozhodnutie — zvyčajne presmerovanie na najbližšiu zodpovedajúcu kategóriu, relevantnú hlavnú stránku, alebo vo výnimočných prípadoch zámernú, akceptovanú chybu 404 —, namiesto toho, aby sa predvolene presmerovali na domovskú stránku alebo náhodne skončili chybou 404.

Plošné „presmerovať všetko na domovskú stránku“ je bežná skratka, ktorá aktívne škodí: rozrieďuje signály relevancie a poskytuje používateľom horší zážitok v porovnaní s tým, keby skončili na najbližšej relevantnej stránke.

#### Implementujte 301 presmerovania a skontrolujte reťazce aj slučky

Pre URL adresy, ktoré sa skutočne trvalo presunuli, používajte trvalé (301) presmerovania — je to signál, ktorý vyhľadávačom hovorí, aby preniesli hodnotenie na novú URL adresu. Akonáhle sú presmerovania živé, aktívne kontrolujte reťazce presmerovaní (URL A → B → C, keď by stačilo A → C) aj slučky (A → B → A), keďže oboje sú bežným vedľajším produktom postupných úprav mapy presmerovaní a oboje plytvajú rozpočtom na prehľadávanie a pridávajú latenciu. Cieľom je jeden skok z každej starej URL adresy priamo na jej finálny nový cieľ.

Po spustení manuálne otestujte reprezentatívnu vzorku presmerovaní — namátkovo skontrolujte stránky s vysokou návštevnosťou, zopár s nízkou a niekoľko zámerných výnimiek —, namiesto toho, aby ste predpokladali, že mapa je správna len preto, že prešla validáciou v tabuľke.

#### S canonical tagmi zaobchádzajte zámerne

Canonical tagy hovoria vyhľadávačom, ktorá URL adresa je autoritatívnou verziou, keď je podobný obsah dostupný z viacerých adries. Po migrácii sa uistite, že canonical tag každej stránky smeruje na jej vlastnú živú, správnu novú URL adresu — nie na zostávajúcu starú URL adresu a omylom ani na URL adresu inej stránky skopírovanú zo šablóny. Chyba v tomto môže vyhľadávače pomýliť ohľadom toho, ktorú verziu stránky majú indexovať, aj keď sú samotné presmerovania správne.

Ak nová platforma generuje canonical tagy automaticky, overte jej predvolené správanie namiesto toho, aby ste predpokladali, že je vhodné pre vaše nastavenie — automatická canonicalizácia niekedy smeruje na neočakávané URL adresy pri parametrizovaných alebo stránkovaných stránkach.

#### Znovu odošlite XML mapu webu a aktualizujte interné odkazy

Akonáhle je nový web živý s funkčnými presmerovaniami, vygenerujte a odošlite novú XML mapu webu, ktorá odzrkadľuje novú štruktúru URL adries, cez Google Search Central aj nástroje pre webmasterov iných vyhľadávačov, aby roboty mohli efektívne objavovať nové stránky namiesto toho, aby sa spoliehali výlučne na sledovanie presmerovaní zo starých URL adries.

Zároveň aktualizujte interné odkazy naprieč webom — navigáciu, pätu, odkazy na súvisiace produkty, obsah blogu —, aby smerovali priamo na nové URL adresy, nie cez presmerovanie. Interné odkazy, ktoré stále smerujú na staré URL adresy, pridávajú zbytočný skok presmerovania pri každom kliknutí a ľahko sa prehliadnu, keďže viditeľne nič nepokazia; jednoducho fungujú menej efektívne.

#### Sledujte stav prehľadávania a indexovania po prepnutí

SEO práca pri migrácii nekončí spustením. V týždňoch po prepnutí sledujte Search Console (alebo ekvivalentný nástroj iných vyhľadávačov) kvôli chybám prehľadávania, náhlemu nárastu chýb 404, stránkam, ktoré sa neindexujú, alebo poklesu zobrazení či kliknutí pri stránkach, ktoré by mali fungovať normálne. Porovnávajte to s predmigračným základom, aby ste zachytili skutočný regres, nie bežný krátkodobý výkyv.

Buďte trpezliví, no nie pasívni: opätovné indexovanie chvíľu trvá aj vtedy, keď je všetko nastavené správne, ale chyba presmerovania alebo canonical tagu, ktorá zostane nepovšimnutá týždne, je oveľa nákladnejšia na opravu než tá, ktorú zachytíte v prvých dňoch po spustení.

#### FAQ

Q: Poškodí migrácia určite moje pozície vo vyhľadávaní?
A: Nie, ak je kontinuita URL adries ošetrená správne — kompletná mapa presmerovaní, správne canonical tagy a znovu odoslaná mapa webu sú hlavnou obranou. Nikto nedokáže zaručiť, že sa konkrétne pozície udržia, keďže hodnotenie závisí od mnohých faktorov nad rámec jedinej migrácie, ale správne mapovanie URL adries je jednoznačne najväčší faktor, ktorý viete ovplyvniť, aby ste si udržali to, čo ste mali.

Q: Mám použiť 301 alebo 302 presmerovania?
A: Používajte 301 (trvalé) presmerovania pre URL adresy, ktoré sa presunuli natrvalo, čo je bežný prípad pri migrácii platformy. 302 (dočasné) presmerovania signalizujú, že presun nie je trvalý, a vyhľadávače nemusia signál hodnotenia preniesť rovnako, takže pre mapu presmerovaní dokončenej migrácie sú nesprávnou voľbou.

Q: Čo ak by dve staré URL adresy mali smerovať na tú istú novú stránku?
A: To je v poriadku a bežné — napríklad dve staré URL adresy kategórií, ktoré sa na novej platforme zlúčili do jednej. Presmerujte obe staré URL adresy priamo na jednu novú. Vyhnúť sa treba opačnému prípadu: jednej starej URL adrese, pri ktorej nie je jasné, na akú novú stránku by sa mala mapovať, čo zvyčajne znamená, že rozhodnutie o mapovaní ešte nebolo skutočne urobené.

Q: Ako dlho mám ponechať staré presmerovania aktívne?
A: Ak je to prakticky možné, natrvalo. Spätné odkazy, záložky aj staré výsledky vyhľadávania odkazujúce na pôvodné URL adresy môžu pretrvávať dlho po migrácii a udržiavanie pravidla presmerovania stojí len málo. Príliš skoré odstránenie presmerovaní je bežný spôsob, ako sa z jednorazového nákladu migrácie stane opakujúci sa zdroj nefunkčných odkazov.

Sources:
- Google Search Central: 301 presmerovania: https://developers.google.com/search/docs/crawling-indexing/301-redirects
- Google Search Central: Zlúčenie duplicitných URL adries (canonicalizácia): https://developers.google.com/search/docs/crawling-indexing/canonicalization
- Google Search Central: Vytvorenie a odoslanie mapy webu: https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap

### Shopify vs WooCommerce: na ktorú platformu migrovať?

URL: https://prevedshop.com/sk/sprievodcovia/shopify-vs-woocommerce
Language: sk
Last reviewed: 2026-09-02

Shopify a WooCommerce sú dve platformy, na ktoré a z ktorých migrujeme najčastejšie, a voľba medzi nimi je málokedy o funkciách. Shopify je hostovaný systém s pevným modelom, ktorý odstraňuje prevádzkovú prácu; WooCommerce je otvorený plugin pre WordPress, ktorý vám dáva databázu aj zodpovednosť. Toto porovnanie sa pozerá na rozdiely, ktoré migráciu skutočne menia: dátový model, vlastníctvo, štruktúru nákladov, prácu s obsahom a SEO, a potom opisuje, ktoré obchody bývajú spokojnejšie na ktorej strane.

#### Dátový model: pevný verzus otvorený

Produkty Shopify majú pevnú schému s až tromi rozmermi možností a metapoliami pre všetko ostatné; kolekcie sú ručné alebo pravidlové zoznamy, nie strom taxonómie. Produkty WooCommerce sú príspevky WordPressu s neobmedzenými atribútmi, vlastnými poliami a vnorenými taxonómiami. Prechod na Shopify je preto konsolidácia - rozhodovanie, kde bude bývať každé vlastné pole - zatiaľ čo prechod na WooCommerce je väčšinou mapovanie malého, úhľadného modelu do väčšieho. Obchody s veľmi štruktúrovanými katalógmi zvyčajne migrujú ľahšie smerom k Shopify; obchody s nezvyčajnými dátami strácajú menej smerom k WooCommerce.

#### Vlastníctvo, hosting a náklady

Shopify účtuje tarif plus transakčné poplatky pri cudzích bránach a predplatné aplikácií; na oplátku nie je žiadny server, žiadne záplatovanie a žiadny rozsah PCI na vašej strane. WooCommerce nemá licenčný poplatok, platíte však spravovaný WordPress hosting, licencie pluginov a čas vývojára, ktorý udržiava aktualizácie bezpečné. Za tri roky sú súčty často bližšie, než obe strany tvrdia. Skutočný rozdiel je v tom, kde sedí riziko: na Shopify môže platforma zmeniť pravidlá a ceny; na WooCommerce môže zanedbaná sada pluginov obchod rozbiť.

#### Obsah a SEO

WordPress je plnohodnotné CMS, obchody na WooCommerce s veľkými blogmi, landing pages a vlastnými šablónami tak majú všetko na jednom mieste. Stránky a blog Shopify sú jednoduchšie a obsahovo bohaté obchody často prevádzkujú WordPress pre obsah vedľa Shopify pre predaj. V SEO sú platformy pri dobrom nastavení rovnocenné; pri migrácii záleží na zmene URL. Shopify vynucuje cesty `/products/` a `/collections/`, trvalé odkazy WordPressu sú ľubovoľné, každá migrácia medzi nimi teda potrebuje kompletnú mapu presmerovaní 301. Presmerovania znižujú riziko; pozície nie sú nikdy zaručené.

#### Ktoré obchody sa hodia na ktorú platformu

Shopify zvyčajne vyhovuje obchodom, ktoré chcú predvídateľnú prevádzku, predávajú do viacerých krajín cez Markets, používajú štandardnú logistiku a majú katalóg, ktorý sa zmestí do troch rozmerov možností. WooCommerce vyhovuje obchodom, ktoré potrebujú vlastnú logiku checkoutu, B2B ceny, nezvyčajné štruktúry produktov, hlbokú integráciu obsahu alebo prísne umiestnenie dát. Ak ani jeden opis nie je jasne váš, krátka discovery so skutočnými vzorkami produktov a objednávok to zodpovie rýchlejšie než akákoľvek porovnávacia tabuľka.

#### FAQ

Q: Je Shopify lepšie než WooCommerce pre SEO?
A: Ani jedna platforma nemá vrodenú výhodu. Viditeľnosť po migrácii závisí od mapy presmerovaní, zhody obsahu a rýchlosti stránok, nie od názvu platformy.

Q: Čo je lacnejšie, Shopify alebo WooCommerce?
A: Záleží od mierky a miery úprav. Shopify má predvídateľné poplatky plus aplikácie a transakčné poplatky; WooCommerce má hosting, licencie pluginov a čas vývojárov. Porovnajte trojročné súčty vrátane migrácie.

Q: Môžem prejsť zo Shopify na WooCommerce, nie len opačne?
A: Áno. Migrujeme oboma smermi; trasa Shopify → WooCommerce je opísaná zvlášť a ide najmä o mapovanie metapolí a prestavbu inteligentných kolekcií.

Q: Ovplyvňuje voľba dĺžku migrácie?
A: Čiastočne. Prechod na Shopify trvá dlhšie pri katalógoch s mnohými vlastnými poliami, pretože každé potrebuje rozhodnutie o metapoli; prechod na WooCommerce trvá dlhšie, keď treba nahradiť mnoho aplikácií pluginmi.

Sources:
- Shopify Help Center - Migrácia na Shopify: https://help.shopify.com/en/manual/migrating-to-shopify
- WooCommerce - Import a export produktov v CSV: https://woocommerce.com/document/product-csv-importer-exporter/

### Glossary

### 301 presmerovanie

URL: https://prevedshop.com/sk/slovnik/presmerovanie-301
Language: sk
Last reviewed: 2026-07-21

301 presmerovanie hovorí prehliadačom aj vyhľadávačom, že stránka sa natrvalo presunula na novú URL adresu, a každého — človeka aj robota —, kto požaduje starú adresu, pošle rovno na novú. „301“ je HTTP stavový kód, ktorý server vráti: je to štandardný, trvalý spôsob, ako povedať „tento obsah teraz žije tu“, na rozdiel od dočasného (302) presmerovania.

#### Čo 301 presmerovanie skutočne robí

Keď niekto požiada o starú URL adresu, server odpovie HTTP stavovým kódom 301 a novou adresou. Prehliadač presmerovanie vykoná automaticky, takže návštevník si to väčšinou ani nevšimne — skončí na novej stránke, nie na chybe. Vyhľadávače reagujú na rovnaký signál: 301 im hovorí, aby postupne preniesli hodnotu starej URL adresy na novú, namiesto toho, aby novú stránku považovali za nesúvisiaci, úplne nový obsah.

Toto je iné než 302 (dočasné) presmerovanie, ktoré robotom hovorí, že presun nie je trvalý a hodnota z vyhľadávania by sa nemala prenášať naplno. Rozdiel je aj oproti ručnej úprave odkazov na vlastnom webe — 301 zachytí každého, kto má starú URL adresu uloženú v záložkách, odkazovanú z iného webu alebo indexovanú vo výsledkoch vyhľadávania, nielen ľudí klikajúcich na odkazy, ktoré máte pod kontrolou.

#### Prečo na 301 presmerovaniach záleží pri migrácii platformy

Presun na novú platformu takmer vždy zmení štruktúru URL adries, aj keď sa ju snažíte zachovať čo najbližšie pôvodnej — URL adresy produktov, cesty kategórií aj blogové príspevky často skončia v inom tvare než predtým. Každá stará URL adresa, ktorú majú vyhľadávače indexovanú a na ktorú odkazujú iné weby, potrebuje 301 presmerovanie na svoj nový ekvivalent, inak prídete o nazbieraný signál hodnotenia danej stránky a návštevníkov pošlete do slepej uličky.

Toto riziko nie je teoretické: spustíte nový obchod bez plánu presmerovaní a typicky sa v priebehu pár dní od spustenia nahromadia chyby 404, prestanú fungovať prichádzajúce odkazy a klesne organická návštevnosť, pretože vyhľadávače navštevujú indexované URL adresy rýchlo. Práve plán presmerovaní pripravený pred spustením, nie narýchlo poskladaný po poklese návštevnosti, tomu dokáže zabrániť.

#### Presmerovania treba nastaviť správne, nielen ich mať

Samotné 301 presmerovanie nestačí — musí smerovať na správny cieľ. Presmerovanie každej starej URL adresy na novú domovskú stránku odkaz technicky „vyrieši“, ale zahodí konkrétnu relevanciu, ktorú vyhľadávač aj návštevník očakávali. My mapujeme staré URL adresy na ich najbližší reálny ekvivalent na novej platforme a stránky bez čistej zhody označíme, namiesto toho, aby sme hádali.

Kontrolujeme tiež reťazce presmerovaní (URL A na B na C) aj slučky, ktoré zvyšujú latenciu a môžu spôsobiť, že roboty prestanú reťazec sledovať úplne. Čistá migrácia končí jedným skokom na URL adresu, nie tromi.

#### FAQ

Q: Je 301 presmerovanie to isté ako zmena URL adresy?
A: Nie — zmena URL adresy bez presmerovania jednoducho poruší starý odkaz. 301 presmerovanie je inštrukcia, ktorá prepojí starú URL adresu s novou, takže každý (človek aj robot), kto požiada o starú adresu, je automaticky poslaný na novú stránku.

Q: Zachovajú 301 presmerovania moje pozície vo vyhľadávaní úplne?
A: Zachovajú väčšinu signálu hodnotenia spojeného so starou URL adresou, ale nie automaticky každú pozíciu pre každé kľúčové slovo — stále platia aj iné faktory ako kvalita webu a konkurencia. Čo 301 spoľahlivo urobí, je informovať vyhľadávače, že sa obsah presunul, namiesto toho, aby novú URL adresu považovali za nesúvisiacu.

Q: Ako dlho musím presmerovania udržiavať?
A: Prakticky natrvalo. Staré odkazy z iných webov, uložené záložky aj tlačené materiály môžu na staré URL adresy posielať návštevnosť ešte roky, a vyhľadávačom môže trvať, kým veľkú dávku presmerovaní úplne spracujú.

Q: Aký je rozdiel medzi 301 a 302 presmerovaním?
A: 301 signalizuje trvalý presun a prenáša signál hodnotenia na novú URL adresu; 302 signalizuje dočasný presun a vyhľadávače sú pri prenose tohto signálu opatrnejšie. Pri migrácii platformy, kde sa stará URL adresa už nevráti, je takmer vždy správnou voľbou 301.

Sources:
- Google Search Central: Presmerovania a Google Search: https://developers.google.com/search/docs/crawling-indexing/301-redirects

### Canonical tag

URL: https://prevedshop.com/sk/slovnik/kanonicka-znacka
Language: sk
Last reviewed: 2026-07-21

Canonical tag (`<link rel="canonical">`) je HTML značka, ktorá vyhľadávačom hovorí, ktorá URL adresa je hlavnou verziou stránky, ak je rovnaký alebo veľmi podobný obsah dostupný z viacerých adries. Návštevníkov nikam nepresmerováva — je to signál pre roboty, ktorá URL adresa má získať kredit a zobrazovať sa vo výsledkoch vyhľadávania.

#### Čo canonical tag skutočne robí

E-commerce platformy bežne servírujú rovnaký produkt alebo kategóriu cez viacero URL adries — s lomkou na konci aj bez nej, s rôznymi parametrami triedenia alebo filtrov, alebo dostupné z viacerých ciest kategórií. Bez canonical tagu musia vyhľadávače hádať, ktorú verziu indexovať, čo môže rozdeliť signál hodnotenia medzi takmer identické URL adresy namiesto toho, aby sa sústredil na jednu.

Canonical tag sa nachádza v `<head>` stránky a ukazuje na jedinú URL adresu, ktorá sa má považovať za hlavnú kópiu. Každý duplicitný alebo takmer duplicitný variant nesie canonical tag smerujúci späť na túto jednu URL adresu; hlavná URL adresa má zvyčajne canonical tag smerujúci sama na seba.

#### Prečo záleží pri migrácii platformy

Nové platformy často zavádzajú vlastné vzory URL adries pre filtrovanie, stránkovanie alebo triedenie, ktoré na starej platforme neexistovali, a ak canonical tagy nie sú nastavené správne od prvého dňa, ľahko vznikne neúmyselný duplicitný obsah. Chyba v tomto zvyčajne nespôsobí dramatický prepad ako chýbajúce presmerovanie, ale ticho rozrieďuje signál hodnotenia medzi takmer duplicitnými stránkami namiesto toho, aby sa sústredil na jednu — pomalší, ťažšie odhaliteľný problém.

Migrácia je zároveň prirodzená príležitosť opraviť už existujúce problémy s canonicalizáciou zo starej platformy, namiesto toho, aby sa preniesli nezmenené.

#### Canonical tagy verzus presmerovania

Canonical tag a presmerovanie riešia rôzne problémy. Presmerovanie (pozri 301 presmerovanie) je pre URL adresu, ktorá už vôbec neexistuje — pošle návštevníkov aj roboty na novú adresu. Canonical tag je pre URL adresy, ktoré stále existujú a sú stále dostupné, ale nemali by si medzi sebou konkurovať vo výsledkoch vyhľadávania — obe zostávajú aktívne, len jedna je označená ako referenčná verzia.

#### FAQ

Q: Presmeruje canonical tag návštevníkov na hlavnú URL adresu?
A: Nie. Návštevníci môžu naďalej skončiť na necanonickej URL adrese a tá sa načíta normálne — canonical tag len signalizuje vyhľadávačom, ktorú verziu majú indexovať a hodnotiť, správanie prehliadača nemení.

Q: Potrebujem canonical tagy, ak nemám duplicitný obsah?
A: Stále je bežnou praxou, aby každá stránka mala canonical tag smerujúci sama na seba, čo odstráni nejasnosti, ak sa duplicita niekedy neskôr objaví — napríklad cez sledovací parameter alebo novú URL adresu filtra.

Q: Môže canonical tag smerovať na stránku na inej doméne?
A: Áno, medzidoménové canonical tagy sú platné a niekedy sa používajú zámerne, ale pri migrácii platformy to zvyčajne nie je to, čo chcete — každá nová URL adresa by sa mala typicky canonicalizovať sama na seba, pričom starú doménu či staré URL adresy majú riešiť presmerovania, nie canonical tagy.

Q: Čo sa stane, ak moje canonical tagy smerujú na nesprávnu URL adresu?
A: Vyhľadávače môžu skončiť s indexovaním a hodnotením nesprávnej verzie stránky, alebo váš canonical signál úplne ignorovať, ak pôsobí nekonzistentne s inými signálmi (napríklad internými odkazmi alebo mapou webu). Canonical tagy kontrolujeme ako súčasť QA migrácie, namiesto toho, aby sme predpokladali, že ich nová platforma nastaví správne automaticky.

Sources:
- Google Search Central: Zlúčenie duplicitných URL adries: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

### Migrácia dát

URL: https://prevedshop.com/sk/slovnik/migracia-dat
Language: sk
Last reviewed: 2026-07-21

Migrácia dát je proces presunu informácií vášho obchodu — produktov, zákazníkov, objednávok, obsahu a všetkého, čo s nimi súvisí — z jednej platformy na druhú, vo forme, ktorú nová platforma vie skutočne správne použiť. Je to jadro technickej práce pri presune platformy, odlišné od dizajnu, plánovania presmerovaní alebo práce s integráciami, ktoré ju obklopujú, hoci všetky tieto veci závisia od toho, či je migrácia dát presná.

#### Čo sa skutočne migruje

Okrem zjavného produktového katalógu plná migrácia dát zvyčajne pokrýva zákaznícke účty a ich históriu objednávok, existujúce objednávky (otvorené aj historické), obsah ako blogové príspevky či statické stránky, recenzie, ak sú uložené priamo na platforme, a akékoľvek vlastné polia či metadáta špecifické pre váš biznis. Nie všetko sa nutne musí presunúť — časť historických dát sa môže skôr archivovať než aktívne migrovať, čo je rozhodnutie o rozsahu urobené počas posúdenia, nie predvolený predpoklad.

#### Prečo priamy export/import nestačí

Dve platformy málokedy modelujú dáta identicky — plochý zoznam produktov na jednej platforme môže byť na druhej hierarchický systém kategórií a atribútov; jednoduchý záznam zákazníka na jednej platforme sa možno musí na novej rozdeliť medzi niekoľko typov objektov. Doslovná kópia dát pole po poli z exportného súboru často vytvorí dáta, ktoré sú technicky prítomné, ale štrukturálne nesprávne — poškodené vzťahy variantov, stratené vlastné polia alebo záznamy zákazníkov, ktoré sa správne neprepoja s ich históriou objednávok. Skutočná migrácia dát znamená zámerné mapovanie každého typu dát, nielen presun súborov.

#### Ako k tomu pristupujeme

Začíname auditom dát — porozumením tomu, čo v starom systéme skutočne existuje, vrátane nezrovnalostí, ktoré sa nahromadili časom (duplicitní zákazníci, osirotené záznamy, nekonzistentné kategórie) — ešte pred rozhodnutím, ako sa to namapuje na novú platformu. Čistenie dát sa často deje ako súčasť tohto kroku, nie až po ňom, pretože verné migrovanie zlých dát len zreprodukuje rovnaké problémy na novej platforme. Ako toto zapadá do riadenej migrácie, popisujeme pri službe Čistenie a mapovanie dát.

#### FAQ

Q: Zahŕňa migrácia dát aj históriu mojich objednávok?
A: Môže — či sa historické objednávky aktívne migrujú do novej platformy, alebo sa archivujú samostatne, je rozhodnutie o rozsahu, keďže nie každá platforma či biznis potrebuje živú históriu objednávok v novom systéme. Toto riešime počas posúdenia.

Q: Prenesú sa moje vlastné polia automaticky?
A: Nie automaticky — vlastné polia potrebujú explicitný ekvivalent na novej platforme (často metapolia alebo vlastné atribúty) a toto mapovanie treba definovať, nie predpokladať, že existuje samo od seba.

Q: Môžem migrovať dáta sám pomocou pluginu alebo importného nástroja?
A: Pri malých, jednoduchých katalógoch to môže fungovať. Pri obchodoch s výraznejšou úpravou, históriou objednávok alebo problémami s kvalitou dát bežný importný nástroj zvyčajne nedokáže robiť rozhodnutia, ktoré vyžaduje poriadny audit a mapovanie dát — jednoducho presunie, čo je v súbore, chyby nevynímajúc.

Q: Ako predchádzate strate dát počas migrácie?
A: Auditom a mapovaním pred akýmkoľvek presunom, otestovaním migrácie najprv na testovacom prostredí a overením počtu záznamov aj namátkovou kontrolou dát po presune, namiesto toho, aby sme predpokladali, že import prebehol správne.

### Headless commerce

URL: https://prevedshop.com/sk/slovnik/headless-commerce
Language: sk
Last reviewed: 2026-07-21

Headless commerce je architektúra, v ktorej sa vitrína obchodu (to, čo zákazníci vidia a s čím pracujú) buduje oddelene od commerce backendu (produktový katalóg, košík, pokladňa, správa objednávok) a oba komunikujú cez API namiesto toho, aby tvorili jeden pevne prepojený systém. „Headless“ znamená, že vitrína — prezentačná vrstva — je oddelená od backendu, ktorý potom môže obsluhovať viacero rôznych „hláv“ (webová stránka, mobilná aplikácia, kiosk v predajni) z jedného zdroja pravdy.

#### Headless verzus tradičné (monolitické) platformy

Tradičná e-commerce platforma spája šablóny vitríny a backend do jedného celku — šablóny Liquid na Shopify alebo WordPress šablóny WooCommerce sú príklady toho, keď vitrínu generuje priamo samotná platforma. V headless riešení je vitrína samostatná aplikácia (často postavená na frameworku ako Next.js alebo podobnom) a dáta si vyžiada z API backendovej platformy namiesto toho, aby stránky vykresľovala priamo platforma. Niektoré platformy (Shopify, commercetools a ďalšie) podporujú tradičný aj headless režim súčasne.

#### Prečo to mení migráciu

Migrácia do headless riešenia alebo z neho je iný typ projektu než migrácia medzi dvomi tradičnými platformami. Presun obchodu z tradičnej platformy na headless architektúru zvyčajne znamená vybudovanie novej vitríny od základu (nie prenesenie existujúcej šablóny), zatiaľ čo migrácia backendu/katalógu sa riadi rovnakými princípmi mapovania dát ako každý iný presun. Presun medzi dvomi headless backendmi je na strane vitríny často jednoduchší, keďže frontend sa niekedy dá len prepojiť s novým API namiesto úplného prebudovania — no katalógové, objednávkové aj zákaznícke dáta backendu si aj tak vyžadujú rovnako starostlivé mapovanie ako pri každej migrácii.

#### Kedy je headless (a kedy nie je) správna voľba

Headless architektúry vo všeobecnosti vymieňajú viac implementačnej a priebežnej vývojárskej práce za väčšiu flexibilitu vo vitríne — vlastné interakcie, kanály mimo webu (aplikácie, kiosky) alebo požiadavky na výkon, ktoré šablónová vitrína nedokáže splniť. Pre obchod bez tejto konkrétnej potreby je zvyčajne jednoduchšie prevádzkovať aj migrovať tradičnú platformu. Toto je rozhodnutie, ktoré má zmysel robiť zámerne počas posúdenia, nie automaticky voliť jednu alebo druhú možnosť.

#### FAQ

Q: Je headless commerce vždy rýchlejší než tradičná vitrína?
A: Nie automaticky — výkon závisí od toho, ako je headless vitrína postavená, nielen od výberu architektúry. Zle postavený headless frontend môže byť pomalší než dobre optimalizovaná tradičná šablóna.

Q: Potrebujem vlastných vývojárov na prevádzku headless obchodu?
A: Vo všeobecnosti áno, priebežne — headless vitrína nemá editor šablón ani možnosti úpravy cez appstore, ktoré ponúka tradičná platforma, takže zmeny zvyčajne prechádzajú cez vlastný vývoj, nie cez vizuálny editor.

Q: Môžem prejsť z tradičnej platformy na headless bez straty SEO?
A: Áno, ale vyžaduje to rovnaké plánovanie presmerovaní a štruktúry URL adries ako každá migrácia, plus osobitnú pozornosť tomu, ako nový headless frontend vykresľuje obsah pre vyhľadávače (dôležité je tu server-side renderovanie) — automaticky sa to nedeje len preto, že backendové dáta zostali zachované.

Q: Ktoré platformy podporujú headless commerce?
A: Viacero väčších platforiem ponúka headless/API-first režim popri tradičnej vitríne alebo namiesto nej — správna voľba závisí od vašich konkrétnych backendových požiadaviek, ktoré pomáhame vyhodnotiť, namiesto automatickej voľby aktuálne populárnej platformy.

### Hreflang

URL: https://prevedshop.com/sk/slovnik/hreflang
Language: sk
Last reviewed: 2026-07-21

Hreflang je HTML atribút (a jeho ekvivalent v HTTP hlavičke alebo v mape webu), ktorý vyhľadávačom hovorí, pre aký jazyk a voliteľne aj krajinu je stránka určená, a ukazuje na jej ekvivalent v iných jazykoch či regiónoch. Je to spôsob, akým viacjazyčný web povie Googlu „tu je španielska verzia, tu nemecká“, namiesto toho, aby to vyhľadávače museli hádať.

#### Čo hreflang skutočne robí

Stránka s hreflang značkovaním obsahuje zoznam alternatívnych URL adries, z ktorých je každá označená jazykovým kódom (voliteľne aj regiónom, napríklad `es` verzus `es-MX`), plus špeciálnym záznamom `x-default` pre návštevníkov, ktorí nezodpovedajú žiadnemu z uvedených jazykov. Vyhľadávače to používajú na to, aby danému návštevníkovi ukázali správnu jazykovú verziu vášho webu a aby vaše preložené stránky nepovažovali navzájom za duplicitný obsah.

Každá stránka v klastri musí odkazovať na všetky ostatné stránky v klastri, vrátane seba samej — bežnou chybou je jednosmerný odkaz (stránka A odkazuje na stránku B, ale B neodkazuje späť na A).

#### Prečo záleží pri migrácii platformy

Ak váš obchod funguje vo viacerých jazykoch, migrácia je presne tá chvíľa, keď sa hreflang zvykne pokaziť — štruktúra URL adries sa mení pre každú lokalitu a ľahko sa stane, že mechanizmus prepínania jazykov na novej platforme automaticky nezapojí správne hreflang klastre pre každú cestu, najmä tie, ktoré ešte nemajú živý preklad. Neúplné alebo nekonzistentné nastavenie hreflang môže spôsobiť, že sa v nesprávnej krajine zobrazí nesprávna jazyková verzia, alebo rozriedi signál hodnotenia medzi takmer duplicitnými lokalizovanými stránkami.

Hreflang treba overiť pre každý vzor URL adries v novej informačnej architektúre, nielen na domovskej stránke — potrebujú ho stránky produktov, kategórií aj akékoľvek ďalšie obsahové stránky, ak sú viacjazyčné.

#### Bežné chyby

Najčastejšími problémami sú chýbajúce spätné odkazy (A odkazuje na B, B neodkazuje späť), hreflang smerujúci na URL adresu, ktorá vracia presmerovanie alebo chybu 404 namiesto živej stránky, a použitie nesprávneho formátu kódu jazyka či regiónu. Žiadna z týchto chýb zvyčajne nespôsobí priamy postih, ale znamenajú, že vyhľadávače nemusia signál vôbec rešpektovať, čím sa stráca zmysel jeho pridania.

#### FAQ

Q: Je hreflang to isté ako prepínač jazykov na mojom webe?
A: Nie — prepínač jazykov je prvok rozhrania pre návštevníkov; hreflang je signál pre vyhľadávače, zvyčajne pre návštevníkov neviditeľný, ktorý žije v hlavičke HTML stránky, v HTTP hlavičke alebo v mape webu. Web môže mať jedno bez druhého, hoci štandardnou praxou je mať oboje.

Q: Potrebujem záznam x-default?
A: Odporúča sa, ak máte záložnú stránku pre návštevníkov, ktorých jazyk či región nezodpovedá žiadnej z vašich konkrétnych verzií — zvyčajne smeruje na stránku vo vašom predvolenom jazyku.

Q: Ovplyvňuje hreflang priamo moje hodnotenie vo vyhľadávaní?
A: Nefunguje ako priame zvýšenie hodnotenia — ovplyvňuje to, ktorá z vašich stránok sa zobrazí hľadajúcim v danom jazyku či regióne, a pomáha zabrániť tomu, aby sa vaše preložené stránky navzájom považovali za nechcené duplicity.

Q: Dá sa hreflang nastaviť v mape webu namiesto na stránke?
A: Áno, podľa dokumentácie vyhľadávačov sú platné oba spôsoby — niektoré weby uprednostňujú hreflang cez mapu webu, pretože sa dá jednoduchšie programovo generovať a validovať pre veľký počet URL adries, čo je prístup, ktorý pri migrovaných weboch zvyčajne používame aj my.

Sources:
- Google Search Central: Ako Googlu oznámiť lokalizované verzie stránky: https://developers.google.com/search/docs/specialty/international/localized-versions

### Produktový feed

URL: https://prevedshop.com/sk/slovnik/produktovy-feed
Language: sk
Last reviewed: 2026-07-21

Produktový feed je štruktúrovaný export vášho katalógu — zvyčajne vo formáte CSV, XML alebo JSON — vytvorený na to, aby ho podľa harmonogramu čítal iný systém: dodávateľ, ktorý vám posiela svoj katalóg, alebo váš obchod, ktorý posiela svoj katalóg do porovnávača cien, na trhovisko či reklamnú platformu (napríklad feed pre Google Nákupy). Každý feed sa riadi konkrétnym formátom, ktorý prijímajúci systém očakáva: presné polia, presnú štruktúru, niekedy aj vlastné povinné identifikátory.

#### Vstupné verzus výstupné feedy

Vstupný feed prichádza do vášho obchodu od dodávateľa alebo distribútora — nové stavy skladu, ceny a produktové dáta, ktoré musí vaša platforma podľa harmonogramu spracovať. Výstupný feed ide opačným smerom — katalóg vášho obchodu naformátovaný tak, aby ho spracovalo trhovisko, porovnávač cien alebo reklamná platforma. Migrácia sa zvyčajne dotkne oboch: nová platforma musí naďalej prijímať dodávateľské feedy vo formáte, v akom ich už posielajú, a musí produkovať výstupné feedy vo formáte, ktorý očakáva každá cieľová destinácia — a ten nemusí byť totožný s tým, čo produkovala stará platforma.

#### Prečo sa feedy pri migrácii pokazia

Formáty feedov málokedy podliehajú univerzálnemu štandardu — dodávateľský feed môže používať názvy polí, kódy kategórií alebo identifikátory, na ktoré bola integrácia starej platformy vyrobená na mieru. Presun na novú platformu znamená, že táto logika spracovania sa musí vybudovať nanovo, nemožno predpokladať, že sa prenesie automaticky, aj keď sa samotný súbor feedu nezmení. Rovnako to platí opačne: výstupný feed, od ktorého závisí váš účet na trhovisku či v reklamnom systéme, musí po presune naďalej zodpovedať formátu požadovanému daným kanálom, inak ho kanál môže odmietnuť alebo nesprávne prečítať.

#### Čo kontroluje riadená migrácia

Počas posúdenia zmapujeme každý aktívny vstupný aj výstupný feed — v akom je formáte, na ktoré polia sa mapuje a ako často beží —, aby sa po prepnutí nič nepokazilo potichu. Dodávateľský feed, ktorý sa prestane správne spracúvať, väčšinou nevyhodí chybu; jednoducho ticho prestane aktualizovať sklad alebo ceny, čo je horšie než zjavná porucha, pretože si to môžete dlhší čas nevšimnúť.

#### FAQ

Q: Bude feed môjho dodávateľa fungovať na novej platforme automaticky?
A: Nie automaticky — na novej platforme treba vybudovať integráciu (alebo znovu použiť existujúci konektor, ak je kompatibilný), ktorá dokáže spracovať formát konkrétneho feedu. Každý dodávateľský feed vyhodnocujeme individuálne počas posúdenia, namiesto toho, aby sme predpokladali, že ho zvládne univerzálny import.

Q: Čo sa stane s mojím feedom pre Google Nákupy alebo trhovisko počas migrácie?
A: Musí naďalej zodpovedať formátu požadovanému cieľovým systémom aj po presune. Výstupné feedy kontrolujeme ako súčasť plánu migrácie, aby kanál po prepnutí neodmietol váš katalóg alebo nezobrazoval zastarané dáta.

Q: Je produktový feed to isté ako export do CSV?
A: Export do CSV môže byť produktovým feedom, ale pojem „feed“ zvyčajne znamená opakovanú, automatizovanú výmenu podľa harmonogramu, nie jednorazový ručný export — hoci samotný formát súboru môže byť identický.

Q: Môžu dva systémy pre rovnaké dáta používať úplne odlišné formáty feedu?
A: Áno, je to bežné — rovnaké katalógové dáta sa môžu exportovať ako jedna XML štruktúra pre jedno trhovisko a iná CSV štruktúra pre druhé, alebo používať úplne odlišné názvy polí a kategorizáciu, čo si vyžaduje samostatné mapovanie pre každý z nich.

### Replatforming

URL: https://prevedshop.com/sk/slovnik/replatforming
Language: sk
Last reviewed: 2026-07-21

Replatforming znamená presun e-shopu z jednej platformy na druhú — nie redizajn na tej istej platforme a nie menší upgrade verzie, ale skutočnú zmenu systému, na ktorom obchod beží. Je to zastrešujúci pojem pre celý projekt: migrácia dát, plánovanie presmerovaní, prebudovanie šablóny či vitríny aj opätovné napojenie integrácií — to všetko sú súčasti replatformingu.

#### Čo sa počíta ako replatforming (a čo nie)

Prechod z Magenta na Shopify je replatforming. Upgrade z Magento 1 na Magento 2 sa dá tiež považovať za replatforming, keďže podkladové systémy sa líšia natoľko, že si vyžadujú skutočnú migráciu, nielen aktualizáciu. Redizajn šablóny na tej istej platforme alebo pridanie novej aplikácie či pluginu replatformingom nie je — podkladový systém aj váš dátový model zostávajú rovnaké.

#### Bežné dôvody, prečo obchody menia platformu

Spúšťačom býva zvyčajne jeden alebo viac z týchto dôvodov: súčasná platforma nedokáže podporiť funkciu alebo škálovanie, ktoré biznis potrebuje, priebežné náklady na prevádzku samostatne hostenej platformy (hosting, bezpečnostné záplaty, súlad s PCI) už nedávajú zmysel, platforma sa blíži ku koncu životnosti alebo stráca podporu výrobcu, alebo biznis prerástol možnosti šablónovej vitríny. Málokedy ide o jediný dôvod — zvyčajne ide o nahromadenie trenia, ktoré nakoniec prevýši náklady a riziko presunu.

#### Prečo sa k replatformingu pristupuje ako k projektu, nie k úlohe

Najrizikovejšia časť replatformingu nie je výber novej platformy — je to všetko, čo sa musí presunúť správne, aby biznis neprišiel o dáta, SEO hodnotenie alebo prevádzkovú kontinuitu: katalóg, záznamy zákazníkov, história objednávok, štruktúra URL adries a jej presmerovania, dodávateľské feedy aj akákoľvek vlastná logika, ktorú stará platforma bežala. Práve to, že sa to berie ako jednorazový import namiesto naplánovaného projektu, je zdrojom väčšiny reálneho rizika pri migrácii.

#### FAQ

Q: Ako dlho zvyčajne trvá replatforming?
A: Výrazne to závisí od veľkosti katalógu, zložitosti dát, počtu integrácií a toho, koľko vlastnej funkcionality treba prebudovať — univerzálny harmonogram neexistuje. Reálny odhad dávame až po posúdení konkrétneho obchodu, nie všeobecné číslo.

Q: Musím meniť platformu, ak chcem len nový dizajn?
A: Nie — redizajn na súčasnej platforme je zvyčajne jednoduchší a menej rizikový než replatforming a nevyžaduje migráciu dát ani prebudovanie integrácií. Replatforming má zmysel vtedy, keď je limitom samotná platforma, nie len jej vzhľad.

Q: Aké je najväčšie riziko pri projekte replatformingu?
A: Strata SEO hodnotenia kvôli nefunkčným presmerovaniam a problémy s kvalitou dát (poškodené vzťahy variantov, stratené záznamy zákazníkov, nezhodná história objednávok) spôsobené neúplnou alebo naivnou migráciou dát — obom sa dá pri správnom plánovaní vyhnúť a obe sú bežné, keď sa s nimi vopred nepočíta.

Q: Dá sa presunúť platforma úplne bez výpadku?
A: Výpadok sa dá minimalizovať starostlivým plánovaním prepnutia (testovacie prostredie, načasovanie prepnutia DNS/prevádzky, finálna synchronizácia dát), ale nulový výpadok ako garanciu nie sme ochotní sľubovať bez znalosti vášho konkrétneho nastavenia — pozrite si našu stránku o bezpečnosti, kde k tejto téme pristupujeme úprimne.

### Mapovanie SKU

URL: https://prevedshop.com/sk/slovnik/mapovanie-sku
Language: sk
Last reviewed: 2026-07-21

Mapovanie SKU je proces priraďovania každého identifikátora produktu (SKU — skladová jednotka) zo starého systému k jeho správnemu ekvivalentu na novom, aby sa objednávky, sklad aj dodávateľské feedy pred migráciou aj po nej odkazovali na ten istý fyzický produkt. Znie to mechanicky, ale je to jedno z miest, kde migrácia najčastejšie zlyhá, ak sa automatizuje naslepo namiesto toho, aby prešla kontrolou.

#### Prečo sa SKU nie vždy prenesú čisto

V ideálnej migrácii sa každé SKU na starej platforme namapuje 1:1 na rovnaké SKU na novej a nič sa nemení. V praxi majú platformy často odlišné pravidlá pre to, čo môže SKU obsahovať, odlišne zaobchádzajú so SKU na úrovni variantu oproti úrovni produktu, alebo má stará platforma históriu duplicitných či opakovane použitých SKU, ktoré treba vyriešiť, nie len skopírovať ďalej v pôvodnej podobe. Priamy export z databázy tieto nezrovnalosti často len prenesie namiesto toho, aby ich opravil.

#### Kde sa mapovanie SKU prepája s inými systémami

Vaše SKU je často spojovací kľúč medzi obchodom a všetkým okolo neho — dodávateľskými feedmi, skladovým alebo logistickým systémom, účtovným softvérom, ponukami na trhoviskách. Ak sa formát alebo hodnota SKU počas migrácie zmení bez toho, aby sa aktualizovali všetky napojené systémy, tieto integrácie prestanú produkty správne priraďovať, hoci samotný obchod vyzerá v poriadku. Mapovanie treba robiť s ohľadom na tieto nadväzujúce systémy, nielen v rámci novej platformy.

#### Čo kontrolujeme pred migráciou SKU

Ešte pred rozhodnutím, či existujúce SKU zachovať v pôvodnej podobe alebo ich na novej platforme normalizovať, preveríme existujúcu sadu SKU na duplicity, nekonzistentné formátovanie a osirotené SKU (odkazované objednávkou či feedom, no bez aktívneho produktu). Zachovanie existujúcich SKU je zvyčajne vhodnejšie, ak na nich závisia nadväzujúce systémy; normalizácia dáva zmysel vtedy, keď bol problémom samotný starý systém SKU.

#### FAQ

Q: Mám si na novej platforme zachovať presne rovnaké SKU?
A: Zvyčajne áno, ak od nich závisí akýkoľvek dodávateľský feed, logistický systém alebo ponuka na trhovisku — zmena SKU tieto integrácie poruší, pokiaľ sa neaktualizujú súčasne. Toto vyhodnocujeme individuálne, nie ako automatickú predvoľbu.

Q: Čo sa stane s duplicitnými SKU počas migrácie?
A: Treba ich vyriešiť pred migráciou alebo počas nej, nie preniesť ďalej — väčšina platforiem skutočné duplicitné SKU nepovoľuje a ak necháte automatizovaný import hádať, ako ich zlúčiť, riskujete zlúčenie alebo stratu nesprávneho produktu.

Q: Ovplyvňuje mapovanie SKU moju históriu objednávok?
A: Môže, ak sa historické objednávky odkazujú na SKU, ktoré sa menia — s týmto počítame, aby sa staré záznamy objednávok aj po presune správne priradili k správnemu produktu, nielen aby sa mapoval aktívny katalóg.

Q: Je mapovanie SKU automatizované, alebo ručné?
A: Je to kombinácia — jednoznačné zhody 1:1 sa dajú automatizovať a rýchlo overiť, ale nejednoznačné prípady (duplicity, nekonzistentné formáty, chýbajúce SKU) potrebujú ľudské rozhodnutie, nie algoritmus, ktorý len hádne.

### Štruktúrované dáta

URL: https://prevedshop.com/sk/slovnik/strukturovane-data
Language: sk
Last reviewed: 2026-07-21

Štruktúrované dáta sú značky pridané na stránku (najčastejšie podľa slovníka schema.org, vo formáte JSON-LD), ktoré strojovo čitateľne opisujú jej obsah — označia stránku ako Produkt s cenou a dostupnosťou, alebo ako Organizáciu s názvom a URL adresou, namiesto toho, aby to museli vyhľadávače odvodzovať z viditeľného textu. Vďaka nim sa vo výsledkoch vyhľadávania môžu priamo zobraziť rozšírené prvky ako hviezdičkové hodnotenie, cena alebo rozbaľovacie FAQ.

#### Čo štruktúrované dáta skutočne umožňujú

Vyhľadávače často dokážu bežnému obsahu stránky porozumieť aj samy, ale štruktúrované dáta odstraňujú nejednoznačnosť a odomykajú konkrétne prvky zobrazenia — rozšírené produktové výsledky s cenou, dostupnosťou a hodnotením, FAQ akordeóny priamo vo výsledkoch vyhľadávania, omrvinkovú navigáciu v ukážke výsledku a ďalšie. Nič z toho sa nezobrazí automaticky (vyhľadávače si samy rozhodujú, kedy to použijú), ale bez značiek tieto prvky spravidla nie sú dostupné vôbec.

#### Prečo si to pri migrácii vyžaduje pozornosť

Štruktúrované dáta negeneruje automaticky každá platforma, a platformy, ktoré ich generujú, to nerobia identicky — schéma produktu, schéma FAQ aj schéma omrviniek musia vždy zodpovedať tomu, čo je na stránke naozaj. Migrácia je bežné miesto, kde sa štruktúrované dáta buď úplne stratia (nová šablóna/téma ich neobsahuje), alebo sa stanú nepresnými (označené dáta už nezodpovedajú viditeľnému obsahu stránky, čo môžu vyhľadávače skôr penalizovať než odmeniť).

#### Označujte len to, čo je skutočne pravda

Najdôležitejšie pravidlo pri štruktúrovaných dátach je, že majú opisovať niečo reálne a viditeľné na stránke — značky FAQPage len tam, kde sa FAQ skutočne zobrazuje, značky Review/rating len pre recenzie, ktoré naozaj existujú, značky Product s reálnou cenou a reálnou dostupnosťou. Značky, ktoré nezodpovedajú viditeľnej stránke, sú v rozpore s pravidlami samotných vyhľadávačov a môžu viesť k tomu, že sa štruktúrované dáta ignorujú alebo je stránka penalizovaná — nielen že „nepomáhajú“.

#### FAQ

Q: Zaručujú štruktúrované dáta rozšírené výsledky vo vyhľadávaní?
A: Nie — umožňujú rozšírené výsledky, ale o ich zobrazení rozhodujú vyhľadávače samostatne, na základe relevancie a vlastných kontrol kvality. Konkrétny rozšírený výsledok sa nedá zaručiť.

Q: Pridá moja nová platforma štruktúrované dáta automaticky?
A: Niektoré platformy generujú základné štruktúrované dáta (napríklad značky Product) predvolene; iné ich treba pridať explicitne cez šablónu alebo aplikáciu. Overíme, čo nová platforma ponúka od základu, a doplníme medzery, namiesto toho, aby sme predpokladali, že je to vyriešené.

Q: Môže pridanie štruktúrovaných dát poškodiť moje SEO?
A: Len ak sú nepresné alebo manipulatívne — značky, ktoré nezodpovedajú skutočnému obsahu stránky, porušujú pravidlá vyhľadávačov. Presné štruktúrované dáta, ktoré odzrkadľujú reálny obsah stránky, toto riziko nenesú.

Q: Aká je najčastejšia chyba so štruktúrovanými dátami pri migrácii?
A: Ich úplná strata, keď ich nová šablóna či téma neprenesie z pôvodnej platformy, alebo ponechanie zastaraných značiek, ktoré už nezodpovedajú prerobenej stránke — obe veci kontrolujeme v rámci QA migrácie.

Sources:
- Google Search Central: Ako fungujú štruktúrované dáta: https://developers.google.com/search/docs/appearance/structured-data/sd-policies

### URL slug

URL: https://prevedshop.com/sk/slovnik/url-slug
Language: sk
Last reviewed: 2026-07-21

URL slug je pre človeka čitateľná časť adresy stránky, ktorá ju identifikuje — v adrese `prevedshop.com/platforms/shopify` je slugom `shopify`. Zvyčajne vzniká z názvu produktu alebo stránky, prevedeného na malé písmená a bezpečné znaky pre URL adresu, a je to práve to, čo návštevníci aj vyhľadávače skutočne vidia a na čo sa odkazujú, keď na stránku odkazujú alebo si ju ukladajú do záložiek.

#### Prečo na slugoch záleží viac než len kvôli čitateľnosti

Jasný, výstižný slug pomáha návštevníkom pochopiť, o čom stránka je, ešte predtým, než na ňu kliknú, a vyhľadávače relevantným slovám v URL adrese pripisujú istú váhu. Väčší význam slugu je však štrukturálny: je súčasťou trvalej adresy stránky, na ktorú sa odkazuje z každého interného aj externého odkazu, uloženej záložky aj indexovaného výsledku vyhľadávania.

#### Prečo migrácie často menia slugy, zámerne aj nezámerne

Každá platforma má vlastné pravidlá pre generovanie a štruktúru slugov — obmedzenia dĺžky, povolené znaky, či sú slugy produktov vnorené pod cestu kategórie alebo sú ploché, ako sa rozlišujú duplicitné názvy. Presun na novú platformu často zmení aspoň niektoré slugy, niekedy preto, že nová platforma vynucuje iný vzor, inokedy preto, že ide o príležitosť opraviť neusporiadané staré slugy zo starého systému. V oboch prípadoch znamená zmenený slug zmenenú URL adresu a zmenená URL adresa potrebuje presmerovanie (pozri 301 presmerovanie) zo starej adresy.

#### Zachovanie stability slugov tam, kde na tom záleží

Pri stránkach s významnými existujúcimi pozíciami vo vyhľadávaní alebo veľkým počtom prichádzajúcich odkazov sa zachovaním presne rovnakého slugu na novej platforme (tam, kde to platforma umožňuje) úplne vyhnete potrebe presmerovania, čo je často najjednoduchší spôsob, ako udržať postavenie danej stránky. Tam, kde sa slug meniť musí, čistý prechod zabezpečí to, že nový slug a jeho presmerovanie naplánujete spolu — namiesto toho, aby ste nechali platformu vygenerovať slug automaticky a s URL adresou sa vysporiadali až dodatočne.

#### FAQ

Q: Môžem si na novej platforme zachovať presne pôvodné URL slugy?
A: Často áno, ak to pravidlá URL adries novej platformy umožňujú a nastavíte ich zámerne namiesto toho, aby ste prijali automaticky vygenerované — je to jeden z najjednoduchších spôsobov, ako pre danú stránku úplne vylúčiť potrebu presmerovania.

Q: Poškodí zmena slugu SEO?
A: Nie, ak je spojená so správnym 301 presmerovaním zo starého slugu na nový — presmerovanie prenesie väčšinu nazbieraného signálu hodnotenia ďalej. SEO škodu spôsobuje zmena slugu bez presmerovania, nie samotná zmena slugu.

Q: Mám ako slug použiť presne názov produktu?
A: Vo všeobecnosti áno, zjednodušený tak, aby bol bezpečný pre URL adresu (malé písmená, pomlčky namiesto medzier, žiadne špeciálne znaky) — slugy nacpané nesúvisiacimi kľúčovými slovami nad rámec skutočnej témy stránky neprinášajú žiadnu výhodu a pôsobia ako spam na návštevníkov aj vyhľadávače.

Q: Čo sa stane, ak by dva produkty vygenerovali rovnaký slug?
A: Platforma potrebuje pravidlo na rozlíšenie — zvyčajne pridaním čísla alebo ďalšieho identifikátora. Toto pri migrácii kontrolujeme, keďže kolízia duplicitných slugov môže inak spôsobiť, že stránka jedného produktu potichu prepíše URL adresu druhého.

### Services

### Migrácia a mapovanie dát e-shopu

URL: https://prevedshop.com/sk/sluzby/cistenie-a-mapovanie-dat
Language: sk
Last reviewed: 2026-07-20

Staré katalógy si postupne nahromadia duplicitné produkty, nekonzistentné kategórie a polia, ktorých účel si už nikto nepamätá. Toto vyčistíme a to, čo zostane, namapujeme na skutočný dátový model novej platformy — namiesto toho, aby sme neporiadok len skopírovali.

#### Čo hľadáme

Duplicitné alebo takmer duplicitné produkty, osirené kategórie, nekonzistentné pomenovanie atribútov, prázdne alebo poškodené polia a staré vlastné polia, ktoré už nič zmysluplné nereprezentujú. Čo nájdeme, s vami prejdeme a dohodneme sa, čo opraviť, zlúčiť alebo zahodiť.

#### Mapovanie, nie hádanie

Každé zdrojové pole dostane výslovné mapovanie na cieľové pole — alebo výslovné rozhodnutie, že sa nemapuje a potrebuje iné miesto (vlastné pole, štítok, alebo nikam). Toto mapovanie dokumentujeme, aby bolo možné ho spätne overiť, nie aby zostalo čiernou skrinkou.

#### Prečo na tom záleží ešte pred spustením

Vyčistenie a mapovanie dát pred migráciou je oveľa lacnejšie než ich oprava po spustení, keď sa už na ne spoliehajú zákazníci aj vyhľadávače. Preskočenie tohto kroku je jeden z najčastejších dôvodov, prečo neskôr migrácia naráža na problémy.

#### FAQ

Q: Zmažete dáta bez môjho súhlasu?
A: Nie — čo vyzerá ako problém, s vami prejdeme a na ďalšom postupe sa dohodneme skôr, než sa čokoľvek zlúči alebo odstráni.

Q: Viete odstrániť duplicity naprieč viacerými starými importami?
A: Áno, to je jedna z najčastejších požiadaviek pri čistení — staršie e-shopy, ktoré za tie roky prešli viacerými importami dodávateľských feedov, mávajú skutočné duplicity.

Q: Riešite aj vlastné polia bez jasného účelu?
A: Preskúmame, na čo pole pravdepodobne slúžilo (na základe vzorov v dátach a prípadne aj vašich informácií), než rozhodneme, či ho namapovať, využiť inak, alebo zrušiť.

### Zmena e-shopovej platformy od rozhodnutia po spustenie

URL: https://prevedshop.com/sk/sluzby/zmena-eshopovej-platformy
Language: sk
Last reviewed: 2026-09-25

Zmena platformy (replatforming) je najprv obchodné rozhodnutie a až potom migrácia dát. Meníte systém, na ktorom beží katalóg, pokladňa, integrácie aj organická návštevnosť – zvyčajne preto, že súčasný je príliš drahý, obmedzujúci alebo rizikový. Pomôžeme vám rozhodnúť sa na základe faktov a potom prechod naplánujeme a vykonáme tak, aby nová platforma štartovala s dátami, URL aj integráciami.

#### Kedy sa zmena platformy oplatí a kedy nie

Oprávnené dôvody: platforma skončila podporu alebo nedostáva bezpečnostné aktualizácie (Magento 1, Shopware 5); hosting, záplaty a údržba rozšírení stoja viac, než e-shop unesie; platforma bráni v tom, čo firma potrebuje – nové trhy, B2B ceny, headless frontend, modernú pokladňu; alebo tím trávi čas udržiavaním systému namiesto predaja.

Slabé dôvody sú zastaraná šablóna, jedna chýbajúca funkcia, ktorú by vyriešil doplnok, alebo prezentácia obchodníka. Redizajn alebo cielená integrácia často vyjde lacnejšie. Keď je to tak, povieme vám to.

#### Najprv požiadavky, potom výber platformy

Vychádzame z toho, čo e-shop skutočne robí: štruktúra katalógu a typy produktov, cenové pravidlá a zákaznícke skupiny, trhy, jazyky a meny, napojenie na ERP, sklad a dopravcov, porovnávače a feedy, obsah a SEO a vlastné funkcie. Každú požiadavku označíme ako nutnú, nahraditeľnú alebo na vyradenie a s týmto zoznamom porovnávame kandidátske platformy.

#### Čo sa pri zmene platformy rozbije

Dátový model sa málokedy zhoduje: atribúty, varianty, sady a stromy kategórií sa v cieli správajú inak. Mení sa štruktúra URL, takže každá dôležitá adresa potrebuje cieľ a presmerovanie 301. Doplnky a aplikácie sa neprenášajú – ich dáta a funkcie potrebujú náhradu, prestavbu alebo rozhodnutie o vyradení. Integrácie s ERP, účtovníctvom, dopravcami a trhoviskami treba prepojiť a otestovať. Heslá zákazníkov sa na hostované platformy zvyčajne preniesť nedajú.

#### Celkové náklady, nielen cena licencie

Porovnajte celý obraz na niekoľko rokov: predplatné alebo licenciu, hosting a bezpečnosť, platobné poplatky, aplikácie a rozšírenia, vývoj, samotnú migráciu a interný čas na prevádzku. Srovnanie vám pomôžeme zostaviť z vašich požiadaviek; licencie platforiem nepredávame.

#### Od rozhodnutia k spusteniu

Po výbere cieľa sa zmena platformy stáva riadenou migráciou: audit zdroja, mapovanie dát, skúšobná migrácia a schválenie, plán SEO a presmerovaní, prepojenie integrácií, zmrazenie obsahu, rozdielová migrácia, spustenie a kontrola po spustení. Väčšie e-shopy často prechádzajú po etapách.

#### FAQ

Q: Aký je rozdiel medzi zmenou platformy a migráciou?
A: Zmena platformy je rozhodnutie a projekt prechodu firmy na nový e-shopový systém. Migrácia je jeho časť, ktorá prenáša dáta, URL a obsah.

Q: Ako dlho zmena platformy trvá?
A: Závisí od zložitosti katalógu, integrácií, grafiky a rýchlosti rozhodovania. Termín stanovíme po posúdení.

Q: Prejsť na Shopify, Shoptet, Shopware, alebo zostať?
A: Závisí od vašich požiadaviek, trhov, integrácií a rozpočtu. Zostať na súčasnej platforme je legitímny výsledok.

Q: Dá sa platforma zmeniť bez straty SEO?
A: Pozície sa nedajú zaručiť. Riziko znižuje kompletný súpis URL, presmerovania 301, prevzaté metadáta, upravené interné odkazy a sledovanie po spustení.

### Riadená migrácia e-shopu: jeden človek od auditu po spustenie

URL: https://prevedshop.com/sk/sluzby/riadena-migracia
Language: sk
Last reviewed: 2026-07-20

Jeden zodpovedný vedúci migrácie naplánuje, vykoná a overí váš presun: produkty, varianty, zákazníkov, objednávky, médiá, obsah aj dizajn obchodu — ako jeden koordinovaný projekt, nie kopu nesúvisiacich exportov.

#### Čo je súčasťou

Riadená migrácia pokrýva celý katalóg — produkty, varianty, kategórie a atribúty —, zákaznícke účty a históriu objednávok, médiá a obsah, vlastné polia aj plán URL/presmerovania. Dizajn obchodu sa prenáša alebo znovu vytvára na cieľovej platforme ako súčasť rovnakého projektu, nie ako neskoršie nemilé prekvapenie na faktúre.

Rozsah presne určíme už pri posúdení, takže nemusíte hádať, čo „migrácia“ zahŕňa, až kým nepríde faktúra.

#### Ako funguje prenos dizajnu

Tam, kde to cieľová platforma reálne umožňuje, dizajn znovu vytvoríme. Tam, kde sú platformy príliš odlišné na presnú kópiu, vám to povieme vopred a navrhneme postup — prispôsobenie dizajnu možnostiam novej platformy, nie predstieranie, že ide o jednoduché skopírovanie.

#### Jeden vedúci od začiatku do konca

Menovaný vedúci migrácie nesie zodpovednosť za celý projekt — posúdenie, mapovanie, testovaciu migráciu, validáciu, spustenie aj kontroly po spustení. Opakovateľné automatické kontroly pomáhajú preveriť dáta a označiť nezrovnalosti, každú fázu však pred pokračovaním kontroluje a schvaľuje vedúci.

#### FAQ

Q: Ako dlho riadená migrácia trvá?
A: Závisí od veľkosti katalógu, zložitosti dát a počtu vlastných polí či integrácií — reálny harmonogram vám dáme až po posúdení, nie všeobecný odhad.

Q: Čo ak moja súčasná platforma nemá čistý export?
A: Pracujeme s tým, čo máte — databázové exporty, prístup k API, XML/CSV feedy alebo ich kombináciu. Neprehľadnejšie zdroje si vyžiadajú viac času na posúdenie, s ktorým počítame vopred.

Q: Migrujete aj nainštalované aplikácie a integrácie?
A: Migrujeme dáta, na ktorých tieto aplikácie stoja, ale konfiguráciu konkrétnej aplikácie je zvyčajne potrebné znovu zostaviť v ekvivalente na cieľovej platforme, ak existuje. Na to upozorníme už pri posúdení, nie až pri spustení.

### SEO migrácia e-shopu a mapa presmerovaní 301

URL: https://prevedshop.com/sk/sluzby/seo-a-presmerovania
Language: sk
Last reviewed: 2026-07-20

Štruktúra URL adries len málokedy prežije zmenu platformy bez zmeny. Staré URL mapujeme na nové ekvivalenty a nastavujeme presmerovania ako pevnú, naplánovanú súčasť migrácie — nie ako dodatočnú opravu po tom, čo už pozície klesli.

#### Mapovanie URL, nie hádanie

Zostavíme výslovnú mapu z každej zmysluplnej starej URL na jej nový ekvivalent — produktové stránky, kategórie, blog či obsahové stránky aj vlastné vstupné stránky. Stránky bez čistého ekvivalentu dostanú zdokumentované rozhodnutie, nie tichú chybu 404.

#### Presmerovania a metadáta

301 presmerovania implementujeme na novej platforme ešte pred spustením a metadáta (titulky, popisy, kanonické značky) preberáme tam, kde sú pre novú URL skutočne stále presné. Kontrolujeme reťazenie a slučky presmerovaní, namiesto toho, aby sme predpokladali, že mapa 1:1 je automaticky čistá.

#### Čo môžeme a nemôžeme sľúbiť

Konkrétne pozície vo vyhľadávaní nemôžeme garantovať — to čestne nedokáže nikto, pretože pozície závisia od mnohých faktorov mimo samotnej migrácie. Čo však kontrolujeme a berieme ako pevnú požiadavku, je kontinuita URL: aby staré odkazy a záložky viedli na správnu novú stránku, nie do slepej uličky.

#### FAQ

Q: Prežijú moje pozície v Google migráciu?
A: Správne mapovanie URL a presmerovania sú jednoznačne najdôležitejším faktorom pre zachovanie pozícií pri migrácii a berieme ich ako kľúčový výstup. Konkrétne pozície však garantovať nemôžeme, pretože závisia od faktorov mimo samotnej migrácie.

Q: Čo sa stane so stránkami, ktoré na novej platforme neexistujú?
A: Označíme ich už vo fáze mapovania a dohodneme sa s vami na najlepšom cieli presmerovania — zvyčajne najbližšej zodpovedajúcej kategórii alebo relevantnej rozcestníkovej stránke, nie všeobecnom presmerovaní na hlavnú stránku.

Q: Aktualizujete aj interné odkazy, nielen externé presmerovania?
A: Ak je to prakticky možné, áno — interné odkazy vedúce na staré vzory URL aktualizujeme v rámci migrácie, pretože reťazenie presmerovaní spomaľuje načítanie a oslabuje hodnotu odkazu.

### Napojenie dodávateľských feedov

URL: https://prevedshop.com/sk/sluzby/napojenie-dodavatelskych-feedov
Language: sk
Last reviewed: 2026-07-20

Prevádzka katalógu na dodávateľských feedoch znamená riešiť nekonzistentné formáty, duplicitné SKU naprieč dodávateľmi aj časovanie aktualizácií, ktoré nezodpovedá očakávaniam vašej platformy. Tieto feedy napojíme a zjednotíme, aby katalóg zostal presný bez ručnej údržby.

#### Čo zjednocujeme

Dodávateľské feedy málokedy zdieľajú formát — názvy polí, štruktúru kategórií aj merné jednotky sa líšia dodávateľ od dodávateľa. Každý feed namapujeme na jednotnú štruktúru vo vašej platforme, aby sa produkty v katalógu správali rovnako bez ohľadu na zdroj.

#### Duplicity a zlučovanie

Ak rovnaký produkt ponúka viacero dodávateľov, vieme ponuky zlúčiť, zvoliť preferovaný zdroj, alebo ich ponechať oddelené — podľa toho, ako chcete riešiť cenu a dostupnosť. Toto rozhodnutie robíme s vami, nie ako predvolené nastavenie, ktoré by sme vám vnútili.

#### Udržiavanie aktuálnosti dát

Frekvencia aktualizácie feedov závisí od toho, čo dodávatelia skutočne ponúkajú a čo dokáže platforma rozumne spracovať — dohodneme reálny harmonogram, namiesto toho, aby sme sľubovali aktualizácie v reálnom čase, ktoré zdrojový feed nedokáže podporovať.

#### FAQ

Q: Viete zlúčiť feedy od viacerých dodávateľov do jedného katalógu?
A: Áno — zlúčenie, odstránenie duplicít a zjednotenie viacerých dodávateľských feedov do jedného konzistentného katalógu je bežnou súčasťou tejto služby.

Q: Čo sa stane, keď dodávateľ produkt vypredá?
A: Podľa vašich preferencií ho môžeme označiť ako nedostupný, skryť, alebo ponechať viditeľný so stavom predobjednávky — nastaví sa raz a pri ďalších aktualizáciách feedu sa uplatní automaticky.

Q: Dajú sa dodávateľské feedy preložiť pre iné trhy?
A: Áno, obsah feedu je možné preložiť, či už automatickým prekladom, alebo podľa vlastného mapovania, ktoré nám poskytnete, podľa požadovanej presnosti.


## Español (es)

### Platform profiles

### Migración a o desde Adobe Commerce (Magento)

URL: https://prevedshop.com/es/plataformas/adobe-commerce-magento
Language: es
Last reviewed: 2026-07-21

"Magento" hoy engloba varias cosas distintas: la plataforma de código abierto Magento Open Source, el nivel de pago Adobe Commerce Cloud, y las instalaciones heredadas de Magento 1, ya fuera de soporte. Cuál de ellas tienes realmente cambia bastante el plan de migración, así que identificar la versión y edición exactas es el primer paso, tanto si Magento es tu origen como tu destino.

#### Magento Open Source, Adobe Commerce y Magento 1 frente a 2

Magento Open Source es software de ecommerce gratuito, autoalojado y basado en PHP; Adobe Commerce (antes Magento Commerce) es el nivel de pago con funciones adicionales de B2B, staging de contenido y alojamiento en la nube gestionado por Adobe. Magento 1 llegó a su fin de soporte hace años, y las tiendas que aún lo usan suelen migrar solo por ese motivo, al margen de cualquier comparación entre plataformas.

Por ese abanico de posibilidades, un proyecto de "migración de Magento" puede significar trasladar una tienda pequeña en Magento 1 a una plataforma completamente distinta, pasar de Magento 1 a Magento 2 (sigue siendo Magento, pero una reconstrucción de versión mayor), o dejar Adobe Commerce Cloud por algo con una estructura de costes diferente. Definimos cuál de estos escenarios aplica antes de estimar nada.

#### El modelo de datos EAV y la configuración multitienda

Magento almacena los datos de producto con una estructura EAV (entidad-atributo-valor), muy potente para catálogos altamente configurables y ricos en atributos, pero estructuralmente distinta de las tablas de producto planas que usan la mayoría de otras plataformas. Los productos configurables (la versión de variantes de Magento), los conjuntos de atributos personalizados y la navegación por capas basada en atributos necesitan un mapeo explícito al migrar a una plataforma sin un equivalente EAV.

La arquitectura multitienda/multisitio de Magento, que permite gestionar varias tiendas, monedas o idiomas desde una sola instalación, es otro elemento que hay que mapear con cuidado, ya que la mayoría de plataformas gestionan el multitienda de forma distinta: tiendas separadas, una única tienda con ajustes por mercado, o directamente sin equivalente nativo.

#### Extensiones, módulos personalizados y desarrolladores de Magento

Las tiendas Magento suelen depender de extensiones del marketplace y módulos desarrollados a medida para todo lo que va más allá de la funcionalidad básica, como métodos de pago, reglas de precios B2B o lógica de catálogo específica del negocio. Como Magento es una plataforma con mucho peso de desarrollo, buena parte de lo que una tienda "hace" suele residir en código PHP personalizado y no en ajustes del panel, y esa lógica hay que identificarla y reconstruirla o sustituirla, no solo exportarla.

Con los temas ocurre algo similar: los temas de Magento se construyen sobre su propio sistema de layout XML/bloques, sin equivalente directo en otras plataformas, así que salir de Magento normalmente implica construir la tienda desde cero en la nueva plataforma.

#### SEO, URLs y cómo gestionamos una migración de Magento

Magento gestiona las reescrituras de URL internamente y admite estructuras de URL bastante flexibles, pero los detalles concretos (rutas de categoría, sufijos de URL de producto, URLs específicas por vista de tienda) varían mucho de una tienda a otra según la configuración. Por esa variabilidad empezamos siempre con una auditoría de los patrones de URL realmente activos en tu tienda, en lugar de asumir una configuración por defecto de Magento.

Para una migración de Magento, construimos el mapa de URLs y redirecciones a partir de lo que tu tienda hace realmente hoy, gestionamos las variantes de URL multitienda cuando corresponde, y validamos que los metadatos y las etiquetas canónicas se trasladen correctamente. Nuestro servicio de SEO y migración de redirecciones cubre esto con más detalle.

#### FAQ

Q: Todavía tengo Magento 1. ¿Podéis migrarlo?
A: Sí, dejar Magento 1 es uno de los proyectos más habituales que vemos, normalmente motivado por su fin de soporte y no por una preferencia de plataforma. Lo tratamos como un cambio de plataforma completo, ya que Magento 1 y 2 tienen arquitecturas subyacentes distintas.

Q: ¿Qué pasa con mis módulos personalizados de Magento?
A: Identificamos qué hace realmente cada módulo personalizado, como una integración de pago, una regla de precios o una función de catálogo, y determinamos si la plataforma de destino tiene un equivalente nativo o de extensión, o si necesita desarrollo a medida.

Q: ¿Pueden migrar las funciones B2B de Adobe Commerce a una plataforma no enterprise?
A: Depende de qué funciones. Las cuentas de empresa, los flujos de presupuestos y los precios B2B por niveles no tienen un equivalente directo en todas las plataformas, así que lo evaluamos caso por caso durante la fase de alcance, sin dar por hecho una correspondencia uno a uno.

Q: ¿Cómo afecta la estructura de atributos EAV a los tiempos de migración?
A: Los catálogos con muchos atributos y conjuntos de atributos personalizados suelen necesitar más tiempo de mapeo que los catálogos planos y simples, ya que cada atributo requiere una decisión explícita sobre dónde se ubica en la plataforma de destino.

Sources:
- Adobe Commerce (Magento) - página oficial del producto: https://business.adobe.com/products/magento/magento-commerce.html

### Migración a BigCommerce o desde BigCommerce

URL: https://prevedshop.com/es/plataformas/bigcommerce
Language: es
Last reviewed: 2026-07-21

BigCommerce es una plataforma SaaS alojada que aparece en ambos lados de las migraciones que gestionamos: comercios que llegan a ella por su estructura de categorías nativa y sus opciones headless, y comercios que se van a medida que cambian sus necesidades. Como con cualquier plataforma cerrada e impulsada por API, lo que más importa en una migración de BigCommerce es lo que exponen su API y su modelo de datos, no solo cuántos productos estás trasladando. Esta página cubre lo que de verdad importa cuando BigCommerce está en uno de los dos lados de una migración.

#### Qué es BigCommerce y dónde encaja

BigCommerce es una plataforma de ecommerce SaaS alojada: se encarga del hosting, los parches de seguridad y la disponibilidad, y tú administras la tienda desde su panel y sus APIs en lugar de un servidor propio. Los planes van desde niveles estándar orientados a comercios pequeños y medianos hasta Enterprise. Multi-Storefront está disponible en distintos planes con límites diferentes de escaparates; Enterprise puede ofrecer límites de API y niveles de soporte superiores, además de más funciones B2B. BigCommerce también ofrece un enfoque headless, que permite usar su backend y APIs con un frontend construido a medida en lugar de su propia capa de temas.

Las tiendas del camino estándar, no headless, se construyen con el framework de temas Stencil de BigCommerce, con temas disponibles en el BigCommerce Theme Marketplace o desarrollados a medida. Como con cualquier plataforma cerrada y alojada, las migraciones hacia o desde BigCommerce funcionan dentro de su modelo de datos y su superficie de API, no mediante una copia directa de base de datos, así que lo que la API expone para productos, pedidos y clientes determina qué puede trasladarse automáticamente.

#### Productos, categorías y el modelo de datos

A diferencia de las plataformas que dependen únicamente de colecciones basadas en etiquetas, BigCommerce admite un árbol de categorías nativo y anidado junto con los productos y sus variantes. Esto la convierte en una opción comparativamente buena para catálogos con estructuras de categorías multinivel, ya que no tienes que aplanar una jerarquía de categorías en etiquetas o colecciones inteligentes como haría falta en otras plataformas alojadas.

Los clientes y el historial de pedidos se transfieren a través de las APIs REST y GraphQL de BigCommerce, pero, como en cualquier migración de plataforma, los pedidos históricos suelen llegar como registros de referencia y no como pedidos totalmente activos y reeditables. Los datos de producto personalizados normalmente se mapean a los campos personalizados de BigCommerce, y las listas de precios (el mecanismo de BigCommerce para precios específicos por grupo de clientes o moneda) son de lo primero que revisamos cuando la plataforma de origen tiene su propia configuración de precios por niveles.

#### Apps, temas y lo que no se traslada automáticamente

Una tienda BigCommerce en funcionamiento suele depender de apps del BigCommerce App Marketplace, para reseñas, suscripciones, búsqueda, automatización de marketing o reglas de envío. Los datos almacenados por las apps no se transfieren como parte de una migración de plataforma; salir de BigCommerce implica exportar por separado todo lo que guarda cada app, y llegar a BigCommerce significa reinstalar y reconfigurar equivalentes en lugar de arrastrar la configuración de las apps anteriores.

Los temas Stencil no se traducen al sistema de plantillas de otra plataforma, así que salir de BigCommerce normalmente implica reconstruir el diseño de la tienda en la nueva plataforma, y llegar a BigCommerce significa adaptar un tema del marketplace o encargar desarrollo a medida. Si en cambio optas por el enfoque headless, el frontend queda completamente desacoplado de la capa de temas de BigCommerce, lo que cambia por completo el alcance de lo que significa "migrar el diseño".

#### SEO, URLs y cómo gestionamos una migración de BigCommerce

BigCommerce es más flexible en cuanto a estructura de URL que algunos competidores alojados, y permite establecer URLs personalizadas para productos, categorías y páginas en lugar de imponer un único patrón fijo. Esa flexibilidad ayuda cuando migras a BigCommerce y quieres que las URLs se parezcan a las anteriores, pero no ocurre automáticamente, y salir de BigCommerce igualmente implica mapear sus patrones de URL a lo que exija la nueva plataforma.

Como parte de una migración gestionada, comparamos tu estructura de URL actual con la de BigCommerce, configuramos las redirecciones necesarias en cualquiera de los dos sentidos, y trasladamos los metadatos que siguen siendo correctos bajo las nuevas URLs, siguiendo el mismo enfoque descrito en nuestro servicio de SEO y migración de redirecciones, adaptado a las limitaciones específicas de API y enrutamiento de BigCommerce.

#### FAQ

Q: ¿Puedo conservar mi estructura de categorías anidadas al pasarme a BigCommerce?
A: Sí. BigCommerce admite un árbol de categorías nativo y multinivel, así que una estructura de categorías profunda procedente de otra plataforma suele mapearse de forma más directa que en una plataforma que solo admite etiquetas o colecciones planas.

Q: ¿Qué pasa con mis apps de BigCommerce si me voy a otra plataforma?
A: Los datos específicos de cada app normalmente hay que exportarlos por separado antes de la migración. Migramos los datos de tienda de los que depende una app, pero no su configuración interna ni sus registros almacenados.

Q: ¿La opción headless de BigCommerce cambia cómo funciona una migración?
A: Cambia lo que significa migrar el tema, ya que una configuración headless desacopla el frontend de la propia capa de temas de BigCommerce, pero los datos subyacentes de producto, pedido y cliente se siguen trasladando igual a través de la API.

Q: ¿Mis URLs se mantendrán si me paso a BigCommerce?
A: Solo si configuras deliberadamente URLs personalizadas equivalentes, algo que BigCommerce permite para productos, categorías y páginas. Normalmente configuramos redirecciones en lugar de asumir una coincidencia exacta de URLs.

Sources:
- BigCommerce - sitio web oficial: https://www.bigcommerce.com

### Migración a OpenCart o desde OpenCart

URL: https://prevedshop.com/es/plataformas/opencart
Language: es
Last reviewed: 2026-07-21

OpenCart es una plataforma de ecommerce de código abierto que vemos con regularidad en migraciones, normalmente de comercios que empezaron con ella por su bajo coste y sencillez y ahora se han quedado pequeños para una instalación autogestionada, o de comercios que la eligen precisamente por su ligereza. Como OpenCart es de código abierto y autoalojada, la complejidad de la migración suele depender de cuánto se haya personalizado la tienda con extensiones, no solo de cuántos productos tenga el catálogo. Esta página cubre lo que de verdad importa cuando OpenCart está en uno de los dos lados de una migración.

#### Qué es OpenCart y dónde encaja

OpenCart es software de ecommerce de código abierto construido en PHP y MySQL, autoalojado en un servidor que controlas tú o tu proveedor de hosting. Es conocido por un núcleo comparativamente ligero y una barrera de entrada más baja que otras plataformas de código abierto, lo que lo hace popular entre comercios pequeños y agencias que construyen tiendas con presupuesto ajustado. La gestión multitienda desde un único panel es una función incorporada, no un añadido.

Las tiendas usan el sistema de temas propio de OpenCart, basado en el motor de plantillas Twig desde OpenCart 3, con temas y extensiones disponibles a través del OpenCart Marketplace oficial o desarrollados a medida. Como con cualquier plataforma de código abierto autoalojada, la cantidad de código personalizado y extensiones de terceros que arrastra una tienda es de lo primero que determina el alcance de la migración.

#### Productos, opciones y el modelo de datos

El catálogo de OpenCart se organiza en torno a productos agrupados en categorías, con "opciones" de producto que gestionan la variación, como talla o color, de una forma estructuralmente distinta a un sistema de variantes dedicado a nivel de SKU que tienen otras plataformas. Las opciones en OpenCart pueden ajustar precio y stock, pero el modelo subyacente no es idéntico a las variantes reales, algo relevante al migrar un catálogo que usa variantes propiamente dichas en otro sitio hacia OpenCart, o al salir de OpenCart hacia una plataforma con un modelo de variantes más estricto.

Como OpenCart es autoalojada, el acceso directo a la base de datos suele estar disponible para las exportaciones, lo que puede simplificar la extracción de datos de producto, cliente y pedido. Pero las tiendas personalizadas con extensiones o con archivos del núcleo modificados, un patrón habitual en el ecosistema OpenCart, especialmente con extensiones antiguas basadas en VQMod u OCMOD, necesitan que esas personalizaciones se identifiquen antes de asumir que una exportación limpia y estándar bastará.

#### Extensiones, temas y lo que no se traslada automáticamente

Una tienda OpenCart en funcionamiento suele depender de extensiones instaladas, para pagos, envíos, herramientas de marketing o funciones de catálogo más allá del núcleo de OpenCart. Los datos y ajustes de las extensiones no se transfieren automáticamente en una migración de plataforma; salir de OpenCart implica revisar qué guarda cada extensión y exportarlo por separado, y llegar a OpenCart significa instalar y configurar equivalentes desde el OpenCart Marketplace o mediante desarrollo a medida.

Los temas basados en Twig de OpenCart son específicos de su sistema de plantillas y no se trasladan a otras plataformas, así que salir de OpenCart normalmente implica reconstruir el diseño de la tienda en otro sitio, y llegar a OpenCart significa adaptar un tema del marketplace o construir uno a medida. Las instalaciones antiguas de OpenCart, anteriores a la 3.0, pueden seguir usando el sistema de temas anterior, algo que conviene identificar pronto porque afecta a cómo se plantea un rediseño.

#### SEO, URLs y cómo gestionamos una migración de OpenCart

OpenCart admite reescritura de URLs amigables para SEO en productos y categorías, pero hay que activarla y configurarla, no viene así por defecto, y las instalaciones antiguas o muy personalizadas a veces siguen funcionando con URLs por defecto, poco amigables. Salir de OpenCart implica comprobar qué modo de URL está realmente en uso antes de asumir un mapeo limpio hacia la nueva plataforma.

Como parte de una migración gestionada, auditamos la configuración de URL actual de tu OpenCart, o planificamos la del destino si llegas a OpenCart, construimos un mapa de redirecciones entre las URLs antiguas y las nuevas, y trasladamos los metadatos que siguen siendo correctos, siguiendo el mismo enfoque descrito en nuestro servicio de SEO y migración de redirecciones, aplicado a la configuración específica de OpenCart.

#### FAQ

Q: ¿OpenCart es gratuito?
A: El software base de OpenCart es de código abierto y gratuito para descargar y autoalojar. Los costes recurrentes vienen del hosting, el tiempo de desarrollo y las extensiones o temas de pago del OpenCart Marketplace.

Q: ¿Cómo se comparan las opciones de producto de OpenCart con las variantes de otras plataformas?
A: Las opciones de OpenCart pueden ajustar precio y stock por combinación, pero no están estructuradas de forma idéntica a un sistema de variantes dedicado a nivel de SKU, así que mapearlas hacia dentro o hacia fuera de una plataforma con un modelo de variantes más estricto requiere una revisión cuidadosa, no una correspondencia directa de campos.

Q: ¿Podéis migrar mis extensiones de OpenCart y sus datos?
A: Migramos los datos de tienda de los que depende una extensión, pero los ajustes específicos de cada extensión y sus registros almacenados normalmente necesitan una exportación aparte de esa extensión, o reconstruirse con un equivalente en la plataforma de destino.

Q: ¿Mi versión de OpenCart afecta a la migración?
A: Sí. Las instalaciones antiguas de OpenCart, sobre todo anteriores a la 3.0, pueden diferir de forma notable en el sistema de temas, el formato de las extensiones e incluso el esquema de base de datos, así que confirmamos tu versión al principio de la evaluación.

Sources:
- OpenCart - sitio web oficial: https://www.opencart.com

### Migración a PrestaShop o desde PrestaShop

URL: https://prevedshop.com/es/plataformas/prestashop
Language: es
Last reviewed: 2026-07-21

PrestaShop es una plataforma de ecommerce de código abierto que vemos a menudo en migraciones, sobre todo entre comercios europeos que llegan a ella por la flexibilidad de tener una instalación propia, o que se van al quedarse pequeña una configuración autogestionada. Como PrestaShop es de código abierto y autoalojada (o alojada a través de la nube propia de PrestaShop), lo que determina la complejidad de una migración suele ser la estructura de la base de datos y los módulos de los que depende la tienda, no solo el tamaño del catálogo. Esta página cubre lo que de verdad importa cuando PrestaShop está en uno de los dos lados de una migración.

#### Qué es PrestaShop y dónde encaja

PrestaShop es software de ecommerce de código abierto construido en PHP y MySQL, lo más habitual es que se autoaloje, aunque PrestaShop también ofrece su propia opción de hosting en la nube. Ser de código abierto significa que tú, o tu proveedor de hosting, gestionáis directamente el servidor, la versión de PHP y la base de datos, y tenéis acceso completo al código subyacente, a diferencia de las plataformas SaaS cerradas. Tiene una presencia especialmente fuerte entre comercios de Francia, España y otros mercados europeos.

Las tiendas se construyen con el sistema de temas propio de PrestaShop, con temas y módulos disponibles en el marketplace oficial de PrestaShop (Addons) o desarrollados a medida. Al ser código abierto, las personalizaciones de una tienda PrestaShop pueden ir desde una configuración sencilla hasta desarrollo de módulos profundo y a medida, y cuánto código personalizado arrastra una tienda es de lo primero que condiciona el alcance de una migración.

#### Productos, categorías y el modelo de datos

El modelo de catálogo de PrestaShop se organiza en torno a productos con "combinaciones" (su término para las variantes, como talla o color) dentro de un árbol de categorías nativo de profundidad ilimitada, además de "características" y "atributos" separados para datos de producto estructurados. Ese árbol de categorías nativo hace que PrestaShop sea un destino razonable para catálogos con estructuras jerárquicas profundas, y es uno de los elementos que mapeamos con especial cuidado al migrar un árbol de categorías hacia PrestaShop, o desde PrestaShop hacia una plataforma con un modelo más plano.

Los clientes y el historial de pedidos residen directamente en la base de datos MySQL de PrestaShop, lo que para una tienda autoalojada suele significar que el acceso directo a la base de datos está disponible para las exportaciones, en lugar de limitarse a lo que exponga una API REST. Eso puede simplificar algunas partes de la migración, pero también implica identificar las personalizaciones específicas del esquema de base de datos, por ejemplo de módulos personalizados, antes de asumir que una exportación estándar lo capturará todo.

#### Módulos, temas y lo que no se traslada automáticamente

Una tienda PrestaShop en funcionamiento suele depender de módulos instalados, para pagos, cálculo de envíos, marketing o funciones de catálogo que no están en el núcleo de PrestaShop. Los datos y la configuración de los módulos no se transfieren automáticamente en una migración de plataforma; salir de PrestaShop implica identificar qué guarda cada módulo y exportarlo por separado, y llegar a PrestaShop significa instalar y configurar módulos equivalentes desde el marketplace de Addons o mediante desarrollo a medida.

Los temas de PrestaShop están ligados a su propio sistema de plantillas y no se traducen a otras plataformas, así que salir de PrestaShop normalmente implica reconstruir el diseño de la tienda en la nueva plataforma, y llegar a PrestaShop significa adaptar un tema del marketplace o encargar uno a medida. Las tiendas autoalojadas a veces también arrastran código personalizado a nivel de tema que hay que revisar por separado del diseño visual en sí.

#### SEO, URLs y cómo gestionamos una migración de PrestaShop

PrestaShop permite una reescritura de URLs bastante flexible y configurable para productos, categorías y páginas CMS, lo que ayuda a intentar conservar la estructura de URL durante una migración, pero aun así hay que configurarla de forma deliberada y no darla por hecha. Salir de PrestaShop implica mapear sus patrones de URL, que pueden variar bastante de una tienda a otra al ser configurables, a los requisitos de la nueva plataforma.

Como parte de una migración gestionada, revisamos la configuración de URL actual de tu PrestaShop, o la del destino si llegas a PrestaShop, construimos un mapa de redirecciones entre las URLs antiguas y las nuevas, y trasladamos los metadatos que siguen siendo correctos, siguiendo el mismo enfoque descrito en nuestro servicio de SEO y migración de redirecciones, aplicado a la configuración de enrutamiento específica de PrestaShop.

#### FAQ

Q: ¿PrestaShop es gratuito?
A: El software base de PrestaShop es de código abierto y gratuito para descargar y autoalojar. Los costes vienen del hosting, el tiempo de desarrollo, los módulos y temas de pago, y cualquier plan de hosting en la nube de PrestaShop que elijas en lugar del autoalojamiento.

Q: ¿Podéis migrar mis módulos de PrestaShop y sus datos?
A: Migramos los datos de tienda de los que depende un módulo, pero la configuración específica de cada módulo y sus registros almacenados normalmente necesitan una exportación aparte de ese módulo, o reconstruirse con un equivalente en la plataforma de destino.

Q: ¿La estructura de categorías de PrestaShop se traslada bien a otras plataformas?
A: Depende del destino. El árbol de categorías nativo y de profundidad ilimitada de PrestaShop se mapea de forma limpia a plataformas con un modelo similar, pero necesita remapearse a etiquetas o colecciones en plataformas que no admiten categorías anidadas reales.

Q: ¿Qué versión de PrestaShop importa para una migración?
A: Importa bastante, ya que el esquema de base de datos y la compatibilidad de módulos pueden diferir entre versiones mayores. Confirmamos tu versión de PrestaShop durante la evaluación antes de cerrar un enfoque de migración.

Sources:
- PrestaShop - sitio web oficial: https://www.prestashop.com

### Migración a Shopify o desde Shopify

URL: https://prevedshop.com/es/plataformas/shopify
Language: es
Last reviewed: 2026-07-21

Shopify es uno de los destinos de migración más habituales con los que trabajamos, tanto como plataforma de llegada como de salida. Al tratarse de una plataforma cerrada y alojada, gran parte de lo que determina la fluidez del traslado depende de lo que realmente expone la API de Shopify, no solo del tamaño de tu catálogo. Esta página cubre lo que de verdad importa cuando Shopify está en uno de los dos lados de una migración.

#### Qué es Shopify y dónde encaja

Shopify es una plataforma de ecommerce SaaS alojada: no gestionas servidores, versiones de PHP ni copias de seguridad de bases de datos. Shopify se encarga de la infraestructura y tú administras la tienda desde su panel y, para personalizaciones más profundas, mediante sus APIs. Los planes van desde los niveles estándar pensados para comercios pequeños y medianos hasta Shopify Plus, orientado a comercios de mayor volumen que necesitan más personalización del checkout y límites de API más altos.

Las tiendas se construyen con el lenguaje de plantillas propio de Shopify, Liquid, y los temas provienen de la Shopify Theme Store o de desarrollo a medida. Al ser una plataforma cerrada y alojada, trabajas dentro del modelo de datos y los puntos de extensión de Shopify en lugar de modificar el código base, y por eso las migraciones hacia o desde Shopify dependen del acceso a la API y de la configuración de apps, no de una copia directa de base de datos.

#### Productos, pedidos y clientes: el modelo de datos

El modelo de producto de Shopify se basa en productos y variantes (por ejemplo, una camiseta con variantes de talla y color), organizados en colecciones manuales o automatizadas en lugar de un árbol de categorías libre. Migrar un catálogo a Shopify normalmente implica remapear la estructura de categorías o atributos de tu plataforma de origen al modelo de producto/variante/colección de Shopify, algo sencillo para catálogos simples y más laborioso para plataformas con categorías profundas, de varios niveles, o productos muy configurables.

Los clientes y el historial de pedidos se transfieren a través de la Admin API, pero los datos de pedidos están ligados al propio modelo de pedidos y cumplimiento de Shopify, por lo que los pedidos históricos suelen migrarse como registros de referencia y no como pedidos totalmente activos y editables. Los metafields (el mecanismo de campos personalizados de Shopify) son donde suele terminar la información de producto no estándar, y mapear tus campos personalizados existentes a metafields es una de las primeras cosas que definimos.

#### Apps, temas y lo que no se traslada automáticamente

Una tienda Shopify en funcionamiento suele depender de varias apps instaladas, para reseñas, suscripciones, fidelización, búsqueda o reglas de envío. Los datos de las apps generalmente no se transfieren con una migración de plataforma; si sales de Shopify, los datos almacenados por cada app (como calendarios de suscripción o puntos de fidelización) necesitan una exportación aparte de esa misma app, y si llegas a Shopify, tendrás que reinstalar los equivalentes desde la Shopify App Store en lugar de arrastrar la configuración anterior.

Con los temas ocurre lo mismo: un tema en Liquid no se traduce al sistema de plantillas de otra plataforma, así que salir de Shopify implica en general reconstruir el diseño de la tienda en la nueva plataforma, y entrar en Shopify significa personalizar un tema de la Theme Store o encargar desarrollo Liquid a medida.

#### SEO, URLs y cómo gestionamos una migración de Shopify

Shopify impone sus propios patrones de URL, como /products/{handle}, /collections/{handle} y /pages/{handle}, que rara vez coinciden exactamente con la estructura de URLs de otra plataforma. Migrar hacia o desde Shopify casi siempre implica un mapa de redirecciones de las URLs antiguas a las nuevas, ya que Shopify no permite replicar por completo una estructura de URL arbitraria de otro sistema, y otras plataformas tampoco conocerán automáticamente tus handles de Shopify.

Como parte de una migración gestionada, mapeamos tus URLs actuales contra la estructura de Shopify (o al revés, cuando sales de Shopify), configuramos redirecciones 301 y trasladamos los metadatos que siguen siendo correctos en las nuevas URLs, siguiendo el mismo enfoque descrito en nuestro servicio de SEO y migración de redirecciones, pero adaptado específicamente a las convenciones de URL y las limitaciones de API de Shopify.

#### FAQ

Q: ¿Podéis migrar mis apps de Shopify y sus datos?
A: Migramos los datos de la tienda de los que dependen esas apps, pero la configuración específica de cada app y sus datos almacenados normalmente deben proceder de una exportación aparte de esa app, o reconstruirse con una app equivalente en la plataforma de destino.

Q: ¿Shopify Plus cambia cómo funciona una migración?
A: Plus afecta principalmente a la personalización del checkout y a los límites de la API. El modelo de datos subyacente de productos y pedidos es el mismo que en Shopify estándar, así que el enfoque de migración no cambia de forma fundamental, aunque los límites de API más altos pueden acelerar la transferencia de catálogos grandes.

Q: ¿Mis URLs de producto se mantendrán si me paso a Shopify?
A: Solo si tus URLs actuales ya coinciden con el patrón /products/{handle} de Shopify, algo poco habitual. En la mayoría de los casos configuramos redirecciones desde tus URLs antiguas hacia la estructura que exige Shopify como parte de la migración.

Q: ¿Qué pasa con mi tema si migro fuera de Shopify?
A: Los temas en Liquid no se transfieren al sistema de plantillas de otras plataformas, así que el diseño de la tienda se reconstruye en la nueva plataforma, ajustándolo a tu diseño actual en la medida en que la nueva plataforma lo permita.

Sources:
- Shopify - sitio web oficial: https://www.shopify.com

### Migración a Shoptet o desde Shoptet

URL: https://prevedshop.com/es/plataformas/shoptet
Language: es
Last reviewed: 2026-07-21

Shoptet es una plataforma de ecommerce alojada centrada específicamente en los mercados checo y eslovaco, y es un destino habitual en migraciones de comercios que operan en esa región, ya sea que lleguen a Shoptet por su soporte local y su configuración sin código, o que se vayan a medida que se expanden o necesitan funciones que la plataforma no ofrece. Al ser Shoptet una plataforma SaaS cerrada y alojada, una migración hacia o desde ella depende de lo que su panel, sus herramientas de exportación y su API realmente exponen. Esta página cubre lo que de verdad importa cuando Shoptet está en uno de los dos lados de una migración.

#### Qué es Shoptet y dónde encaja

Shoptet es una plataforma de ecommerce SaaS alojada, construida para los mercados checo y eslovaco, con su panel, documentación y soporte principalmente en checo. Como otras plataformas alojadas, Shoptet gestiona el hosting y la infraestructura, y los comercios administran su tienda a través del panel en lugar de tener acceso al servidor. Está orientada principalmente a comercios regionales pequeños y medianos que quieren tener una tienda en marcha sin gestionar código ni infraestructura por su cuenta.

Las tiendas se construyen con el sistema propio de plantillas y personalización de diseño de Shoptet, con complementos disponibles en su propio marketplace para funciones como integraciones contables, herramientas de marketing y métodos de pago o envío regionales habituales en el mercado checo/eslovaco. Al ser una plataforma cerrada y alojada, las migraciones hacia o desde Shoptet funcionan dentro de su propio modelo de datos y sus opciones de exportación o API, no mediante una copia directa de base de datos.

#### Productos, categorías y el modelo de datos

El modelo de catálogo de Shoptet organiza los productos en categorías con soporte para variantes de producto y parámetros para atributos estructurados. Migrar un catálogo a Shoptet generalmente implica mapear la estructura de categorías o atributos de la plataforma de origen al modelo de Shoptet, algo que suele ser sencillo para catálogos de complejidad moderada.

Shoptet ofrece opciones de exportación de datos y una API para extraer datos de producto, pedido y cliente, que es lo que se usa para migrar fuera de la plataforma. Como en otras plataformas alojadas, los pedidos históricos suelen llegar como registros de referencia y no como pedidos totalmente activos y editables en la nueva plataforma.

#### Complementos, diseño y lo que no se traslada automáticamente

Una tienda Shoptet en funcionamiento suele depender de complementos instalados, para contabilidad, marketing, feeds de comparación de precios (algo habitual entre comercios checos y eslovacos que se anuncian en servicios como Heureka o Zbozi.cz), o integraciones de pago regionales. Los datos y ajustes de los complementos no se transfieren automáticamente en una migración de plataforma; salir de Shoptet implica revisar qué guarda cada complemento y exportarlo por separado, y llegar a Shoptet significa configurar equivalentes desde su propio marketplace de complementos.

Las plantillas de diseño de Shoptet son específicas de su propio sistema y no se trasladan a otras plataformas, así que salir de Shoptet normalmente implica reconstruir el diseño de la tienda en otro sitio, y llegar a Shoptet significa adaptar una de sus plantillas o trabajar dentro de sus opciones de personalización de diseño.

#### SEO, URLs y cómo gestionamos una migración de Shoptet

Shoptet permite cierta personalización de la estructura de URL para productos y categorías, pero, como en cualquier cambio de plataforma, los patrones de URL existentes rara vez coinciden exactamente con los requisitos de una plataforma nueva. Esto es especialmente relevante para comercios checos y eslovacos, que a menudo tienen visibilidad orgánica ligada a sus URLs actuales y a listados de feeds en comparadores de precios regionales.

Como parte de una migración gestionada, mapeamos tus URLs de Shoptet actuales, o las de la plataforma de destino si llegas a Shoptet, contra la nueva estructura, configuramos redirecciones y trasladamos los metadatos y la configuración de feeds de comparación que sigan siendo correctos, siguiendo el mismo enfoque descrito en nuestro servicio de SEO y migración de redirecciones, aplicado a la configuración específica de Shoptet y al ecosistema regional de feeds al que suele conectarse.

#### FAQ

Q: ¿Shoptet está disponible fuera de la República Checa y Eslovaquia?
A: Shoptet está construida y respaldada específicamente para los mercados checo y eslovaco, con su panel y documentación principalmente en checo. No se posiciona como una plataforma global al estilo de otros competidores alojados, algo a tener en cuenta si te expandes más allá de Chequia y Eslovaquia.

Q: ¿Podéis migrar mis feeds de producto de Shoptet para Heureka o Zbozi.cz?
A: Migramos los datos de producto subyacentes sobre los que se construyen esos feeds; la configuración del feed en sí normalmente hay que reconstruirla en la nueva plataforma, o gestionarla a través de nuestro servicio de Integración de Feeds de Proveedores, según cómo gestione la plataforma de destino los feeds de comparación de precios.

Q: ¿Podéis migrar mis complementos de Shoptet y sus datos?
A: Migramos los datos de tienda de los que depende un complemento, pero los ajustes específicos de cada complemento y sus registros almacenados normalmente necesitan una exportación aparte de ese complemento, o reconstruirse con un equivalente en la plataforma de destino.

Q: ¿Mis URLs de producto se mantendrán si migro hacia o desde Shoptet?
A: Normalmente no de forma exacta, ya que la estructura de URL de Shoptet rara vez coincide con los requisitos de otra plataforma. Configuramos redirecciones de las URLs antiguas a las nuevas como parte de la migración para proteger el posicionamiento existente en buscadores.

Sources:
- Shoptet - sitio web oficial: https://www.shoptet.cz

### Migración a Shopware o desde Shopware

URL: https://prevedshop.com/es/plataformas/shopware-6
Language: es
Last reviewed: 2026-07-21

Shopware es una plataforma que vemos sobre todo entre comercios con sede en Alemania, Austria y Suiza, ya sea que lleguen a ella por su arquitectura abierta y su fuerte presencia en la región DACH, o que se vayan de una instalación antigua de Shopware a medida que cambian sus necesidades. La doble naturaleza de Shopware, software de código abierto que también puede ejecutarse como producto en la nube alojado, hace que el enfoque de migración adecuado dependa de qué versión y despliegue tengas realmente. Esta página cubre lo que de verdad importa cuando Shopware está en uno de los dos lados de una migración.

#### Qué es Shopware y dónde encaja

Shopware es software de ecommerce construido sobre el framework PHP Symfony, disponible como software de código abierto autoalojado (la Community Edition) o como producto en la nube con ediciones comerciales que añaden funciones como herramientas B2B avanzadas y precios basados en reglas. Shopware 6 es la generación actual, construida alrededor de un núcleo con capacidad headless, con una capa de tienda y de administración separadas, que sustituye al Shopware 5 anterior, con una estructura distinta.

Como Shopware expone una Store API, admite configuraciones headless y composables junto a su propia tienda por defecto, algo relevante en migraciones donde el frontend y el backend se gestionan por separado. Las tiendas del camino estándar usan el sistema de temas propio de Shopware, construido sobre Twig, con plugins y temas disponibles en la Shopware Store.

#### Productos, canales de venta y el modelo de datos

Shopware organiza los productos con "propiedades" y grupos de configuración para las variantes, dentro de un árbol de categorías nativo, y usa "canales de venta" para gestionar distintas tiendas o presentaciones de marca desde un único backend, un concepto estructuralmente distinto de cómo gestionan las plataformas de tienda única las configuraciones multimarca. Ese modelo de canales de venta es de lo primero que mapeamos cuando un comercio gestiona varias tiendas relacionadas desde una sola instalación de Shopware.

Los precios basados en reglas, precios o promociones distintos según el grupo de clientes, el contenido del carrito u otras condiciones, es una función de Shopware que conviene señalar pronto en una migración, ya que no todas las plataformas de destino modelan los precios condicionales de la misma forma. Los datos de clientes y pedidos residen en la estructura de base de datos propia de Shopware, y en instalaciones autoalojadas suele haber acceso directo a la base de datos disponible, lo que puede simplificar algunas exportaciones, pero igualmente requiere identificar cualquier campo añadido por plugins personalizados antes de asumir que una exportación estándar lo captura todo.

#### Plugins, temas y lo que no se traslada automáticamente

Una tienda Shopware en funcionamiento suele depender de plugins de la Shopware Store, para pagos, envíos, marketing o funciones B2B que no están en el núcleo de Shopware. Los datos y la configuración almacenados por los plugins no se transfieren automáticamente en una migración de plataforma; salir de Shopware implica revisar qué guarda cada plugin y exportarlo por separado, y llegar a Shopware significa instalar y configurar equivalentes a través de la Shopware Store o mediante desarrollo a medida.

Los temas basados en Twig de Shopware son específicos de su sistema de plantillas y no se trasladan a otros sitios, así que salir de Shopware normalmente implica reconstruir el diseño de la tienda en la nueva plataforma, y llegar a Shopware significa adaptar un tema de la Store o construir uno a medida. Las migraciones que involucran Shopware 5, que usa una arquitectura subyacente distinta a Shopware 6, deben plantearse como un caso propio y no dar por hecho que funcionarán como una migración de Shopware 6.

#### SEO, URLs y cómo gestionamos una migración de Shopware

Shopware admite plantillas de URL SEO configurables para productos, categorías y otras páginas, que pueden personalizarse por canal de venta, pero los patrones de URL realmente en uso varían de una tienda a otra según cómo se configuraron. Salir de Shopware implica comprobar la configuración de URL activa en lugar de asumir un patrón por defecto.

Como parte de una migración gestionada, revisamos la configuración de URL actual de tu Shopware, o planificamos la del destino si llegas a Shopware, construimos un mapa de redirecciones entre las URLs antiguas y las nuevas por canal de venta cuando corresponde, y trasladamos los metadatos que siguen siendo correctos, siguiendo el mismo enfoque descrito en nuestro servicio de SEO y migración de redirecciones, aplicado a la estructura específica de enrutamiento y canales de venta de Shopware.

#### FAQ

Q: ¿Importa si tengo Shopware 5 o Shopware 6?
A: Sí, bastante. Shopware 6 tiene una arquitectura subyacente, un sistema de plugins y una estructura de temas distintos de Shopware 5, así que tratamos las migraciones desde cada versión como casos diferenciados y no asumimos que aplica el mismo enfoque.

Q: ¿Shopware es gratuito?
A: La Community Edition de Shopware es de código abierto y gratuita para autoalojar. Las ediciones comerciales y la opción de hosting en la nube añaden costes de licencia o suscripción junto con funciones adicionales como herramientas B2B avanzadas.

Q: ¿Cómo afectan los canales de venta de Shopware a una migración?
A: Si gestionas varias tiendas o marcas a través de la función de canales de venta de Shopware, mapeamos cada una individualmente en lugar de tratar la instalación como una única tienda plana, ya que las plataformas de destino no siempre modelan las configuraciones multicanal de la misma forma.

Q: ¿Podéis migrar mis plugins de Shopware y sus datos?
A: Migramos los datos de tienda de los que depende un plugin, pero los ajustes específicos de cada plugin y sus registros almacenados normalmente necesitan una exportación aparte de ese plugin, o reconstruirse con un equivalente en la plataforma de destino.

Sources:
- Shopware - sitio web oficial: https://www.shopware.com

### Migración a WooCommerce o desde WooCommerce

URL: https://prevedshop.com/es/plataformas/woocommerce
Language: es
Last reviewed: 2026-07-21

WooCommerce no es una plataforma en el mismo sentido que una herramienta SaaS alojada. Es un plugin gratuito que convierte un sitio WordPress autoalojado en una tienda, lo que significa que una migración de WooCommerce es en realidad una migración de WordPress más base de datos. Esa distinción cambia lo que realmente hay que trasladar, y es lo primero que definimos en cualquiera de los dos lados de un proyecto con WooCommerce.

#### Qué es WooCommerce y quién lo gestiona

WooCommerce es un plugin de ecommerce de código abierto para WordPress, creado y mantenido por Automattic. Al ser autoalojado, tú (o tu proveedor de hosting) sois responsables del servidor, la versión de PHP, las copias de seguridad y las actualizaciones. No hay un único proveedor gestionando la disponibilidad como en una plataforma SaaS, lo que da más control pero también más responsabilidad de mantenimiento.

Es popular entre comercios que ya usan WordPress para contenido, o que quieren control total sobre el hosting, los plugins y el código. Esa flexibilidad también explica por qué las tiendas WooCommerce varían enormemente en complejidad: un catálogo sencillo con un par de plugins es una migración muy distinta a una instalación muy personalizada con decenas de plugins interactuando entre sí.

#### El modelo de datos: los productos como contenido de WordPress

WooCommerce almacena los productos como un tipo de contenido personalizado de WordPress, con variaciones, atributos y precios guardados en tablas relacionadas y metadatos de entrada en lugar de un esquema de ecommerce dedicado. Las categorías y etiquetas reutilizan el sistema de taxonomías de WordPress. Esto funciona bien dentro de WordPress, pero implica que migrar hacia WooCommerce requiere mapear tus datos de origen no solo a "productos", sino específicamente al modelo de contenido de WordPress, y migrar fuera de WooCommerce implica extraer datos de ecommerce que están entrelazados con contenido general de WordPress.

El almacenamiento de pedidos depende de la versión y la configuración de WooCommerce: las tiendas antiguas usan entradas y metadatos de WordPress, mientras que High-Performance Order Storage puede guardar pedidos y direcciones en tablas dedicadas. Los clientes siguen vinculados a los usuarios de WordPress y las extensiones pueden añadir más tablas. Que el historial pueda trasladarse como pedidos editables o solo como datos de referencia depende de la plataforma de destino y del método de importación; por eso hay que inventariar el esquema de origen antes del mapeo.

#### Plugins, temas y dónde vive la lógica personalizada

Una tienda WooCommerce en funcionamiento suele depender de varios plugins además del propio WooCommerce, para reglas de envío, pasarelas de pago, suscripciones o campos personalizados a través de herramientas como Advanced Custom Fields. Los datos específicos de cada plugin normalmente no tienen un formato de exportación portable, así que migrar fuera de WooCommerce implica identificar qué guarda realmente cada plugin y si la plataforma de destino tiene un equivalente.

Los temas son temas de WordPress, a menudo combinados con constructores de páginas (Elementor, WPBakery y similares) que guardan los datos de maquetación de formas que no se traducen fuera de WordPress. Salir de WooCommerce generalmente implica reconstruir el diseño de la tienda en la nueva plataforma en lugar de exportarlo.

#### SEO, URLs y cómo gestionamos una migración de WooCommerce

La estructura de URL de WooCommerce está controlada por los ajustes de enlaces permanentes de WordPress, así que es flexible, pero esa flexibilidad implica que las URLs de cada sitio WooCommerce están configuradas de forma ligeramente distinta, y no existe un único patrón fijo contra el que migrar como en algunas plataformas SaaS. Los plugins de SEO populares (Yoast, Rank Math) también almacenan metadatos y redirecciones en sus propias tablas, algo que hay que tener en cuenta por separado de los datos básicos de WooCommerce/WordPress.

Como parte de una migración gestionada, mapeamos tu estructura real de enlaces permanentes, no una supuesta por defecto, a los patrones de URL de la plataforma de destino, extraemos los metadatos del plugin de SEO que uses y configuramos redirecciones para que el posicionamiento existente y los enlaces entrantes sigan resolviendo correctamente. Consulta nuestro servicio de SEO y migración de redirecciones para ver cómo funciona esto en general.

#### FAQ

Q: ¿Los datos de WooCommerce incluyen también mi contenido de WordPress?
A: Solo lo que nos pidas trasladar. WooCommerce y el contenido general de WordPress (entradas de blog, páginas) residen en la misma base de datos, así que definimos con precisión qué cuenta como "datos de tienda" frente a contenido del sitio antes de empezar la migración.

Q: ¿Podéis migrar una tienda WooCommerce con muchos plugins personalizados?
A: Sí, pero requiere más tiempo de evaluación. Identificamos qué guarda realmente cada plugin y si se corresponde con algo en la nueva plataforma o necesita reconstruirse desde cero.

Q: ¿Qué pasa con mis datos de SEO de Yoast o Rank Math si dejo WooCommerce?
A: Extraemos los metadatos y redirecciones que almacenan esos plugins y trasladamos lo que sigue siendo correcto a los campos equivalentes de la nueva plataforma, en lugar de partir de cero con tus metadatos de SEO.

Q: ¿Puedo migrar a WooCommerce desde una plataforma SaaS?
A: Sí, es una dirección habitual cuando los comercios quieren más control sobre el hosting y el código. Mapeamos tu catálogo de origen al modelo de tipos de contenido de WordPress y configuramos WooCommerce en consecuencia.

Sources:
- WooCommerce - sitio web oficial: https://woocommerce.com

### Migration routes

### Migración de Magento a BigCommerce

URL: https://prevedshop.com/es/migraciones/magento-a-bigcommerce
Language: es
Last reviewed: 2026-07-21
Route: adobe-commerce -> bigcommerce

Pasar de Adobe Commerce o Magento Open Source a BigCommerce cambia una plataforma autoalojada centrada en código por una SaaS gestionada, algo parecido en espíritu a un paso a Shopify pero con un conjunto de compromisos distinto. BigCommerce admite de forma nativa más combinaciones de variantes de producto y te da más control sobre la estructura de URL que muchos competidores SaaS, lo que puede hacerla un encaje estructural más cercano para un catálogo Magento complejo, pero el hosting, las extensiones y la configuración multitienda igualmente hay que reconstruirlos de forma deliberada, no exportarlos en bloque.

#### Por qué los comercios dejan Magento

Magento Open Source y Adobe Commerce dan control total sobre el código, el hosting y el checkout, a costa de tener que gestionar esa infraestructura tú mismo: parches de seguridad de PHP y Magento, hosting en servidor o nube, y cumplimiento PCI para el checkout que alojas. BigCommerce, como plataforma SaaS gestionada, quita de encima de tu equipo el hosting, el cumplimiento PCI y los parches de seguridad de plataforma, a cambio de trabajar dentro de sus límites en lugar de con código arbitrario.

Un detonante habitual es el mismo que empuja a los comercios hacia Shopify: el coste de mantener a un desarrollador o agencia para sostener una instancia de Magento deja de tener sentido cuando el crecimiento de la tienda ya no justifica ese gasto, sobre todo en tiendas que aún tienen una instancia de Magento 2 sin parchear o que se han quedado en el Magento 1 fuera de soporte.

#### Qué cambia en el modelo de datos

La estructura de catálogo EAV (entidad-atributo-valor) de Magento permite definir atributos personalizados prácticamente arbitrarios por tipo de producto. El modelo de producto de BigCommerce es más estructurado que el de Magento, pero por lo general más flexible en variantes que otras plataformas SaaS competidoras: admite de forma nativa un número mayor de combinaciones de variantes de producto, además de campos personalizados y modificadores de producto para atributos fuera de la estructura de variantes. Eso no quita que los conjuntos de atributos de Magento haya que mapearlos de forma deliberada a las opciones de variante y los campos personalizados de BigCommerce, en lugar de copiarlos atributo por atributo.

El árbol de categorías de Magento permite anidar con la profundidad que quieras y ajustes de visualización por vista de tienda, y un producto puede pertenecer a varias categorías a la vez. Las categorías de BigCommerce se parecen más a un árbol tradicional que al modelo plano de colecciones de Shopify, lo que hace algo más directa la migración de una estructura de categorías muy anidada de Magento, pero aun así conviene revisarla y simplificarla donde la estructura de Magento haya crecido de forma orgánica a lo largo de los años en vez de haber sido diseñada.

#### URLs, redirecciones y qué es distinto aquí respecto a Shopify

Las claves de URL y reescrituras de Magento son totalmente configurables por vista de tienda. BigCommerce, a diferencia de Shopify, permite rutas de URL personalizadas para productos, categorías y páginas sin imponer un prefijo obligatorio `/products/` o `/collections/`, lo que puede facilitar conservar la estructura de URL existente de Magento. Eso no elimina la necesidad de un plan de redirecciones: cualquier URL que sí cambie sigue necesitando una redirección 301 explícita, y el ejercicio de auditar cada URL indexada de Magento contra su nuevo equivalente en BigCommerce hay que hacerlo de todas formas para evitar una caída de posicionamiento tras la migración.

#### Extensiones, checkout y multitienda

El ecosistema de extensiones de Magento y su capacidad para personalizar el checkout y los flujos del panel mediante código no tienen un equivalente directo en BigCommerce: BigCommerce usa un marketplace de apps más sus propias APIs y la personalización de tienda Stencil/Catalyst para la lógica a medida. Cada extensión activa de Magento necesita una decisión explícita durante la evaluación: una app equivalente de BigCommerce, un desarrollo a medida contra las APIs de BigCommerce, o la confirmación de que ya no hace falta. El modelo multisitio/multitienda de Magento también necesita mapearse a las capacidades multitienda de BigCommerce, que funcionan de forma distinta por dentro aunque el resultado final se parezca.

#### FAQ

Q: ¿BigCommerce puede gestionar los atributos de producto personalizados de Magento?
A: A través de una combinación de opciones de variante y campos personalizados, pero BigCommerce no tiene un equivalente automático a los conjuntos de atributos EAV de Magento. Mapeamos el uso real de tus atributos durante la evaluación, en lugar de migrar cada atributo que Magento tenga definido.

Q: ¿Migrar las URLs de Magento a BigCommerce es más fácil que a Shopify?
A: A menudo, algo más, porque BigCommerce permite rutas de URL personalizadas sin un prefijo obligatorio, a diferencia de la estructura fija de Shopify. Eso reduce cuántas URLs necesitan cambiar, pero cualquier URL que sí cambie sigue necesitando una redirección 301 explícita; la auditoría hay que hacerla igualmente.

Q: ¿Qué pasa con mis extensiones y módulos personalizados de Magento?
A: Cada uno se evalúa individualmente durante la evaluación: se sustituye por una app existente de BigCommerce, se reconstruye contra las APIs de BigCommerce, o se confirma que ya no es necesario. Señalamos esta lista antes de definir el alcance del proyecto, no después.

Q: ¿Puedo conservar la funcionalidad multitienda o multisitio?
A: El modelo multisitio de Magento no se corresponde directamente con la arquitectura de BigCommerce, aunque BigCommerce también admite varias tiendas. Mapeamos tu necesidad real (marcas, regiones o monedas separadas) a la estructura de BigCommerce adecuada, en lugar de asumir una conversión uno a uno.

Sources:
- Sitio web y documentación oficial de BigCommerce: https://www.bigcommerce.com
- Documentación de Adobe Commerce / Magento Open Source: https://experienceleague.adobe.com/en/docs/commerce

### Migración de Magento a Shopify

URL: https://prevedshop.com/es/migraciones/magento-a-shopify
Language: es
Last reviewed: 2026-07-21
Route: adobe-commerce -> shopify

Pasar de Adobe Commerce o Magento Open Source a Shopify cambia una plataforma PHP autoalojada y muy personalizable por una plataforma SaaS gestionada. Ese cambio te quita de encima el mantenimiento del servidor, la versión de PHP y el cumplimiento PCI, pero también implica que el modelo de datos de tu catálogo, tu estructura de URL y la mayoría de tus extensiones hay que reconstruirlos, no copiarlos. Hecho con cuidado, es un movimiento bien conocido; hecho como una exportación/importación en bruto, es donde el SEO y la lógica personalizada se rompen sin hacer ruido.

#### Por qué los comercios dejan Magento

Magento Open Source y Adobe Commerce dan control total sobre el código, el hosting y el checkout, precisamente lo que los hace caros de mantener en marcha. Alguien tiene que aplicar los parches de seguridad de PHP y Magento, gestionar el servidor o la infraestructura en la nube, y mantener al día el cumplimiento PCI del checkout que alojas tú mismo. Shopify quita el hosting, el cumplimiento PCI y los parches de seguridad de la plataforma de encima de tu equipo, a cambio de menos control de bajo nivel.

Un detonante habitual es que el coste continuado de mantener a un desarrollador o agencia para sostener una instancia de Magento deja de tener sentido en relación con el tamaño de la tienda, sobre todo cuando Magento 1 (fuera de soporte desde hace tiempo) o una instalación envejecida de Magento 2 empieza a acumular extensiones sin parchear.

#### Qué cambia realmente en el modelo de datos

El catálogo de productos de Magento se construye sobre una estructura EAV (entidad-atributo-valor), que permite definir atributos personalizados prácticamente arbitrarios por tipo de producto. El modelo de producto de Shopify es más sencillo: un producto tiene un conjunto fijo de campos principales más hasta tres dimensiones de opciones de variante (como talla y color) y metafields para todo lo demás. Los productos configurables y las opciones personalizadas de Magento se mapean a variantes y metafields de Shopify, pero el mapeo no es uno a uno: los conjuntos de atributos con muchos atributos personalizados suelen necesitar un esquema de metafields diseñado a propósito, no una conversión automática atributo por atributo.

Las categorías son otra diferencia real: Magento permite anidar categorías con la profundidad que quieras y asignar un producto a muchas de ellas con distintos ajustes de visualización por vista de tienda. Las colecciones de Shopify son más planas, listas manuales o basadas en reglas ("inteligentes") en lugar de un árbol de categorías real, así que un catálogo de Magento muy anidado necesita una estructura de colecciones pensada de forma deliberada, no una exportación directa.

#### URLs, redirecciones y lo que se rompe en silencio

Las claves de URL y reescrituras de Magento son totalmente configurables por vista de tienda. Shopify impone sus propios patrones de URL (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`, `/blogs/{blog}/{handle}`) que no puedes reestructurar a tu gusto. Eso significa que cada URL indexada de Magento necesita una redirección explícita a su equivalente en Shopify: esta es, con diferencia, la causa más habitual de una caída de posicionamiento tras la migración, y es totalmente evitable con un mapa de URLs bien construido antes del lanzamiento, no parcheado después de que Google detecte errores 404.

#### Extensiones, personalizaciones de checkout y multitienda

El ecosistema de extensiones de Magento y su capacidad para personalizar el checkout, las reglas de precios y los flujos de trabajo del panel mediante código no tienen un equivalente directo en Shopify: Shopify usa una App Store más, en Shopify Plus, Checkout Extensibility y Shopify Functions para lógica de checkout personalizada. Cada módulo personalizado de Magento necesita una decisión explícita: si hay una app equivalente, si necesita una app a medida construida sobre las APIs de Shopify, o si esa funcionalidad se descarta. Lo mismo aplica a las configuraciones multisitio/multitienda de Magento, que no se traducen directamente al modelo de tienda única más Markets que usa Shopify para vender internacionalmente.

Nuestro proceso de migración gestionada define todo esto durante la evaluación, catalogando tus extensiones activas y módulos personalizados antes de presupuestar el trabajo, no descubriéndolos a mitad de la migración.

#### FAQ

Q: ¿Shopify puede gestionar los atributos de producto personalizados de Magento?
A: Sí, mediante metafields, pero hay que definirlos y mapearlos de forma deliberada; Shopify no tiene un equivalente automático de los conjuntos de atributos EAV de Magento. Mapeamos el uso real de tus atributos durante la evaluación en lugar de migrar cada atributo que Magento tenga definido.

Q: ¿Mis URLs de Magento se redirigirán automáticamente?
A: No. La estructura de URL de Shopify es fija, así que cada URL relevante de Magento necesita una redirección 301 explícita a su nuevo equivalente en Shopify. Esto es parte central del plan de migración, no un añadido opcional; consulta nuestro servicio de SEO y migración de redirecciones.

Q: ¿Qué pasa con mis extensiones y módulos personalizados de Magento?
A: Cada uno se evalúa individualmente durante la evaluación: se sustituye por una app existente de Shopify, se reconstruye como app personalizada o personalización de tema, o se confirma que ya no es necesario. Señalamos esta lista antes de definir el alcance del proyecto, no después.

Q: ¿Puedo conservar la funcionalidad multitienda o multisitio?
A: El modelo multisitio de Magento no se corresponde directamente con Shopify. Según lo que realmente necesites (marcas separadas, regiones separadas, monedas separadas), el equivalente adecuado en Shopify podría ser Shopify Markets, una segunda tienda o una organización de Shopify Plus. Te ayudamos a elegir según la necesidad real, no con una respuesta genérica.

Sources:
- Shopify - Migra tu tienda a Shopify: https://www.shopify.com/migrate
- Documentación de Adobe Commerce / Magento Open Source: https://experienceleague.adobe.com/en/docs/commerce

### Migración de Magento (Adobe Commerce) a Shoptet

URL: https://prevedshop.com/es/migraciones/magento-a-shoptet
Language: es
Last reviewed: 2026-09-02
Route: adobe-commerce -> shoptet

Magento y Adobe Commerce están pensados para catálogos complejos, múltiples store views y mucha personalización, a cambio de un hosting y un desarrollo caros. Shoptet es una plataforma alojada para comerciantes checos y eslovacos con un modelo de datos fijo más simple e integraciones locales integradas. La migración es sobre todo una consolidación: reducir los conjuntos de atributos, productos configurables, store views y módulos a medida de Magento a lo que Shoptet puede representar, mover clientes e historial de pedidos y proteger las URL que traen tráfico orgánico.

#### Quién pasa de Magento a Shoptet y por qué

Los comerciantes dan este paso cuando la instalación de Magento se ha vuelto desproporcionada para el negocio: una tienda checa o eslovaca mediana que paga hosting de Magento, parches de seguridad, licencias de extensiones y horas de agencia que ya no necesita. Shoptet lo sustituye por un plan mensual, integraciones nativas con Zásilkovna, PPL, GoPay, Comgate, Heureka y Zboží.cz y un entorno gestionado. La contrapartida es la profundidad: sin conjuntos de atributos, sin jerarquía multisitio, sin extensiones libres. Si tu negocio depende de ellas, la evaluación lo dirá antes de empezar cualquier trabajo.

#### Conjuntos de atributos, productos configurables y categorías

Los conjuntos de atributos de Magento se convierten en una única lista plana de parámetros de Shoptet, así que los atributos solapados de distintos conjuntos deben fusionarse y renombrarse de forma coherente. Los productos configurables se mapean a productos de Shoptet con variantes; los hijos simples pasan a ser filas de variante con su propio código, precio y stock. Los productos bundle y agrupados no tienen equivalente directo y se reconstruyen como productos separados o conjuntos. Los árboles de categorías se transfieren, pero las categorías ancla y la navegación por capas de Magento se sustituyen por categorías y filtros de parámetros de Shoptet, lo que suele implicar aplanar la jerarquía.

#### Store views, clientes y pedidos

Los store views de Magento suelen usarse para idiomas o marcas. Shoptet admite mutaciones de idioma por tienda pero no sitios independientes, así que cada store view requiere una decisión: fusionar en una tienda Shoptet, operar varias tiendas Shoptet o descartar. Los clientes y direcciones se importan, los grupos de clientes se mapean a niveles de precio de Shoptet y las contraseñas se restablecen en la nueva tienda. El historial de pedidos se importa para informes. Módulos a medida, conectores ERP y funciones B2B se listan uno a uno y se asignan a funciones nativas, complementos o una integración personalizada.

#### Redirecciones y cambio

Las reescrituras de URL de Magento y las rutas de categoría en las URL de producto difieren de los patrones de Shoptet, así que exportamos todas las URL indexadas, construimos un mapa 301 completo y lo cargamos en Shoptet antes de cambiar el DNS. Una importación de prueba del catálogo completo se revisa en precios, IVA, stock y variantes; después se regeneran los feeds y se reenvía el sitemap. Las redirecciones protegen la continuidad de URL y reducen el riesgo; ninguna migración garantiza posiciones.

#### FAQ

Q: ¿Se pueden migrar los productos configurables de Magento a Shoptet?
A: Sí. Cada producto configurable se convierte en un producto Shoptet con variantes, y los hijos simples pasan a ser filas de variante con su propio código, precio y stock.

Q: ¿Qué pasa con los conjuntos de atributos de Magento?
A: Shoptet tiene una única lista plana de parámetros, así que los conjuntos se fusionan. Los nombres de atributo duplicados o en conflicto se limpian y renombran antes de importar.

Q: ¿Cómo se gestionan los store views de Magento?
A: Cada store view se decide por separado: fusionar en una tienda Shoptet, operar varias tiendas o descartar. Shoptet admite mutaciones de idioma, no sitios independientes.

Q: ¿Conservo clientes e historial de pedidos?
A: Se importan clientes, direcciones y precios por grupo; las contraseñas se restablecen. Los pedidos se importan como historial para informes, no como pedidos activos editables.

Sources:
- Adobe Commerce - Transferencia de datos (importación y exportación): https://experienceleague.adobe.com/en/docs/commerce-admin/systems/data-transfer/data-transfer
- Shoptet Developers - Importación de datos: https://developers.shoptet.com/shoptet-tools/data-import/

### Migración de OpenCart a Shopify

URL: https://prevedshop.com/es/migraciones/opencart-a-shopify
Language: es
Last reviewed: 2026-07-21
Route: opencart -> shopify

OpenCart es una plataforma ligera, autoalojada y de código abierto — más sencilla de gestionar que Magento o PrestaShop, pero que igualmente exige administrar tu propio servidor, tu versión de PHP, los parches de seguridad y el cumplimiento PCI. Pasar a Shopify cambia esa configuración autogestionada por una plataforma alojada y gestionada. Como el modelo de datos de OpenCart es comparativamente sencillo, la migración en sí suele ser más directa que desde una plataforma empresarial más pesada, pero las opciones de producto, la configuración multitienda y las extensiones siguen necesitando un mapeo deliberado, no una exportación/importación en bruto.

#### Por qué los comercios dejan OpenCart

El atractivo de OpenCart es que es gratuito y ligero, pero eso también significa que estás solo a la hora de gestionar el hosting, las actualizaciones de seguridad, el cumplimiento PCI y la compatibilidad de las extensiones con cada nueva versión del núcleo. Muchas tiendas OpenCart las gestionan equipos pequeños sin desarrolladores dedicados, y la carga continua de aplicar parches de seguridad y resolver conflictos entre extensiones acaba siendo desproporcionada respecto al tamaño del negocio con el tiempo. Shopify elimina esa carga de hosting y parcheo de seguridad a cambio de una cuota de plataforma gestionada.

Un detonante habitual es el ecosistema de extensiones: las extensiones de OpenCart (construidas como modificaciones OCMOD o VQMOD) varían en calidad y a menudo dejan de mantenerse, lo que se convierte en un riesgo creciente a medida que la plataforma principal avanza y la pila de extensiones de una tienda va quedando desactualizada.

#### Opciones de producto, categorías y el modelo de datos

OpenCart representa las variantes de producto mediante "opciones" — elecciones como talla o color asociadas a un producto, cada una pudiendo afectar opcionalmente al precio y al stock. Esto es conceptualmente cercano al sistema de variantes de Shopify, lo que hace que el mapeo del producto principal sea más directo que desde plataformas con un modelo de atributos EAV completo. Aun así, Shopify sigue limitando los productos a tres dimensiones de opciones de variante, así que los productos de OpenCart con más grupos de opciones que eso necesitan que parte de esas opciones se trasladen a metafields en lugar de a variantes.

Las categorías de OpenCart pueden anidarse y un producto puede pertenecer a varias categorías a la vez, algo similar en espíritu a las colecciones de Shopify pero estructurado de forma distinta por dentro — el árbol de categorías de OpenCart no se corresponde uno a uno con el modelo de colecciones manuales/inteligentes de Shopify, así que la estructura de colecciones normalmente hay que planificarla en lugar de copiarla en bloque.

#### Multitienda, URLs y extensiones

OpenCart permite ejecutar varios escaparates desde una única instalación, compartiendo un mismo panel de administración y un mismo catálogo de productos entre tiendas con configuraciones distintas. Los equivalentes más cercanos en Shopify son Shopify Markets para variaciones regionales o de divisa dentro de una misma tienda, o tiendas Shopify genuinamente separadas para marcas distintas — ninguno de los dos es una correspondencia arquitectónica directa, así que qué enfoque encaja depende de para qué se esté usando realmente la configuración multitienda.

La configuración de URLs amigables para SEO de OpenCart se puede ajustar por tienda, así que las URLs existentes necesitan mapearse con redirecciones 301 explícitas hacia los patrones de URL fijos de Shopify (`/products/{handle}`, `/collections/{handle}`) para evitar perder visibilidad en buscadores. Las extensiones de OpenCart que gestionan envíos, pagos o personalización del catálogo también necesitan una evaluación individual durante la valoración — una app equivalente de Shopify, un desarrollo a medida, o la confirmación de que ya no son necesarias.

#### FAQ

Q: ¿El sistema de opciones de producto de OpenCart se corresponde bien con las variantes de Shopify?
A: Se corresponde mejor que desde plataformas con un modelo completo de atributos personalizados, ya que las opciones de OpenCart ya están conceptualmente cerca de las variantes de Shopify. Los productos con más de tres grupos de opciones necesitan que parte de esas opciones se mapeen a metafields de Shopify en lugar de a variantes.

Q: ¿Qué pasa con mi configuración multitienda de OpenCart?
A: No existe un equivalente directo uno a uno en Shopify. Según si necesitas un catálogo compartido con variación regional o marcas realmente separadas, te ayudamos a elegir entre Shopify Markets y tiendas Shopify independientes según tus necesidades reales.

Q: ¿Mis URLs de OpenCart redirigirán automáticamente?
A: No. La estructura de URLs de Shopify es fija, así que cada URL indexada de OpenCart necesita una redirección 301 explícita a su equivalente en Shopify — esto se planifica como parte de la migración, no se deja para después del lanzamiento.

Q: ¿Qué pasa con mis extensiones de OpenCart?
A: Cada extensión activa se evalúa de forma individual durante la valoración: se sustituye por una app de Shopify, se reconstruye como una app personalizada o una personalización de tema, o se descarta si ya no es necesaria. Señalamos esto antes de definir el alcance del proyecto.

Sources:
- Shopify - Migra tu tienda a Shopify: https://www.shopify.com/migrate
- OpenCart - sitio oficial y documentación: https://www.opencart.com

### Migración de PrestaShop a Shopify

URL: https://prevedshop.com/es/migraciones/prestashop-a-shopify
Language: es
Last reviewed: 2026-07-21
Route: prestashop -> shopify

PrestaShop es una plataforma autoalojada y de código abierto muy popular en Europa, construida en torno a un soporte nativo multiidioma y multidivisa y a un sistema flexible de "combinaciones" para las variantes de producto. Pasar a Shopify significa renunciar al acceso directo al servidor y a la base de datos a cambio de un hosting gestionado y cumplimiento PCI, y significa replantear en los términos propios de Shopify algunas cosas que PrestaShop gestiona de forma nativa — multitienda, contenido multiidioma y combinaciones de producto —, en lugar de asumir una exportación exactamente equivalente.

#### Por qué los comercios dejan PrestaShop

Al ser una plataforma autoalojada, PrestaShop pone en manos de tu equipo la gestión del servidor, las actualizaciones de versión de PHP, la compatibilidad de módulos y el cumplimiento PCI del checkout. Eso es manejable para una tienda con recursos técnicos dedicados, pero se convierte en un coste real — tiempo de desarrollo, hosting, parches de seguridad — en cuanto la tienda funciona con recursos ajustados. Shopify absorbe el hosting, el cumplimiento PCI y los parches de seguridad de la plataforma, a cambio de ceder algo de control de bajo nivel por una carga de gestión predecible.

Un detonante frecuente es el ecosistema de módulos: los módulos de PrestaShop varían mucho en calidad y mantenimiento, y una tienda construida a lo largo de los años a menudo arrastra varios módulos que ya no reciben soporte activo, lo que se convierte en un riesgo creciente a medida que PrestaShop sigue avanzando.

#### Combinaciones, categorías y el modelo de datos

Los productos de PrestaShop usan un sistema de "combinaciones" — atributos como talla o color generan filas de combinación, y PrestaShop apenas impone límites estrictos a cuántos atributos o combinaciones puede tener un producto. El modelo de variantes de Shopify es más restringido: hasta tres dimensiones de opciones por producto, con metafields disponibles para los atributos que no encajan en el modelo de variantes. Los productos con muchas combinaciones de atributos en PrestaShop, o atributos usados más como datos descriptivos que como variantes reales, necesitan un plan de metafields deliberado, no una copia atributo por atributo tal cual.

El árbol de categorías de PrestaShop, como el de Magento, permite anidamiento arbitrario y la asignación de un producto a varias categorías. Las colecciones de Shopify son más planas — listas manuales o basadas en reglas —, así que un catálogo de PrestaShop con categorías muy anidadas necesita una estructura de colecciones rediseñada para funcionar bien en Shopify, no una exportación literal de categorías.

#### Multitienda, multiidioma y multidivisa

La función multitienda de PrestaShop y su soporte nativo multiidioma y multidivisa son muy usados por comercios de la UE que venden en varios mercados desde una sola instalación. El equivalente más cercano en Shopify es Shopify Markets para la variación de divisa, idioma y escaparate regional, o en algunos casos una tienda Shopify separada por marca o región. Ninguno de los dos es una correspondencia arquitectónica directa con el multitienda de PrestaShop, así que el enfoque correcto depende de lo que la tienda realmente necesite — un solo escaparate que sirva a varios mercados, o escaparates genuinamente separados —, y esa decisión debe tomarse de forma deliberada antes de definir el alcance de la migración.

#### URLs, redirecciones y módulos

La configuración de URLs amigables de PrestaShop es totalmente personalizable, así que las URLs existentes de PrestaShop rara vez coinciden de serie con los patrones fijos de Shopify (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`). Cada URL indexada de PrestaShop necesita una redirección explícita hacia su equivalente en Shopify para proteger el posicionamiento en buscadores durante el traslado.

Los módulos de PrestaShop que cubren envíos, pagos, marketing y personalización del checkout no tienen un equivalente automático en Shopify. Cada módulo activo necesita una decisión explícita durante la evaluación — sustituirlo por una app de Shopify, reconstruirlo como una app personalizada o una personalización de tema, o descartarlo —, de modo que el alcance de la migración se conozca antes de empezar a trabajar, no se descubra a mitad de proyecto.

#### FAQ

Q: ¿Shopify puede gestionar las combinaciones de producto de PrestaShop?
A: Las combinaciones estándar se mapean a las variantes de Shopify, pero Shopify limita los productos a tres dimensiones de opciones de variante. Las combinaciones que superan ese límite, o los atributos usados más como datos descriptivos, necesitan mapearse a metafields de forma deliberada durante la evaluación.

Q: ¿Qué pasa con mi configuración multitienda de PrestaShop?
A: No existe un equivalente arquitectónico directo en Shopify. Según lo que realmente necesites — catálogo compartido entre regiones, divisas separadas o marcas genuinamente distintas —, la estructura correcta en Shopify puede ser Shopify Markets o tiendas separadas. Te ayudamos a elegir según tus necesidades, no con una respuesta por defecto.

Q: ¿Mis URLs de PrestaShop redirigirán automáticamente a Shopify?
A: No. Shopify impone su propia estructura de URLs, así que cada URL relevante de PrestaShop necesita una redirección 301 explícita mapeada a su equivalente en Shopify — esto es parte central del plan de migración, no un extra opcional.

Q: ¿Qué pasa con mis módulos de PrestaShop?
A: Cada uno se evalúa de forma individual: se sustituye por una app existente de Shopify, se reconstruye como una app personalizada o una personalización de tema, o se confirma que ya no es necesario. Señalamos esta lista durante la evaluación, antes de definir el alcance del proyecto.

Sources:
- Shopify - Migra tu tienda a Shopify: https://www.shopify.com/migrate
- PrestaShop - sitio oficial y documentación: https://www.prestashop.com

### Migración de PrestaShop a Shoptet

URL: https://prevedshop.com/es/migraciones/prestashop-a-shoptet
Language: es
Last reviewed: 2026-09-02
Route: prestashop -> shoptet

PrestaShop es una plataforma de código abierto que alojas y mantienes tú mismo; Shoptet es un sistema alojado orientado a comerciantes checos y eslovacos con envíos, pagos y feeds de marketplaces locales integrados. La migración sustituye las combinaciones, características y datos de módulos de PrestaShop por variantes, parámetros y complementos de Shoptet, traslada clientes e historial de pedidos y convierte cada URL indexada en una redirección 301 para que el cambio no tire años de visibilidad en buscadores.

#### Qué ganan y qué ceden los comerciantes de PrestaShop

Shoptet elimina la administración del servidor, las actualizaciones de PHP y la compatibilidad de módulos. Facturación, IVA, Zásilkovna, PPL, GoPay, Comgate, Heureka y Zboží.cz son nativos, lo que suele sustituir una docena de módulos de PrestaShop. Se cede la personalización ilimitada: en PrestaShop cualquier cosa se cambia con un módulo u override, mientras que Shoptet ofrece un conjunto fijo de campos, plantillas y complementos. La funcionalidad de módulos a medida debe reevaluarse, no copiarse.

#### Combinaciones, características y categorías

Las combinaciones de PrestaShop (conjuntos de atributos como talla y color) se mapean a variantes de Shoptet; cada combinación pasa a ser una fila de variante con su propio código, precio y stock. Las características de PrestaShop, usadas para filtrar, se convierten en parámetros de Shoptet creados antes de importar. Ambos sistemas admiten varias categorías por producto, pero la categoría por defecto de PrestaShop debe elegirse explícitamente como categoría principal en Shoptet. Imágenes, descripciones, títulos y descripciones meta se transfieren en la importación; las reglas de precios específicos y los precios por grupo de clientes requieren revisión, porque Shoptet modela los descuentos de otra forma.

#### Clientes, pedidos y redirecciones

Los clientes se importan con direcciones y pertenencia a grupos; las contraseñas no se pueden trasladar, así que el restablecimiento forma parte de la comunicación de lanzamiento. Los pedidos se importan como historial para informes. Las URL de PrestaShop dependen de la configuración de URL amigables y suelen incluir IDs; Shoptet usa sus propios patrones de ruta, por lo que generamos un mapa 301 completo a partir del sitemap y los datos de analítica y lo verificamos antes de cambiar el DNS. Las redirecciones protegen la continuidad de URL y reducen el riesgo; las posiciones nunca están garantizadas.

#### Módulos, feeds y puesta en marcha

Listamos cada módulo activo de PrestaShop y decidimos: nativo en Shoptet, disponible como complemento, integración a medida o descartado. Los feeds de marketplaces se regeneran desde Shoptet. El lanzamiento consiste en una importación de prueba, la revisión de una muestra de precios, IVA y stock y el cambio de DNS, manteniendo PrestaShop en solo lectura durante un breve solapamiento mientras Google Search Console confirma el mapa de redirecciones.

#### FAQ

Q: ¿Las combinaciones de PrestaShop se convierten en variantes de Shoptet?
A: Sí. Cada combinación se convierte en una variante con su propio código, precio y stock; los grupos de atributos pasan a ser las dimensiones de variante. Los nombres de atributos incoherentes se limpian antes de importar.

Q: ¿Puedo conservar el historial de pedidos de PrestaShop?
A: Los pedidos se importan como historial para consulta e informes. No son pedidos activos editables y las facturas siguen en tu sistema contable.

Q: ¿Funcionarán mis módulos de PrestaShop en Shoptet?
A: Ningún módulo se transfiere directamente. Mapeamos cada uno a una función nativa de Shoptet, un complemento o una integración a medida, y descartamos los que ya no hacen falta.

Q: ¿Cómo gestionáis las URL de PrestaShop con IDs de producto?
A: Cada URL indexada recibe una redirección 301 explícita a su equivalente en Shoptet, generada a partir del sitemap y la analítica y verificada antes del lanzamiento.

Sources:
- PrestaShop - Documentación del webservice: https://devdocs.prestashop-project.org/9/webservice/
- Shoptet Developers - Importación de datos: https://developers.shoptet.com/shoptet-tools/data-import/

### Migración de Shopify a WooCommerce

URL: https://prevedshop.com/es/migraciones/shopify-a-woocommerce
Language: es
Last reviewed: 2026-09-02
Route: shopify -> woocommerce

La mayoría de las guías solo describen el paso a Shopify. La dirección contraria es igual de habitual cuando una tienda quiere la propiedad total de sus datos, un sitio con mucho contenido en WordPress o librarse de comisiones por transacción y suscripciones de apps. Pasar de Shopify a WooCommerce implica asumir el hosting, la seguridad y las actualizaciones a cambio de un modelo de datos abierto y personalización sin límites. La migración cubre productos, variantes, metafields, clientes, historial de pedidos, contenido y un mapa de redirecciones completo.

#### Por qué las tiendas dejan Shopify

Los motivos habituales son los costes recurrentes de apps que se acumulan, las comisiones en pasarelas de terceros, un checkout difícil de personalizar y el deseo de tener comercio y contenido en una sola instalación de WordPress. WooCommerce no cobra cuota de plataforma y guarda toda la base de datos en tu propio servidor, algo importante para comerciantes con requisitos estrictos de residencia de datos o mucha personalización B2B. La contrapartida es operativa: el rendimiento del hosting, las copias de seguridad, las actualizaciones de plugins y el alcance PCI pasan a ser tuyos o de tu agencia.

#### Productos, variantes y metafields

Los productos de Shopify con hasta tres dimensiones de opciones se mapean limpiamente a productos variables de WooCommerce con atributos y variaciones. La excepción son los metafields: WooCommerce no tiene equivalente nativo, así que cada metafield se mapea a un atributo de producto, un campo personalizado o la estructura de datos de un plugin concreto. Las colecciones se convierten en categorías o etiquetas según su uso; las colecciones inteligentes basadas en reglas deben recrearse como categorías con asignación manual o mediante un plugin de filtrado. Imágenes, SKU, pesos e inventario se mueven con el importador CSV o mediante un proceso directo de API a base de datos.

#### Clientes, pedidos y contenido

Los clientes se importan con direcciones y consentimiento de marketing; las contraseñas se cifran de forma distinta en cada plataforma y nunca se transfieren. El historial de pedidos se importa para informes y atención al cliente, con estados mapeados a sus equivalentes en WooCommerce. Las páginas y entradas de blog de Shopify pasan a ser páginas y entradas de WordPress, lo que suele ganar flexibilidad de edición. Los códigos de descuento y las tarjetas regalo requieren revisión, porque los cupones de WooCommerce y los plugins de tarjetas regalo no reproducen exactamente las reglas de Shopify.

#### URL, redirecciones y lanzamiento

Shopify impone los prefijos `/products/`, `/collections/` y `/pages/`; WordPress permite definir los enlaces permanentes libremente, una oportunidad para diseñar una estructura más limpia. Cada URL indexada de Shopify debe mapearse a una URL de WooCommerce mediante una redirección 301 servida por el nuevo sitio antes de mover el dominio. Probamos el mapa de redirecciones, la velocidad y el checkout en un servidor de staging y después cambiamos el DNS dejando la tienda de Shopify abierta durante un breve solapamiento. Las redirecciones preservan la continuidad de URL y reducen el riesgo; las posiciones no se pueden garantizar.

#### FAQ

Q: ¿Se pueden migrar los metafields de Shopify a WooCommerce?
A: Sí, pero no de forma automática. Cada metafield se mapea a un atributo de WooCommerce, un campo personalizado o una estructura de plugin que tu tema pueda mostrar.

Q: ¿Conservan los clientes sus contraseñas al pasar a WooCommerce?
A: No. Los hashes de contraseña son propios de cada plataforma. Los clientes reciben un enlace de restablecimiento en la nueva tienda, idealmente dentro del anuncio de lanzamiento.

Q: ¿Qué hosting necesita WooCommerce tras dejar Shopify?
A: Un hosting WordPress gestionado con PHP 8, caché de objetos y copias diarias es el mínimo práctico para una tienda que antes estaba en la infraestructura de Shopify.

Q: ¿Perderé SEO al dejar Shopify?
A: Los patrones de URL cambian, así que un mapa completo de redirecciones 301 es obligatorio. Con redirecciones, etiquetas canónicas y un sitemap reenviado el riesgo se reduce, pero ninguna migración garantiza posiciones intactas.

Sources:
- WooCommerce - Importador y exportador de productos CSV: https://woocommerce.com/document/product-csv-importer-exporter/
- Shopify Help Center - Migrar a Shopify: https://help.shopify.com/en/manual/migrating-to-shopify

### Migración de Shoptet a Shopify

URL: https://prevedshop.com/es/migraciones/shoptet-a-shopify
Language: es
Last reviewed: 2026-07-21
Route: shoptet -> shopify

Shoptet es una plataforma SaaS cerrada y alojada, centrada en los mercados checo y eslovaco, así que este traslado es distinto de una migración de autoalojado a SaaS: ambas plataformas gestionan el hosting y el cumplimiento PCI por ti. Los motivos habituales suelen ser el alcance más allá del mercado CZ/SK, el ecosistema de apps global, mucho mayor, de Shopify, y más flexibilidad de diseño gracias al sistema de temas Liquid de Shopify. Como Shoptet es de código cerrado, el acceso a los datos depende de sus herramientas de exportación y de su API en lugar del acceso directo a la base de datos, lo que condiciona cómo hay que planificar la migración en sí.

#### Por qué los comercios dejan Shoptet

Shoptet es una plataforma sólida y sencilla de gestionar para comercios de CZ/SK, pero tiene un enfoque regional — su mercado de apps, sus integraciones de pago y envío, y sus herramientas multidivisa/multiidioma están construidas principalmente en torno a ese mercado. Los comercios que se expanden más allá de Chequia y Eslovaquia suelen encontrar en el ecosistema global de apps de Shopify, en sus herramientas nativas multidivisa y multiidioma a través de Shopify Markets, y en su base más amplia de integraciones de terceros, un mejor encaje para el crecimiento internacional.

La flexibilidad de diseño es otro motivo habitual: la personalización de temas de Shoptet es más limitada que el sistema de temas basado en Liquid de Shopify, así que los comercios que quieren un diseño de escaparate muy personalizado o una personalización más profunda del checkout (disponible para comercios de Shopify Plus) suelen encontrar en Shopify más margen para construir exactamente lo que quieren.

#### Sacar los datos de una plataforma cerrada

A diferencia de las plataformas de código abierto, donde se puede consultar la base de datos directamente, Shoptet no ofrece acceso directo a la base de datos — los datos de producto, pedido y cliente hay que extraerlos a través de las herramientas de exportación de Shoptet (exportaciones CSV/XML) y de su API. Eso significa que el paso de extracción de datos de la migración depende de lo que realmente exponen la exportación y la API de Shoptet, y cualquier dato que no sea accesible por esos canales (ciertos campos personalizados, metadatos históricos de pedidos) hay que identificarlo pronto, ya que no se puede extraer simplemente de un volcado de base de datos como en una plataforma autoalojada.

#### Datos de producto, categorías y variantes

El modelo de producto de Shoptet, como el de la mayoría de las plataformas SaaS, usa parámetros/variantes para opciones de producto como la talla o el color. Mapear esto al sistema de variantes de Shopify (limitado a tres dimensiones de opciones) suele ser más directo que migrar desde una plataforma con un modelo de atributos personalizados arbitrario, aunque los parámetros de Shoptet usados más para filtrado descriptivo que como variantes reales se ubican mejor en metafields de Shopify. La estructura de categorías de Shoptet también necesita revisarse frente al modelo más plano y basado en colecciones de Shopify, en lugar de copiarse como un árbol literal.

#### URLs, localización y apps

Las URLs de Shoptet siguen las convenciones propias de la plataforma y necesitan mapearse a los patrones fijos de Shopify (`/products/{handle}`, `/collections/{handle}`) con redirecciones 301 explícitas para cada página indexada, para proteger la visibilidad en buscadores ya conseguida — algo especialmente importante para el SEO acumulado con el tiempo en el mercado CZ/SK. Si la tienda vende en varios idiomas o divisas, hay que configurar Shopify Markets para replicar esa configuración, ya que funciona de forma distinta por dentro que la localización integrada de Shoptet. Cualquier app o integración del marketplace de Shoptet (pasarelas de pago, transportistas, herramientas de marketing) también necesita una evaluación individual frente a la App Store de Shopify, para confirmar si existe un equivalente o hace falta un desarrollo a medida.

#### FAQ

Q: ¿Cómo saco mis datos de producto y pedidos de Shoptet?
A: A través de las herramientas de exportación CSV/XML de Shoptet y de su API — no hay acceso directo a la base de datos, ya que es una plataforma SaaS cerrada. Identificamos desde el principio qué tipos de datos son realmente exportables y señalamos lo que no lo sea antes de definir el alcance de la migración.

Q: ¿Mis URLs de Shoptet redirigirán automáticamente a Shopify?
A: No. La estructura de URLs de Shopify es fija y distinta de la de Shoptet, así que cada URL indexada de Shoptet necesita una redirección 301 explícita a su equivalente en Shopify, algo especialmente relevante para la visibilidad en buscadores acumulada en CZ/SK.

Q: ¿Shopify puede gestionar la venta multiidioma y multidivisa como lo hace Shoptet?
A: Sí, a través de Shopify Markets, pero se configura de forma distinta a la localización integrada de Shoptet — hay que configurarlo de forma deliberada para replicar tu configuración multimercado actual, no dar por hecho que funciona igual de serie.

Q: ¿Por qué pasar de Shoptet a Shopify si ambas son plataformas SaaS alojadas?
A: Los motivos habituales son el alcance y la flexibilidad, no la carga de hosting — el ecosistema global de apps de Shopify, integraciones de pago y envío más amplias para vender a nivel internacional, y más opciones de personalización de tema y checkout para tiendas que han superado el conjunto de herramientas, más orientado a lo regional, de Shoptet.

Sources:
- Shopify - Migra tu tienda a Shopify: https://www.shopify.com/migrate
- Shoptet - sitio oficial: https://www.shoptet.cz

### Migración de Shopware a Shopify

URL: https://prevedshop.com/es/migraciones/shopware-a-shopify
Language: es
Last reviewed: 2026-07-21
Route: shopware-6 -> shopify

Shopware es una plataforma de comercio flexible, basada en Symfony y muy popular en la región DACH, disponible tanto autoalojada como en una versión cloud gestionada. Pasar a Shopify significa renunciar al sistema de entidades y plugins altamente personalizable de Shopware a cambio de la plataforma de Shopify, más restringida pero totalmente gestionada. El trabajo principal consiste en mapear las propiedades de producto flexibles y el modelo de canales de venta de Shopware al esquema de producto fijo y al ecosistema de apps de Shopify, junto con la planificación habitual de URLs y redirecciones que exige cualquier cambio de plataforma.

#### Por qué los comercios dejan Shopware

El punto fuerte de Shopware — una plataforma muy extensible construida sobre Symfony, con un sistema de entidades flexible y una personalización profunda mediante plugins y apps — conlleva una carga real si está autoalojada: la gestión del servidor, las actualizaciones de versión de PHP y de Shopware, y el cumplimiento PCI del checkout recaen en tu equipo. Incluso la opción cloud gestionada de Shopware sigue implicando gestionar un ecosistema de plugins que deben mantenerse compatibles con cada actualización. Shopify elimina por completo el hosting y los parches de la plataforma de tus responsabilidades, a costa de las opciones de personalización más profundas a nivel de código que ofrece Shopware.

Un detonante habitual es el mismo que se ve con otras plataformas flexibles de código abierto: el tiempo de desarrollo necesario para mantener plugins personalizados de Shopware y que sigan funcionando con cada actualización de versión deja de ser proporcionado a lo que la tienda necesita, especialmente para comercios que han aprovechado la flexibilidad de Shopware menos de lo esperado.

#### Propiedades de producto, variantes y el modelo de datos

Shopware representa la variación de producto mediante "propiedades" y "opciones" que generan combinaciones de variantes, junto con un sistema flexible de campos personalizados para atributos fuera de esa estructura. Esto es conceptualmente más cercano al modelo de variantes de Shopify que un sistema EAV completo, pero el límite estricto de Shopify de tres dimensiones de opciones de variante por producto significa que los productos de Shopware que usan más grupos de propiedades que eso necesitan trasladar parte de esas propiedades a metafields de Shopify en lugar de a variantes.

La estructura de categorías de Shopware, como la de la mayoría de las plataformas con un árbol de categorías real, permite categorías anidadas con asignación flexible. Las colecciones de Shopify son más planas — listas manuales o basadas en reglas, en lugar de un árbol anidado —, así que una estructura de categorías de Shopware necesita rediseñarse como un conjunto de colecciones de Shopify, no exportarse directamente.

#### Canales de venta y múltiples escaparates

El concepto de "Canal de venta" de Shopware permite que una sola instancia de Shopware sirva a varios escaparates, apps o marketplaces desde un catálogo compartido, cada uno con su propia configuración. Los equivalentes más cercanos en Shopify son sus propios múltiples canales de venta (tienda online, TPV, marketplaces) más Shopify Markets para la variación regional y de divisa dentro de una misma tienda, o tiendas Shopify separadas para marcas genuinamente distintas. Los conceptos se solapan pero no son una correspondencia arquitectónica directa, así que una configuración de canales de venta de Shopware necesita mapearse a la estructura correcta de Shopify según para qué se esté usando realmente, no asumir que se traduce uno a uno.

#### URLs, plugins y consideraciones específicas de la UE

Las URLs SEO de Shopware son configurables por canal de venta, así que las URLs existentes necesitan redirecciones 301 explícitas mapeadas a los patrones fijos de Shopify (`/products/{handle}`, `/collections/{handle}`) para proteger el posicionamiento en buscadores durante el traslado. Los plugins y apps de Shopware que cubren envíos, pagos y personalización del checkout no tienen un equivalente automático en Shopify y necesitan una evaluación individual — una app de Shopify, un desarrollo a medida, o la confirmación de que esa funcionalidad ya no es necesaria.

Shopware se usa mucho en toda la UE y cuenta con herramientas integradas para la gestión del IVA y los requisitos de datos relacionados con el RGPD habituales en ese mercado. Shopify cubre un terreno similar mediante Shopify Tax y sus propias herramientas de cumplimiento normativo, pero la configuración específica — registro fiscal, formato de facturas, ajustes de tratamiento de datos — hay que revisarla y reconfigurarla para Shopify, no asumir que se traslada automáticamente.

#### FAQ

Q: ¿Las propiedades de producto de Shopware se corresponden bien con las variantes de Shopify?
A: Razonablemente bien para el uso estándar de variantes, ya que las propiedades de Shopware son conceptualmente similares a las opciones de variante de Shopify. Los productos que usan más de tres grupos de propiedades necesitan trasladar parte de esas propiedades a metafields de Shopify, ya que Shopify limita los productos a tres dimensiones de opciones de variante.

Q: ¿Qué pasa con mis Canales de venta de Shopware?
A: No hay un equivalente exacto en Shopify — los propios múltiples canales de venta de Shopify, Shopify Markets y las tiendas separadas cubren cada uno una parte de lo que puede hacer una configuración de Canales de venta de Shopware. Mapeamos tu caso de uso real (regiones, marcas, marketplaces) a la estructura correcta de Shopify durante la evaluación.

Q: ¿Mis URLs de Shopware redirigirán automáticamente a Shopify?
A: No. La estructura de URLs de Shopify es fija, así que cada URL indexada de Shopware necesita una redirección 301 explícita a su equivalente en Shopify — forma parte del plan de migración, no es un añadido de última hora.

Q: ¿La configuración de IVA de la UE y RGPD de Shopware se traslada a Shopify?
A: No de forma automática. Shopify tiene sus propias herramientas de impuestos y cumplimiento normativo (Shopify Tax y ajustes relacionados), pero el registro fiscal, el formato de facturas y la configuración de tratamiento de datos hay que revisarlos y configurarlos específicamente para Shopify, no asumir que se trasladan desde Shopware.

Sources:
- Shopify - Migra tu tienda a Shopify: https://www.shopify.com/migrate
- Shopware - sitio oficial y documentación: https://www.shopware.com

### Migración de WooCommerce a BigCommerce

URL: https://prevedshop.com/es/migraciones/woocommerce-a-bigcommerce
Language: es
Last reviewed: 2026-07-21
Route: woocommerce -> bigcommerce

WooCommerce funciona como plugin de WordPress, así que sus datos, hosting y rendimiento están ligados a tu instalación de WordPress. Pasar a BigCommerce separa el comercio de tu stack de contenido en WordPress y traslada el hosting, el cumplimiento PCI y la seguridad de plataforma a BigCommerce, a la vez que te da más flexibilidad nativa de variantes y más control de URL que la mayoría de competidores SaaS. El trabajo consiste en mapear los datos de producto y contenido de WooCommerce, basados en WordPress, a la estructura de BigCommerce sin perder valor SEO ni romper funcionalidad dependiente de plugins por el camino.

#### Por qué los comercios dejan WooCommerce

WooCommerce en sí es gratuito, pero ejecutarlo implica asumir las actualizaciones del núcleo y los plugins de WordPress, el rendimiento del hosting, la seguridad a nivel de servidor y el cumplimiento PCI del checkout. A medida que una tienda crece, los conflictos entre plugins y el efecto de una pila de plugins cada vez mayor sobre la velocidad de página se convierten en costes reales y recurrentes, sin contar el tiempo de desarrollador o agencia necesario para mantenerlo todo parcheado y compatible. BigCommerce, como plataforma SaaS gestionada, elimina esa carga de hosting y mantenimiento a cambio de trabajar dentro de los límites de su plataforma.

Las tiendas que se han quedado pequeñas para su configuración de hosting en WordPress, o que están cansadas de la fragilidad de una pila de plugins a medida que el sitio crece, son las candidatas más habituales para este movimiento.

#### Datos de producto: un encaje más cercano de lo que parece

WooCommerce almacena los productos como un tipo de contenido personalizado de WordPress, con variaciones y atributos construidos sobre taxonomías de WordPress, algo flexible ya que WordPress apenas impone límites a los campos personalizados. El modelo de producto de BigCommerce es más estructurado, pero notablemente más permisivo en variantes que algunos competidores SaaS, y admite un número mayor de combinaciones de variantes por producto junto con campos personalizados y modificadores de producto para atributos que no encajan en la estructura de variantes. Aun así, los productos de WooCommerce con un uso intensivo de ACF (Advanced Custom Fields) o muchos atributos personalizados necesitan un plan de mapeo deliberado hacia los campos personalizados de BigCommerce, no una copia a ciegas.

Las categorías y etiquetas de WooCommerce son taxonomías de WordPress que se pueden anidar y asignar de forma cruzada libremente. El árbol de categorías de BigCommerce se parece más a una jerarquía tradicional que a las colecciones planas de Shopify, lo que hace algo más directa la traducción de una estructura de categorías de WooCommerce, aunque igualmente merece la pena revisarla en lugar de exportarla sin cambios.

#### URLs, contenido y plugins

Los enlaces permanentes de WordPress son totalmente configurables, así que las URLs de WooCommerce rara vez coinciden con un patrón fijo por defecto. BigCommerce, a diferencia de algunas plataformas SaaS, permite rutas de URL personalizadas sin prefijo obligatorio, lo que puede facilitar conservar la estructura de URL existente de WooCommerce, pero cualquier URL que sí cambie sigue necesitando una redirección 301 explícita, y conviene auditar igualmente cada URL indexada de WooCommerce frente a su equivalente en BigCommerce.

También está la cuestión del contenido en WordPress: muchas tiendas WooCommerce dependen de WordPress como CMS completo para el blog y las landing pages, algo sin equivalente directo en las herramientas de contenido, más limitadas, de BigCommerce. Las tiendas con contenido sustancial en WordPress necesitan un plan: migrarlo a páginas de BigCommerce, o mantener WordPress funcionando aparte para el contenido mientras BigCommerce gestiona el comercio. Los plugins de WooCommerce para envíos, suscripciones o campos de checkout personalizados también necesitan una evaluación individual: un equivalente en forma de app de BigCommerce, un desarrollo a medida, o la confirmación de que ya no son necesarios.

#### FAQ

Q: ¿BigCommerce admite la configuración de variantes y atributos de WooCommerce?
A: BigCommerce admite más combinaciones de variantes por producto que algunos competidores SaaS, lo que ayuda con catálogos WooCommerce complejos, pero sigue sin haber un equivalente automático a los campos personalizados de WordPress o los datos de ACF; hay que mapearlos a campos personalizados de BigCommerce de forma deliberada.

Q: ¿Qué pasa con mi blog y mis landing pages de WordPress?
A: No migran automáticamente, ya que las herramientas de contenido de BigCommerce son más limitadas que las de WordPress. Puedes migrar entradas de blog y páginas a BigCommerce, o mantener WordPress funcionando aparte para el contenido mientras BigCommerce gestiona el comercio; te ayudamos a decidir según cuánto tráfico genera ese contenido.

Q: ¿Mis URLs de WooCommerce tendrán que cambiar en BigCommerce?
A: Menos de lo que esperarías al migrar a otras plataformas SaaS, ya que BigCommerce permite rutas de URL personalizadas sin prefijo obligatorio. Cualquier URL que sí cambie sigue necesitando una redirección 301 explícita, y auditamos cada URL indexada de WooCommerce antes del lanzamiento en cualquier caso.

Q: ¿BigCommerce puede sustituir todos mis plugins de WooCommerce?
A: La mayoría tienen un equivalente en forma de app de BigCommerce, pero no todos; parte de la funcionalidad de los plugins necesita un desarrollo a medida contra las APIs de BigCommerce, y otra parte se descarta si ya no es necesaria. Catalogamos tus plugins activos durante la evaluación antes de definir el alcance del trabajo.

Sources:
- Sitio web y documentación oficial de BigCommerce: https://www.bigcommerce.com
- Documentación de WooCommerce: https://woocommerce.com/documentation/

### Migración de WooCommerce a Shopify

URL: https://prevedshop.com/es/migraciones/woocommerce-a-shopify
Language: es
Last reviewed: 2026-07-21
Route: woocommerce -> shopify

WooCommerce funciona como un plugin sobre WordPress, así que los datos, el hosting y el rendimiento de tu tienda están entrelazados con tu instalación de WordPress. Pasar a Shopify separa el comercio del contenido: obtienes una plataforma de hosting gestionada y compatible con PCI y un modelo de producto/checkout diseñado a propósito, pero también pierdes la flexibilidad nativa de WordPress para el contenido y la equivalencia directa plugin-a-app que podrías esperar. El trabajo principal consiste en mapear el modelo de datos de WooCommerce, basado en WordPress, al esquema fijo de Shopify sin perder el valor SEO acumulado ni romper funcionalidad personalizada por el camino.

#### Por qué los comercios dejan WooCommerce

WooCommerce es gratuito de instalar, pero gestionarlo bien no lo es: eres responsable de las actualizaciones del núcleo de WordPress y de los plugins, del rendimiento del hosting, de la seguridad a nivel de servidor y del cumplimiento PCI de todo lo que toca datos de pago. A medida que una tienda crece, los conflictos entre plugins, los problemas de velocidad de página por una pila de plugins cada vez mayor, y el coste recurrente de un desarrollador o agencia para mantenerlo todo parcheado y compatible se convierten en el verdadero coste del software "gratis". Shopify cambia ese mantenimiento continuo por una cuota de plataforma fija y un entorno gestionado y compatible con PCI.

Un detonante habitual es la escala: el rendimiento de WooCommerce depende en gran medida de la calidad del hosting y de la disciplina con los plugins, y las tiendas que empezaron pequeñas a menudo llegan a un punto en el que el tráfico o el tamaño del catálogo superan lo que su configuración de hosting en WordPress estaba pensada para soportar.

#### Qué cambia en el modelo de datos

WooCommerce almacena los productos como un tipo de contenido personalizado de WordPress, con variaciones, atributos y categorías construidos sobre taxonomías de WordPress, una estructura flexible ya que WordPress apenas impone límites a los campos personalizados. El modelo de producto de Shopify es más limitado: un conjunto fijo de campos principales, hasta tres dimensiones de opciones de variante, y metafields para todo lo demás. Los productos con muchos atributos personalizados de WooCommerce o datos de ACF (Advanced Custom Fields) necesitan una estructura de metafields planificada a propósito, no una copia ciega campo por campo.

Las categorías y etiquetas de producto de WooCommerce son taxonomías de WordPress y se pueden anidar y asignar de forma cruzada libremente. Las colecciones de Shopify son listas manuales o basadas en reglas ("inteligentes") en lugar de un árbol de taxonomía real, así que una estructura de categorías profunda de WooCommerce normalmente necesita rediseñarse como un conjunto de colecciones más plano, no exportarse tal cual.

#### URLs, redirecciones y la cuestión del contenido

Los enlaces permanentes de WordPress son totalmente configurables, así que las URLs de producto y categoría de WooCommerce pueden tener casi cualquier forma que el sitio haya elegido. Shopify impone sus propios patrones (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`, `/blogs/{blog}/{handle}`), así que cada URL indexada de WooCommerce que no coincida ya necesita una redirección 301 para sobrevivir al cambio sin perder posicionamiento en buscadores.

También hay una cuestión de contenido específica de este par: WordPress es un CMS completo, y muchas tiendas WooCommerce se apoyan en él para contenido de blog, landing pages y plantillas de página personalizadas. Las herramientas de blog y páginas de Shopify son más sencillas que las de WordPress. Las tiendas con contenido sustancial en WordPress necesitan un plan para ese contenido: migrarlo a páginas/blog de Shopify, o mantener una instancia de WordPress separada para el contenido mientras Shopify gestiona el comercio, decidido de forma deliberada y no descubierto tras el cambio.

#### Plugins, checkout y pasarelas de pago

El ecosistema de plugins de WooCommerce cubre desde calculadoras de envío hasta facturación de suscripciones y campos de checkout personalizados, a menudo mediante plugins de terceros sin equivalente directo en Shopify. Cada plugin activo necesita una decisión explícita durante la migración: una app equivalente de Shopify, una app personalizada o una personalización de tema, o la confirmación de que esa funcionalidad ya no es necesaria. Las pasarelas de pago también necesitan reconfigurarse: WooCommerce admite un amplio abanico de plugins de pasarela, mientras que Shopify centraliza los pagos a través de Shopify Payments o una pasarela de terceros compatible, así que cualquier lógica de checkout personalizada ligada a un plugin de pago específico de WooCommerce hay que reconstruirla para el modelo de checkout de Shopify.

#### FAQ

Q: ¿Mi posicionamiento SEO de WooCommerce sobrevivirá al paso a Shopify?
A: Puede hacerlo, pero solo con un mapeo de redirecciones deliberado. Los enlaces permanentes de WordPress y la estructura fija de URL de Shopify rara vez coinciden exactamente, así que cada URL indexada de WooCommerce necesita una redirección 301 explícita a su equivalente en Shopify antes del lanzamiento; consulta nuestro servicio de SEO y migración de redirecciones.

Q: ¿Qué pasa con mi blog y mis landing pages de WordPress?
A: No migran automáticamente, porque las herramientas de contenido de Shopify son más limitadas que las de WordPress. Puedes migrar entradas de blog y páginas a Shopify, o mantener una instancia de WordPress separada para el contenido mientras Shopify gestiona el comercio; te ayudamos a decidir según cuánto de tu tráfico depende de ese contenido.

Q: ¿Shopify puede sustituir todos mis plugins de WooCommerce?
A: La mayoría tienen un equivalente en forma de app de Shopify, pero no todos; parte de la funcionalidad de los plugins de WooCommerce necesita una app personalizada o una personalización de tema en Shopify, y otra parte se descarta si ya no es necesaria. Catalogamos tus plugins activos durante la evaluación antes de definir el alcance del trabajo.

Q: ¿Qué pasa con las variaciones de producto y los atributos personalizados de WooCommerce?
A: Las variaciones estándar se mapean al sistema de variantes de Shopify, limitado a tres dimensiones de opciones. Los atributos personalizados de WooCommerce y los campos de ACF más allá de eso necesitan mapearse a metafields de Shopify de forma deliberada; no hay una conversión automática uno a uno desde los campos personalizados de WordPress.

Sources:
- Shopify - Migra tu tienda a Shopify: https://www.shopify.com/migrate
- Documentación de WooCommerce: https://woocommerce.com/documentation/

### Migración de WooCommerce a Shoptet

URL: https://prevedshop.com/es/migraciones/woocommerce-a-shoptet
Language: es
Last reviewed: 2026-09-02
Route: woocommerce -> shoptet

Shoptet es una plataforma alojada creada para comerciantes checos y eslovacos, con soporte nativo de transportistas locales, pasarelas de pago, reglas de facturación y feeds para comparadores. Migrar desde WooCommerce significa dejar un WordPress autoalojado por un sistema gestionado con un modelo de datos fijo. La migración consiste sobre todo en traducir los productos, taxonomías y datos de plugins de WordPress a la estructura de importación de Shoptet, conservar el historial de clientes y pedidos donde importa y proteger las URL que traen tu tráfico de búsqueda.

#### Por qué las tiendas pasan de WooCommerce a Shoptet

La mayoría cambia porque mantener bien WordPress cuesta tiempo: actualizaciones de plugins, rendimiento del hosting, parches de seguridad y responsabilidades PCI recaen en el comerciante. Shoptet lo sustituye por una cuota mensual y un entorno gestionado que ya integra Zásilkovna, PPL, GoPay, Comgate, Heureka y Zboží.cz. Si tus clientes están en Chequia o Eslovaquia, las integraciones nativas suelen eliminar varios plugins de golpe. El precio es la flexibilidad: el modelo de productos y contenido de Shoptet es más estrecho que WordPress, así que todo lo personalizado necesita un destino decidido de antemano.

#### Mapeo de productos, variantes y parámetros

WooCommerce guarda los productos como entradas de WordPress con atributos, variaciones y categorías basadas en taxonomías. Shoptet espera una importación estructurada con productos, variantes, parámetros, categorías y disponibilidad definidos en sus propios campos. Las variaciones se convierten en variantes de Shoptet si la estructura de opciones es coherente; los atributos usados para filtrar pasan a ser parámetros, que deben crearse y nombrarse antes de importar. Los árboles de categorías pueden anidarse en ambos sistemas, pero Shoptet funciona mejor con una jerarquía limpia y poco profunda. Los campos personalizados de ACF o de plugins no tienen destino automático y se deciden uno a uno: texto de descripción, parámetro o descarte.

#### Clientes, pedidos y redirecciones de URL

Las cuentas de cliente se importan con datos de contacto y direcciones; las contraseñas no se pueden mover, así que el cliente recibe un flujo de restablecimiento en la nueva tienda. El historial de pedidos se importa como referencia e informes, no como pedidos activos editables. La parte más sensible son las URL: los enlaces permanentes de WordPress son libres, mientras que Shoptet usa sus propios patrones de ruta, por lo que cada producto, categoría y página indexada necesita una redirección 301 a su equivalente en Shoptet antes del lanzamiento. Las redirecciones mantienen la continuidad de URL y reducen el riesgo; ninguna migración garantiza posiciones intactas.

#### Cambio y primeros días en Shoptet

Recomendamos ejecutar la tienda de Shoptet en modo de prueba con todo el catálogo importado, revisar una muestra de productos, precios, tipos de IVA y variantes, y solo entonces cambiar el DNS. Los feeds de Heureka y Zboží.cz deben regenerarse desde Shoptet y reenviarse, y Google Search Console debe recibir el nuevo sitemap el día del lanzamiento. Mantén WordPress accesible en modo lectura durante un breve periodo para no perder nada mientras se confirma el mapa de redirecciones.

#### FAQ

Q: ¿Puedo migrar pedidos y clientes de WooCommerce a Shoptet?
A: Los clientes con direcciones se pueden importar. Los pedidos se importan como historial de referencia; no se convierten en pedidos activos editables. Las contraseñas nunca se transfieren, así que el cliente crea una nueva en el primer acceso.

Q: ¿Seguirán funcionando mis URL de WooCommerce en Shoptet?
A: Solo con un mapa explícito de redirecciones 301. Los patrones de URL de WordPress y Shoptet difieren, así que construimos el mapeo a partir de tus URL indexadas y lo verificamos antes del lanzamiento.

Q: ¿Qué pasa con los plugins de WooCommerce?
A: Revisamos cada plugin. Muchas funciones del mercado checo son nativas en Shoptet, algunas tienen complementos y el resto requiere una solución a medida o se descarta por decisión.

Q: ¿Cuánto tarda una migración de WooCommerce a Shoptet?
A: Un catálogo pequeño o mediano suele tardar de dos a cuatro semanas, incluidas la prueba, las redirecciones y la puesta en marcha; estructuras de parámetros complejas o historiales de pedidos grandes tardan más.

Sources:
- Shoptet Developers - Importación de datos: https://developers.shoptet.com/shoptet-tools/data-import/
- WooCommerce - Importador y exportador de productos CSV: https://woocommerce.com/document/product-csv-importer-exporter/

### Guides

### Cómo elegir una plataforma ecommerce antes de migrar

URL: https://prevedshop.com/es/guias/como-elegir-plataforma-ecommerce
Language: es
Last reviewed: 2026-09-02

Elegir la plataforma es la decisión que condiciona el coste de cualquier migración posterior. Las listas de funciones de los proveedores ayudan poco, porque casi todas las plataformas modernas cubren lo básico. Las preguntas útiles tratan de la estructura de tu catálogo, el mercado al que vendes, los sistemas que debes conectar, cuánta propiedad quieres y qué exigirá la propia migración. Esta guía recorre esas cinco preguntas y termina con una breve lista de señales de alarma que deberían frenar la decisión.

#### Empieza por el catálogo, no por la lista de funciones

Cuenta productos, variantes y parámetros y observa cómo se relacionan. Tres dimensiones de opciones con un conjunto limpio de atributos de filtrado encajan en casi cualquier plataforma. Conjuntos de atributos distintos por tipo de producto, bundles, configuradores, tarifas B2B o miles de variantes reducen las opciones a plataformas con un modelo de datos más rico, como Adobe Commerce, Shopware o una arquitectura composable. Anota los cinco productos más incómodos de tu catálogo y pregunta a cada candidata cómo los almacenaría; las respuestas dicen más que cualquier tabla comparativa.

#### Mercado, idioma e integraciones

Una tienda que vende a clientes checos y eslovacos necesita transportistas locales, pasarelas de pago, feeds para comparadores y reglas de facturación. Shoptet o Upgates lo ofrecen de forma nativa; una plataforma SaaS global puede hacerlo con apps a cambio de más coste y mantenimiento. Vender en varios países plantea otras preguntas: mutaciones de idioma, monedas, gestión del IVA y si la forma correcta es una tienda o varias. Enumera los sistemas que deben seguir conectados - ERP, contabilidad, almacén, PIM, feeds de marketplaces - y comprueba si cada candidata tiene un conector mantenido o solo una API contra la que tendrías que desarrollar.

#### Propiedad, coste y ruta de migración

Las plataformas alojadas cambian control por comodidad: no tocas la base de datos, pero tampoco parcheas nunca un servidor. Las plataformas de código abierto te dan los datos y la responsabilidad. El coste total incluye licencia o plan, hosting, apps o extensiones, horas de agencia y el tiempo interno dedicado a actualizaciones. Por último, pon precio a la propia migración: cuántos datos trasladas, si importan el historial de pedidos y las cuentas de cliente, cuántas URL necesitan redirección y qué funciones a medida hay que reconstruir. Una plataforma más barata sobre el papel puede salir más cara al sumar el esfuerzo de migración.

#### Señales de alarma que deberían frenar la decisión

Desconfía cuando una plataforma no puede mostrar cómo representará un tipo de dato concreto de tu tienda actual, cuando una integración esencial solo existe como app de terceros con mantenimiento incierto, cuando el proveedor promete que las posiciones no cambiarán tras la migración o cuando nadie sabe explicar cómo abandonarías la plataforma más adelante. Un descubrimiento breve con muestras reales de tus datos resuelve la mayoría de estas dudas antes de firmar nada.

#### FAQ

Q: ¿Debo elegir la plataforma antes o después de la evaluación de migración?
A: Lo ideal es que la evaluación informe la elección. Un descubrimiento breve con muestras reales de productos, clientes y pedidos muestra cómo almacenaría cada candidata tus datos y cuánta reconstrucción exigiría la migración.

Q: ¿Una plataforma alojada es siempre más barata que el código abierto?
A: No siempre. Las alojadas tienen cuotas previsibles pero las apps se acumulan; el código abierto no tiene licencia pero requiere hosting, actualizaciones y tiempo de desarrollo. Compara el coste total a tres años, migración incluida.

Q: ¿Cuánto importa la plataforma ecommerce para el SEO?
A: Menos que el proceso de migración. Cualquier plataforma habitual puede posicionar bien; lo que hace perder visibilidad es un mapa de redirecciones incompleto, contenido cambiado o páginas lentas tras el cambio.

Q: ¿Podré cambiar de plataforma otra vez más adelante?
A: Sí, si tus datos siguen siendo exportables. Antes de elegir, comprueba que productos, clientes, pedidos y contenido se pueden exportar en un formato estructurado, para que la siguiente migración sea posible sin ayuda del proveedor.

Sources:
- Google Search Central: Traslados de sitio con cambios de URL: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### La checklist de QA post-lanzamiento

URL: https://prevedshop.com/es/guias/checklist-qa-tras-el-lanzamiento
Language: es
Last reviewed: 2026-07-21

La migración no termina en el momento en que la nueva tienda se pone en marcha — termina cuando has confirmado, de forma deliberada, que todo aquello de lo que dependen tus clientes y los buscadores funciona realmente en condiciones reales. El entorno de pruebas detecta la mayoría de los problemas, pero unos pocos solo aparecen con tráfico real, procesadores de pago reales y buscadores rastreando de nuevo el sitio. Esta checklist cubre qué verificar en los días y semanas posteriores al cambio, sea cual sea la combinación de plataformas implicadas.

#### Verifica el flujo de checkout de principio a fin, en condiciones reales

Realiza tú mismo una compra completa en el sitio ya activo — no en el entorno de pruebas — cubriendo los caminos que realmente usan los clientes: checkout como invitado y checkout con sesión iniciada, al menos un producto con variantes, y cualquier código de descuento o promoción activa en ese momento. Comprueba que los correos de confirmación de pedido se envían correctamente y que el pedido aparece bien reflejado después en tu panel de administración.

No des por hecho que la cobertura del entorno de pruebas se traslada automáticamente. Las pasarelas de pago, los servicios de impuestos y las APIs de tarifas de envío en producción a veces se comportan de forma distinta a sus equivalentes de prueba o sandbox, y precisamente por eso hace falta una comprobación real en condiciones de producción, no confiar en lo que funcionó en pruebas.

#### Confirma que las pasarelas de pago están totalmente activas y bien configuradas

Verifica que el procesamiento de pagos funciona en modo real (no de prueba/sandbox), que todos los métodos de pago que ofrecía tu tienda anteriormente están habilitados y funcionando, y que una transacción real se liquida correctamente de principio a fin — que el dinero llega de verdad, no solo que cambia el estado del pedido. Revisa también la función de reembolso, ya que se usa con menos frecuencia que el checkout y es fácil dejarla sin verificar.

Si admites varios métodos de pago o divisas, prueba cada uno por separado en lugar de asumir que, porque un método funciona, el resto están configurados de la misma manera.

#### Revisa las reglas de impuestos y envío con pedidos reales

La lógica de impuestos y envíos es fácil de configurar mal de forma sutil en una migración, ya que ambas suelen depender de configuraciones que no se corresponden de forma directa entre plataformas. Realiza pedidos de prueba a tus destinos de envío más habituales y confirma que el impuesto se calcula correctamente y que las tarifas y métodos de envío disponibles coinciden con lo que pretendías, no solo con lo que la nueva plataforma configuró por defecto.

Presta especial atención a cualquier caso particular del que dependa tu negocio: exenciones fiscales, umbrales de envío gratuito, reglas específicas por región o restricciones de envío para ciertos productos. Son precisamente los detalles de configuración que con más probabilidad se pierden o quedan con un valor por defecto incorrecto durante una migración.

#### Revisa redirecciones puntuales, no solo las que recuerdas

Aunque tengas un mapa de redirecciones completo elaborado antes del lanzamiento, revisa después del cambio una muestra real de URLs: tus páginas con más tráfico, algunas con menos tráfico, y algunas de las excepciones deliberadas (productos descatalogados, categorías fusionadas). Confirma que cada una redirige al destino correcto en un solo salto, sin cadenas ni bucles.

Revisa también una muestra de URLs que no deberían existir en el sitio antiguo — erratas, antiguas URLs con parámetros, cualquier cosa que un rastreador pudiera haber indexado de forma incidental — para asegurarte de que se resuelven de forma sensata en lugar de dar un error que parezca un problema más amplio.

#### Confirma la continuidad del seguimiento analítico

Verifica que tu plataforma de analítica, el seguimiento de conversiones y cualquier píxel publicitario se disparan correctamente en el nuevo sitio — un pedido de prueba realizado debería aparecer en tus informes de analítica y de plataformas publicitarias igual que antes. El código de seguimiento es fácil de perder en silencio durante un cambio de plataforma, ya que un píxel ausente o mal configurado no genera un mensaje de error; simplemente deja de reportar datos.

Compara las primeras cifras de analítica tras el lanzamiento con tu referencia previa a la migración para el mismo tipo de día (día laborable frente a fin de semana, fuentes de tráfico similares), en lugar de hacer una comparación directa antes/después, ya que la variación normal del tráfico puede enmascarar o simular un problema real de seguimiento.

#### Comprueba el acceso a cuentas de cliente y el historial de pedidos

Haz que unas cuantas cuentas de cliente reales (o de prueba) confirmen que pueden iniciar sesión, ver su historial de pedidos correcto y acceder a las funciones de cuenta de las que dependían antes — direcciones guardadas, métodos de pago guardados cuando aplique, saldos de fidelización o recompensas si tu tienda los tiene. Los problemas de acceso a la cuenta son muy visibles para los clientes que los sufren y afectan directamente a la confianza, así que merece la pena verificarlos de forma deliberada en lugar de asumir que la migración de cuentas "probablemente funcionó".

Si la migración de contraseñas no formó parte del traslado técnico (algo habitual cuando las plataformas usan sistemas de cifrado de contraseñas incompatibles), asegúrate de que los clientes tengan un camino claro para restablecer su contraseña y de que se les comunique, no solo de que exista técnicamente.

#### Vigila la cobertura de Search Console en las semanas siguientes

Sigue vigilando Search Console (o el equivalente en otros buscadores) bastante después del día de lanzamiento — los errores de rastreo, el estado de indexación y cualquier repunte de errores 404 reportados son las señales más tempranas de un problema de redirección o de etiqueta canonical que las pruebas no detectaron. Compáralo con tu referencia previa a la migración para poder distinguir una regresión real de una fluctuación normal a corto plazo tras un cambio de sitio.

Este período de seguimiento es también el momento de volver a enviar tu sitemap si aún no lo has hecho, y de confirmar que las páginas que esperas ver indexadas realmente aparecen en los resultados de búsqueda en las semanas siguientes, y no solo que han sido rastreadas.

#### FAQ

Q: ¿Cuánto tiempo debe continuar el QA post-lanzamiento tras el cambio?
A: Las revisiones activas y casi diarias suelen ser más importantes en la primera o segunda semana, que es cuando surge la mayoría de los problemas de configuración y redirecciones. La reindexación por parte de los buscadores y la estabilización de los patrones de tráfico tardan más, así que merece la pena mantener un seguimiento más ligero (Search Console, tendencias de analítica) durante más tiempo — varias semanas es habitual — en lugar de detenerlo en cuanto la primera semana parece limpia.

Q: ¿Cuál es lo primero y más importante que hay que revisar tras el lanzamiento?
A: Una prueba real, en producción, de checkout y pago, ya que afecta directamente a los ingresos y es el único flujo que toca todo cliente. Los problemas de redirecciones y de seguimiento también importan, pero un checkout roto es el problema más costoso de dejar sin descubrir, aunque solo sea durante unas horas.

Q: ¿Es normal que el posicionamiento baje ligeramente justo después de una migración?
A: Cierta fluctuación a corto plazo es habitual incluso en una migración bien ejecutada, ya que los buscadores necesitan tiempo para rastrear y reevaluar las nuevas URLs. Lo que no es normal es una caída sostenida o un repunte de errores de rastreo — esa es la señal para revisar tu mapa de redirecciones y tus etiquetas canonical en busca de un error real, en lugar de esperar a que se resuelva solo.

Q: ¿Quién del equipo debería encargarse del QA post-lanzamiento?
A: Idealmente alguien con visión de conjunto de toda la tienda, no solo el equipo técnico de la migración — porque varias de estas comprobaciones (que las reglas de impuestos tengan sentido, el comportamiento de las cuentas de cliente, si los números de seguimiento parecen normales) se benefician del contexto de negocio, no solo de una verificación técnica de que una función está presente.

Sources:
- Google Search Central: Site moves with URL changes: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### Limpieza de datos de producto antes de la migración

URL: https://prevedshop.com/es/guias/limpieza-de-datos-de-producto-antes-de-migrar
Language: es
Last reviewed: 2026-07-21

Una migración de plataforma copia lo que le des — no limpia nada por ti. Los SKU duplicados, las imágenes huérfanas, las categorías inconsistentes y las estructuras de variantes descuadradas que se han ido acumulando en silencio durante años se trasladarán a la nueva plataforma tal cual, a menos que alguien se ocupe de ellos antes. Hacer esa limpieza antes de la migración es mucho más barato que hacerla después, cuando los clientes y los buscadores ya dependen del resultado. Esta guía cubre qué buscar y cómo abordarlo.

#### Encuentra y resuelve SKU duplicados y productos casi duplicados

Exporta tu lista completa de productos y busca primero duplicados exactos de SKU — suelen ser un error de entrada de datos o de importación y son sencillos de fusionar una vez localizados. Después busca casi duplicados: el mismo producto recreado bajo un SKU distinto, a menudo resultado de una reimportación de un feed de proveedor que no coincidió con los registros existentes, o un producto que se recreó manualmente en lugar de editarse tras un cambio de sistema.

Para cada pareja de duplicados, decide qué registro es el "real" — normalmente el que tiene datos más completos, más historial de pedidos o mejores señales de SEO, como enlaces entrantes o reseñas — y fusiona o redirige el otro hacia él, en lugar de migrar ambos y resolverlo más tarde en la nueva plataforma.

#### Localiza imágenes y contenido multimedia huérfano

El contenido multimedia huérfano — imágenes y archivos subidos a tu biblioteca de medios que ya no referencia ningún producto, categoría o página de contenido — se acumula de forma natural a lo largo de años de actualizaciones de producto, campañas estacionales y cambios de plataforma. No aportan ningún valor en la nueva plataforma y solo aumentan el tiempo de migración y el almacenamiento, así que merece la pena identificarlos y excluirlos.

Ten cuidado también con el caso contrario: las imágenes que están referenciadas pero rotas (un archivo que falta, una URL externa muerta) merece la pena detectarlas ahora, ya que una imagen rota en una página de producto es un problema de confianza pequeño pero real, mucho más fácil de arreglar sobre tus datos actuales y conocidos que después del traslado.

#### Estandariza categorías y atributos

Años de añadidos improvisados suelen dejar categorías y atributos inconsistentes: el mismo concepto escrito o capitalizado de forma distinta según el producto, categorías que se solapan o se duplican entre sí, atributos usados para un propósito en una línea de producto y para otro distinto en otra. Esta inconsistencia normalmente no causa problemas visibles en la plataforma antigua, donde el equipo ha aprendido a convivir con ella, pero se convierte en un problema real en cuanto se mapea de forma mecánica al modelo de datos de una nueva plataforma.

Construye (o confirma) una taxonomía limpia y consensuada antes de la migración — un árbol de categorías definido y una lista de atributos definida con nomenclatura consistente — y concilia tus datos reales con ella. Este es también el momento de preguntarse qué atributos siguen siendo relevantes para los clientes o la operativa interna y cuáles existen solo porque nadie los ha eliminado.

#### Concilia los desajustes en la estructura de variantes

Las estructuras de variantes (talla, color, material y cómo se combinan en SKU concretos y vendibles) se gestionan de forma distinta en cada plataforma, y unos datos de origen inconsistentes empeoran esto. Busca productos donde las opciones de variante no sigan un patrón consistente — algunas variantes de talla llamadas "S/M/L" y otras "Small/Medium/Large" para la misma línea de producto, o productos donde existe una combinación de variante en tu sistema pero sin un precio o stock válido detrás.

Decide tu modelo de variantes objetivo antes de la migración, no durante ella. Saber de antemano si la nueva plataforma gestiona las combinaciones de variantes igual que la antigua — y dónde no lo hace — determina si tus datos de variantes actuales pueden mapearse directamente o necesitan reestructurarse antes.

#### Decide qué necesita trasladarse realmente

No todo lo que hay en tu catálogo actual merece un lugar en la nueva plataforma. Los productos descatalogados sin stock restante, las entradas de prueba o marcador de posición, y los campos heredados cuyo propósito original nadie recuerda son candidatos a quedarse atrás — con una decisión documentada, no con una omisión silenciosa. Migrar menos, de forma deliberada, suele ser mejor que migrarlo todo y resolverlo después en un sistema nuevo y poco familiar.

Para cualquier elemento que decidas no migrar pero que todavía tenga una URL indexada, asegúrate de que quede contemplado en tu plan de redirecciones (ver la guía de mapeo de redirecciones) en lugar de dejarlo dar un 404 por accidente.

#### FAQ

Q: ¿Cuánto tiempo hay que presupuestar para la limpieza de datos antes de una migración?
A: Depende en gran medida del tamaño del catálogo y de lo desordenados que estén realmente los datos — un catálogo pequeño y bien mantenido necesita mucho menos tiempo que uno con decenas de miles de SKU y años de importaciones de feeds de proveedores. Auditar los datos primero es lo que revela el alcance real; saltarse la auditoría y adivinar es lo que hace que el tiempo de limpieza se subestime.

Q: ¿Debemos limpiar los datos antes o durante el proyecto de migración?
A: Antes, o como mínimo como una fase inicial explícita con su propia revisión — no mezclada con el traslado técnico de datos. Las decisiones de limpieza (qué es un duplicado, qué se puede eliminar con seguridad, para qué servía un campo personalizado misterioso) suelen necesitar la aportación de alguien que conozca el historial del catálogo, y eso es un tipo de trabajo distinto del mapeo y el traslado técnico en sí.

Q: ¿Y si no estamos seguros de si un duplicado lo es realmente?
A: Márcalo en lugar de adivinar en un sentido u otro. Un casi duplicado con precios distintos, opciones de variante distintas o un historial de pedidos distinto podría ser un producto independiente legítimo que simplemente se parece a otro. En caso de duda, conserva ambos y revísalo cuando termine la auditoría, en lugar de fusionar por suposición.

Q: ¿Se puede hacer la limpieza de datos mientras la tienda antigua sigue activa y recibiendo pedidos?
A: Sí, para la mayor parte del trabajo de auditoría y planificación — revisar exportaciones, decidir fusiones y construir la taxonomía objetivo no requiere tocar la tienda en producción. La aplicación real de los cambios (fusionar registros, eliminar contenido multimedia huérfano) suele ser más segura sobre una copia o exportación, para después incorporar el conjunto de datos ya limpio a la migración, en lugar de editar el catálogo en producción en mitad de la auditoría.

### La checklist de replatforming en ecommerce

URL: https://prevedshop.com/es/guias/checklist-cambio-de-plataforma-ecommerce
Language: es
Last reviewed: 2026-07-21

Hacer replatforming de una tienda online es un proyecto, no un botón que se pulsa. Las plataformas implicadas importan menos de lo que la mayoría asume — lo que realmente determina si una migración va bien es si has hecho las partes menos vistosas en orden: auditar lo que tienes, mapearlo de forma deliberada, planificar tus redirecciones, probar en un entorno de pruebas y vigilar de cerca la tienda tras el cambio. Esta checklist recorre esa secuencia para que puedas aplicarla sin importar de qué plataforma sales o a cuál llegas.

#### 1. Empieza con un descubrimiento y una auditoría, no con una comparación de herramientas

Antes de comparar plataformas de destino, audita lo que realmente tienes en la actual: cuántos productos y variantes, cuántas cuentas de cliente y cuánto historial de pedidos, qué campos personalizados están en uso activo frente a restos abandonados, de qué apps o integraciones depende el escaparate, y qué URLs reciben tráfico relevante actualmente. Esta auditoría es lo que convierte "vamos a migrar" en un proyecto acotado con una lista real de lo que hay que trasladar.

Sé honesto sobre la calidad de los datos en esta fase. Si tu catálogo tiene duplicados conocidos, categorías huérfanas o atributos inconsistentes, anótalo ahora — limpiarlo más tarde es más barato antes del traslado que después, y saltarse la auditoría es cómo los equipos acaban descubriendo estos problemas a mitad de la migración.

#### 2. Mapea tu modelo de datos antes de mapear un solo campo

Cada plataforma estructura productos, variantes, categorías y datos de clientes de forma ligeramente distinta. Antes de mover cualquier dato, construye un mapeo explícito: qué campo de origen va a qué campo de destino, qué conceptos de origen (un atributo personalizado, una etiqueta, un tipo de paquete) no tienen un equivalente directo en el destino y necesitan una decisión, y qué campos se pueden eliminar por completo con seguridad porque ya nada depende de ellos.

Documenta este mapeo en algún sitio duradero — una hoja de cálculo o un documento compartido, no la memoria de alguien. Se convierte en la referencia que todo el mundo consulta durante el control de calidad, y es lo primero que querrás tener a mano si algo parece ir mal tras el lanzamiento.

#### 3. Planifica tus redirecciones y tu estructura de URLs pronto

La estructura de URLs es uno de los puntos donde una migración daña el SEO en silencio y rompe marcadores con más frecuencia. Consigue una lista completa de tus URLs actuales — páginas de producto, páginas de categoría, entradas de blog o contenido, y cualquier landing page personalizada — y decide la nueva URL de cada una antes de lanzar nada. Las páginas sin un equivalente limpio en la nueva plataforma necesitan una decisión explícita (normalmente una redirección a la categoría o página central más parecida), no un 404 silencioso.

Esta planificación se hace bien antes del cambio, idealmente en paralelo con el trabajo de mapeo de datos, ya que ambos están relacionados: cómo mapeas categorías y productos suele determinar cómo son las nuevas URLs. Consulta la guía dedicada de mapeo de redirecciones enlazada más abajo para ver el proceso completo.

#### 4. Construye un entorno de pruebas y haz un control de calidad real

Nunca trates una primera importación como la definitiva. Carga tus datos ya mapeados en una instancia de pruebas de la plataforma de destino y usa la tienda de verdad: navega por las categorías, revisa las páginas de producto, comprueba la selección de variantes y los precios, prueba el carrito y el flujo de checkout, y confirma que las cuentas de cliente y el historial de pedidos se muestran correctamente. Involucra a alguien ajeno al equipo de migración — una mirada fresca detecta cosas que quienes construyeron el mapeo ya han dejado de notar.

Trata esta fase como iterativa. Es normal encontrar problemas de mapeo en el primer intento; el objetivo es detectarlos y corregirlos aquí, en el entorno de pruebas, donde un error cuesta una reimportación, no un tramo de inactividad en producción o un error de cara al cliente.

#### 5. Planifica la ventana de cambio como una operación, no como pulsar un interruptor

Decide, por escrito, qué ocurre durante el cambio: cómo se gestionan los pedidos nuevos en la plataforma antigua si la migración lleva tiempo (una congelación temporal de pedidos, una página de mantenimiento o continuar operando hasta un punto de sincronización final definido), quién hace la sincronización final de datos, quién verifica el DNS y el SSL en la nueva plataforma, y quién tiene la autoridad para revertir o pausar si algo parece ir mal.

Dale al equipo una checklist compartida para el propio día, no solo un plan en la cabeza de alguien. Un cambio precipitado o ambiguo es donde migraciones por lo demás bien preparadas pierden datos — un puñado de pedidos realizados en el hueco entre la sincronización final y la puesta en marcha, por ejemplo — así que planifica ese hueco de forma explícita en lugar de esperar que no importe.

#### 6. Vigila después del lanzamiento: la migración no termina al ponerse en marcha

Los días y semanas tras el cambio son cuando suelen aparecer los problemas que el entorno de pruebas no detectó: una pasarela de pago mal configurada para tráfico real, una regla de impuestos o envío que se comportó de forma distinta con pedidos reales, redirecciones que funcionan para las páginas que probaste pero no para casos particulares, o un píxel de seguimiento que dejó de dispararse en silencio. Establece una rutina de monitorización deliberada en lugar de asumir que el silencio significa éxito.

Nuestra checklist de QA post-lanzamiento (enlazada más abajo) cubre esta fase en detalle — verificación de checkout y pago, revisiones puntuales de redirecciones, continuidad de la analítica y monitorización de Search Console —, ya que merece su propio proceso dedicado, no una idea de última hora una vez que la atención del equipo ya se ha desplazado a otra cosa.

#### FAQ

Q: ¿Cuánto dura un proyecto de replatforming?
A: Depende en gran medida del tamaño del catálogo, la complejidad de los datos y cuántas integraciones personalizadas hay implicadas. Un catálogo pequeño y limpio suele avanzar más rápido que uno con decenas de miles de SKU, años de campos personalizados acumulados y varias apps conectadas. Consigue una estimación realista tras una auditoría de tu tienda concreta, en lugar de fiarte de un calendario genérico.

Q: ¿Deberíamos migrar todo de golpe o por fases?
A: Ambos enfoques funcionan según la tienda. Un único cambio es más sencillo de gestionar y evita tener que operar dos plataformas en paralelo, pero concentra el riesgo en una sola ventana. Un enfoque por fases (por ejemplo, trasladar primero el contenido y el diseño, después el catálogo y luego los datos transaccionales) reparte el riesgo pero exige coordinar con más cuidado qué está "activo" y dónde en cada etapa. La elección correcta depende del tamaño de tu catálogo, tu tolerancia a una ventana de mantenimiento y lo estrechamente integrados que estén tus sistemas.

Q: ¿Cuál es la causa más habitual de los problemas de migración?
A: Saltarse o precipitar las fases de auditoría y mapeo. Los equipos que se lanzan directamente a mover datos sin entender primero lo que realmente tienen — productos duplicados, campos personalizados sin documentar, URLs de las que nadie se ha hecho cargo — tienden a descubrir esos problemas en producción, después del cambio, en lugar de en el entorno de pruebas, donde son baratos de corregir.

Q: ¿Necesitamos congelar la tienda antigua durante la migración?
A: No necesariamente durante todo el proyecto, pero sí necesitas un plan claro para la ventana de cambio final — normalmente una congelación breve o un punto de sincronización final definido — para que no se pierdan pedidos ni cambios de cliente entre la última extracción de datos y la puesta en marcha de la nueva tienda. Cuánto debe durar esa ventana depende de tu volumen de pedidos y de cómo se gestione la sincronización final.

Sources:
- Google Search Central: Site moves with URL changes: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### Mapeo de redirecciones seguro para el SEO en migraciones de ecommerce

URL: https://prevedshop.com/es/guias/mapeo-de-redirecciones-sin-perder-seo
Language: es
Last reviewed: 2026-07-21

El posicionamiento en buscadores y el tráfico orgánico son de lo más valioso que tiene una tienda consolidada, y también de lo más fácil de dañar en una migración descuidada. La buena noticia es que la continuidad de URLs es un problema resoluble y mecánico: construye un mapa de redirecciones adecuado, impleméntalo correctamente y vigila cómo responden los buscadores. Esta guía recorre ese proceso de principio a fin, sea cual sea la combinación de plataformas implicadas.

#### Construye primero un inventario completo de URLs

Antes de poder mapear nada, necesitas una lista completa de las URLs actualmente en uso — no solo las que recuerdas, sino cada página de producto, página de categoría o colección, entrada de blog o contenido, y cualquier landing page personalizada que exista en el sitio actual. Extrae esto de tu sitemap, de los informes de páginas de tu herramienta de analítica y de un rastreo del sitio en producción, y contrasta las tres fuentes entre sí, ya que cada una suele detectar algo que las otras pasan por alto.

Presta especial atención a las URLs que reciben tráfico orgánico o tienen enlaces entrantes externos, aunque sean páginas que consideres menores. Una entrada de blog con poco tráfico pero con algunos buenos enlaces entrantes merece mapearse correctamente; perderla en silencio es una pérdida pequeña pero evitable.

#### Mapea cada URL a su equivalente nuevo, y decide las excepciones de forma deliberada

Para cada URL de tu inventario, decide su destino en la nueva plataforma. La mayoría de las páginas de producto y categoría tendrán un equivalente razonablemente directo una vez que tu mapeo de datos esté cerrado. Las páginas sin un equivalente limpio (un producto descatalogado, una landing page puntual, una categoría que ya no existe) también necesitan una decisión explícita — normalmente una redirección a la categoría más parecida, a una página central relevante o, en casos poco frecuentes, un 404 deliberado y aceptado — en lugar de dejar que redirijan a la página de inicio por defecto o den un 404 por accidente.

Un enfoque de "redirigir todo a la página de inicio" es un atajo habitual que en realidad perjudica: diluye las señales de relevancia y ofrece a los usuarios una experiencia peor que llegar a la página relevante más cercana.

#### Implementa redirecciones 301 y revisa cadenas y bucles

Usa redirecciones permanentes (301) para las URLs que se han trasladado de forma definitiva — es la señal que indica a los buscadores que deben transferir las señales de posicionamiento a la nueva URL. Una vez que tus redirecciones estén activas, revisa activamente si hay cadenas de redirecciones (URL A → B → C, cuando A → C bastaría) y bucles (A → B → A), ya que ambos son subproductos habituales de ediciones iterativas del mapa de redirecciones y ambos desperdician presupuesto de rastreo y añaden latencia. El objetivo es una redirección de un solo salto desde cada URL antigua directamente a su destino final.

Prueba manualmente una muestra representativa de redirecciones tras el lanzamiento — revisa páginas con mucho tráfico, algunas con poco tráfico y algunas de las excepciones deliberadas — en lugar de asumir que el mapa es correcto solo porque se validó en una hoja de cálculo.

#### Gestiona las etiquetas canonical de forma deliberada

Las etiquetas canonical indican a los buscadores cuál es la versión autorizada cuando un contenido similar es accesible desde más de una dirección. Después de una migración, asegúrate de que la etiqueta canonical de cada página apunte a su propia URL nueva, activa y correcta — no a una URL antigua que ha quedado suelta, ni por error a la URL de otra página por culpa de una plantilla copiada y pegada. Un error aquí puede confundir a los buscadores sobre qué versión de una página indexar, incluso cuando las redirecciones en sí son correctas.

Si la nueva plataforma genera etiquetas canonical automáticamente, verifica su comportamiento por defecto en lugar de asumir que es correcto para tu configuración — la canonicalización automática a veces apunta a URLs inesperadas en páginas con parámetros o paginadas.

#### Vuelve a enviar tu sitemap XML y actualiza los enlaces internos

Una vez que el sitio nuevo esté activo con las redirecciones funcionando, genera y envía un sitemap XML actualizado que refleje la nueva estructura de URLs a través de Google Search Central y de las herramientas para webmasters de otros buscadores, para que los rastreadores puedan descubrir las páginas nuevas de forma eficiente en lugar de depender únicamente de seguir redirecciones desde las URLs antiguas.

Al mismo tiempo, actualiza los enlaces internos de todo el sitio — navegación, pie de página, enlaces de productos relacionados, contenido de blog — para que apunten directamente a las URLs nuevas en lugar de pasar por una redirección. Los enlaces internos que siguen apuntando a URLs antiguas añaden saltos de redirección innecesarios en cada clic y son fáciles de pasar por alto, ya que no rompen nada de forma visible; simplemente funcionan de forma menos eficiente.

#### Vigila el estado de rastreo e indexación tras el cambio

El trabajo de SEO de una migración no termina en el lanzamiento. En las semanas posteriores al cambio, vigila Search Console (o la herramienta equivalente de otros buscadores) por si aparecen errores de rastreo, un repunte repentino de 404, páginas que no se están indexando, o una caída de impresiones/clics en páginas que deberían funcionar con normalidad. Compáralo con tu referencia previa a la migración para detectar regresiones reales y no una fluctuación normal a corto plazo.

Ten paciencia pero no seas pasivo: parte de la reindexación lleva tiempo incluso cuando todo está bien configurado, pero un error de redirección o de canonicalización que pasa desapercibido durante semanas es mucho más caro de corregir que uno detectado en los primeros días tras el lanzamiento.

#### FAQ

Q: ¿Una migración siempre va a perjudicar mi posicionamiento?
A: No si la continuidad de URLs se gestiona bien — un mapa de redirecciones completo, etiquetas canonical correctas y un sitemap reenviado son las defensas principales. Nadie puede garantizar que se mantengan posiciones concretas, ya que el posicionamiento depende de muchos factores más allá de una sola migración, pero un mapeo de URLs adecuado es el factor controlable con más peso a la hora de conservar lo que ya tenías.

Q: ¿Debería usar redirecciones 301 o 302?
A: Usa redirecciones 301 (permanentes) para las URLs que se han trasladado de forma definitiva, que es el caso normal en una migración de plataforma. Las redirecciones 302 (temporales) indican que el traslado no es definitivo y los buscadores pueden no transferir las señales de posicionamiento de la misma manera, así que son la opción equivocada para el mapa de redirecciones de una migración ya completada.

Q: ¿Y si dos URLs antiguas deberían apuntar a la misma página nueva?
A: Eso es normal y habitual — por ejemplo, dos URLs de categoría antiguas que se fusionaron en una sola en la nueva plataforma. Redirige ambas URLs antiguas directamente a la única URL nueva. Lo que conviene evitar es el caso contrario: una URL antigua ambigua sobre a qué página nueva debería corresponder, lo que normalmente significa que la decisión de mapeo todavía no se ha tomado.

Q: ¿Cuánto tiempo debo mantener activas las redirecciones antiguas?
A: Indefinidamente, si es viable. Los enlaces entrantes, los marcadores y los resultados de búsqueda antiguos que referencian las URLs anteriores pueden persistir mucho tiempo después de una migración, y mantener viva una regla de redirección tiene un coste mínimo. Eliminar las redirecciones demasiado pronto es una forma habitual de convertir lo que debería ser un coste puntual de la migración en una fuente recurrente de enlaces rotos.

Sources:
- Google Search Central: 301 redirects: https://developers.google.com/search/docs/crawling-indexing/301-redirects
- Google Search Central: Consolidate duplicate URLs (canonicalization): https://developers.google.com/search/docs/crawling-indexing/canonicalization
- Google Search Central: Build and submit a sitemap: https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap

### Shopify vs WooCommerce: ¿a cuál deberías migrar?

URL: https://prevedshop.com/es/guias/shopify-vs-woocommerce
Language: es
Last reviewed: 2026-09-02

Shopify y WooCommerce son las dos plataformas hacia y desde las que más migramos, y la elección entre ellas rara vez tiene que ver con funciones. Shopify es un sistema alojado de modelo fijo que elimina el trabajo operativo; WooCommerce es un plugin abierto sobre WordPress que te da la base de datos y la responsabilidad. Esta comparación se centra en las diferencias que cambian de verdad una migración: modelo de datos, propiedad, estructura de costes, gestión de contenido y SEO, y luego describe qué tiendas suelen estar más contentas en cada lado.

#### Modelo de datos: fijo frente a abierto

Los productos de Shopify tienen un esquema fijo con hasta tres dimensiones de opciones y metafields para todo lo demás; las colecciones son listas manuales o por reglas, no un árbol de taxonomía. Los productos de WooCommerce son entradas de WordPress con atributos ilimitados, campos personalizados y taxonomías anidadas. Migrar a Shopify es por tanto un ejercicio de consolidación - decidir dónde vive cada campo personalizado - mientras que migrar a WooCommerce es sobre todo mapear un modelo pequeño y ordenado en uno mayor. Las tiendas con catálogos muy estructurados suelen migrar más fácilmente hacia Shopify; las tiendas con datos poco habituales pierden menos hacia WooCommerce.

#### Propiedad, hosting y coste

Shopify cobra un plan más comisiones por transacción en pasarelas ajenas y suscripciones de apps; a cambio no hay servidor, ni parches, ni alcance PCI por tu parte. WooCommerce no tiene licencia, pero pagas hosting WordPress gestionado, licencias de plugins y el tiempo de desarrollo que mantiene las actualizaciones seguras. A tres años los totales suelen estar más cerca de lo que cada bando afirma. La diferencia real es dónde está el riesgo: en Shopify la plataforma puede cambiar reglas y precios; en WooCommerce una pila de plugins descuidada puede romper la tienda.

#### Contenido y SEO

WordPress es un CMS completo, así que las tiendas WooCommerce con blogs grandes, landing pages y plantillas a medida lo mantienen todo en un solo lugar. Las páginas y el blog de Shopify son más simples, y las tiendas con mucho contenido acaban a menudo con WordPress para contenido junto a Shopify para comercio. En SEO las plataformas son equivalentes si están bien configuradas; lo que importa en una migración es el cambio de URL. Shopify impone rutas `/products/` y `/collections/`, los enlaces permanentes de WordPress son libres, así que toda migración entre ambas necesita un mapa completo de redirecciones 301. Las redirecciones reducen el riesgo; las posiciones nunca están garantizadas.

#### Qué tiendas encajan en cada plataforma

Shopify suele encajar con tiendas que quieren operaciones previsibles, venden en varios países mediante Markets, usan logística estándar y tienen un catálogo que cabe en tres dimensiones de opciones. WooCommerce suele encajar con tiendas que necesitan lógica de checkout a medida, precios B2B, estructuras de producto inusuales, integración profunda de contenido o residencia de datos estricta. Si ninguna descripción es claramente la tuya, un descubrimiento breve con muestras reales de productos y pedidos lo responde más rápido que cualquier tabla comparativa.

#### FAQ

Q: ¿Es Shopify mejor que WooCommerce para el SEO?
A: Ninguna plataforma tiene ventaja intrínseca. La visibilidad tras una migración depende del mapa de redirecciones, la paridad de contenido y la velocidad de las páginas, no del nombre de la plataforma.

Q: ¿Cuál es más barato, Shopify o WooCommerce?
A: Depende de la escala y la personalización. Shopify tiene cuotas previsibles más apps y comisiones; WooCommerce tiene hosting, licencias de plugins y tiempo de desarrollo. Compara los totales a tres años incluyendo la migración.

Q: ¿Puedo pasar de Shopify a WooCommerce y no solo al revés?
A: Sí. Migramos en ambas direcciones; la ruta de Shopify a WooCommerce está documentada aparte y consiste sobre todo en mapear metafields y reconstruir colecciones inteligentes.

Q: ¿Afecta la elección a la duración de la migración?
A: En parte. Migrar a Shopify suele tardar más con catálogos de muchos campos personalizados, porque cada uno requiere una decisión de metafield; migrar a WooCommerce tarda más cuando hay que sustituir muchas apps por plugins.

Sources:
- Shopify Help Center - Migrar a Shopify: https://help.shopify.com/en/manual/migrating-to-shopify
- WooCommerce - Importador y exportador de productos CSV: https://woocommerce.com/document/product-csv-importer-exporter/

### Glossary

### Redirección 301

URL: https://prevedshop.com/es/glosario/redireccion-301
Language: es
Last reviewed: 2026-07-21

Una redirección 301 le dice a los navegadores y a los buscadores que una página se ha trasladado de forma permanente a una URL nueva, y envía a quien pida la dirección antigua — persona o rastreador — directamente a la nueva. El "301" es el código de estado HTTP que devuelve el servidor: es la forma estándar y permanente de decir "este contenido ahora vive aquí", a diferencia de una redirección temporal (302).

#### Qué hace realmente una redirección 301

Cuando alguien solicita una URL antigua, el servidor responde con un código de estado HTTP 301 y una nueva ubicación. El navegador la sigue automáticamente, así que un visitante casi nunca lo nota — llega a la página nueva, no a un error. Los buscadores siguen la misma señal: un 301 les indica que deben transferir con el tiempo el valor de posicionamiento de la URL antigua a la nueva, en lugar de tratar la página nueva como contenido completamente distinto y sin relación.

Esto es distinto de una redirección 302 (temporal), que le dice a los rastreadores que el traslado no es definitivo y que el valor de búsqueda no debe transferirse por completo. También es distinto de actualizar manualmente los enlaces en tu propio sitio — una 301 alcanza a todo el mundo que aún tenga la URL antigua guardada en marcadores, enlazada desde otro sitio o indexada en los resultados de búsqueda, no solo a quien hace clic en enlaces que tú controlas.

#### Por qué las redirecciones 301 importan durante una migración de plataforma

Pasarte a una nueva plataforma casi siempre cambia tu estructura de URLs, incluso cuando intentas mantenerla lo más parecida posible — las URLs de producto, las rutas de categoría y las entradas de blog suelen acabar con una forma distinta a la anterior. Cada URL antigua que los buscadores tienen indexada, y que otros sitios enlazan, necesita una 301 que apunte a su equivalente nuevo, o pierdes la señal de posicionamiento acumulada de esa página y envías a los visitantes a un callejón sin salida.

El riesgo no es hipotético: lanzar una tienda nueva sin un plan de redirecciones suele traducirse en una acumulación de errores 404, enlaces entrantes rotos y una caída del tráfico orgánico en cuestión de días desde el lanzamiento, ya que los buscadores revisitan las URLs indexadas con rapidez. Un plan de redirecciones preparado antes del lanzamiento, no improvisado después de que caiga el tráfico, es lo que evita que esto ocurra.

#### Hacer bien las redirecciones, no solo tenerlas

Tener una 301 no basta por sí solo — tiene que apuntar al destino correcto. Redirigir cada URL antigua a tu nueva página de inicio técnicamente "resuelve" el enlace, pero desperdicia la relevancia específica que un buscador o un visitante esperaba encontrar. Nosotros mapeamos las URLs antiguas a su equivalente real más cercano en la nueva plataforma, y señalamos las páginas sin una correspondencia clara en lugar de adivinar.

También revisamos si hay cadenas de redirecciones (URL A a B a C) y bucles, que añaden latencia y pueden hacer que los rastreadores dejen de seguir la cadena por completo. Una migración limpia termina con un solo salto por URL, no con tres.

#### FAQ

Q: ¿Una redirección 301 es lo mismo que cambiar una URL?
A: No — cambiar una URL sin redirección simplemente rompe el enlace antiguo. Una redirección 301 es la instrucción que conecta la URL antigua con la nueva, de modo que cualquiera (persona o sistema) que solicite la dirección antigua se envía automáticamente a la página nueva.

Q: ¿Las redirecciones 301 conservan completamente mi posicionamiento?
A: Conservan la mayor parte de la señal de posicionamiento asociada a la URL antigua, pero no automáticamente todas las posiciones para todas las palabras clave — otros factores, como la calidad del sitio y la competencia, siguen aplicando. Lo que una 301 hace de forma fiable es decirle a los buscadores que el contenido se ha trasladado, en lugar de dejar que traten la nueva URL como algo sin relación.

Q: ¿Cuánto tiempo debo mantener las redirecciones activas?
A: Indefinidamente, o lo más cerca posible de eso. Los enlaces antiguos de otros sitios web, los marcadores guardados y los materiales impresos pueden seguir enviando tráfico a URLs antiguas durante años, y los buscadores pueden tardar en procesar por completo un lote grande de redirecciones.

Q: ¿Cuál es la diferencia entre una redirección 301 y una 302?
A: Una 301 indica un traslado permanente y transfiere la señal de posicionamiento a la nueva URL; una 302 indica un traslado temporal, y los buscadores son más cautos a la hora de transferir esa señal. En una migración de plataforma, donde la URL antigua no va a volver, una 301 es casi siempre la opción correcta.

Sources:
- Google Search Central: Redirects and Google Search: https://developers.google.com/search/docs/crawling-indexing/301-redirects

### Etiqueta canonical

URL: https://prevedshop.com/es/glosario/etiqueta-canonical
Language: es
Last reviewed: 2026-07-21

Una etiqueta canonical (`<link rel="canonical">`) es una etiqueta HTML que le indica a los buscadores cuál es la versión autorizada de una página cuando el mismo contenido, o uno muy parecido, se puede alcanzar desde más de una dirección. No redirige a los visitantes a ningún sitio — es una señal para los rastreadores sobre qué URL debe recibir el crédito y aparecer en los resultados de búsqueda.

#### Qué hace realmente una etiqueta canonical

Las plataformas de ecommerce sirven habitualmente el mismo producto o categoría a través de varias URLs distintas — con y sin barra final, con distintos parámetros de orden o filtro, o accesibles desde más de una ruta de categoría. Sin una etiqueta canonical, los buscadores tienen que adivinar qué versión indexar, lo que puede repartir la señal de posicionamiento entre URLs casi duplicadas en lugar de concentrarla en una sola.

La etiqueta canonical se coloca en el `<head>` de una página y apunta a la única URL que debe tratarse como copia maestra. Cada variante duplicada o casi duplicada lleva una etiqueta canonical que apunta de vuelta a esa URL; la URL maestra suele tener una etiqueta canonical que apunta a sí misma.

#### Por qué importa durante una migración de plataforma

Las plataformas nuevas suelen introducir sus propios patrones de URL para filtros, paginación u orden que no existían en la plataforma anterior, y es fácil acabar con contenido duplicado no intencionado si las etiquetas canonical no se configuran bien desde el primer día. Un error aquí no suele provocar una caída brusca como la de una redirección ausente, pero diluye silenciosamente la señal de posicionamiento entre páginas casi duplicadas en lugar de concentrarla — un problema más lento y más difícil de diagnosticar.

Las migraciones también son un momento natural para corregir problemas de canonicalización ya existentes en la plataforma anterior, en lugar de arrastrarlos sin cambios.

#### Etiquetas canonical frente a redirecciones

Una etiqueta canonical y una redirección resuelven problemas distintos. Una redirección (ver redirección 301) es para una URL que ya no existe en absoluto — envía a visitantes y rastreadores a la nueva dirección. Una etiqueta canonical es para URLs que siguen existiendo y siguen siendo accesibles, pero que no deberían competir entre sí en los resultados de búsqueda — ambas siguen activas, solo que una queda marcada como la versión de referencia.

#### FAQ

Q: ¿Una etiqueta canonical redirige a los visitantes a la URL principal?
A: No. Los visitantes pueden seguir llegando a la URL no canonical y esta carga con normalidad — la etiqueta canonical solo indica a los buscadores qué versión indexar y posicionar, no cambia lo que hace el navegador.

Q: ¿Necesito etiquetas canonical si no tengo contenido duplicado?
A: Sigue siendo una práctica habitual que cada página tenga una etiqueta canonical autorreferencial (que apunte a sí misma), lo que elimina la ambigüedad si más adelante aparece algún duplicado — por ejemplo, a través de un parámetro de seguimiento o una nueva URL de filtro.

Q: ¿Puede una etiqueta canonical apuntar a una página en otro dominio?
A: Sí, los canonicals entre dominios son válidos y a veces se usan de forma deliberada, pero en una migración de plataforma normalmente no es lo que quieres — cada URL nueva debería canonicalizar hacia sí misma, y las redirecciones (no los canonicals) son las que deben encargarse del dominio o las URLs antiguas.

Q: ¿Qué pasa si mis etiquetas canonical apuntan a la URL equivocada?
A: Los buscadores pueden acabar indexando y posicionando la versión equivocada de una página, o ignorando por completo tu señal canonical si resulta incoherente con otras señales (como los enlaces internos o el sitemap). Revisamos las etiquetas canonical como parte del control de calidad de la migración, en lugar de asumir que la nueva plataforma las configura bien por defecto.

Sources:
- Google Search Central: Consolidate duplicate URLs: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

### Migración de datos

URL: https://prevedshop.com/es/glosario/migracion-de-datos
Language: es
Last reviewed: 2026-07-21

La migración de datos es el proceso de trasladar la información de tu tienda — productos, clientes, pedidos, contenido y todo lo que está conectado a ellos — de una plataforma a otra, en una forma que la plataforma nueva pueda usar correctamente. Es el trabajo técnico central de un cambio de plataforma, distinto del diseño, la planificación de redirecciones o el trabajo de integraciones que lo rodean, aunque todos ellos dependen de que la migración de datos sea precisa.

#### Qué se migra realmente

Más allá del catálogo de productos evidente, una migración de datos completa suele cubrir las cuentas de clientes y su historial de pedidos, los pedidos existentes (abiertos e históricos), contenido como entradas de blog o páginas estáticas, reseñas si están almacenadas en la propia plataforma, y cualquier campo personalizado o metadato específico de tu negocio. No todo tiene por qué trasladarse necesariamente — parte de los datos históricos puede archivarse en lugar de migrarse de forma activa, una decisión de alcance que se toma durante la evaluación, no algo que se dé por hecho de partida.

#### Por qué una simple exportación/importación no basta

Dos plataformas rara vez modelan los datos de forma idéntica — la lista plana de productos de una plataforma puede ser el sistema jerárquico de categorías y atributos de otra; el registro sencillo de cliente de una plataforma puede necesitar dividirse en varios tipos de objeto en la nueva. Una copia literal campo a campo desde un archivo de exportación suele producir datos técnicamente presentes pero estructuralmente incorrectos — relaciones de variantes rotas, campos personalizados perdidos o registros de clientes que no enlazan correctamente con su historial de pedidos. Una migración de datos real significa mapear cada tipo de dato de forma deliberada, no solo mover archivos.

#### Cómo lo abordamos

Empezamos con una auditoría de datos — entender qué existe realmente en el sistema antiguo, incluidas las inconsistencias acumuladas con el tiempo (clientes duplicados, registros huérfanos, categorización incoherente) — antes de decidir cómo se traslada a la nueva plataforma. La limpieza suele producirse como parte de este paso y no después, ya que migrar datos incorrectos fielmente solo reproduce los mismos problemas en la nueva plataforma. Consulta Limpieza y mapeo de datos para ver cómo encaja esto dentro de una migración gestionada.

#### FAQ

Q: ¿La migración de datos incluye mi historial de pedidos?
A: Puede incluirlo — si los pedidos históricos se migran de forma activa a la nueva plataforma o se archivan por separado es una decisión de alcance, ya que no todas las plataformas ni todos los negocios necesitan un historial de pedidos activo en el sistema nuevo. Lo tratamos durante la evaluación.

Q: ¿Mis campos personalizados se transferirán automáticamente?
A: No de forma automática — los campos personalizados necesitan un equivalente explícito en la nueva plataforma (a menudo metafields o atributos personalizados), y ese mapeo hay que definirlo, no dar por hecho que existe por defecto.

Q: ¿Puedo migrar los datos yo mismo con un plugin o una herramienta de importación?
A: Para catálogos pequeños y sencillos puede funcionar. Para tiendas con personalización relevante, historial de pedidos o problemas de calidad de datos, una herramienta de importación genérica normalmente no puede tomar las decisiones que requiere una auditoría y un mapeo de datos adecuados — simplemente mueve lo que hay en el archivo, errores incluidos.

Q: ¿Cómo evitáis la pérdida de datos durante la migración?
A: Auditando y mapeando antes de mover nada, probando la migración primero en un entorno de pruebas, y verificando los recuentos de registros y revisando los datos puntualmente después del traslado, en lugar de asumir que la importación se ejecutó correctamente.

### Comercio headless

URL: https://prevedshop.com/es/glosario/headless-commerce
Language: es
Last reviewed: 2026-07-21

El comercio headless es una arquitectura en la que el escaparate (lo que ven y con lo que interactúan los clientes) se construye por separado del backend de comercio (catálogo de productos, carrito, checkout, gestión de pedidos), y ambos se comunican mediante una API en lugar de formar un único sistema fuertemente acoplado. "Headless" se refiere a que el escaparate — la capa de presentación — está desacoplado del backend, que puede entonces servir varias "cabezas" distintas (un sitio web, una app móvil, un quiosco en tienda física) desde una sola fuente de verdad.

#### Headless frente a plataformas tradicionales (monolíticas)

Una plataforma de ecommerce tradicional integra las plantillas del escaparate y el backend en un mismo paquete — los temas Liquid de Shopify o las plantillas de WordPress de WooCommerce son ejemplos de un escaparate generado directamente por la propia plataforma. En una configuración headless, el escaparate es una aplicación independiente (a menudo construida con un framework como Next.js u otro similar) que obtiene los datos de la API de la plataforma backend, en lugar de que la plataforma renderice las páginas directamente. Algunas plataformas (Shopify, commercetools, entre otras) admiten tanto un modo tradicional como uno headless.

#### Por qué cambia una migración

Migrar hacia o desde una configuración headless es un tipo de proyecto distinto al de migrar entre dos plataformas tradicionales. Trasladar una tienda de plataforma tradicional a una arquitectura headless suele implicar construir un escaparate nuevo desde cero (no adaptar un tema existente), mientras que la migración del backend/catálogo sigue los mismos principios de mapeo de datos que cualquier otro traslado. Migrar entre dos backends headless suele estar más contenido en el lado del escaparate, ya que a veces el frontend puede simplemente actualizarse para apuntar a una nueva API en lugar de reconstruirse por completo — pero el catálogo, los pedidos y los datos de clientes del backend siguen necesitando el mismo mapeo cuidadoso que cualquier migración.

#### Cuándo headless es (y cuándo no es) la decisión correcta

Las arquitecturas headless en general cambian más esfuerzo de implementación e ingeniería continua por más flexibilidad en la experiencia del escaparate — interacciones a medida, canales que no son un sitio web (apps, quioscos) o requisitos de rendimiento que un escaparate basado en plantillas no puede cumplir. Para una tienda sin esa necesidad concreta, una plataforma tradicional suele ser más sencilla de operar y de migrar. Es una decisión que conviene tomar de forma deliberada durante la evaluación, sin decantarse por defecto hacia ninguna de las dos opciones.

#### FAQ

Q: ¿El comercio headless es siempre más rápido que un escaparate tradicional?
A: No de forma automática — el rendimiento depende de cómo se construya el escaparate headless, no solo de la elección de arquitectura. Un frontend headless mal construido puede ser más lento que un tema tradicional bien optimizado.

Q: ¿Necesito desarrolladores a medida para llevar una tienda headless?
A: En general sí, de forma continuada — un escaparate headless no viene con el editor de temas ni las opciones de personalización vía tienda de apps que ofrece una plataforma tradicional, así que los cambios suelen pasar por desarrollo a medida en lugar de un editor visual.

Q: ¿Puedo migrar de una plataforma tradicional a headless sin perder SEO?
A: Sí, pero requiere la misma planificación de redirecciones y estructura de URLs que cualquier migración, además de una atención específica a cómo el nuevo frontend headless renderiza el contenido para los buscadores (aquí importa el renderizado en servidor) — no es automático solo porque los datos del backend se conserven.

Q: ¿Qué plataformas admiten comercio headless?
A: Varias plataformas importantes ofrecen un modo headless o API-first junto a su escaparate tradicional, o en lugar de él — la elección correcta depende de tus necesidades concretas de backend, que ayudamos a evaluar en lugar de decantarnos por defecto por la plataforma de moda.

### Hreflang

URL: https://prevedshop.com/es/glosario/hreflang
Language: es
Last reviewed: 2026-07-21

Hreflang es un atributo HTML (y su cabecera HTTP o entrada de sitemap equivalente) que indica a los buscadores para qué idioma y, opcionalmente, para qué país está escrita una página, y apunta a la página equivalente en otros idiomas o regiones. Es la forma en que un sitio multilingüe le dice a Google "aquí está la versión en español, aquí está la versión en alemán" en lugar de dejar que los buscadores lo adivinen.

#### Qué hace realmente hreflang

Una página con marcado hreflang enumera un conjunto de URLs alternativas, cada una etiquetada con un código de idioma (y opcionalmente una región, como `es` frente a `es-MX`) más una entrada especial `x-default` para los visitantes que no coinciden con ningún idioma listado. Los buscadores usan esto para servir la versión de idioma correcta a cada persona que busca, y para evitar tratar tus páginas traducidas como contenido duplicado entre sí.

Cada página del conjunto necesita referenciar a todas las demás páginas del conjunto, incluida ella misma — una fuente habitual de errores es un enlace en una sola dirección (la página A apunta a la página B, pero B no apunta de vuelta a A).

#### Por qué importa durante una migración de plataforma

Si tu tienda opera en varios idiomas, una migración es precisamente el momento en el que hreflang tiende a romperse — la estructura de URLs cambia según el idioma, y es fácil que el mecanismo de cambio de idioma de la nueva plataforma no conecte automáticamente conjuntos hreflang correctos para cada ruta, especialmente las rutas que todavía no tienen una traducción publicada. Una configuración de hreflang incompleta o incoherente puede hacer que la versión de idioma equivocada se posicione en el país equivocado, o diluir la señal de posicionamiento entre páginas localizadas casi duplicadas.

Hreflang debe verificarse para cada patrón de URL de la nueva arquitectura de información, no solo la página de inicio — las páginas de producto, las páginas de categoría y cualquier página de contenido lo necesitan si son multilingües.

#### Errores habituales

Los problemas más frecuentes son los enlaces de vuelta ausentes (A enlaza a B, B no enlaza de vuelta), apuntar hreflang a una URL que devuelve una redirección o un 404 en lugar de la página activa, y usar el formato incorrecto de código de idioma o región. Ninguno de estos suele provocar una penalización directa, pero sí implica que los buscadores pueden no respetar la señal en absoluto, lo que anula el propósito de haberla añadido.

#### FAQ

Q: ¿Hreflang es lo mismo que un selector de idioma en mi sitio?
A: No — un selector de idioma es un elemento de interfaz para los visitantes; hreflang es una señal para los buscadores, normalmente invisible para los visitantes, que vive en el head HTML de la página, en una cabecera HTTP o en el sitemap. Un sitio puede tener uno sin el otro, aunque lo habitual es tener ambos.

Q: ¿Necesito una entrada x-default?
A: Se recomienda si tienes una página de reserva para los visitantes cuyo idioma o región no coincide con ninguna de tus versiones específicas — normalmente apunta a tu página en el idioma por defecto.

Q: ¿Hreflang afecta directamente a mi posicionamiento?
A: No actúa como un impulso de posicionamiento — afecta a qué páginas tuyas aparecen para quienes buscan en un idioma o región determinados, y ayuda a evitar que tus páginas traducidas se traten como duplicados no deseados entre sí.

Q: ¿Se puede configurar hreflang en el sitemap en lugar de en la página?
A: Sí, ambas opciones son válidas según la documentación de los buscadores — algunos sitios prefieren hreflang basado en sitemap porque es más fácil de generar y validar de forma automática para un gran número de URLs, que es el enfoque que solemos usar en sitios migrados.

Sources:
- Google Search Central: Tell Google about localized versions of your page: https://developers.google.com/search/docs/specialty/international/localized-versions

### Feed de productos

URL: https://prevedshop.com/es/glosario/feed-de-productos
Language: es
Last reviewed: 2026-07-21

Un feed de productos es una exportación estructurada de tu catálogo — normalmente en CSV, XML o JSON — pensada para que otro sistema la lea de forma periódica: un proveedor que te envía su catálogo, o tu tienda que envía el suyo a un marketplace, un comparador de precios o una plataforma publicitaria (como un feed de Google Shopping). Cada feed sigue un formato concreto que el sistema receptor espera: ciertos campos, en una estructura determinada, a veces con sus propios identificadores obligatorios.

#### Feeds entrantes frente a salientes

Un feed entrante llega de un proveedor o distribuidor hacia tu tienda — nuevos niveles de stock, precios y datos de producto que tu plataforma necesita ingerir de forma periódica. Un feed saliente va en la dirección contraria — el catálogo de tu tienda formateado para que lo consuma un marketplace, un comparador de compras o una plataforma publicitaria. Una migración suele afectar a ambos: tu nueva plataforma necesita seguir recibiendo los feeds de proveedores en el formato en que ya los envían, y necesita producir feeds salientes en el formato que cada destino espera, que no siempre coincide con el que producía tu plataforma anterior.

#### Por qué los feeds se rompen durante una migración

Los formatos de feed rara vez son un estándar universal — el feed de un proveedor puede usar nombres de campo, códigos de categoría o identificadores que la integración de tu plataforma anterior estaba construida a medida para interpretar. Pasarte a una nueva plataforma significa que esa lógica de interpretación hay que reconstruirla, no dar por hecho que se traslada sola, aunque el propio archivo del feed no cambie. Lo mismo ocurre a la inversa: un feed saliente del que depende tu marketplace o tu cuenta publicitaria necesita seguir coincidiendo con el formato exigido por ese canal después del traslado, o el canal puede rechazarlo o interpretarlo mal.

#### Qué revisa una migración gestionada

Mapeamos cada feed entrante y saliente activo durante la evaluación — en qué formato está, a qué campos se corresponde y con qué frecuencia se ejecuta — para que nada se rompa de forma silenciosa después del cambio. Un feed de proveedor que deja de interpretarse correctamente no suele lanzar un error; simplemente deja de actualizar el stock o los precios en silencio, lo cual es peor que un fallo evidente porque puede pasar desapercibido durante un tiempo.

#### FAQ

Q: ¿El feed de mi proveedor funcionará automáticamente en mi nueva plataforma?
A: No de forma automática — la nueva plataforma necesita una integración construida (o reutilizada, si existe un conector compatible) para interpretar el formato de ese feed en concreto. Evaluamos cada feed de proveedor de forma individual durante la evaluación, en lugar de asumir que una importación genérica lo va a resolver.

Q: ¿Qué pasa con mi feed de Google Shopping o de marketplace durante una migración?
A: Necesita seguir coincidiendo con el formato exigido por el destino después del traslado. Revisamos los feeds salientes como parte del plan de migración para que un canal no rechace tu catálogo ni muestre datos desactualizados después del cambio.

Q: ¿Un feed de productos es lo mismo que una exportación CSV?
A: Una exportación CSV puede ser un feed de productos, pero "feed" suele implicar un intercambio recurrente y automatizado según un calendario, no una exportación manual puntual — aunque el formato del archivo subyacente puede ser idéntico.

Q: ¿Pueden dos sistemas usar formatos de feed completamente distintos para los mismos datos?
A: Sí, es habitual — los mismos datos de catálogo pueden exportarse como una estructura XML para un marketplace y una estructura CSV distinta para otro, o usar nombres de campo y taxonomías de categoría totalmente diferentes, lo que exige un mapeo independiente para cada uno.

### Replatforming

URL: https://prevedshop.com/es/glosario/replatforming
Language: es
Last reviewed: 2026-07-21

Replatforming significa trasladar una tienda de ecommerce de una plataforma a otra — no es un rediseño en la misma plataforma, ni una actualización menor de versión, sino un cambio real del sistema subyacente que hace funcionar tu tienda. Es el término general para todo el proyecto: la migración de datos, la planificación de redirecciones, la reconstrucción del tema o escaparate y la reconexión de integraciones son todas piezas de un proyecto de replatforming.

#### Qué cuenta como replatforming (y qué no)

Pasar de Magento a Shopify es replatforming. Actualizar de Magento 1 a Magento 2 puede considerarse también replatforming, ya que los sistemas subyacentes son lo bastante distintos como para requerir una migración real, no solo una actualización. Un rediseño de tema en la misma plataforma, o añadir una nueva app o plugin, no es replatforming — el sistema subyacente y tu modelo de datos siguen siendo los mismos.

#### Motivos habituales para hacer replatforming

El desencadenante suele ser uno o varios de estos: la plataforma actual no puede dar soporte a una función o escalar lo que el negocio necesita, el coste continuo de mantener una plataforma autoalojada (hosting, parches de seguridad, cumplimiento PCI) deja de tener sentido, la plataforma está llegando al final de su vida útil o pierde el soporte del proveedor, o el negocio ha superado lo que puede ofrecer un escaparate basado en plantillas. Casi nunca es un único motivo — suele ser una acumulación de fricciones que acaba pesando más que el coste y el riesgo de trasladarse.

#### Por qué el replatforming se trata como un proyecto, no como una tarea

La parte más arriesgada del replatforming no es elegir la nueva plataforma — es todo lo que tiene que trasladarse correctamente para que el negocio no pierda datos, posicionamiento SEO o continuidad operativa: el catálogo, los registros de clientes, el historial de pedidos, la estructura de URLs y sus redirecciones, los feeds de proveedores y cualquier lógica personalizada que ejecutaba la plataforma anterior. Tratarlo como una simple tarea de importación en lugar de como un proyecto planificado es de donde viene la mayor parte del riesgo real en una migración.

#### FAQ

Q: ¿Cuánto suele durar un replatforming?
A: Depende en gran medida del tamaño del catálogo, la complejidad de los datos, cuántas integraciones existen y cuánta funcionalidad personalizada hay que reconstruir — no hay un calendario universal. Damos una estimación realista después de evaluar la tienda concreta, no una cifra genérica.

Q: ¿Necesito hacer replatforming si solo quiero un nuevo diseño?
A: No — un rediseño en tu plataforma actual suele ser más sencillo y de menor riesgo que un replatforming, y no requiere migrar datos ni reconstruir integraciones. El replatforming tiene sentido cuando la limitación es la propia plataforma, no solo su apariencia.

Q: ¿Cuál es el mayor riesgo en un proyecto de replatforming?
A: Perder posicionamiento SEO por redirecciones rotas, y problemas de calidad de datos (relaciones de variantes rotas, registros de clientes perdidos, historial de pedidos descuadrado) por una migración de datos incompleta o poco cuidada — ambos son evitables con una buena planificación, y ambos son habituales cuando no se planifican.

Q: ¿Puedo hacer replatforming sin tiempo de inactividad?
A: El tiempo de inactividad puede minimizarse con una planificación cuidadosa del cambio (entorno de pruebas, momento del cambio de DNS/tráfico, sincronización final de datos), pero prometer cero tiempo de inactividad como garantía no es algo que estemos dispuestos a asegurar sin conocer tu configuración concreta — consulta nuestra página de Seguridad para ver cómo abordamos esta conversación con honestidad.

### Mapeo de SKU

URL: https://prevedshop.com/es/glosario/mapeo-de-sku
Language: es
Last reviewed: 2026-07-21

El mapeo de SKU es el proceso de hacer coincidir cada identificador de producto (SKU, stock keeping unit) de tu sistema antiguo con su equivalente correcto en el nuevo, de modo que los pedidos, el inventario y los feeds de proveedores sigan refiriéndose al mismo producto físico antes y después de una migración. Suena mecánico, pero es uno de los puntos donde una migración falla con más frecuencia cuando se automatiza a ciegas en lugar de revisarse.

#### Por qué los SKU no siempre se trasladan de forma limpia

En una migración ideal, cada SKU de la plataforma antigua se corresponde 1:1 con el mismo SKU en la nueva y nada cambia. En la práctica, las plataformas suelen tener reglas distintas sobre qué puede contener un SKU, un tratamiento distinto de los SKU a nivel de variante frente a los de nivel de producto, o un historial de SKU duplicados o reutilizados en el sistema antiguo que hay que resolver en lugar de trasladar tal cual. Una exportación directa de base de datos puede arrastrar estas inconsistencias en lugar de corregirlas.

#### Dónde conecta el mapeo de SKU con otros sistemas

Tu SKU suele ser la clave de unión entre tu tienda y todo lo que la rodea — feeds de proveedores, un sistema de almacén o logística, software de contabilidad, listados de marketplace. Si un SKU cambia de formato o de valor durante una migración sin actualizar cada sistema conectado, esas integraciones empiezan a fallar a la hora de identificar productos aunque la tienda en sí parezca correcta. El mapeo tiene que hacerse teniendo en cuenta esos sistemas posteriores, no solo dentro de la nueva plataforma.

#### Qué revisamos antes de migrar los SKU

Auditamos el conjunto de SKU existente en busca de duplicados, formatos inconsistentes y SKU huérfanos (referenciados por un pedido o un feed pero sin un producto activo) antes de decidir si conservarlos tal cual o normalizarlos en la nueva plataforma. Conservar los SKU existentes suele ser preferible cuando otros sistemas dependen de ellos; normalizarlos tiene sentido cuando el propio esquema de SKU antiguo era el problema.

#### FAQ

Q: ¿Debo mantener exactamente los mismos SKU en la nueva plataforma?
A: Normalmente sí, si algún feed de proveedor, sistema de logística o listado de marketplace depende de ellos — cambiar los SKU rompe esas integraciones a menos que se actualicen al mismo tiempo. Evaluamos esto caso por caso en lugar de decantarnos por defecto por una opción.

Q: ¿Qué pasa con los SKU duplicados durante una migración?
A: Hay que resolverlos antes o durante la migración, no arrastrarlos — la mayoría de las plataformas no permiten SKU verdaderamente duplicados, y dejar que una importación automatizada adivine cómo desduplicarlos supone el riesgo de fusionar o eliminar el producto equivocado.

Q: ¿El mapeo de SKU afecta a mi historial de pedidos?
A: Puede afectarlo, si los pedidos históricos hacen referencia a SKU que cambian — tenemos esto en cuenta para que los registros de pedidos pasados sigan resolviendo hacia el producto correcto después del traslado, en lugar de mapear solo el catálogo activo.

Q: ¿El mapeo de SKU es automático o manual?
A: Es una combinación — las coincidencias directas 1:1 pueden automatizarse y verificarse rápidamente, pero los casos ambiguos (duplicados, formatos inconsistentes, SKU faltantes) necesitan una decisión humana en lugar de un algoritmo de mejor conjetura.

### Datos estructurados

URL: https://prevedshop.com/es/glosario/datos-estructurados
Language: es
Last reviewed: 2026-07-21

Los datos estructurados son un marcado que se añade a una página (normalmente siguiendo el vocabulario schema.org, en formato JSON-LD) y que describe su contenido de forma legible por máquinas — marcar una página como un Product con un precio y una disponibilidad, o como una Organization con un nombre y una URL, en lugar de dejar que los buscadores lo deduzcan a partir del texto visible. Es lo que permite que los resultados de búsqueda muestren funciones enriquecidas, como valoraciones con estrellas, precio o desplegables de preguntas frecuentes, directamente en los resultados.

#### Qué permite realmente los datos estructurados

Los buscadores suelen entender razonablemente bien el contenido normal de una página, pero los datos estructurados eliminan la ambigüedad y desbloquean funciones de presentación concretas — resultados enriquecidos de producto con precio, disponibilidad y valoración, acordeones de preguntas frecuentes mostrados directamente en los resultados de búsqueda, rutas de navegación (breadcrumbs) en el fragmento del resultado, y más. Nada de esto está garantizado (los buscadores deciden cuándo usarlo), pero sin el marcado, esas funciones normalmente no están disponibles en absoluto.

#### Por qué necesita atención durante una migración

Los datos estructurados no son algo que todas las plataformas generen automáticamente, y las plataformas que sí lo hacen no lo hacen todas de forma idéntica — el schema de producto, el de preguntas frecuentes y el de breadcrumbs tienen que reflejar lo que realmente hay en la página. Una migración es un punto habitual en el que los datos estructurados o bien se pierden por completo (el nuevo tema o plantilla no los incluye) o se vuelven inexactos (marcado que ya no coincide con el contenido visible de la página, algo que los buscadores pueden penalizar en lugar de premiar).

#### Marca solo lo que sea realmente cierto

La regla más importante con los datos estructurados es que deben describir algo real y visible en la página — marcado FAQPage solo donde realmente se muestran preguntas frecuentes, marcado Review/rating solo para reseñas que realmente existen, marcado Product con un precio y una disponibilidad reales. Un marcado que no coincide con la página visible incumple las propias directrices de los buscadores y puede hacer que los datos estructurados se ignoren o que la página se penalice, no solo que "no ayude".

#### FAQ

Q: ¿Los datos estructurados garantizan resultados enriquecidos en la búsqueda?
A: No — hacen posibles los resultados enriquecidos, pero los buscadores deciden de forma independiente si mostrarlos, según la relevancia y sus propios controles de calidad. No hay forma de garantizar que aparezca un resultado enriquecido concreto.

Q: ¿Mi nueva plataforma añadirá datos estructurados automáticamente?
A: Algunas plataformas generan datos estructurados básicos (como el marcado Product) por defecto; otras necesitan añadirlos explícitamente mediante un tema o una app. Comprobamos qué ofrece la nueva plataforma de serie y completamos lo que falte, en lugar de asumir que ya está resuelto.

Q: ¿Añadir datos estructurados puede perjudicar mi SEO?
A: Solo si son inexactos o manipuladores — un marcado que no coincide con el contenido real de la página incumple las directrices de los buscadores. Unos datos estructurados precisos que reflejan el contenido real de la página no tienen ese riesgo.

Q: ¿Cuál es el error más habitual con los datos estructurados en una migración?
A: Perderlos por completo cuando el nuevo tema o plantilla no traslada lo que tenía la plataforma anterior, o dejar activo un marcado desactualizado que ya no coincide con la página rediseñada — ambos son aspectos que revisamos en el control de calidad de la migración.

Sources:
- Google Search Central: Understand how structured data works: https://developers.google.com/search/docs/appearance/structured-data/sd-policies

### Slug de URL

URL: https://prevedshop.com/es/glosario/url-slug
Language: es
Last reviewed: 2026-07-21

Un slug de URL es la parte legible de la dirección de una página que la identifica — en `prevedshop.com/platforms/shopify`, `shopify` es el slug. Normalmente se deriva del nombre de un producto o página, se pone en minúsculas y se adapta para ser seguro en una URL, y es lo que tanto los visitantes como los buscadores realmente ven y referencian cuando enlazan o guardan en marcadores una página.

#### Por qué los slugs importan más allá de la legibilidad

Un slug claro y descriptivo ayuda a los visitantes a entender de qué trata una página antes de hacer clic, y los buscadores sí dan cierto peso a las palabras relevantes que aparecen en la URL. Pero la importancia mayor de un slug es estructural: forma parte de la dirección permanente de la página, referenciada por cada enlace interno y externo, cada marcador guardado y cada resultado de búsqueda indexado que apunta a ella.

#### Por qué las migraciones suelen cambiar los slugs, a propósito o no

Cada plataforma tiene sus propias reglas sobre cómo se generan y estructuran los slugs — límites de longitud, caracteres permitidos, si los slugs de producto van anidados bajo una ruta de categoría o son planos, cómo se distinguen los nombres duplicados. Pasarte a una nueva plataforma cambia con frecuencia al menos algunos slugs, a veces porque la nueva plataforma impone un patrón distinto, a veces porque es una oportunidad para corregir slugs heredados y desordenados del sistema anterior. En cualquier caso, un slug cambiado significa una URL cambiada, y una URL cambiada necesita una redirección (ver redirección 301) desde la dirección antigua.

#### Mantener los slugs estables donde importa

Para páginas con un posicionamiento existente relevante o muchos enlaces entrantes, mantener exactamente el mismo slug en la nueva plataforma (cuando esta lo permite) evita por completo la necesidad de una redirección y suele ser la forma más sencilla de conservar la posición de esa página. Cuando un slug sí necesita cambiar, planificar el nuevo slug y su redirección de forma conjunta — en lugar de dejar que la plataforma genere uno automáticamente y tratar la URL como algo secundario — es lo que mantiene limpia la transición.

#### FAQ

Q: ¿Puedo mantener exactamente mis antiguos slugs de URL en una nueva plataforma?
A: A menudo sí, si las reglas de URL de la nueva plataforma lo permiten y los defines de forma deliberada en lugar de aceptar los generados automáticamente — es una de las formas más sencillas de evitar por completo la necesidad de una redirección para esa página.

Q: ¿Cambiar un slug perjudica el SEO?
A: No si va acompañado de una redirección 301 adecuada del slug antiguo al nuevo — la redirección transfiere la mayor parte de la señal de posicionamiento acumulada. Cambiar un slug sin redirección es lo que causa daño al SEO, no el cambio de slug en sí.

Q: ¿Debo usar el nombre de mi producto exactamente como slug?
A: Por lo general sí, simplificado para que sea seguro en una URL (minúsculas, guiones en lugar de espacios, sin caracteres especiales) — los slugs rellenos de palabras clave sin relación con el tema real de la página no aportan ningún beneficio extra y se perciben como spam tanto para los visitantes como para los buscadores.

Q: ¿Qué pasa si dos productos generarían el mismo slug?
A: La plataforma necesita una regla de desambiguación — normalmente añadiendo un número u otro identificador adicional. Revisamos esto durante la migración, ya que las colisiones de slugs duplicados pueden hacer que la página de un producto sobrescriba en silencio la URL de otro.

### Services

### Migración y mapeo de datos ecommerce

URL: https://prevedshop.com/es/servicios/limpieza-y-mapeo-de-datos
Language: es
Last reviewed: 2026-07-20

Los catálogos antiguos acumulan productos duplicados, categorías inconsistentes y campos cuyo propósito ya nadie recuerda. Limpiamos eso y mapeamos lo que queda al modelo de datos real de tu nueva plataforma, en lugar de copiar el desorden tal cual.

#### Qué buscamos

Productos duplicados o casi duplicados, categorías huérfanas, nomenclatura de atributos inconsistente, campos vacíos o mal formados, y campos personalizados heredados que ya no corresponden a nada. Te señalamos lo que encontramos y acordamos contigo qué corregir, fusionar o eliminar.

#### Mapeo, no suposiciones

Cada campo de origen recibe un mapeo explícito a un campo de destino, o una decisión explícita de que no se mapea y necesita otro lugar (un campo personalizado, una etiqueta, o ninguno). Documentamos este mapeo para que sea auditable, no una caja negra.

#### Por qué importa antes del lanzamiento

Limpiar y mapear datos antes de la migración es mucho más barato que corregirlos después del lanzamiento, cuando clientes y buscadores ya dependen de ellos. Saltarse este paso es una de las causas más comunes de problemas posteriores en una migración.

#### FAQ

Q: ¿Vais a borrar datos sin preguntarme?
A: No — señalamos lo que parece un problema y acordamos contigo la acción antes de fusionar o eliminar nada.

Q: ¿Podéis deduplicar productos de varias importaciones antiguas?
A: Sí, es una de las solicitudes de limpieza más habituales — las tiendas antiguas que pasaron por varias importaciones de feeds de proveedores a lo largo de los años suelen tener duplicados reales.

Q: ¿Trabajáis con campos personalizados sin un propósito claro?
A: Investigamos para qué se usaba probablemente un campo (según los patrones de datos y, si es posible, tu opinión) antes de decidir si mapearlo, reutilizarlo o retirarlo.

### Cambio de plataforma ecommerce, de la decisión al lanzamiento

URL: https://prevedshop.com/es/servicios/cambio-de-plataforma-ecommerce
Language: es
Last reviewed: 2026-09-25

Cambiar de plataforma (replatforming) es primero una decisión de negocio y después una migración de datos. Sustituyes el sistema que mueve tu catálogo, el checkout, las integraciones y el tráfico orgánico, normalmente porque el actual se ha vuelto caro, limitante o arriesgado. Te ayudamos a decidir con datos y después planificamos y ejecutamos el cambio para que la nueva plataforma arranque con sus datos, URLs e integraciones.

#### Cuándo compensa cambiar de plataforma y cuándo no

Motivos sólidos: la plataforma ha llegado al fin de su vida útil o ya no recibe actualizaciones de seguridad (Magento 1, Shopware 5); el hosting, los parches y el mantenimiento de módulos cuestan más de lo que la tienda justifica; la plataforma bloquea algo que el negocio necesita, como nuevos mercados, precios B2B, un frontend headless o un checkout moderno; o el equipo dedica su tiempo a mantener la plataforma en lugar de vender.

Motivos débiles: una plantilla anticuada, una única función que resolvería una app o una demo comercial. Un rediseño o una integración concreta suele salir más barato, y te lo diremos.

#### Primero requisitos, después plataforma

Partimos de lo que la tienda hace de verdad: estructura del catálogo y tipos de producto, reglas de precios y grupos de clientes, mercados, idiomas y monedas, integraciones con ERP, almacén y transportistas, marketplaces y feeds, contenido y SEO, y funciones a medida. Cada requisito se marca como imprescindible, sustituible o prescindible, y con esa lista comparamos las plataformas candidatas.

#### Qué se rompe en un cambio de plataforma

El modelo de datos rara vez coincide: atributos, variantes, packs y árboles de categorías se comportan distinto en el destino. Cambia la estructura de URLs, así que cada URL relevante necesita un destino y una redirección 301. Los módulos y apps no se trasladan; sus datos y funciones necesitan sustituto, reconstrucción o retirada. Las integraciones con ERP, contabilidad, transportistas y marketplaces hay que reconectarlas y probarlas. Las contraseñas de clientes normalmente no pueden pasar a una plataforma alojada.

#### Coste total, no solo la licencia

Compara el cuadro completo a varios años: suscripción o licencia, hosting y seguridad, comisiones de pago, apps y módulos, desarrollo, la propia migración y el tiempo interno de operación. Te ayudamos a construir esa comparación a partir de tus requisitos; no vendemos licencias.

#### De la decisión al lanzamiento

Elegido el destino, el cambio se convierte en una migración gestionada: auditoría de origen, mapeo de datos, migración de prueba y aprobación, plan SEO y de redirecciones, cambio de integraciones, congelación de contenido, migración delta, lanzamiento y control posterior. Las tiendas grandes suelen migrar por fases para verificar cada paso.

#### FAQ

Q: ¿Qué diferencia hay entre cambio de plataforma y migración?
A: El cambio de plataforma es la decisión y el proyecto de llevar el negocio a un nuevo sistema ecommerce. La migración es la parte que traslada datos, URLs y contenido.

Q: ¿Cuánto tarda un cambio de plataforma?
A: Depende del catálogo, las integraciones, el diseño y la rapidez de las decisiones. Damos un calendario tras la evaluación.

Q: ¿Shopify, PrestaShop, WooCommerce o quedarnos?
A: Depende de tus requisitos, mercados, integraciones y presupuesto. Quedarse es un resultado legítimo.

Q: ¿Se puede cambiar de plataforma sin perder SEO?
A: No se pueden garantizar posiciones. El riesgo baja con un inventario completo de URLs, redirecciones 301, metadatos trasladados, enlaces internos actualizados y seguimiento tras el lanzamiento.

### Migración ecommerce gestionada: un responsable de la auditoría al lanzamiento

URL: https://prevedshop.com/es/servicios/migracion-gestionada
Language: es
Last reviewed: 2026-07-20

Un responsable de migración designado planifica, ejecuta y valida tu traslado: productos, variantes, clientes, pedidos, contenido multimedia, contenido y el diseño de tu tienda, gestionados como un único proyecto coordinado, no como exportaciones sueltas.

#### Qué incluye

La Migración Gestionada cubre todo tu catálogo — productos, variantes, categorías y atributos —, cuentas de clientes e historial de pedidos, contenido multimedia y contenido, campos personalizados, y un plan de URLs/redirecciones. El diseño de la tienda se traslada o se reconstruye en la plataforma destino como parte del mismo proyecto, no como una sorpresa facturada aparte.

Definimos exactamente qué entra y qué no durante la evaluación, para que no tengas que adivinar qué incluye la "migración" hasta que llegue la factura.

#### Cómo funciona la transferencia de diseño

Cuando la plataforma destino puede reproducir razonablemente tu diseño actual, lo reconstruimos allí. Cuando las plataformas son demasiado distintas para una transferencia idéntica, te lo decimos de antemano y proponemos un enfoque — adaptar tu diseño a las limitaciones de la nueva plataforma, en lugar de fingir que es una copia directa.

#### Un responsable, de principio a fin

Un responsable de migración designado responde por todo el proyecto: evaluación, mapeo, migración de prueba, validación, lanzamiento y revisión post-lanzamiento. Las comprobaciones automatizadas y repetibles ayudan a revisar los datos y señalar inconsistencias, mientras el responsable revisa y aprueba cada etapa antes de avanzar.

#### FAQ

Q: ¿Cuánto dura una migración gestionada?
A: Depende del tamaño del catálogo, la complejidad de los datos y cuántos campos personalizados o integraciones estén implicados — te damos un calendario realista después de la evaluación, no una estimación genérica.

Q: ¿Y si mi plataforma actual no tiene una exportación limpia?
A: Trabajamos con lo que tengas — exportaciones de base de datos, acceso a API, feeds XML/CSV, o una combinación. Los orígenes más desordenados requieren más tiempo de evaluación, que tenemos en cuenta desde el principio.

Q: ¿Migráis aplicaciones e integraciones instaladas?
A: Migramos los datos de los que dependen esas aplicaciones, pero la configuración específica de cada app normalmente hay que reconstruirla en el equivalente de la plataforma destino, si existe. Te lo señalamos durante la evaluación, no al llegar al lanzamiento.

### Migración SEO de tiendas online y mapa de redirecciones 301

URL: https://prevedshop.com/es/servicios/seo-y-redirecciones
Language: es
Last reviewed: 2026-07-20

Las estructuras de URL rara vez sobreviven intactas a un cambio de plataforma. Mapeamos las URLs antiguas a sus equivalentes nuevas y configuramos redirecciones como parte central y planificada de la migración, no como un arreglo posterior cuando el posicionamiento ya ha caído.

#### Mapeo de URLs, no suposiciones

Construimos un mapa explícito de cada URL antigua relevante a su equivalente nueva — páginas de producto, categorías, blog o páginas de contenido, y cualquier landing page personalizada. Las páginas sin un equivalente claro reciben una decisión documentada, no un 404 silencioso.

#### Redirecciones y metadatos

Las redirecciones 301 se implementan en la nueva plataforma antes del lanzamiento, y trasladamos los metadatos (títulos, descripciones, etiquetas canónicas) donde siguen siendo realmente precisos para la nueva URL. Comprobamos cadenas y bucles de redirección en lugar de asumir que un mapeo uno a uno es automáticamente correcto.

#### Qué podemos y no podemos prometer

No podemos garantizar posiciones concretas — nadie honesto puede hacerlo, ya que el posicionamiento depende de muchos factores ajenos a cualquier migración. Lo que sí controlamos, y tratamos como un requisito ineludible, es la continuidad de las URLs: que los enlaces y marcadores antiguos lleven a la página nueva correcta, no a un callejón sin salida.

#### FAQ

Q: ¿Sobrevivirán mis posiciones en Google a la migración?
A: Un mapeo de URLs y redirecciones correctos son, con diferencia, el factor más importante para conservar el posicionamiento durante una migración, y lo tratamos como un entregable central. No podemos garantizar posiciones concretas, ya que dependen de factores ajenos a la migración.

Q: ¿Qué pasa con las páginas que no existen en la nueva plataforma?
A: Las señalamos durante la fase de mapeo y acordamos contigo el mejor destino de redirección — normalmente la categoría equivalente más cercana o una página hub relevante, en lugar de una redirección genérica a la portada.

Q: ¿Actualizáis también los enlaces internos, no solo las redirecciones externas?
A: Cuando es viable, sí — los enlaces internos que apuntan a patrones de URL antiguos se actualizan como parte de la migración, ya que las cadenas de redirección añaden latencia y diluyen el valor del enlace.

### Integración de feeds de proveedores

URL: https://prevedshop.com/es/servicios/integracion-de-feeds-de-proveedores
Language: es
Last reviewed: 2026-07-20

Gestionar tu catálogo a partir de feeds de proveedores implica lidiar con formatos inconsistentes, SKUs duplicados entre proveedores, y una periodicidad de actualización que no siempre encaja con lo que espera tu plataforma. Conectamos y normalizamos esos feeds para que tu catálogo se mantenga preciso sin mantenimiento manual.

#### Qué normalizamos

Los feeds de proveedores rara vez comparten formato — nombres de campos, estructuras de categorías e incluso unidades de medida varían de un proveedor a otro. Mapeamos cada feed a una estructura consistente en tu plataforma, para que los productos se comporten igual en tu catálogo sin importar el origen.

#### Duplicados y fusión

Cuando varios proveedores ofrecen el mismo producto, podemos fusionar las fichas, elegir una fuente preferente, o mantenerlas separadas — según cómo quieras gestionar precio y stock. Esta decisión la tomamos contigo, no es un valor predeterminado que te imponemos.

#### Mantener los datos al día

La frecuencia de actualización de los feeds depende de lo que tus proveedores realmente ofrezcan y de lo que tu plataforma pueda absorber razonablemente — acordamos un calendario realista en lugar de prometer actualizaciones en tiempo real que un feed de origen no puede sostener.

#### FAQ

Q: ¿Podéis combinar feeds de varios proveedores en un solo catálogo?
A: Sí — fusionar, deduplicar y normalizar varios feeds de proveedores en un catálogo único y consistente es una parte habitual de este servicio.

Q: ¿Qué ocurre cuando un proveedor deja de tener stock de un producto?
A: Según tu preferencia, podemos marcarlo como no disponible, ocultarlo, o mantenerlo visible con estado de reserva — se configura una vez y se aplica automáticamente en futuras actualizaciones del feed.

Q: ¿Se pueden traducir los feeds de proveedores para otros mercados?
A: Sí, el contenido del feed puede traducirse, mediante traducción automática o un mapeo personalizado que nos proporciones, según el nivel de precisión que necesites.


## Deutsch (de)

### Platform profiles

### Migration zu oder von Adobe Commerce (Magento)

URL: https://prevedshop.com/de/plattformen/adobe-commerce-magento
Language: de
Last reviewed: 2026-07-21

"Magento" umfasst inzwischen mehrere unterschiedliche Dinge: die Open-Source-Plattform Magento Open Source, die kostenpflichtige Adobe Commerce Cloud-Stufe sowie ältere Magento-1-Installationen, deren Lebenszyklus bereits beendet ist. Welche davon Sie tatsächlich betreiben, verändert den Migrationsplan erheblich - deshalb ist die genaue Version und Edition zu bestimmen der erste Schritt, egal ob Magento Ihre Quelle oder Ihr Ziel ist.

#### Magento Open Source, Adobe Commerce sowie Magento 1 vs. 2

Magento Open Source ist kostenlose, selbst gehostete Ecommerce-Software auf PHP-Basis; Adobe Commerce (früher Magento Commerce) ist die kostenpflichtige Stufe mit zusätzlichen B2B-, Content-Staging- und Cloud-Hosting-Funktionen, betrieben auf von Adobe verwalteter Infrastruktur. Magento 1 erreichte bereits vor Jahren das Ende seines Lebenszyklus, und Shops, die es noch betreiben, migrieren meist allein aus diesem Grund, unabhängig von jeder Plattformvergleichsentscheidung.

Aufgrund dieser Bandbreite kann ein "Magento-Migrationsprojekt" bedeuten, einen kleinen Magento-1-Shop auf eine völlig andere Plattform zu verschieben, Magento 1 zu Magento 2 zu migrieren (immer noch Magento, aber ein Neuaufbau über eine Hauptversion hinweg), oder von Adobe Commerce Cloud zu etwas mit anderer Kostenstruktur zu wechseln. Wir grenzen zuerst ab, welcher Fall zutrifft, bevor wir irgendetwas schätzen.

#### Das EAV-Datenmodell und Multi-Store-Setups

Magento speichert Produktdaten über eine EAV-Struktur (Entity-Attribute-Value), die für stark konfigurierbare, attributreiche Kataloge leistungsfähig, aber strukturell anders ist als die einfacheren flachen Produkttabellen, die die meisten anderen Plattformen nutzen. Konfigurierbare Produkte (Magentos Version von Varianten), individuelle Attribut-Sets und attributgesteuerte facettierte Navigation benötigen alle ein explizites Mapping beim Wechsel zu einer Plattform ohne EAV-Äquivalent.

Magentos Multi-Store-/Multi-Website-Architektur, mit der mehrere Storefronts, Währungen oder Locales aus einer Installation betrieben werden, ist ein weiterer Punkt, der sorgfältig gemappt werden muss, da die meisten Plattformen Multi-Store unterschiedlich handhaben: separate Shops, ein einzelner Shop mit marktspezifischen Einstellungen, oder gar kein natives Äquivalent.

#### Extensions, individuelle Module und Magento-Entwickler

Magento-Shops verlassen sich für alles über die Kernfunktionalität hinaus häufig auf Marketplace-Extensions und individuell gebaute Module - etwa für Zahlungsmethoden, B2B-Preisregeln oder unternehmensspezifische Katalog-Logik. Da Magento eine entwicklerlastige Plattform ist, steckt ein nennenswerter Teil dessen, was ein Shop "tut", oft in individuellem PHP-Code statt in Admin-Einstellungen, und diese Logik muss identifiziert und entweder neu aufgebaut oder ersetzt werden, nicht nur exportiert.

Bei Themes gilt dasselbe Muster: Magento-Themes basieren auf dem eigenen Layout-XML-/Blocks-System, das anderswo keine direkte Entsprechung hat, weshalb ein Wechsel von Magento meist einen kompletten Storefront-Neuaufbau auf der neuen Plattform bedeutet.

#### SEO, URLs und wie wir eine Magento-Migration durchführen

Magento verwaltet URL-Rewrites intern und unterstützt recht flexible URL-Strukturen, aber die konkreten Details (Kategoriepfade, Produkt-URL-Suffixe, storeview-spezifische URLs) variieren je nach Konfiguration stark von Shop zu Shop. Genau diese Variabilität ist der Grund, warum wir mit einem Audit Ihrer tatsächlichen Live-URL-Muster beginnen, statt einen Magento-Standard vorauszusetzen.

Für eine Magento-Migration bauen wir die URL-/Weiterleitungskarte anhand dessen, was Ihr Shop heute wirklich tut, behandeln Multi-Store-URL-Varianten, wo relevant, und validieren, dass Metadaten und Canonical-Tags korrekt übernommen werden. Unser Service SEO- und Weiterleitungsmigration behandelt das ausführlicher.

#### FAQ

Q: Ich nutze noch Magento 1. Können Sie das migrieren?
A: Ja, der Wechsel weg von Magento 1 ist eines der häufigeren Projekte, die wir sehen, meist getrieben vom Ende des Lebenszyklus statt von einer Plattformpräferenz. Wir behandeln es als vollständiges Replatforming, da Magento 1 und 2 unterschiedliche zugrunde liegende Architekturen haben.

Q: Was passiert mit meinen individuellen Magento-Modulen?
A: Wir identifizieren, was jedes individuelle Modul tatsächlich tut - etwa eine Zahlungsintegration, eine Preisregel oder eine Katalogfunktion - und klären, ob die Zielplattform ein integriertes oder Extension-Äquivalent hat oder ob individuelle Entwicklung nötig ist.

Q: Können Adobe Commerce B2B-Funktionen auf eine nicht-Enterprise-Plattform migrieren?
A: Das hängt von den konkreten Funktionen ab. Firmenkonten, Angebots-Workflows und gestaffelte B2B-Preise haben nicht auf jeder Plattform eine direkte Entsprechung, daher bewerten wir das im Rahmen der Bewertung von Fall zu Fall, statt eine Eins-zu-eins-Übereinstimmung vorauszusetzen.

Q: Wie wirkt sich die EAV-Attributstruktur auf die Migrationsdauer aus?
A: Kataloge mit vielen individuellen Attributen und Attribut-Sets benötigen im Allgemeinen mehr Mapping-Zeit als einfache flache Kataloge, da für jedes Attribut explizit entschieden werden muss, wo es auf der Zielplattform landet.

Sources:
- Adobe Commerce (Magento) - offizielle Produktseite: https://business.adobe.com/products/magento/magento-commerce.html

### Migration zu oder von BigCommerce

URL: https://prevedshop.com/de/plattformen/bigcommerce
Language: de
Last reviewed: 2026-07-21

BigCommerce ist eine gehostete SaaS-Plattform, die bei von uns betreuten Migrationen auf beiden Seiten vorkommt: Händler, die wegen der nativen Kategoriestruktur und der Headless-Optionen dorthin wechseln, und Händler, die wegdriften, weil sich ihre Anforderungen geändert haben. Wie bei anderen geschlossenen, API-gesteuerten Plattformen kommt es bei einer BigCommerce-Migration vor allem darauf an, was ihre API und ihr Datenmodell offenlegen - nicht nur darauf, wie viele Produkte Sie umziehen. Diese Seite behandelt, worauf es tatsächlich ankommt, wenn BigCommerce auf einer Seite einer Migration steht.

#### Was BigCommerce ist und wo es einzuordnen ist

BigCommerce ist eine gehostete SaaS-Ecommerce-Plattform: BigCommerce verwaltet Hosting, Sicherheits-Patches und Verfügbarkeit, und Sie verwalten den Shop über dessen Backend und APIs statt über einen selbst kontrollierten Server. Die Tarife reichen von Standardstufen für kleine und mittlere Händler bis zu Enterprise. Multi-Storefront ist in mehreren Tarifen mit unterschiedlichen Storefront-Limits verfügbar; Enterprise kann höhere API-Limits, Service-Level und zusätzliche B2B-Funktionen bieten. BigCommerce bietet zudem einen Headless-Ansatz, bei dem Sie das Backend und die APIs mit einem individuell gebauten Frontend statt der eigenen Theme-Schicht nutzen.

Storefronts auf dem standardmäßigen, nicht-headless Weg werden mit BigCommerces Stencil-Theme-Framework gebaut, mit Themes aus dem BigCommerce Theme Marketplace oder individueller Entwicklung. Wie bei jeder geschlossenen, gehosteten Plattform arbeiten Migrationen zu oder von BigCommerce innerhalb ihres Datenmodells und ihrer API-Oberfläche statt über eine direkte Datenbankkopie - was die API für Produkte, Bestellungen und Kunden offenlegt, bestimmt also, was automatisch mitziehen kann.

#### Produkte, Kategorien und das Datenmodell

Anders als Plattformen, die rein auf tagbasierten Collections beruhen, unterstützt BigCommerce einen nativen, verschachtelten Kategoriebaum neben Produkten und ihren Varianten. Das macht es vergleichsweise gut geeignet für Kataloge mit mehrstufigen Kategoriestrukturen, da Sie eine Kategoriehierarchie nicht wie bei manchen anderen gehosteten Plattformen in Tags oder Smart Collections flachdrücken müssen.

Kunden und Bestellhistorie werden über BigCommerces REST- und GraphQL-APIs übertragen, aber wie bei jeder Plattformmigration landen historische Bestellungen typischerweise als Referenzdatensätze statt als vollständig live bearbeitbare Bestellungen. Individuelle Produktdaten werden meist auf BigCommerces individuelle Felder gemappt, und Preislisten (BigCommerces Mechanismus für kundengruppen- oder währungsspezifische Preise) gehören zu den ersten Dingen, die wir prüfen, wenn eine Quellplattform ein eigenes gestaffeltes Preissystem hat.

#### Apps, Themes und was nicht automatisch mitkommt

Ein funktionierender BigCommerce-Shop hängt häufig von Apps aus dem BigCommerce App Marketplace ab - für Bewertungen, Abonnements, Suche, Marketing-Automatisierung oder Versandregeln. In Apps gespeicherte Daten werden bei einer Plattformmigration nicht übertragen; ein Wechsel von BigCommerce bedeutet, alles innerhalb einer App separat zu exportieren, und ein Wechsel zu BigCommerce bedeutet, Äquivalente neu zu installieren und zu konfigurieren, statt App-Einstellungen zu übernehmen.

Stencil-Themes lassen sich nicht in das Templatesystem einer anderen Plattform übertragen, daher bedeutet ein Wechsel von BigCommerce meist, das Storefront-Design auf der neuen Plattform neu aufzubauen, und ein Wechsel zu BigCommerce bedeutet, ein Marketplace-Theme anzupassen oder individuelle Theme-Entwicklung zu beauftragen. Wählen Sie stattdessen den Headless-Weg, ist das Frontend vollständig von BigCommerces Theme-Schicht entkoppelt, was verändert, was "Designmigration" überhaupt bedeutet.

#### SEO, URLs und wie wir eine BigCommerce-Migration durchführen

BigCommerce ist bei der URL-Struktur flexibler als manche gehosteten Wettbewerber und erlaubt individuelle URLs für Produkte, Kategorien und Seiten, statt ein einziges festes Muster vorzugeben. Diese Flexibilität hilft, wenn Sie zu BigCommerce migrieren und URLs Ihren alten ähneln sollen, geschieht aber nicht automatisch, und ein Wechsel von BigCommerce bedeutet weiterhin, dessen URL-Muster auf das zu mappen, was die neue Plattform verlangt.

Als Teil einer verwalteten Migration vergleichen wir Ihre bestehende URL-Struktur mit der von BigCommerce, richten die in beide Richtungen nötigen Weiterleitungen ein und übernehmen Metadaten, die unter den neuen URLs noch zutreffend sind - mit demselben Ansatz wie in unserem Service SEO- und Weiterleitungsmigration beschrieben, zugeschnitten auf BigCommerces spezifische API- und Routing-Beschränkungen.

#### FAQ

Q: Kann ich meine verschachtelte Kategoriestruktur beim Wechsel zu BigCommerce behalten?
A: Ja. BigCommerce unterstützt einen nativen, mehrstufigen Kategoriebaum, sodass eine tiefe Kategoriestruktur von einer anderen Plattform meist direkter übertragen werden kann, als auf eine Plattform, die nur flache Tags oder Collections unterstützt.

Q: Was passiert mit meinen BigCommerce-Apps, wenn ich wegmigriere?
A: App-spezifische Daten müssen im Allgemeinen vor der Migration separat aus jeder App exportiert werden. Wir migrieren die Kern-Shop-Daten, auf denen eine App basiert, aber nicht deren interne Konfiguration oder gespeicherte Datensätze.

Q: Verändert BigCommerces Headless-Option, wie eine Migration abläuft?
A: Es verändert, was Theme-Migration bedeutet, da ein Headless-Setup das Frontend von BigCommerces eigener Theme-Schicht entkoppelt, aber die zugrunde liegenden Produkt-, Bestell- und Kundendaten werden weiterhin auf demselben Weg über die API übertragen.

Q: Bleiben meine URLs gleich, wenn ich zu BigCommerce wechsle?
A: Nur, wenn Sie bewusst passende individuelle URLs konfigurieren, was BigCommerce für Produkte, Kategorien und Seiten erlaubt. Wir richten in der Regel Weiterleitungen ein, statt eine 1:1-URL-Übereinstimmung vorauszusetzen.

Sources:
- BigCommerce - offizielle Website: https://www.bigcommerce.com

### Migration zu oder von OpenCart

URL: https://prevedshop.com/de/plattformen/opencart
Language: de
Last reviewed: 2026-07-21

OpenCart ist eine Open-Source-Ecommerce-Plattform, die uns regelmäßig bei Migrationen begegnet - meist bei Händlern, die wegen der niedrigen Kosten und Einfachheit damit gestartet sind und nun über ein selbst verwaltetes Setup hinauswachsen, oder bei Händlern, die sich gezielt wegen des schlanken Umfangs dafür entscheiden. Da OpenCart Open-Source und selbst gehostet ist, hängt die Komplexität einer Migration eher davon ab, wie stark der Shop mit Extensions individualisiert wurde, als von der bloßen Anzahl der Produkte im Katalog. Diese Seite behandelt, worauf es tatsächlich ankommt, wenn OpenCart auf einer Seite einer Migration steht.

#### Was OpenCart ist und wo es einzuordnen ist

OpenCart ist Open-Source-Ecommerce-Software auf Basis von PHP und MySQL, selbst gehostet auf einem Server, den Sie oder Ihr Hosting-Anbieter kontrollieren. Es ist bekannt für einen vergleichsweise schlanken Kern und eine niedrigere Einstiegshürde als manche andere Open-Source-Plattformen, was es bei kleineren Händlern und Agenturen mit budgetbewussten Shops beliebt macht. Multi-Store-Verwaltung aus einem einzigen Admin ist eine integrierte Funktion, kein Zusatz.

Storefronts nutzen OpenCarts eigenes Theme-System, das seit OpenCart 3 auf der Twig-Template-Engine basiert, mit Themes und Extensions aus dem offiziellen OpenCart Marketplace oder individueller Entwicklung. Wie bei jeder selbst gehosteten Open-Source-Plattform bestimmt der Umfang an individuellem Code und Drittanbieter-Extensions eines Shops als Erstes den Umfang der Migration.

#### Produkte, Optionen und das Datenmodell

OpenCarts Katalog basiert auf Produkten, organisiert in Kategorien, wobei Produkt-"Optionen" Variation - etwa Größe oder Farbe - auf eine Weise handhaben, die strukturell anders ist als ein dediziertes SKU-Ebene-Variantensystem mancher anderer Plattformen. Optionen können in OpenCart Preis und Menge anpassen, aber das zugrunde liegende Modell entspricht nicht echten Varianten, was wichtig wird, wenn ein Katalog, der anderswo echte Varianten nutzt, nach OpenCart migriert wird, oder umgekehrt von OpenCart auf eine Plattform mit strengerem Variantenmodell.

Da OpenCart selbst gehostet ist, steht oft direkter Datenbankzugriff für Exporte zur Verfügung, was das Abrufen von Produkt-, Kunden- und Bestelldaten vereinfachen kann. Aber Shops, die mit Extensions individualisiert oder an Kerndateien verändert wurden - ein im OpenCart-Ökosystem verbreitetes Muster, besonders bei älteren VQMod- oder OCMOD-basierten Extensions -, benötigen eine Identifizierung dieser Anpassungen, bevor ein sauberer Standardexport vorausgesetzt werden kann.

#### Extensions, Themes und was nicht automatisch mitkommt

Ein funktionierender OpenCart-Shop hängt oft von installierten Extensions ab - für Zahlungen, Versand, Marketing-Tools oder Katalogfunktionen über den OpenCart-Kern hinaus. Extension-Daten und -Einstellungen werden bei einer Plattformmigration nicht automatisch übertragen; ein Wechsel von OpenCart bedeutet, zu prüfen, was jede Extension speichert, und es separat zu exportieren, und ein Wechsel zu OpenCart bedeutet, Äquivalente aus dem OpenCart Marketplace zu installieren und zu konfigurieren oder individuell zu entwickeln.

OpenCarts Twig-basierte Themes sind spezifisch für dessen Templatesystem und lassen sich nicht auf andere Plattformen übertragen, daher bedeutet ein Wechsel von OpenCart meist, das Storefront-Design anderswo neu aufzubauen, und ein Wechsel zu OpenCart bedeutet, ein Marketplace-Theme anzupassen oder ein individuelles zu bauen. Ältere OpenCart-Installationen vor Version 3.0 nutzen unter Umständen noch das frühere Theme-System, was früh geklärt werden sollte, da es den Umfang eines Redesigns beeinflusst.

#### SEO, URLs und wie wir eine OpenCart-Migration durchführen

OpenCart unterstützt SEO-freundliches URL-Rewriting für Produkte und Kategorien, muss dafür aber aktiviert und konfiguriert werden, statt standardmäßig aktiv zu sein, und ältere oder stark individualisierte Installationen laufen manchmal noch mit den nicht freundlichen Standard-URLs. Ein Wechsel von OpenCart bedeutet, zunächst zu prüfen, welcher URL-Modus tatsächlich verwendet wird, bevor ein sauberes Mapping zur neuen Plattform vorausgesetzt werden kann.

Als Teil einer verwalteten Migration prüfen wir Ihre aktuelle OpenCart-URL-Konfiguration, oder planen die des Ziels, wenn Sie zu OpenCart wechseln, bauen eine Weiterleitungskarte zwischen alten und neuen URLs und übernehmen Metadaten, die weiterhin zutreffend sind - mit demselben Ansatz wie in unserem Service SEO- und Weiterleitungsmigration beschrieben, angewendet auf OpenCarts spezifisches Setup.

#### FAQ

Q: Ist OpenCart kostenlos nutzbar?
A: OpenCarts Kern-Software ist Open-Source und kostenlos herunterzuladen und selbst zu hosten. Laufende Kosten entstehen durch Hosting, Entwicklungszeit sowie kostenpflichtige Extensions oder Themes aus dem OpenCart Marketplace.

Q: Wie vergleichen sich OpenCarts Produktoptionen mit Varianten auf anderen Plattformen?
A: OpenCarts Optionen können Preis und Menge je Kombination anpassen, sind aber nicht identisch strukturiert wie ein dediziertes SKU-Ebene-Variantensystem, daher braucht das Mapping zu oder von einer Plattform mit strengerem Variantenmodell sorgfältige Prüfung statt einer direkten Feldübereinstimmung.

Q: Können Sie meine OpenCart-Extensions und deren Daten migrieren?
A: Wir migrieren die Kern-Shop-Daten, auf denen eine Extension basiert, aber extension-spezifische Einstellungen und gespeicherte Datensätze benötigen in der Regel einen separaten Export aus dieser Extension oder müssen mit einem Äquivalent auf der Zielplattform neu aufgebaut werden.

Q: Beeinflusst meine OpenCart-Version die Migration?
A: Ja. Ältere OpenCart-Installationen, besonders vor Version 3.0, können sich deutlich in Theme-System, Extension-Format und sogar Datenbankschema unterscheiden, daher bestätigen wir Ihre Version früh im Rahmen der Bewertung.

Sources:
- OpenCart - offizielle Website: https://www.opencart.com

### Migration zu oder von PrestaShop

URL: https://prevedshop.com/de/plattformen/prestashop
Language: de
Last reviewed: 2026-07-21

PrestaShop ist eine Open-Source-Ecommerce-Plattform, die uns bei Migrationen häufig begegnet, besonders bei Händlern in Europa, die wegen der Flexibilität des Self-Hosting dorthin wechseln oder wegdriften, weil sie über ein selbst verwaltetes Setup hinauswachsen. Da PrestaShop Open-Source und selbst gehostet ist (oder über PrestaShops eigenes Cloud-Angebot gehostet werden kann), bestimmen meist die Datenbankstruktur und die genutzten Module die Migrationskomplexität, nicht nur die Kataloggröße. Diese Seite behandelt, worauf es tatsächlich ankommt, wenn PrestaShop auf einer Seite einer Migration steht.

#### Was PrestaShop ist und wo es einzuordnen ist

PrestaShop ist Open-Source-Ecommerce-Software auf Basis von PHP und MySQL, meist selbst gehostet, wobei PrestaShop auch ein eigenes Cloud-Hosting-Angebot bereitstellt. Open-Source bedeutet, dass Sie oder Ihr Hosting-Anbieter Server, PHP-Version und Datenbank direkt verwalten und vollen Zugriff auf den zugrunde liegenden Code haben, anders als bei geschlossenen SaaS-Plattformen. Es hat eine besonders starke Präsenz bei Händlern in Frankreich, Spanien und anderen europäischen Märkten.

Storefronts werden mit PrestaShops eigenem Theming-System gebaut, mit Themes und Modulen aus dem offiziellen PrestaShop Marketplace (Addons) oder individueller Entwicklung. Da der Code offen ist, können die Anpassungen eines PrestaShop-Shops von einfacher Konfiguration bis zu tiefgreifender, individueller Modulentwicklung reichen, und wie viel individueller Code ein Shop mitbringt, ist einer der ersten Faktoren, die den Migrationsumfang prägen.

#### Produkte, Kategorien und das Datenmodell

PrestaShops Katalogmodell basiert auf Produkten mit Kombinationen (dem Begriff für Varianten wie Größe oder Farbe), organisiert in einem nativen Kategoriebaum ohne Tiefenbegrenzung, plus separaten "Merkmalen" und "Attributen" für strukturierte Produktdaten. Dieser native Kategoriebaum macht PrestaShop zu einem passablen Ziel für Kataloge mit tiefen hierarchischen Strukturen, und es ist einer der Punkte, die wir sorgfältig mappen, wenn ein Kategoriebaum dorthin oder von dort auf eine Plattform mit flacherem Modell migriert wird.

Kunden und Bestellhistorie liegen direkt in PrestaShops MySQL-Datenbank, was für einen selbst gehosteten Shop bedeutet, dass für Exporte oft direkter Datenbankzugriff verfügbar ist, statt auf das beschränkt zu sein, was eine REST-API offenlegt. Das kann manche Teile einer Migration vereinfachen, bedeutet aber auch, dass shopspezifische Anpassungen am Datenbankschema, etwa durch individuelle Module, identifiziert werden müssen, bevor ein Standardexport als vollständig vorausgesetzt werden kann.

#### Module, Themes und was nicht automatisch mitkommt

Ein funktionierender PrestaShop-Shop hängt meist von installierten Modulen ab - für Zahlungen, Versandberechnung, Marketing oder Katalogfunktionen, die nicht im PrestaShop-Kern enthalten sind. Moduldaten und -konfiguration werden bei einer Plattformmigration nicht automatisch übertragen; ein Wechsel von PrestaShop bedeutet, zu identifizieren, was jedes Modul speichert, und es separat zu exportieren, und ein Wechsel zu PrestaShop bedeutet, äquivalente Module aus dem Addons-Marketplace zu installieren und zu konfigurieren oder individuell zu entwickeln.

PrestaShop-Themes sind an das eigene Templatesystem gebunden und lassen sich nicht auf andere Plattformen übertragen, daher bedeutet ein Wechsel von PrestaShop meist, das Storefront-Design auf der neuen Plattform neu aufzubauen, und ein Wechsel zu PrestaShop bedeutet, ein Marketplace-Theme anzupassen oder ein individuelles zu beauftragen. Selbst gehostete Shops bringen manchmal auch individuellen Code auf Theme-Ebene mit, der getrennt vom eigentlichen visuellen Design geprüft werden muss.

#### SEO, URLs und wie wir eine PrestaShop-Migration durchführen

PrestaShop erlaubt recht flexibles, konfigurierbares URL-Rewriting für Produkte, Kategorien und CMS-Seiten, was hilfreich ist, wenn die URL-Struktur bei einer Migration erhalten bleiben soll, aber weiterhin bewusst eingerichtet werden muss, statt vorausgesetzt zu werden. Ein Wechsel von PrestaShop bedeutet, dessen URL-Muster, die von Shop zu Shop stark variieren können, da sie konfigurierbar sind, auf die Anforderungen der neuen Plattform zu mappen.

Als Teil einer verwalteten Migration prüfen wir Ihre bestehende PrestaShop-URL-Konfiguration, oder die des Ziels, wenn Sie zu PrestaShop wechseln, bauen eine Weiterleitungskarte zwischen alten und neuen URLs und übernehmen Metadaten, die weiterhin zutreffend sind - mit demselben Ansatz wie in unserem Service SEO- und Weiterleitungsmigration beschrieben, angewendet auf PrestaShops spezifisches Routing-Setup.

#### FAQ

Q: Ist PrestaShop kostenlos nutzbar?
A: PrestaShops Kern-Software ist Open-Source und kostenlos herunterzuladen und selbst zu hosten. Kosten entstehen durch Hosting, Entwicklungszeit, kostenpflichtige Module und Themes sowie einen etwaigen PrestaShop-Cloud-Hosting-Plan anstelle von Self-Hosting.

Q: Können Sie meine PrestaShop-Module und deren Daten migrieren?
A: Wir migrieren die Kern-Shop-Daten, auf denen ein Modul basiert, aber modulspezifische Konfiguration und gespeicherte Datensätze benötigen in der Regel einen separaten Export aus diesem Modul oder müssen mit einem Äquivalent auf der Zielplattform neu aufgebaut werden.

Q: Überträgt sich PrestaShops Kategoriestruktur gut auf andere Plattformen?
A: Das hängt vom Ziel ab. PrestaShops nativer Kategoriebaum ohne Tiefenbegrenzung lässt sich sauber auf Plattformen mit ähnlichem Modell mappen, muss aber auf Plattformen ohne echte verschachtelte Kategorien in Tags oder Collections umgemappt werden.

Q: Welche PrestaShop-Version ist für eine Migration wichtig?
A: Das spielt eine erhebliche Rolle, da sich Datenbankschema und Modulkompatibilität zwischen Hauptversionen unterscheiden können. Wir bestätigen Ihre PrestaShop-Version während der Bewertung, bevor wir einen Migrationsansatz festlegen.

Sources:
- PrestaShop - offizielle Website: https://www.prestashop.com

### Migration zu oder von Shopify

URL: https://prevedshop.com/de/plattformen/shopify
Language: de
Last reviewed: 2026-07-21

Shopify ist einer der häufigsten Migrations-Endpunkte, mit denen wir arbeiten - sowohl als Zielplattform als auch als die Plattform, die Shops verlassen. Da es sich um eine geschlossene, gehostete Plattform handelt, hängt die Reibungslosigkeit des Umzugs stark davon ab, was die Shopify-API tatsächlich offenlegt, nicht nur von der Größe Ihres Katalogs. Diese Seite behandelt, worauf es tatsächlich ankommt, wenn Shopify auf einer Seite einer Migration steht.

#### Was Shopify ist und wo es einzuordnen ist

Shopify ist eine gehostete SaaS-Ecommerce-Plattform: Sie verwalten keine Server, PHP-Versionen oder Datenbank-Backups. Shopify betreibt die Infrastruktur, und Sie verwalten den Shop über das Backend und, für tiefere Anpassungen, über die APIs. Die Tarife reichen von Standardstufen für kleine und mittlere Händler bis zu Shopify Plus, das auf Händler mit höherem Volumen zielt, die mehr Checkout-Anpassung und höhere API-Limits benötigen.

Storefronts werden mit Shopifys eigener Templatesprache Liquid erstellt, und Themes stammen aus dem Shopify Theme Store oder aus individueller Entwicklung. Da die Plattform Closed-Source und gehostet ist, arbeiten Sie innerhalb von Shopifys Datenmodell und dessen Erweiterungspunkten, statt Kerncode zu verändern - genau deshalb hängen Migrationen zu oder von Shopify vom API-Zugang und der App-Konfiguration ab, nicht von einer direkten Datenbankkopie.

#### Produkte, Bestellungen und Kunden: das Datenmodell

Shopifys Produktmodell basiert auf Produkten und Varianten (z. B. einem T-Shirt mit Größen-/Farbvarianten), organisiert in manuellen oder automatisierten Collections statt in einem frei definierbaren Kategoriebaum. Einen Katalog nach Shopify zu migrieren bedeutet meist, die Kategorie- oder Attributstruktur Ihrer Quellplattform auf Shopifys Produkt-/Varianten-/Collection-Modell umzumappen - bei einfachen Katalogen unkompliziert, bei Plattformen mit tiefen, mehrstufigen Kategorien oder stark konfigurierbaren Produkten aufwendiger.

Kunden und Bestellhistorie werden über die Admin-API übertragen, aber Bestelldaten sind an Shopifys eigenes Bestell- und Fulfillment-Modell gebunden, weshalb historische Bestellungen in der Regel als Referenzdatensätze migriert werden statt als vollständig live bearbeitbare Bestellungen. Metafelder (Shopifys Mechanismus für individuelle Felder) sind meist der Ort, an dem nicht standardmäßige Produktdaten landen, und das Mapping Ihrer bestehenden individuellen Felder auf Metafelder gehört zu den ersten Dingen, die wir im Rahmen der Bewertung festlegen.

#### Apps, Themes und was nicht automatisch mitkommt

Ein funktionierender Shopify-Shop hängt meist von einer Handvoll installierter Apps ab - für Bewertungen, Abonnements, Treueprogramme, Suche oder Versandregeln. App-Daten werden bei einer Plattformmigration in der Regel nicht mit übertragen; wenn Sie Shopify verlassen, benötigen in Apps gespeicherte Daten (wie Abo-Zeitpläne oder Treuepunkte) einen separaten Export aus dieser App, und wenn Sie zu Shopify wechseln, installieren Sie Äquivalente aus dem Shopify App Store neu, statt die App-Konfiguration zu übernehmen.

Dasselbe gilt für Themes: Ein Liquid-Theme lässt sich nicht in das Templatesystem einer anderen Plattform übertragen. Ein Wechsel von Shopify bedeutet daher in der Regel, das Storefront-Design auf der neuen Plattform neu aufzubauen, und ein Wechsel zu Shopify bedeutet, entweder ein Theme-Store-Theme anzupassen oder individuelle Liquid-Entwicklung zu beauftragen.

#### SEO, URLs und wie wir eine Shopify-Migration durchführen

Shopify erzwingt eigene URL-Muster wie /products/{handle}, /collections/{handle} und /pages/{handle}, die selten exakt mit der URL-Struktur einer anderen Plattform übereinstimmen. Ein Wechsel zu oder von Shopify bedeutet fast immer einen Weiterleitungsplan von alten zu neuen URLs, da Shopify keine beliebige URL-Struktur aus einem anderen System vollständig nachbilden lässt und andere Plattformen Ihre Shopify-Handles nicht automatisch kennen.

Als Teil einer verwalteten Migration mappen wir Ihre bestehenden URLs gegen Shopifys Struktur (oder umgekehrt, wenn Sie Shopify verlassen), richten 301-Weiterleitungen ein und übernehmen Metadaten, die auf den neuen URLs noch zutreffend sind - mit demselben Ansatz wie in unserem Service SEO- und Weiterleitungsmigration beschrieben, nur speziell zugeschnitten auf Shopifys URL-Konventionen und API-Beschränkungen.

#### FAQ

Q: Können Sie meine Shopify-Apps und deren Daten migrieren?
A: Wir migrieren die Shop-Daten, auf denen diese Apps basieren, aber app-spezifische Konfiguration und gespeicherte Daten müssen in der Regel aus einem separaten Export dieser App stammen oder mit einer äquivalenten App auf der Zielplattform neu aufgebaut werden.

Q: Verändert Shopify Plus, wie eine Migration abläuft?
A: Plus betrifft vor allem die Checkout-Anpassung und die API-Ratenlimits. Das zugrunde liegende Produkt-/Bestelldatenmodell ist dasselbe wie bei Standard-Shopify, daher ändert sich der grundlegende Migrationsansatz nicht - höhere API-Limits können aber die Übertragung großer Kataloge beschleunigen.

Q: Bleiben meine Produkt-URLs gleich, wenn ich zu Shopify wechsle?
A: Nur, wenn Ihre aktuellen URLs bereits Shopifys Muster /products/{handle} entsprechen, was selten der Fall ist. In den meisten Fällen richten wir im Rahmen der Migration Weiterleitungen von Ihren alten URLs zu Shopifys erforderlicher Struktur ein.

Q: Was passiert mit meinem Theme, wenn ich von Shopify wegmigriere?
A: Liquid-Themes lassen sich nicht in die Templatesysteme anderer Plattformen übertragen, daher wird das Storefront-Design auf der neuen Plattform neu aufgebaut - angepasst an Ihr bestehendes Design, soweit die neue Plattform das zulässt.

Sources:
- Shopify - offizielle Website: https://www.shopify.com

### Migration zu oder von Shoptet

URL: https://prevedshop.com/de/plattformen/shoptet
Language: de
Last reviewed: 2026-07-21

Shoptet ist eine gehostete Ecommerce-Plattform, die sich gezielt auf den tschechischen und slowakischen Markt konzentriert, und ein häufiger Endpunkt bei Migrationen für Händler in dieser Region - egal ob sie wegen des lokalen Supports und des No-Code-Setups dorthin wechseln oder wegdriften, weil sie expandieren oder Funktionen brauchen, die die Plattform nicht bietet. Da Shoptet eine geschlossene, gehostete SaaS-Plattform ist, hängt eine Migration zu oder von Shoptet davon ab, was ihr Backend, ihre Exporttools und ihre API tatsächlich offenlegen. Diese Seite behandelt, worauf es tatsächlich ankommt, wenn Shoptet auf einer Seite einer Migration steht.

#### Was Shoptet ist und wo es einzuordnen ist

Shoptet ist eine gehostete SaaS-Ecommerce-Plattform für den tschechischen und slowakischen Markt, mit Backend, Dokumentation und Support hauptsächlich auf Tschechisch. Wie andere gehostete Plattformen verwaltet Shoptet Hosting und Infrastruktur, und Händler verwalten ihren Shop über das Backend statt über Serverzugriff. Sie richtet sich vor allem an kleine und mittlere regionale Händler, die einen Shop betreiben möchten, ohne selbst Code oder Infrastruktur zu verwalten.

Storefronts werden mit Shoptets eigenem Template- und Design-Anpassungssystem gebaut, mit Add-ons aus dem eigenen Marketplace für Funktionen wie Buchhaltungsintegrationen, Marketing-Tools und im CZ/SK-Markt verbreitete regionale Zahlungs- oder Versandmethoden. Da sie Closed-Source und gehostet ist, arbeiten Migrationen zu oder von Shoptet innerhalb ihres eigenen Datenmodells und ihrer Export- oder API-Optionen statt über eine direkte Datenbankkopie.

#### Produkte, Kategorien und das Datenmodell

Shoptets Katalogmodell organisiert Produkte in Kategorien mit Unterstützung für Produktvarianten und Parameter für strukturierte Attribute. Einen Katalog nach Shoptet zu migrieren bedeutet meist, die Kategorie- oder Attributstruktur einer Quellplattform auf Shoptets Modell zu mappen, was bei Katalogen mittlerer Komplexität in der Regel unkompliziert ist.

Shoptet bietet Datenexportoptionen und eine API zum Abrufen von Produkt-, Bestell- und Kundendaten, worauf sich eine Migration von der Plattform stützt. Wie bei anderen gehosteten Plattformen landen historische Bestellungen typischerweise als Referenzdatensätze statt als vollständig live bearbeitbare Bestellungen auf der neuen Plattform.

#### Add-ons, Design und was nicht automatisch mitkommt

Ein funktionierender Shoptet-Shop hängt oft von installierten Add-ons ab - für Buchhaltung, Marketing, Preisvergleichs-Feeds (verbreitet bei CZ/SK-Händlern, die auf Diensten wie Heureka oder Zbozi.cz gelistet sind) oder regionale Zahlungsintegrationen. Add-on-Daten und -Einstellungen werden bei einer Plattformmigration nicht automatisch übertragen; ein Wechsel von Shoptet bedeutet, zu prüfen, was jedes Add-on speichert, und es separat zu exportieren, und ein Wechsel zu Shoptet bedeutet, Äquivalente aus dem eigenen Add-on-Marketplace einzurichten.

Shoptets Design-Templates sind spezifisch für das eigene System und lassen sich nicht auf andere Plattformen übertragen, daher bedeutet ein Wechsel von Shoptet meist, das Storefront-Design anderswo neu aufzubauen, und ein Wechsel zu Shoptet bedeutet, eines der Templates anzupassen oder innerhalb der Design-Anpassungsoptionen zu arbeiten.

#### SEO, URLs und wie wir eine Shoptet-Migration durchführen

Shoptet erlaubt eine gewisse Anpassung der URL-Struktur für Produkte und Kategorien, aber wie bei jedem Plattformwechsel entsprechen bestehende URL-Muster selten genau den Anforderungen einer neuen Plattform. Das ist besonders relevant für CZ/SK-Händler, deren organische Sichtbarkeit oft an ihre aktuellen URLs und Produktfeed-Listings auf regionalen Preisvergleichsportalen gebunden ist.

Als Teil einer verwalteten Migration mappen wir Ihre bestehenden Shoptet-URLs, oder die der Zielplattform, wenn Sie zu Shoptet wechseln, gegen die neue Struktur, richten Weiterleitungen ein und übernehmen Metadaten sowie Vergleichsportal-Feed-Konfiguration, die weiterhin zutreffend sind - mit demselben Ansatz wie in unserem Service SEO- und Weiterleitungsmigration beschrieben, angewendet auf Shoptets spezifisches Setup und das regionale Feed-Ökosystem, mit dem es typischerweise verbunden ist.

#### FAQ

Q: Ist Shoptet außerhalb Tschechiens und der Slowakei verfügbar?
A: Shoptet ist gezielt für den tschechischen und slowakischen Markt gebaut und unterstützt, mit Backend und Dokumentation hauptsächlich auf Tschechisch. Es ist nicht als globale Plattform positioniert, wie manche gehosteten Wettbewerber - ein Faktor, den Sie bedenken sollten, wenn Sie über CZ/SK hinaus expandieren.

Q: Können Sie meine Shoptet-Produktfeeds für Heureka oder Zbozi.cz migrieren?
A: Wir migrieren die zugrunde liegenden Produktdaten, aus denen diese Feeds gebaut sind; die Feed-Konfiguration selbst muss in der Regel auf der neuen Plattform neu aufgebaut oder über unseren Service Lieferanten-Feed-Integration abgewickelt werden, je nachdem, wie die Zielplattform Preisvergleichs-Feeds verwaltet.

Q: Können Sie meine Shoptet-Add-ons und deren Daten migrieren?
A: Wir migrieren die Kern-Shop-Daten, auf denen ein Add-on basiert, aber add-on-spezifische Einstellungen und gespeicherte Datensätze benötigen in der Regel einen separaten Export aus diesem Add-on oder müssen mit einem Äquivalent auf der Zielplattform neu aufgebaut werden.

Q: Bleiben meine Produkt-URLs gleich, wenn ich zu oder von Shoptet wechsle?
A: Meist nicht exakt, da Shoptets URL-Struktur selten genau den Anforderungen einer anderen Plattform entspricht. Wir richten als Teil der Migration Weiterleitungen von alten zu neuen URLs ein, um bestehende Suchrankings zu schützen.

Sources:
- Shoptet - offizielle Website: https://www.shoptet.cz

### Migration zu oder von Shopware

URL: https://prevedshop.com/de/plattformen/shopware-6
Language: de
Last reviewed: 2026-07-21

Shopware ist eine Plattform, die uns am häufigsten bei Händlern in Deutschland, Österreich und der Schweiz begegnet - entweder beim Wechsel dorthin wegen der offenen Architektur und starken Präsenz im DACH-Raum, oder beim Wegzug von einer älteren Shopware-Installation, wenn sich die Anforderungen ändern. Shopwares doppelte Natur - Open-Source-Software, die auch als gehostetes Cloud-Produkt betrieben werden kann - bedeutet, dass der richtige Migrationsansatz davon abhängt, welche Version und welches Deployment Sie tatsächlich betreiben. Diese Seite behandelt, worauf es tatsächlich ankommt, wenn Shopware auf einer Seite einer Migration steht.

#### Was Shopware ist und wo es einzuordnen ist

Shopware ist Ecommerce-Software auf Basis des Symfony-PHP-Frameworks, verfügbar als selbst gehostete Open-Source-Software (Community Edition) oder als gehostetes Cloud-Produkt mit kommerziellen Editionen, die Funktionen wie erweiterte B2B-Tools und regelbasierte Preisgestaltung hinzufügen. Shopware 6 ist die aktuelle Generation, aufgebaut um einen headless-fähigen Kern mit getrennter Storefront- und Verwaltungsschicht, als Ersatz für das ältere, strukturell andere Shopware 5.

Da Shopware eine Store API bereitstellt, unterstützt es Headless- und Composable-Setups neben der eigenen Standard-Storefront, was für Migrationen relevant ist, bei denen Frontend und Backend getrennt behandelt werden. Storefronts auf dem Standardweg nutzen Shopwares eigenes Theme-System auf Twig-Basis, mit Plugins und Themes aus dem Shopware Store.

#### Produkte, Sales Channels und das Datenmodell

Shopware organisiert Produkte mit "Eigenschaften" und Konfigurator-Gruppen für Varianten innerhalb eines nativen Kategoriebaums und nutzt "Sales Channels", um unterschiedliche Storefronts oder Markenauftritte aus einem einzigen Backend zu verwalten - ein strukturell anderes Konzept als das, wie Plattformen mit nur einer Storefront Multi-Marken-Setups handhaben. Dieses Sales-Channel-Modell ist einer der ersten Punkte, die wir mappen, wenn ein Händler mehrere zusammengehörige Shops aus einer Shopware-Installation betreibt.

Regelbasierte Preisgestaltung - unterschiedliche Preise oder Aktionen, ausgelöst durch Kundengruppe, Warenkorbinhalt oder andere Bedingungen - ist eine Shopware-Funktion, die früh in einer Migration geklärt werden sollte, da nicht jede Zielplattform bedingte Preisgestaltung auf dieselbe Weise modelliert. Kunden- und Bestelldaten liegen in Shopwares eigener Datenbankstruktur, und bei selbst gehosteten Installationen ist oft direkter Datenbankzugriff verfügbar, was manche Exporte vereinfachen kann, aber weiterhin erfordert, individuelle, durch Plugins hinzugefügte Felder zu identifizieren, bevor ein Standardexport als vollständig vorausgesetzt werden kann.

#### Plugins, Themes und was nicht automatisch mitkommt

Ein funktionierender Shopware-Shop hängt meist von Plugins aus dem Shopware Store ab - für Zahlungen, Versand, Marketing oder B2B-Funktionen, die nicht im Shopware-Kern enthalten sind. In Plugins gespeicherte Daten und Konfiguration werden bei einer Plattformmigration nicht automatisch übertragen; ein Wechsel von Shopware bedeutet, zu prüfen, was jedes Plugin speichert, und es separat zu exportieren, und ein Wechsel zu Shopware bedeutet, Äquivalente über den Shopware Store zu installieren und zu konfigurieren oder individuell zu entwickeln.

Shopwares Twig-basierte Themes sind spezifisch für dessen Templatesystem und lassen sich nicht anderswo übertragen, daher bedeutet ein Wechsel von Shopware meist, das Storefront-Design auf der neuen Plattform neu aufzubauen, und ein Wechsel zu Shopware bedeutet, ein Store-Theme anzupassen oder ein individuelles zu bauen. Migrationen mit Shopware 5, das eine andere zugrunde liegende Architektur als Shopware 6 nutzt, müssen als eigener Fall abgegrenzt werden, statt anzunehmen, sie liefen wie eine Shopware-6-Migration.

#### SEO, URLs und wie wir eine Shopware-Migration durchführen

Shopware unterstützt konfigurierbare SEO-URL-Vorlagen für Produkte, Kategorien und andere Seiten, die je Sales Channel angepasst werden können, aber die tatsächlich genutzten URL-Muster variieren je nach Konfiguration von Shop zu Shop. Ein Wechsel von Shopware bedeutet, die Live-URL-Konfiguration zu prüfen, statt ein Standardmuster vorauszusetzen.

Als Teil einer verwalteten Migration prüfen wir Ihr bestehendes Shopware-URL-Setup, oder planen das des Ziels, wenn Sie zu Shopware wechseln, bauen eine Weiterleitungskarte zwischen alten und neuen URLs je Sales Channel, wo relevant, und übernehmen Metadaten, die weiterhin zutreffend sind - mit demselben Ansatz wie in unserem Service SEO- und Weiterleitungsmigration beschrieben, angewendet auf Shopwares spezifisches Routing und Sales-Channel-Struktur.

#### FAQ

Q: Spielt es eine Rolle, ob ich Shopware 5 oder Shopware 6 nutze?
A: Ja, erheblich. Shopware 6 hat eine andere zugrunde liegende Architektur, ein anderes Plugin-System und eine andere Theme-Struktur als Shopware 5, daher behandeln wir Migrationen aus jeder Version als eigenständigen Fall, statt anzunehmen, derselbe Ansatz gelte für beide.

Q: Ist Shopware kostenlos nutzbar?
A: Shopwares Community Edition ist Open-Source und kostenlos selbst zu hosten. Die kommerziellen Editionen und die Cloud-Hosting-Option bringen Lizenz- oder Abokosten zusammen mit zusätzlichen Funktionen wie erweiterten B2B-Tools mit sich.

Q: Wie wirken sich Shopwares Sales Channels auf eine Migration aus?
A: Betreiben Sie mehrere Storefronts oder Marken über Shopwares Sales-Channel-Funktion, mappen wir jeden einzeln, statt die Installation als einen flachen Shop zu behandeln, da Zielplattformen Multi-Channel-Setups nicht immer auf dieselbe Weise modellieren.

Q: Können Sie meine Shopware-Plugins und deren Daten migrieren?
A: Wir migrieren die Kern-Shop-Daten, auf denen ein Plugin basiert, aber plugin-spezifische Einstellungen und gespeicherte Datensätze benötigen in der Regel einen separaten Export aus diesem Plugin oder müssen mit einem Äquivalent auf der Zielplattform neu aufgebaut werden.

Sources:
- Shopware - offizielle Website: https://www.shopware.com

### Migration zu oder von WooCommerce

URL: https://prevedshop.com/de/plattformen/woocommerce
Language: de
Last reviewed: 2026-07-21

WooCommerce ist keine Plattform im selben Sinne wie ein gehostetes SaaS-Tool. Es ist ein kostenloses Plugin, das eine selbst gehostete WordPress-Website in einen Shop verwandelt - eine WooCommerce-Migration ist also im Kern eine WordPress-plus-Datenbank-Migration. Dieser Unterschied verändert, was tatsächlich bewegt werden muss, und ist das Erste, was wir bei jedem WooCommerce-Projekt festlegen.

#### Was WooCommerce ist und wer es betreibt

WooCommerce ist ein Open-Source-Ecommerce-Plugin für WordPress, entwickelt und gepflegt von Automattic. Da es selbst gehostet wird, sind Sie (oder Ihr Hoster) für Server, PHP-Version, Backups und Updates verantwortlich. Es gibt keinen einzelnen Anbieter, der die Verfügbarkeit verwaltet, wie es bei einer SaaS-Plattform der Fall wäre - das bringt mehr Kontrolle, aber auch mehr Wartungsaufwand mit sich.

Es ist beliebt bei Händlern, die bereits WordPress für Inhalte nutzen oder volle Kontrolle über Hosting, Plugins und Code wollen. Diese Flexibilität ist auch der Grund, warum WooCommerce-Shops in ihrer Komplexität enorm variieren: ein schlanker Katalog mit ein paar Plugins ist eine ganz andere Migration als eine stark angepasste Installation mit Dutzenden zusammenwirkenden Plugins.

#### Das Datenmodell: Produkte als WordPress-Inhalte

WooCommerce speichert Produkte als eigenen WordPress-Post-Type, wobei Variationen, Attribute und Preise in verknüpften Tabellen und Post-Meta liegen statt in einem dedizierten Ecommerce-Schema. Kategorien und Tags nutzen das Taxonomiesystem von WordPress mit. Das funktioniert gut innerhalb von WordPress, bedeutet aber, dass eine Migration nach WooCommerce Ihre Quelldaten nicht nur auf „Produkte“, sondern konkret auf das Content-Modell von WordPress abbilden muss - und eine Migration aus WooCommerce heraus bedeutet, Ecommerce-Daten zu extrahieren, die mit allgemeinen WordPress-Inhalten verflochten sind.

Die Speicherung von Bestellungen hängt von WooCommerce-Version und Konfiguration ab: ältere Shops nutzen WordPress-Posts und Post-Meta, während High-Performance Order Storage Bestellungen und Adressen in eigenen Tabellen ablegen kann. Kunden bleiben mit WordPress-Benutzern verknüpft, und Erweiterungen können zusätzliche Tabellen anlegen. Ob historische Bestellungen editierbar oder nur als Referenzdaten übertragen werden können, hängt von Zielplattform und Importmethode ab; deshalb muss das Quellschema vor dem Mapping inventarisiert werden.

#### Plugins, Themes und wo individuelle Logik lebt

Ein funktionierender WooCommerce-Shop hängt häufig von mehreren Plugins über WooCommerce selbst hinaus ab - für Versandregeln, Zahlungs-Gateways, Abonnements oder individuelle Felder über Tools wie Advanced Custom Fields. Plugin-spezifische Daten haben meist kein portables Exportformat, daher bedeutet eine Migration aus WooCommerce, zu ermitteln, was jedes Plugin tatsächlich speichert und ob die Zielplattform ein Äquivalent hat.

Themes sind WordPress-Themes, oft kombiniert mit Page-Buildern (Elementor, WPBakery und ähnliche), die Layout-Daten auf eine Weise speichern, die sich außerhalb von WordPress nicht übertragen lässt. Ein Wechsel von WooCommerce bedeutet daher in der Regel, das Storefront-Design auf der neuen Plattform neu aufzubauen, statt es zu exportieren.

#### SEO, URLs und wie wir eine WooCommerce-Migration durchführen

Die URL-Struktur von WooCommerce wird über die WordPress-Permalink-Einstellungen gesteuert und ist daher flexibel - diese Flexibilität bedeutet aber auch, dass die URLs jeder WooCommerce-Website leicht unterschiedlich konfiguriert sind, ohne ein einziges festes Muster, gegen das man migrieren könnte, wie bei manchen SaaS-Plattformen. Verbreitete SEO-Plugins (Yoast, Rank Math) speichern Metadaten und Weiterleitungen zudem in eigenen Tabellen, was separat von den WooCommerce-/WordPress-Kerndaten berücksichtigt werden muss.

Als Teil einer verwalteten Migration mappen wir Ihre tatsächliche Permalink-Struktur - nicht einen angenommenen Standard - auf das URL-Muster der Zielplattform, ziehen Metadaten aus dem jeweils genutzten SEO-Plugin und richten Weiterleitungen ein, damit bestehende Rankings und eingehende Links weiterhin funktionieren. Wie das generell abläuft, beschreibt unser Service SEO- und Weiterleitungsmigration.

#### FAQ

Q: Enthalten meine WooCommerce-Daten auch meine WordPress-Inhalte?
A: Nur das, was Sie uns beauftragen zu migrieren. WooCommerce und allgemeine WordPress-Inhalte (Blogbeiträge, Seiten) liegen in derselben Datenbank, daher legen wir vor Migrationsbeginn genau fest, was als „Shop-Daten“ zählt und was als Website-Inhalt.

Q: Können Sie einen WooCommerce-Shop mit vielen individuellen Plugins migrieren?
A: Ja, das erfordert allerdings mehr Zeit für die Bewertung. Wir ermitteln, was jedes Plugin tatsächlich speichert und ob es auf der neuen Plattform ein Äquivalent gibt oder von Grund auf neu aufgebaut werden muss.

Q: Was passiert mit meinen Yoast- oder Rank-Math-SEO-Daten, wenn ich WooCommerce verlasse?
A: Wir extrahieren die Metadaten und Weiterleitungen, die diese Plugins speichern, und übernehmen, was weiterhin zutreffend ist, in die entsprechenden Felder der neuen Plattform - statt Ihre SEO-Metadaten bei null anzufangen.

Q: Kann ich von einer SaaS-Plattform nach WooCommerce migrieren?
A: Ja, das ist eine gängige Richtung, wenn Händler mehr Kontrolle über Hosting und Code wollen. Wir mappen Ihren Quellkatalog auf das Post-Type-Modell von WordPress und richten WooCommerce entsprechend ein.

Sources:
- WooCommerce - offizielle Website: https://woocommerce.com

### Migration routes

### Migration von Magento zu BigCommerce

URL: https://prevedshop.com/de/migrationen/magento-zu-bigcommerce
Language: de
Last reviewed: 2026-07-21
Route: adobe-commerce -> bigcommerce

Der Wechsel von Adobe Commerce oder Magento Open Source zu BigCommerce tauscht eine selbst gehostete, codezentrierte Plattform gegen eine verwaltete SaaS-Plattform - im Grundsatz ähnlich einem Wechsel zu Shopify, aber mit anderen Kompromissen. BigCommerce unterstützt nativ mehr Produktvariantenkombinationen und gibt Ihnen mehr Kontrolle über die URL-Struktur als viele SaaS-Wettbewerber, was es strukturell näher an einen komplexen Magento-Katalog heranbringen kann - Hosting, Extensions und Multi-Store-Setup müssen aber trotzdem bewusst neu aufgebaut werden, nicht pauschal exportiert.

#### Warum Händler von Magento wegwechseln

Magento Open Source und Adobe Commerce geben volle Kontrolle über Codebasis, Hosting und Checkout - auf Kosten dessen, diese Infrastruktur selbst verwalten zu müssen: PHP- und Magento-Sicherheitspatches, Server- oder Cloud-Hosting sowie PCI-Compliance für den selbst gehosteten Checkout. BigCommerce nimmt als verwaltete SaaS-Plattform Hosting, PCI-Compliance und plattformseitige Sicherheitspatches von Ihrem Team, im Austausch dafür, dass Sie innerhalb der Plattformgrenzen statt mit beliebigem Code arbeiten.

Ein häufiger Auslöser ist derselbe, der Händler auch zu Shopify treibt: Die Kosten, einen Entwickler oder eine Agentur dauerhaft für die Pflege einer Magento-Instanz zu beauftragen, rechnen sich irgendwann nicht mehr, sobald das Wachstum des Shops diesen Aufwand nicht mehr rechtfertigt - besonders bei Shops, die noch eine ungepatchte Magento-2-Instanz betreiben oder auf dem End-of-Life-Magento-1 verharren.

#### Was sich im Datenmodell ändert

Magentos EAV-Katalogstruktur (Entity-Attribute-Value) erlaubt weitgehend beliebige individuelle Attribute je Produkttyp. BigCommerces Produktmodell ist strukturierter als das von Magento, aber generell flexibler bei Varianten als konkurrierende SaaS-Plattformen - es unterstützt nativ eine größere Zahl an Produktvariantenkombinationen sowie individuelle Felder und Produktmodifikatoren für Attribute außerhalb der Variantenstruktur. Das bedeutet dennoch, dass Magento-Attribut-Sets bewusst auf BigCommerces Variantenoptionen und individuelle Felder gemappt werden müssen, statt Attribut für Attribut kopiert zu werden.

Magentos Kategoriebaum erlaubt beliebige Verschachtelung mit storeview-spezifischen Anzeigeeinstellungen, und ein Produkt kann mehreren Kategorien gleichzeitig angehören. BigCommerce-Kategorien liegen näher an einem traditionellen Baum als Shopifys flachem Collection-Modell, was die Migration einer tief verschachtelten Magento-Kategoriestruktur etwas direkter macht - sie sollte aber trotzdem überprüft und vereinfacht werden, wo Magentos Struktur über Jahre organisch gewachsen statt gezielt entworfen wurde.

#### URLs, Weiterleitungen und was hier anders ist als bei Shopify

Magento-URL-Keys und Rewrites sind je Storeview vollständig konfigurierbar. BigCommerce erlaubt anders als Shopify individuelle URL-Pfade für Produkte, Kategorien und Seiten, ohne ein verpflichtendes Präfix wie `/products/` oder `/collections/` vorzugeben - das kann es leichter machen, eine bestehende Magento-URL-Struktur zu erhalten. Das macht einen Weiterleitungsplan aber nicht überflüssig: Jede URL, die sich doch ändert, braucht weiterhin eine explizite 301-Weiterleitung, und die Aufgabe, jede indexierte Magento-URL gegen ihr neues BigCommerce-Äquivalent zu prüfen, muss so oder so erledigt werden, um einen Rankingverlust nach der Migration zu vermeiden.

#### Extensions, Checkout und Multi-Storefront

Magentos Extension-Ökosystem und seine Fähigkeit, Checkout, Preisregeln und Admin-Workflows im Code anzupassen, haben kein direktes BigCommerce-Äquivalent - BigCommerce nutzt einen App-Marketplace sowie eigene APIs und Stencil-/Catalyst-Storefront-Anpassung für individuelle Logik. Jede aktive Magento-Extension braucht während der Bewertung eine explizite Entscheidung: eine äquivalente BigCommerce-App, ein individueller Build gegen BigCommerces APIs, oder die Bestätigung, dass sie nicht mehr gebraucht wird. Dasselbe gilt für Magentos Multi-Website-/Multi-Store-Setups, die sich nicht direkt auf BigCommerces Multi-Storefront-Fähigkeiten übertragen lassen, auch wenn das Ergebnis am Ende ähnlich aussehen kann.

#### FAQ

Q: Kann BigCommerce Magentos individuelle Produktattribute abbilden?
A: Über eine Kombination aus Variantenoptionen und individuellen Feldern, aber BigCommerce hat kein automatisches Äquivalent zu Magentos EAV-Attribut-Sets. Wir mappen Ihre tatsächliche Attributnutzung während der Bewertung, statt jedes Attribut zu migrieren, das Magento zufällig definiert hat.

Q: Ist die Migration von Magento-URLs zu BigCommerce einfacher als zu Shopify?
A: Oft etwas einfacher, da BigCommerce individuelle URL-Pfade ohne verpflichtendes Präfix erlaubt, anders als Shopifys feste Struktur. Das verringert, wie viele URLs sich ändern müssen, aber jede URL, die sich doch ändert, braucht weiterhin eine explizite 301-Weiterleitung - das Audit muss trotzdem stattfinden.

Q: Was passiert mit meinen Magento-Extensions und individuellen Modulen?
A: Jede wird während der Bewertung einzeln evaluiert: Ersatz durch eine bestehende BigCommerce-App, Neuaufbau gegen BigCommerces APIs, oder die Bestätigung, dass sie nicht mehr benötigt wird. Wir erfassen diese Liste vor der Umfangsfestlegung des Projekts, nicht danach.

Q: Kann ich Multi-Store- oder Multi-Website-Funktionalität behalten?
A: Magentos Multi-Website-Modell lässt sich nicht direkt auf BigCommerces Architektur übertragen, auch wenn BigCommerce ebenfalls mehrere Storefronts unterstützt. Wir mappen Ihren tatsächlichen Bedarf - separate Marken, Regionen oder Währungen - auf die passende BigCommerce-Struktur, statt eine 1:1-Umwandlung vorauszusetzen.

Sources:
- BigCommerce official site and documentation: https://www.bigcommerce.com
- Adobe Commerce / Magento Open Source documentation: https://experienceleague.adobe.com/en/docs/commerce

### Migration von Magento zu Shopify

URL: https://prevedshop.com/de/migrationen/magento-zu-shopify
Language: de
Last reviewed: 2026-07-21
Route: adobe-commerce -> shopify

Der Wechsel von Adobe Commerce oder Magento Open Source zu Shopify tauscht eine selbst gehostete, stark anpassbare PHP-Plattform gegen eine verwaltete SaaS-Plattform. Dieser Tausch nimmt Ihnen die Pflege von Server, PHP-Version und PCI-Compliance ab, bedeutet aber auch, dass das Datenmodell Ihres Katalogs, Ihre URL-Struktur und die meisten Ihrer Extensions neu aufgebaut statt kopiert werden müssen. Bewusst durchgeführt ist das ein gut verstandener Schritt; als roher Export/Import durchgeführt ist es der Punkt, an dem SEO und individuelle Logik still zerbrechen.

#### Warum Händler von Magento wegwechseln

Magento Open Source und Adobe Commerce geben Ihnen volle Kontrolle über Codebasis, Hosting und Checkout - genau deshalb sind sie teuer im laufenden Betrieb. Jemand muss PHP- und Magento-Sicherheitsupdates einspielen, die Server- oder Cloud-Infrastruktur verwalten und die PCI-Compliance für den selbst gehosteten Checkout aktuell halten. Shopify nimmt Hosting, PCI-Compliance und plattformseitige Sicherheitspatches von Ihrem Team, im Austausch gegen weniger Kontrolle auf niedriger Ebene.

Ein häufiger Auslöser ist, dass die laufenden Kosten für einen Entwickler oder eine Agentur zur Pflege einer Magento-Instanz nicht mehr zur Größe des Shops passen - besonders sobald Magento 1 (dessen Lebenszyklus längst beendet ist) oder ein alterndes Magento-2-Setup beginnt, ungepatchte Extensions anzuhäufen.

#### Was sich im Datenmodell tatsächlich ändert

Magentos Produktkatalog basiert auf einer EAV-Struktur (Entity-Attribute-Value), die beliebige individuelle Attribute je Produkttyp erlaubt. Shopifys Produktmodell ist einfacher: Ein Produkt hat einen festen Satz an Kernfeldern plus bis zu drei Varianten-Optionsdimensionen (wie Größe und Farbe) sowie Metafelder für alles Weitere. Magentos konfigurierbare Produkte und individuelle Optionen werden auf Shopify-Varianten und Metafelder gemappt, aber das Mapping ist nicht 1:1 - Attribut-Sets mit vielen individuellen Attributen brauchen meist ein bewusst entworfenes Metafeld-Schema, keine automatische Attribut-für-Attribut-Umwandlung.

Kategorien sind ein weiterer echter Unterschied: Magento erlaubt beliebig tiefe Verschachtelung und die Zuordnung eines Produkts zu vielen Kategorien mit unterschiedlichen Anzeigeeinstellungen je Storeview. Shopify-Collections sind flacher - manuelle oder regelbasierte ("Smart") Listen statt eines echten Kategoriebaums -, daher braucht ein tief verschachtelter Magento-Katalog eine bewusst geplante Collection-Struktur, keinen direkten Export.

#### URLs, Weiterleitungen und was still kaputtgeht

Magento-URL-Keys und Rewrites sind je Storeview vollständig konfigurierbar. Shopify erzwingt eigene URL-Muster (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`, `/blogs/{blog}/{handle}`), die sich nicht frei umstrukturieren lassen. Das bedeutet, dass jede indexierte Magento-URL eine explizite Weiterleitung zu ihrem Shopify-Äquivalent braucht - das ist die mit Abstand häufigste Quelle für einen Rankingverlust nach der Migration, und vollständig vermeidbar mit einer vor dem Launch erstellten, ordentlichen URL-Karte, statt nachträglich zu reparieren, sobald Google 404-Fehler bemerkt.

#### Extensions, Checkout-Anpassungen und Multi-Store

Magentos Extension-Ökosystem und seine Fähigkeit, Checkout, Preisregeln und Admin-Workflows im Code anzupassen, haben kein direktes Shopify-Äquivalent - Shopify nutzt einen App Store sowie, bei Shopify Plus, Checkout Extensibility und Shopify Functions für individuelle Checkout-Logik. Jedes individuelle Magento-Modul braucht eine explizite Entscheidung: Gibt es eine äquivalente App, braucht es eine individuelle, auf Shopifys APIs aufbauende App, oder entfällt die Funktion. Dasselbe gilt für Magento-Multi-Website-/Multi-Store-Setups, die sich nicht direkt auf Shopifys Modell aus einem Shop plus Markets für den internationalen Verkauf übertragen lassen.

Unser Prozess für verwaltete Migrationen klärt das während der Bewertung - Ihre aktiven Extensions und individuellen Module werden erfasst, bevor die Arbeit angeboten wird, nicht erst mitten in der Migration entdeckt.

#### FAQ

Q: Kann Shopify Magentos individuelle Produktattribute abbilden?
A: Ja, über Metafelder, aber sie müssen bewusst definiert und gemappt werden - Shopify hat kein automatisches Äquivalent zu Magentos EAV-Attribut-Sets. Wir mappen Ihre tatsächliche Attributnutzung während der Bewertung, statt jedes Attribut zu migrieren, das Magento zufällig definiert hat.

Q: Werden meine Magento-URLs automatisch weitergeleitet?
A: Nein. Shopifys URL-Struktur ist fest, daher braucht jede relevante Magento-URL eine explizite 301-Weiterleitung zu ihrem neuen Shopify-Äquivalent. Das ist Kernbestandteil des Migrationsplans, kein optionaler Zusatz - siehe unseren Service SEO- und Weiterleitungsmigration.

Q: Was passiert mit meinen Magento-Extensions und individuellen Modulen?
A: Jede wird während der Bewertung einzeln evaluiert: Ersatz durch eine bestehende Shopify-App, Neuaufbau als individuelle App oder Theme-Anpassung, oder die Bestätigung, dass sie nicht mehr benötigt wird. Wir erfassen diese Liste vor der Umfangsfestlegung des Projekts, nicht danach.

Q: Kann ich Multi-Store- oder Multi-Website-Funktionalität behalten?
A: Magentos Multi-Website-Modell lässt sich nicht direkt auf Shopify übertragen. Je nachdem, was Sie tatsächlich brauchen - separate Marken, separate Regionen, separate Währungen -, kann das passende Shopify-Äquivalent Shopify Markets, ein zweiter Shop oder eine Shopify-Plus-Organisation sein. Wir helfen bei der Wahl basierend auf dem tatsächlichen Bedarf, nicht mit einer pauschalen Antwort.

Sources:
- Shopify - Migrate your store to Shopify: https://www.shopify.com/migrate
- Adobe Commerce / Magento Open Source documentation: https://experienceleague.adobe.com/en/docs/commerce

### Migration von Magento (Adobe Commerce) zu Shoptet

URL: https://prevedshop.com/de/migrationen/magento-zu-shoptet
Language: de
Last reviewed: 2026-09-02
Route: adobe-commerce -> shoptet

Magento und Adobe Commerce sind für komplexe Kataloge, mehrere Store Views und tiefe Anpassung gebaut - um den Preis teuren Hostings und teurer Entwicklung. Shoptet ist eine gehostete Plattform für tschechische und slowakische Händler mit einfacherem, festem Datenmodell und eingebauten lokalen Integrationen. Die Migration ist vor allem Konsolidierung: Attributsets, konfigurierbare Produkte, Store Views und Custom-Module von Magento auf das reduzieren, was Shoptet abbilden kann, Kunden und Bestellhistorie übernehmen und die URLs schützen, die organischen Traffic bringen.

#### Wer von Magento zu Shoptet wechselt und warum

Händler gehen diesen Schritt, wenn das Magento-Setup zum Geschäft nicht mehr passt: ein mittelgroßer tschechischer oder slowakischer Shop zahlt Magento-Hosting, Sicherheitspatches, Extension-Lizenzen und Agenturstunden, die er nicht mehr braucht. Shoptet ersetzt das durch einen Monatstarif, native Integrationen für Zásilkovna, PPL, GoPay, Comgate, Heureka und Zboží.cz und eine verwaltete Umgebung. Der Preis ist Tiefe: keine Attributsets, keine Multi-Website-Hierarchie, keine freien Extensions. Wenn Ihr Geschäft darauf beruht, sagt das die Bewertung, bevor Arbeit beginnt.

#### Attributsets, konfigurierbare Produkte und Kategorien

Magento-Attributsets werden zu einer einzigen flachen Parameterliste in Shoptet, überlappende Attribute aus verschiedenen Sets müssen also zusammengeführt und konsistent benannt werden. Konfigurierbare Produkte werden zu Shoptet-Produkten mit Varianten; die einfachen Kindprodukte werden zu Variantenzeilen mit eigenem Code, Preis und Bestand. Bundle- und Gruppenprodukte haben kein direktes Pendant und werden als separate Produkte oder Sets neu aufgebaut. Kategoriebäume werden übernommen, Anchor-Kategorien und Layered Navigation von Magento aber durch Shoptet-Kategorien und Parameterfilter ersetzt, was meist eine flachere Hierarchie bedeutet.

#### Store Views, Kunden und Bestellungen

Magento Store Views werden oft für Sprachen oder Marken genutzt. Shoptet unterstützt Sprachmutationen pro Shop, aber keine unabhängigen Websites, deshalb braucht jeder Store View eine Entscheidung: in einen Shoptet-Shop zusammenführen, mehrere Shoptet-Shops betreiben oder wegfallen lassen. Kunden und Adressen werden importiert, Kundengruppen auf Shoptet-Preisstufen abgebildet und Passwörter im neuen Shop zurückgesetzt. Die Bestellhistorie wird für Auswertungen importiert. Custom-Module, ERP-Konnektoren und B2B-Funktionen werden einzeln gelistet und nativen Funktionen, Add-ons oder einer individuellen Integration zugeordnet.

#### Weiterleitungen und Umstellung

Magento-URL-Rewrites und Kategoriepfade in Produkt-URLs unterscheiden sich von den Shoptet-Mustern, deshalb exportieren wir alle indexierten URLs, bauen eine vollständige 301-Karte und laden sie vor der DNS-Umstellung in Shoptet. Ein Testimport des gesamten Katalogs wird auf Preise, Steuersätze, Bestände und Varianten geprüft, danach werden Feeds neu erzeugt und die Sitemap eingereicht. Weiterleitungen sichern URL-Kontinuität und senken das Risiko; Rankings garantiert keine Migration.

#### FAQ

Q: Können konfigurierbare Magento-Produkte zu Shoptet migriert werden?
A: Ja. Jedes konfigurierbare Produkt wird zu einem Shoptet-Produkt mit Varianten, die einfachen Kindprodukte zu Variantenzeilen mit eigenem Code, Preis und Bestand.

Q: Was passiert mit Magento-Attributsets?
A: Shoptet hat eine flache Parameterliste, Attributsets werden daher zusammengeführt. Doppelte oder widersprüchliche Attributnamen werden vor dem Import bereinigt und umbenannt.

Q: Wie werden Magento Store Views behandelt?
A: Jeder Store View wird einzeln entschieden: in einen Shoptet-Shop zusammenführen, mehrere Shoptet-Shops betreiben oder wegfallen lassen. Shoptet unterstützt Sprachmutationen, keine unabhängigen Websites.

Q: Behalte ich Kunden und Bestellhistorie?
A: Kunden, Adressen und Gruppenpreise werden importiert; Passwörter werden zurückgesetzt. Bestellungen werden als Historie für Auswertungen importiert, nicht als bearbeitbare Live-Bestellungen.

Sources:
- Adobe Commerce - Datenübertragung (Import und Export): https://experienceleague.adobe.com/en/docs/commerce-admin/systems/data-transfer/data-transfer
- Shoptet Developers - Datenimport: https://developers.shoptet.com/shoptet-tools/data-import/

### Migration von OpenCart zu Shopify

URL: https://prevedshop.com/de/migrationen/opencart-zu-shopify
Language: de
Last reviewed: 2026-07-21
Route: opencart -> shopify

OpenCart ist eine schlanke, selbst gehostete Open-Source-Plattform - einfacher zu betreiben als Magento oder PrestaShop, aber weiterhin erfordert sie, dass Sie Ihren eigenen Server, Ihre PHP-Version, Sicherheitspatches und PCI-Compliance selbst verwalten. Der Wechsel zu Shopify tauscht dieses selbst verwaltete Setup gegen eine gehostete, verwaltete Plattform. Da OpenCarts Datenmodell vergleichsweise einfach ist, ist die Migration selbst meist unkomplizierter als von einer schwergewichtigeren Enterprise-Plattform, aber Produktoptionen, Multi-Store-Konfiguration und Extensions brauchen weiterhin bewusstes Mapping statt eines rohen Export/Imports.

#### Warum Händler von OpenCart wegwechseln

OpenCarts Reiz liegt darin, kostenlos und schlank zu sein, aber das bedeutet auch, dass Sie für Hosting, Sicherheitsupdates, PCI-Compliance und die Kompatibilität von Extensions über Kernversions-Upgrades hinweg selbst verantwortlich sind. Viele OpenCart-Shops werden von kleinen Teams ohne dedizierte Entwickler betrieben, und der laufende Aufwand, Sicherheitspatches einzuspielen und Extension-Konflikte zu beheben, wird mit der Zeit unverhältnismäßig zur Größe des Geschäfts. Shopify nimmt diesen Hosting- und Patch-Aufwand ab, im Austausch gegen eine Plattformgebühr für eine verwaltete Umgebung.

Ein häufiger Auslöser ist das Extension-Ökosystem: OpenCart-Extensions (als OCMOD- oder VQMOD-Modifikationen gebaut) variieren stark in Qualität und werden oft nicht mehr aktiv gepflegt, was mit fortschreitender Kernplattform und alterndem Extension-Stack eines Shops zu einem wachsenden Risiko wird.

#### Produktoptionen, Kategorien und das Datenmodell

OpenCart stellt Produktvarianten über "Optionen" dar - Auswahlmöglichkeiten wie Größe oder Farbe, die an ein Produkt geknüpft sind und optional Preis und Bestand beeinflussen. Das ist konzeptionell nah an Shopifys Variantensystem, was das Kern-Produktmapping direkter macht als von Plattformen mit einem vollständigen EAV-Attributmodell. Shopify begrenzt Produkte weiterhin auf drei Varianten-Optionsdimensionen, daher müssen OpenCart-Produkte mit mehr Optionsgruppen teilweise auf Metafelder statt auf Varianten verschoben werden.

OpenCart-Kategorien können verschachtelt werden, und ein Produkt kann mehreren Kategorien angehören - im Grundsatz ähnlich wie Shopify-Collections, aber strukturell anders aufgebaut. OpenCarts Kategoriebaum lässt sich nicht eins-zu-eins auf Shopifys manuelles/Smart-Collection-Modell übertragen, daher muss die Collection-Struktur meist geplant statt pauschal übernommen werden.

#### Multi-Store, URLs und Extensions

OpenCart unterstützt den Betrieb mehrerer Storefronts aus einer Installation, mit einem gemeinsamen Admin und einem gemeinsamen Produktkatalog über Shops mit unterschiedlichen Einstellungen hinweg. Shopifys nächste Entsprechungen sind Shopify Markets für regionale/Währungsvariation innerhalb eines Shops oder in manchen Fällen echte separate Shopify-Shops für unterschiedliche Marken - keine davon entspricht architektonisch direkt, daher hängt der passende Ansatz davon ab, wofür das Multi-Store-Setup tatsächlich genutzt wird.

OpenCarts SEO-freundliche URL-Einstellungen sind je Shop konfigurierbar, daher müssen bestehende URLs mit expliziten 301-Weiterleitungen auf Shopifys feste URL-Muster (`/products/{handle}`, `/collections/{handle}`) gemappt werden, um keine Suchsichtbarkeit zu verlieren. OpenCart-Extensions für Versand, Zahlung oder Katalog-Anpassung brauchen während der Bewertung ebenfalls eine individuelle Einschätzung - ein Shopify-App-Ersatz, ein individueller Build, oder die Bestätigung, dass sie nicht mehr benötigt werden.

#### FAQ

Q: Lässt sich OpenCarts Produktoptionssystem sauber auf Shopify-Varianten übertragen?
A: Sauberer als von Plattformen mit einem vollständigen individuellen Attributmodell, da OpenCart-Optionen konzeptionell bereits nah an Shopify-Varianten liegen. Produkte mit mehr als drei Optionsgruppen benötigen teilweise ein Mapping auf Shopify-Metafelder statt auf Varianten.

Q: Was passiert mit meinem OpenCart-Multi-Store-Setup?
A: Dafür gibt es auf Shopify keine direkte Eins-zu-eins-Entsprechung. Je nachdem, ob Sie einen gemeinsamen Katalog mit regionaler Variation oder tatsächlich getrennte Marken brauchen, helfen wir bei der Wahl zwischen Shopify Markets und separaten Shopify-Shops anhand Ihres tatsächlichen Bedarfs.

Q: Werden meine OpenCart-URLs automatisch weitergeleitet?
A: Nein. Shopifys URL-Struktur ist fest, daher braucht jede indexierte OpenCart-URL eine explizite 301-Weiterleitung zu ihrem Shopify-Äquivalent - das wird als Teil der Migration geplant, nicht erst nach dem Launch nachgeholt.

Q: Was passiert mit meinen OpenCart-Extensions?
A: Jede aktive Extension wird während der Bewertung einzeln evaluiert: ersetzt durch eine Shopify-App, neu aufgebaut als individuelle App oder Theme-Anpassung, oder fallengelassen, wenn sie nicht mehr benötigt wird. Wir erfassen das vor der Umfangsfestlegung des Projekts.

Sources:
- Shopify - Migrate your store to Shopify: https://www.shopify.com/migrate
- OpenCart official site and documentation: https://www.opencart.com

### Migration von PrestaShop zu Shopify

URL: https://prevedshop.com/de/migrationen/prestashop-zu-shopify
Language: de
Last reviewed: 2026-07-21
Route: prestashop -> shopify

PrestaShop ist eine selbst gehostete, europaweit verbreitete Open-Source-Plattform mit nativer Mehrsprachigkeit, Mehrwährungsunterstützung und einem flexiblen "Kombinationen"-System für Produktvarianten. Der Wechsel zu Shopify bedeutet, direkten Server- und Datenbankzugriff gegen verwaltetes Hosting und PCI-Compliance einzutauschen, und er bedeutet, einige Dinge, die PrestaShop nativ handhabt - Multistore, mehrsprachige Inhalte und Produktkombinationen -, in Shopifys eigenen Begriffen neu zu denken, statt einen gleichwertigen Export vorauszusetzen.

#### Warum Händler von PrestaShop wegwechseln

Als selbst gehostete Plattform legt PrestaShop Serververwaltung, PHP-Versions-Upgrades, Modulkompatibilität und PCI-Compliance für den Checkout in die Verantwortung Ihres Teams. Das ist für einen Shop mit dedizierten technischen Ressourcen handhabbar, wird aber zu echten Kosten - Entwicklungszeit, Hosting, Sicherheitspatches -, sobald der Shop schlank betrieben wird. Shopify übernimmt Hosting, PCI-Compliance und plattformseitige Sicherheitspatches, im Tausch gegen etwas weniger Kontrolle auf niedriger Ebene gegen planbaren, verwalteten Plattformaufwand.

Ein häufiger Auslöser ist das Modul-Ökosystem: PrestaShop-Module variieren stark in Qualität und Pflege, und ein über Jahre gewachsener Shop trägt oft mehrere Module mit sich, die nicht mehr aktiv unterstützt werden - ein wachsendes Risiko, während PrestaShop selbst weiterentwickelt wird.

#### Kombinationen, Kategorien und das Datenmodell

PrestaShop-Produkte nutzen ein "Kombinationen"-System - Attribute wie Größe oder Farbe erzeugen Kombinationszeilen, und PrestaShop setzt kaum harte Grenzen, wie viele Attribute oder Kombinationen ein Produkt haben kann. Shopifys Variantenmodell ist enger begrenzt: bis zu drei Optionsdimensionen je Produkt, mit Metafeldern für Attribute, die nicht ins Variantenmodell passen. Produkte mit vielen PrestaShop-Attributkombinationen, oder Attribute, die eher als beschreibende Daten denn als echte Varianten genutzt werden, brauchen einen bewussten Metafeld-Plan statt einer direkten Attribut-für-Attribut-Kopie.

PrestaShops Kategoriebaum erlaubt, wie der von Magento, beliebige Verschachtelung und die Zuordnung eines Produkts zu mehreren Kategorien. Shopify-Collections sind flacher - manuelle oder regelbasierte Listen -, daher braucht ein tief verschachtelter PrestaShop-Katalog eine neu entworfene Collection-Struktur, um auf Shopify gut zu funktionieren, keinen wörtlichen Kategorieexport.

#### Multistore, Mehrsprachigkeit und Mehrwährungsunterstützung

PrestaShops Multistore-Funktion sowie die native Mehrsprachigkeit und Mehrwährungsunterstützung werden häufig von EU-Händlern genutzt, die aus einer Installation heraus mehrere Märkte bedienen. Shopifys nächste Entsprechung ist Shopify Markets für Währungs-, Sprach- und regionale Storefront-Variation, oder in manchen Fällen ein separater Shopify-Shop je Marke oder Region. Keine davon entspricht architektonisch direkt PrestaShops Multistore, daher hängt der richtige Ansatz davon ab, was der Shop tatsächlich braucht - ein Storefront für mehrere Märkte oder tatsächlich getrennte Storefronts -, und diese Entscheidung sollte bewusst getroffen werden, bevor der Umfang der Migration festgelegt wird.

#### URLs, Weiterleitungen und Module

PrestaShops Einstellungen für sprechende URLs sind vollständig konfigurierbar, daher passen bestehende PrestaShop-URLs selten ohne Weiteres zu Shopifys festen Mustern (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`). Jede indexierte PrestaShop-URL braucht eine explizite Weiterleitung zu ihrem Shopify-Äquivalent, um Suchrankings während des Umzugs zu schützen.

PrestaShop-Module für Versand, Zahlung, Marketing und Checkout-Anpassung haben kein automatisches Shopify-Äquivalent. Jedes aktive Modul braucht während der Bewertung eine explizite Entscheidung - Ersatz durch eine Shopify-App, Neuaufbau als individuelle App oder Theme-Anpassung, oder Wegfall -, damit der Umfang der Migration vor Projektbeginn bekannt ist, statt mitten im Projekt entdeckt zu werden.

#### FAQ

Q: Kann Shopify PrestaShops Produktkombinationen abbilden?
A: Standardkombinationen werden auf Shopify-Varianten gemappt, aber Shopify begrenzt Produkte auf drei Varianten-Optionsdimensionen. Kombinationen darüber hinaus, oder Attribute, die eher als beschreibende Daten genutzt werden, müssen während der Bewertung bewusst auf Metafelder gemappt werden.

Q: Was passiert mit meinem PrestaShop-Multistore-Setup?
A: Dafür gibt es auf Shopify keine direkte architektonische Entsprechung. Je nachdem, was Sie tatsächlich brauchen - gemeinsamer Katalog über Regionen hinweg, separate Währungen oder tatsächlich getrennte Marken -, kann die passende Shopify-Struktur Shopify Markets oder separate Shops sein. Wir helfen bei der Wahl basierend auf Ihrem Bedarf, nicht mit einer Standardantwort.

Q: Werden meine PrestaShop-URLs automatisch zu Shopify weitergeleitet?
A: Nein. Shopify erzwingt seine eigene URL-Struktur, daher braucht jede relevante PrestaShop-URL eine explizite 301-Weiterleitung zu ihrem Shopify-Äquivalent - das ist Kernbestandteil des Migrationsplans, kein optionaler Zusatz.

Q: Was passiert mit meinen PrestaShop-Modulen?
A: Jedes wird einzeln evaluiert: ersetzt durch eine bestehende Shopify-App, neu aufgebaut als individuelle App oder Theme-Anpassung, oder als nicht mehr benötigt bestätigt. Wir erfassen diese Liste während der Bewertung, bevor der Projektumfang festgelegt wird.

Sources:
- Shopify - Migrate your store to Shopify: https://www.shopify.com/migrate
- PrestaShop official site and documentation: https://www.prestashop.com

### Migration von PrestaShop zu Shoptet

URL: https://prevedshop.com/de/migrationen/prestashop-zu-shoptet
Language: de
Last reviewed: 2026-09-02
Route: prestashop -> shoptet

PrestaShop ist eine Open-Source-Plattform, die Sie selbst hosten und pflegen; Shoptet ist ein gehostetes System für tschechische und slowakische Händler mit integriertem Versand, Zahlung und Marktplatz-Feeds. Die Migration ersetzt Kombinationen, Eigenschaften und Moduldaten von PrestaShop durch Varianten, Parameter und Add-ons von Shoptet, überträgt Kunden und Bestellhistorie und baut jede indexierte URL als 301-Weiterleitung nach, damit der Wechsel keine jahrelange Sichtbarkeit in der Suche verschenkt.

#### Was PrestaShop-Händler gewinnen und aufgeben

Shoptet nimmt Serveradministration, PHP-Upgrades und Modulkompatibilität ab. Rechnungsstellung, Mehrwertsteuer, Zásilkovna, PPL, GoPay, Comgate, Heureka und Zboží.cz sind nativ, was oft ein Dutzend PrestaShop-Module ersetzt. Aufgegeben wird die unbegrenzte Anpassbarkeit: In PrestaShop lässt sich alles per Modul oder Override ändern, Shoptet bietet einen festen Satz an Feldern, Templates und Add-ons. Funktionen aus individuellen PrestaShop-Modulen müssen neu bewertet und nicht kopiert werden.

#### Kombinationen, Eigenschaften und Kategorien

PrestaShop-Kombinationen (Attributsätze wie Größe und Farbe) werden auf Shoptet-Varianten abgebildet; jede Kombination wird zu einer Variantenzeile mit eigenem Code, Preis und Bestand. PrestaShop-Eigenschaften für Filter werden zu Shoptet-Parametern, die vor dem Import angelegt werden. Mehrfache Kategoriezuordnung unterstützen beide Systeme, die Standardkategorie aus PrestaShop muss aber explizit als Hauptkategorie in Shoptet gewählt werden. Bilder, Beschreibungen, Meta-Titel und -Beschreibungen kommen per Import mit; spezifische Preisregeln und Kundengruppenpreise brauchen eine Prüfung, weil Shoptet Rabatte anders modelliert.

#### Kunden, Bestellungen und Weiterleitungen

Kunden mit Adressen und Gruppenzugehörigkeit werden importiert; Passwörter können nicht übernommen werden, ein Reset-Ablauf gehört daher zur Launch-Kommunikation. Bestellungen werden als Historie für Auswertungen importiert. PrestaShop-URLs hängen von den Einstellungen für sprechende URLs ab und enthalten oft IDs; Shoptet nutzt eigene Pfadmuster, deshalb erzeugen wir aus Sitemap und Analytics eine vollständige 301-Karte und prüfen sie vor der DNS-Umstellung. Weiterleitungen sichern URL-Kontinuität und senken das Risiko; Rankings werden nie garantiert.

#### Module, Feeds und Go-live

Wir listen jedes aktive PrestaShop-Modul und entscheiden: nativ in Shoptet, als Add-on verfügbar, individuelle Integration oder Wegfall. Marktplatz-Feeds werden aus Shoptet neu erzeugt. Der Launch selbst besteht aus Testimport, Stichprobe von Preisen, Steuersätzen und Beständen und der DNS-Umstellung, wobei PrestaShop kurz schreibgeschützt bleibt, bis die Weiterleitungskarte in der Google Search Console bestätigt ist.

#### FAQ

Q: Werden PrestaShop-Kombinationen zu Shoptet-Varianten?
A: Ja. Jede Kombination wird zu einer Variante mit eigenem Code, Preis und Bestand; Attributgruppen werden zu Variantendimensionen. Uneinheitliche Attributnamen in PrestaShop werden vor dem Import bereinigt.

Q: Kann ich meine PrestaShop-Bestellhistorie behalten?
A: Bestellungen werden als Historie zur Referenz und für Auswertungen importiert. Es sind keine bearbeitbaren Live-Bestellungen, Rechnungen bleiben in Ihrem Buchhaltungssystem.

Q: Funktionieren meine PrestaShop-Module auf Shoptet?
A: Kein Modul wird direkt übertragen. Wir ordnen jedes einer nativen Shoptet-Funktion, einem Add-on oder einer individuellen Integration zu und lassen nicht mehr benötigte weg.

Q: Wie gehen Sie mit PrestaShop-URLs mit Produkt-IDs um?
A: Jede indexierte URL erhält eine explizite 301-Weiterleitung auf das Shoptet-Pendant, erzeugt aus Sitemap und Analytics und vor dem Launch geprüft.

Sources:
- PrestaShop - Webservice-Dokumentation: https://devdocs.prestashop-project.org/9/webservice/
- Shoptet Developers - Datenimport: https://developers.shoptet.com/shoptet-tools/data-import/

### Migration von Shopify zu WooCommerce

URL: https://prevedshop.com/de/migrationen/shopify-zu-woocommerce
Language: de
Last reviewed: 2026-09-02
Route: shopify -> woocommerce

Die meisten Leitfäden beschreiben nur den Weg zu Shopify. Die Gegenrichtung ist genauso üblich, wenn ein Shop volle Datenhoheit, eine content-starke WordPress-Site oder Freiheit von Transaktionsgebühren und App-Abos will. Der Wechsel von Shopify zu WooCommerce bedeutet, Hosting, Sicherheit und Updates selbst zu verantworten - im Tausch gegen ein offenes Datenmodell und unbegrenzte Anpassbarkeit. Die Migration umfasst Produkte, Varianten, Metafelder, Kunden, Bestellhistorie, Inhalte und eine vollständige Weiterleitungskarte.

#### Warum Shops Shopify verlassen

Typische Gründe sind wiederkehrende App-Kosten, Transaktionsgebühren bei Drittanbieter-Zahlungsdiensten, ein schwer anpassbarer Checkout und der Wunsch, Commerce und Content auf einer WordPress-Installation zu betreiben. WooCommerce hat keine Plattformgebühr und legt die gesamte Datenbank auf Ihrem eigenen Server ab, was für Händler mit strengen Anforderungen an den Datenstandort oder umfangreicher B2B-Anpassung zählt. Die andere Seite ist der Betrieb: Hosting-Performance, Backups, Plugin-Updates und PCI-Umfang liegen jetzt bei Ihnen oder Ihrer Agentur.

#### Produkte, Varianten und Metafelder

Shopify-Produkte mit bis zu drei Optionsdimensionen lassen sich sauber auf variable WooCommerce-Produkte mit Attributen und Variationen abbilden. Die Ausnahme sind Metafelder: WooCommerce hat kein eingebautes Pendant, jedes Metafeld wird daher auf ein Produktattribut, ein benutzerdefiniertes Feld oder die Datenstruktur eines bestimmten Plugins abgebildet. Kollektionen werden je nach Nutzung zu Produktkategorien oder Schlagwörtern; regelbasierte Smart Collections müssen als Kategorien mit manueller Zuordnung oder über ein Filter-Plugin neu aufgebaut werden. Bilder, SKUs, Gewichte und Bestände wandern über den CSV-Importer oder einen direkten API-zu-Datenbank-Prozess.

#### Kunden, Bestellungen und Inhalte

Kunden werden mit Adressen und Marketing-Einwilligung importiert; Passwörter werden auf beiden Plattformen unterschiedlich gehasht und nie übertragen. Die Bestellhistorie wird für Auswertungen und Kundenservice importiert, Status werden auf WooCommerce-Pendants abgebildet. Shopify-Seiten und Blogposts werden zu WordPress-Seiten und -Beiträgen, meist ein Gewinn an Bearbeitungsflexibilität. Rabattcodes und Geschenkkarten brauchen eine Prüfung, weil WooCommerce-Gutscheine und Geschenkkarten-Plugins die Shopify-Regeln nicht exakt spiegeln.

#### URLs, Weiterleitungen und Launch

Shopify erzwingt die Präfixe `/products/`, `/collections/` und `/pages/`; WordPress lässt Permalinks frei gestalten - eine Chance für eine sauberere Struktur. Jede indexierte Shopify-URL muss vor dem Domainumzug über eine vom neuen Shop ausgelieferte 301-Weiterleitung auf eine WooCommerce-URL zeigen. Wir testen Weiterleitungskarte, Ladezeit und Checkout auf einem Staging-Server und stellen dann den DNS um, wobei der Shopify-Shop kurz parallel offen bleibt. Weiterleitungen sichern URL-Kontinuität und senken das Risiko; Rankings lassen sich nicht garantieren.

#### FAQ

Q: Können Shopify-Metafelder zu WooCommerce migriert werden?
A: Ja, aber nicht automatisch. Jedes Metafeld wird auf ein WooCommerce-Attribut, ein benutzerdefiniertes Feld oder eine Plugin-Struktur abgebildet, die Ihr Theme anzeigen kann.

Q: Behalten Kunden nach dem Wechsel zu WooCommerce ihre Passwörter?
A: Nein. Passwort-Hashes sind plattformspezifisch. Kunden erhalten im neuen Shop einen Reset-Link, idealerweise als Teil der Launch-Ankündigung.

Q: Welches Hosting braucht WooCommerce nach dem Abschied von Shopify?
A: Managed WordPress-Hosting mit PHP 8, Object Caching und täglichen Backups ist das praktische Minimum für einen Shop, der zuvor auf der Shopify-Infrastruktur lief.

Q: Verliere ich SEO, wenn ich Shopify verlasse?
A: Die URL-Muster ändern sich, deshalb ist eine vollständige 301-Weiterleitungskarte Pflicht. Mit Weiterleitungen, Canonical-Tags und neu eingereichter Sitemap sinkt das Risiko, aber keine Migration garantiert unveränderte Rankings.

Sources:
- WooCommerce - Produkt-CSV-Importer und -Exporter: https://woocommerce.com/document/product-csv-importer-exporter/
- Shopify Help Center - Migration zu Shopify: https://help.shopify.com/en/manual/migrating-to-shopify

### Migration von Shoptet zu Shopify

URL: https://prevedshop.com/de/migrationen/shoptet-zu-shopify
Language: de
Last reviewed: 2026-07-21
Route: shoptet -> shopify

Shoptet ist eine geschlossene, gehostete SaaS-Plattform mit Fokus auf den tschechischen und slowakischen Markt, daher sieht dieser Wechsel anders aus als eine Migration von selbst gehostet zu SaaS: Beide Plattformen verwalten Hosting und PCI-Compliance für Sie. Die eigentlichen Treiber sind meist Reichweite über den CZ/SK-Markt hinaus, Shopifys größeres globales App-Ökosystem und mehr Designflexibilität durch Shopifys Liquid-Theme-System. Da Shoptet Closed-Source ist, läuft der Datenzugriff über dessen Exporttools und API statt über direkten Datenbankzugriff, was die Planung der Migration selbst prägt.

#### Warum Händler von Shoptet wegwechseln

Shoptet ist eine solide, einfach zu betreibende Plattform für CZ/SK-Händler, aber regional fokussiert - ihr App-Marketplace, Zahlungs- und Versandintegrationen sowie Mehrwährungs-/Mehrsprachigkeits-Tools sind primär auf diesen Markt zugeschnitten. Händler, die über Tschechien und die Slowakei hinaus expandieren, finden Shopifys globales App-Ökosystem, dessen native Mehrwährungs- und Mehrsprachigkeits-Tools über Shopify Markets sowie die breitere Basis an Drittanbieter-Integrationen oft besser für grenzüberschreitendes Wachstum geeignet.

Designflexibilität ist ein weiterer häufiger Treiber: Shoptets Theme-Anpassung ist eingeschränkter als Shopifys Liquid-basiertes Theme-System, daher finden Händler, die ein stark individuelles Storefront-Design oder tiefere Checkout-Anpassung (verfügbar für Shopify-Plus-Händler) wollen, bei Shopify oft mehr Spielraum, um genau das zu bauen, was sie möchten.

#### Daten aus einer geschlossenen Plattform herausholen

Anders als bei Open-Source-Plattformen, wo Sie die Datenbank direkt abfragen können, gibt Shoptet keinen direkten Datenbankzugriff - Produkt-, Bestell- und Kundendaten müssen über Shoptets Exporttools (CSV-/XML-Exporte) und dessen API herausgeholt werden. Das bedeutet, der Datenextraktionsschritt der Migration hängt davon ab, was Shoptets Export- und API-Oberfläche tatsächlich offenlegt, und alle Daten, die über diese Kanäle nicht zugänglich sind (bestimmte individuelle Felder, historische Bestellmetadaten), müssen früh identifiziert werden, da sie sich nicht einfach aus einem Datenbank-Dump ziehen lassen wie bei einer selbst gehosteten Plattform.

#### Produktdaten, Kategorien und Varianten

Shoptets Produktmodell nutzt, wie die meisten SaaS-Plattformen, Parameter/Varianten für Produktoptionen wie Größe oder Farbe. Diese auf Shopifys Variantensystem (begrenzt auf drei Optionsdimensionen) zu mappen, ist meist direkter als die Migration von einer Plattform mit beliebigem individuellem Attributmodell, wobei Shoptet-Parameter, die eher für beschreibende Filterung als für echte Varianten genutzt werden, besser in Shopify-Metafeldern aufgehoben sind. Shoptets Kategoriestruktur muss ebenfalls gegen Shopifys flacheres, collectionbasiertes Modell geprüft werden, statt als wörtlicher Baum übernommen zu werden.

#### URLs, Lokalisierung und Apps

Shoptet-URLs folgen eigenen Plattformkonventionen und müssen mit expliziten 301-Weiterleitungen für jede indexierte Seite auf Shopifys feste URL-Muster (`/products/{handle}`, `/collections/{handle}`) gemappt werden, um bestehende Suchsichtbarkeit zu schützen - besonders wichtig für über die Zeit aufgebautes CZ/SK-Markt-SEO. Verkauft der Shop in mehreren Sprachen oder Währungen, muss Shopify Markets konfiguriert werden, um dieses Setup nachzubilden, da es intern anders funktioniert als Shoptets integrierte Lokalisierung. Shoptet-Marketplace-Apps oder -Integrationen (Zahlungsgateways, Versanddienstleister, Marketing-Tools) benötigen ebenfalls eine individuelle Bewertung gegen Shopifys App Store, um zu klären, ob ein Äquivalent existiert oder ein individueller Build nötig ist.

#### FAQ

Q: Wie bekomme ich meine Produkt- und Bestelldaten aus Shoptet heraus?
A: Über Shoptets CSV-/XML-Exporttools und dessen API - es gibt keinen direkten Datenbankzugriff, da es sich um eine geschlossene SaaS-Plattform handelt. Wir klären früh, welche Datentypen tatsächlich exportierbar sind, und kennzeichnen alles, was es nicht ist, bevor der Umfang der Migration festgelegt wird.

Q: Werden meine Shoptet-URLs automatisch zu Shopify weitergeleitet?
A: Nein. Shopifys URL-Struktur ist fest und anders als die von Shoptet, daher braucht jede indexierte Shoptet-URL eine explizite 301-Weiterleitung zu ihrem Shopify-Äquivalent - besonders relevant für über die Zeit aufgebaute CZ/SK-Suchsichtbarkeit.

Q: Kann Shopify Mehrsprachigkeit und Mehrwährungsverkauf wie Shoptet abbilden?
A: Ja, über Shopify Markets, aber es wird anders konfiguriert als Shoptets integrierte Lokalisierung - es muss bewusst eingerichtet werden, um Ihr bestehendes Multi-Markt-Setup nachzubilden, statt vorauszusetzen, dass es von Haus aus gleich funktioniert.

Q: Warum von Shoptet zu Shopify wechseln, wenn beide gehostete SaaS-Plattformen sind?
A: Die üblichen Treiber sind Reichweite und Flexibilität, nicht der Hosting-Aufwand - Shopifys globales App-Ökosystem, breitere Zahlungs- und Versandintegrationen für grenzüberschreitenden Verkauf sowie mehr Theme- und Checkout-Anpassungsoptionen für Shops, die Shoptets stärker regional ausgerichtetes Werkzeugset überwachsen haben.

Sources:
- Shopify - Migrate your store to Shopify: https://www.shopify.com/migrate
- Shoptet official site: https://www.shoptet.cz

### Migration von Shopware zu Shopify

URL: https://prevedshop.com/de/migrationen/shopware-zu-shopify
Language: de
Last reviewed: 2026-07-21
Route: shopware-6 -> shopify

Shopware ist eine flexible, auf Symfony basierende Commerce-Plattform, die im DACH-Raum verbreitet ist und sowohl selbst gehostet als auch als verwaltetes Cloud-Angebot verfügbar ist. Der Wechsel zu Shopify bedeutet, Shopwares hochgradig anpassbares Entity- und Plugin-System gegen Shopifys eingeschränktere, aber vollständig verwaltete Plattform einzutauschen. Die Kernarbeit besteht darin, Shopwares flexible Produkteigenschaften und Sales-Channel-Modell auf Shopifys festes Produktschema und App-Ökosystem zu mappen, neben der üblichen URL- und Weiterleitungsplanung, die jeder Plattformwechsel erfordert.

#### Warum Händler von Shopware wegwechseln

Shopwares Stärke - eine hochgradig erweiterbare, auf Symfony basierende Plattform mit flexiblem Entity-System und tiefer Plugin-/App-Anpassung - bringt bei Self-Hosting echten Mehraufwand mit sich: Serververwaltung, PHP- und Shopware-Versions-Upgrades sowie PCI-Compliance für den Checkout liegen bei Ihrem Team. Selbst Shopwares Cloud-Hosting-Option bedeutet weiterhin, ein Ökosystem an Plugins zu verwalten, die über Upgrades hinweg kompatibel bleiben müssen. Shopify nimmt Hosting und plattformseitiges Patchen vollständig aus Ihrer Verantwortung, auf Kosten von Shopwares tieferen codeseitigen Anpassungsoptionen.

Ein häufiger Auslöser ist derselbe, der auch bei anderen flexiblen Open-Source-Plattformen zu beobachten ist: Die Entwicklungszeit, um individuelle Shopware-Plugins zu pflegen und über Versions-Upgrades hinweg funktionsfähig zu halten, steht irgendwann nicht mehr im Verhältnis zum tatsächlichen Bedarf des Shops - besonders bei Händlern, die Shopwares Flexibilität weniger genutzt haben als erwartet.

#### Produkteigenschaften, Varianten und das Datenmodell

Shopware stellt Produktvariation über "Eigenschaften" und "Optionen" dar, die Variantenkombinationen erzeugen, ergänzt durch ein flexibles individuelles Feldsystem für Attribute außerhalb dieser Struktur. Das ist konzeptionell näher an Shopifys Variantenmodell als ein vollständiges EAV-System, aber Shopifys harte Grenze von drei Varianten-Optionsdimensionen je Produkt bedeutet, dass Shopware-Produkte mit mehr Eigenschaftsgruppen teilweise auf Shopify-Metafelder statt auf Varianten verschoben werden müssen.

Shopwares Kategoriestruktur erlaubt, wie bei den meisten Plattformen mit echtem Kategoriebaum, verschachtelte Kategorien mit flexibler Zuordnung. Shopify-Collections sind flacher - manuelle oder regelbasierte Listen statt eines verschachtelten Baums -, daher muss eine Shopware-Kategoriestruktur als Shopify-Collection-Set neu entworfen werden, statt direkt exportiert zu werden.

#### Sales Channels und Multi-Storefront

Shopwares "Sales-Channel"-Konzept erlaubt es, aus einer Shopware-Instanz mehrere Storefronts, Apps oder Marktplätze aus einem gemeinsamen Katalog zu bedienen, jeweils mit eigenen Einstellungen. Shopifys nächste Entsprechungen sind die eigenen mehreren Vertriebskanäle (Onlineshop, POS, Marktplätze) plus Shopify Markets für regionale und Währungsvariation innerhalb eines Shops, oder separate Shopify-Shops für tatsächlich getrennte Marken. Die Konzepte überschneiden sich, entsprechen sich aber nicht architektonisch direkt, daher muss ein Shopware-Sales-Channel-Setup anhand seiner tatsächlichen Nutzung auf die passende Shopify-Struktur gemappt werden, statt eine Eins-zu-eins-Übertragung vorauszusetzen.

#### URLs, Plugins und EU-spezifische Überlegungen

Shopware-SEO-URLs sind je Sales Channel konfigurierbar, daher brauchen bestehende URLs explizite 301-Weiterleitungen zu Shopifys festen Mustern (`/products/{handle}`, `/collections/{handle}`), um Suchrankings während des Umzugs zu schützen. Shopware-Plugins und -Apps für Versand, Zahlung und Checkout-Anpassung haben kein automatisches Shopify-Äquivalent und benötigen eine individuelle Bewertung - eine Shopify-App, einen individuellen Build, oder die Bestätigung, dass die Funktion nicht mehr benötigt wird.

Shopware ist EU-weit verbreitet und bringt integrierte Werkzeuge für die MwSt.-Behandlung und für DSGVO-bezogene Datenanforderungen mit, die für diesen Markt typisch sind. Shopify deckt ähnliches über Shopify Tax und eigene Compliance-Werkzeuge ab, aber die konkrete Konfiguration - Steuerregistrierung, Rechnungsformatierung, Datenverarbeitungseinstellungen - muss für Shopify geprüft und neu eingerichtet werden, statt eine automatische Übernahme vorauszusetzen.

#### FAQ

Q: Lassen sich Shopware-Produkteigenschaften sauber auf Shopify-Varianten übertragen?
A: Für die Standardnutzung von Varianten recht gut, da Shopware-Eigenschaften konzeptionell ähnlich zu Shopifys Variantenoptionen sind. Produkte mit mehr als drei Eigenschaftsgruppen benötigen teilweise ein Mapping auf Shopify-Metafelder, da Shopify Produkte auf drei Varianten-Optionsdimensionen begrenzt.

Q: Was passiert mit meinen Shopware Sales Channels?
A: Es gibt kein exaktes Shopify-Äquivalent - Shopifys eigene mehrere Vertriebskanäle, Shopify Markets und separate Shops decken jeweils einen Teil dessen ab, was ein Shopware-Sales-Channel-Setup kann. Wir mappen Ihren tatsächlichen Anwendungsfall (Regionen, Marken, Marktplätze) während der Bewertung auf die passende Shopify-Struktur.

Q: Werden meine Shopware-URLs automatisch zu Shopify weitergeleitet?
A: Nein. Shopifys URL-Struktur ist fest, daher braucht jede indexierte Shopware-URL eine explizite 301-Weiterleitung zu ihrem Shopify-Äquivalent - Teil des Migrationsplans, kein nachträglicher Gedanke.

Q: Überträgt sich Shopwares EU-MwSt.- und DSGVO-Setup auf Shopify?
A: Nicht automatisch. Shopify hat eigene Steuer- und Compliance-Werkzeuge (Shopify Tax und zugehörige Einstellungen), aber Steuerregistrierung, Rechnungsformatierung und Datenverarbeitungskonfiguration müssen speziell für Shopify geprüft und eingerichtet werden, statt eine Übernahme aus Shopware vorauszusetzen.

Sources:
- Shopify - Migrate your store to Shopify: https://www.shopify.com/migrate
- Shopware official site and documentation: https://www.shopware.com

### Migration von WooCommerce zu BigCommerce

URL: https://prevedshop.com/de/migrationen/woocommerce-zu-bigcommerce
Language: de
Last reviewed: 2026-07-21
Route: woocommerce -> bigcommerce

WooCommerce läuft als WordPress-Plugin, daher sind seine Daten, sein Hosting und seine Performance an Ihre WordPress-Installation gebunden. Der Wechsel zu BigCommerce trennt Commerce von Ihrem WordPress-Content-Stack und übergibt Hosting, PCI-Compliance und plattformseitige Sicherheit an BigCommerce - während Sie mehr native Variantenflexibilität und URL-Kontrolle erhalten als bei den meisten SaaS-Wettbewerbern. Die Arbeit besteht darin, WooCommerces WordPress-basierte Produkt- und Inhaltsdaten auf BigCommerces Struktur zu mappen, ohne dabei SEO-Wert zu verlieren oder plugin-abhängige Funktionalität zu zerstören.

#### Warum Händler von WooCommerce wegwechseln

WooCommerce selbst ist kostenlos, aber es zu betreiben bedeutet, WordPress-Kern- und Plugin-Updates, Hosting-Performance, serverseitige Sicherheit und PCI-Compliance für den Checkout selbst zu verantworten. Mit wachsendem Shop werden Plugin-Konflikte und die Auswirkung eines wachsenden Plugin-Stacks auf die Ladegeschwindigkeit zu echten, wiederkehrenden Kosten - ganz zu schweigen von der Entwicklungs- oder Agenturzeit, die nötig ist, um alles gepatcht und kompatibel zu halten. BigCommerce nimmt als verwaltete SaaS-Plattform diesen Hosting- und Patch-Aufwand ab, im Austausch dafür, dass Sie innerhalb der Plattformgrenzen arbeiten.

Shops, die aus ihrem WordPress-Hosting-Setup herauswachsen oder der Zerbrechlichkeit eines wachsenden Plugin-Stacks überdrüssig sind, sind die häufigsten Kandidaten für diesen Wechsel.

#### Produktdaten: näher dran, als man erwarten würde

WooCommerce speichert Produkte als individuellen WordPress-Beitragstyp, mit Variationen und Attributen auf Basis von WordPress-Taxonomien - flexibel, da WordPress kaum harte Grenzen für individuelle Felder setzt. BigCommerces Produktmodell ist strukturierter, aber bei Varianten spürbar großzügiger als manche SaaS-Wettbewerber und unterstützt eine größere Zahl an Variantenkombinationen je Produkt neben individuellen Feldern und Produktmodifikatoren für Attribute außerhalb der Variantenstruktur. Trotzdem brauchen WooCommerce-Produkte mit starker Nutzung von ACF (Advanced Custom Fields) oder vielen individuellen Attributen einen bewussten Mapping-Plan zu BigCommerce-individuellen Feldern, statt einer blinden Kopie.

WooCommerce-Kategorien und -Tags sind WordPress-Taxonomien, die frei verschachtelt und kreuzweise zugeordnet werden können. BigCommerces Kategoriebaum ist näher an einer traditionellen Hierarchie als Shopifys flache Collections, was die Übertragung einer WooCommerce-Kategoriestruktur etwas direkter macht - trotzdem lohnt sich eine Prüfung statt eines unveränderten Exports.

#### URLs, Inhalte und Plugins

WordPress-Permalinks sind vollständig konfigurierbar, daher passen WooCommerce-URLs selten standardmäßig zu einem festen Muster. BigCommerce erlaubt anders als manche SaaS-Plattformen individuelle URL-Pfade ohne verpflichtendes Präfix, was das Erhalten einer bestehenden WooCommerce-URL-Struktur erleichtern kann - aber jede URL, die sich doch ändert, braucht weiterhin eine explizite 301-Weiterleitung, und jede indexierte WooCommerce-URL sollte ohnehin gegen ihr BigCommerce-Äquivalent geprüft werden.

Es gibt außerdem die WordPress-Content-Frage: Viele WooCommerce-Shops nutzen WordPress als vollständiges CMS für Blog- und Landingpage-Inhalte, wofür es innerhalb von BigCommerces eingeschränkteren Content-Tools keine direkte Entsprechung gibt. Shops mit umfangreichem WordPress-Content brauchen einen Plan - ihn in BigCommerce-Seiten migrieren, oder WordPress separat für Inhalte weiterlaufen lassen, während BigCommerce Commerce übernimmt. WooCommerce-Plugins für Versand, Abonnements oder individuelle Checkout-Felder brauchen ebenfalls eine individuelle Bewertung: ein BigCommerce-App-Äquivalent, ein individueller Build, oder die Bestätigung, dass sie nicht mehr benötigt werden.

#### FAQ

Q: Unterstützt BigCommerce WooCommerces Varianten- und Attribut-Setup?
A: BigCommerce unterstützt mehr Variantenkombinationen je Produkt als manche SaaS-Wettbewerber, was bei komplexen WooCommerce-Katalogen hilft, aber es gibt weiterhin kein automatisches Äquivalent zu WordPress-individuellen Feldern oder ACF-Daten - diese müssen bewusst auf BigCommerce-individuelle Felder gemappt werden.

Q: Was passiert mit meinem WordPress-Blog und meinen Landingpages?
A: Sie migrieren nicht automatisch, da BigCommerces Content-Tools enger gefasst sind als die von WordPress. Sie können Blogbeiträge und Seiten in BigCommerce migrieren oder WordPress separat für Inhalte weiterlaufen lassen, während BigCommerce Commerce übernimmt - wir helfen bei der Entscheidung, je nachdem, wie viel Traffic dieser Content bringt.

Q: Müssen sich meine WooCommerce-URLs bei BigCommerce ändern?
A: Weniger, als Sie beim Wechsel zu manchen anderen SaaS-Plattformen erwarten würden, da BigCommerce individuelle URL-Pfade ohne verpflichtendes Präfix erlaubt. Jede URL, die sich doch ändert, braucht weiterhin eine explizite 301-Weiterleitung, und wir prüfen ohnehin jede indexierte WooCommerce-URL vor dem Launch.

Q: Kann BigCommerce alle meine WooCommerce-Plugins ersetzen?
A: Die meisten haben ein BigCommerce-App-Äquivalent, aber nicht alle - manche Plugin-Funktionalität benötigt einen individuellen Build gegen BigCommerces APIs, und manche entfällt, wenn sie nicht mehr benötigt wird. Wir erfassen Ihre aktiven Plugins während der Bewertung, bevor der Umfang der Arbeit festgelegt wird.

Sources:
- BigCommerce official site and documentation: https://www.bigcommerce.com
- WooCommerce documentation: https://woocommerce.com/documentation/

### Migration von WooCommerce zu Shopify

URL: https://prevedshop.com/de/migrationen/woocommerce-zu-shopify
Language: de
Last reviewed: 2026-07-21
Route: woocommerce -> shopify

WooCommerce läuft als Plugin auf WordPress, was bedeutet, dass die Daten, das Hosting und die Performance Ihres Shops eng mit Ihrer WordPress-Installation verflochten sind. Der Wechsel zu Shopify trennt Commerce von Content: Sie erhalten eine verwaltete, PCI-konforme Hosting-Plattform und ein zweckgebundenes Produkt-/Checkout-Modell, verlieren aber auch WordPress' native Flexibilität für Inhalte und die direkte Plugin-zu-App-Entsprechung, die Sie vielleicht erwarten. Die Kernarbeit besteht darin, WooCommerces WordPress-basiertes Datenmodell auf Shopifys festes Schema zu mappen, ohne dabei SEO-Wert zu verlieren oder individuelle Funktionalität zu zerstören.

#### Warum Händler von WooCommerce wegwechseln

WooCommerce ist kostenlos zu installieren, aber es gut zu betreiben, ist es nicht: Sie sind für WordPress-Kern- und Plugin-Updates, Hosting-Performance, serverseitige Sicherheit und PCI-Compliance für alles verantwortlich, was Zahlungsdaten berührt. Mit wachsendem Shop werden Plugin-Konflikte, Ladegeschwindigkeitsprobleme durch einen wachsenden Plugin-Stack und die wiederkehrenden Kosten für einen Entwickler oder eine Agentur, um alles gepatcht zu halten, zu den echten Kosten "kostenloser" Software. Shopify tauscht diesen laufenden Wartungsaufwand gegen eine feste Plattformgebühr und eine verwaltete, PCI-konforme Umgebung.

Ein häufiger Auslöser ist Skalierung: WooCommerces Performance hängt stark von Hosting-Qualität und Plugin-Disziplin ab, und klein gestartete Shops erreichen oft einen Punkt, an dem Traffic oder Kataloggröße das übersteigen, wofür ihr WordPress-Hosting-Setup gebaut war.

#### Was sich im Datenmodell ändert

WooCommerce speichert Produkte als individuellen WordPress-Beitragstyp, mit Variationen, Attributen und Kategorien auf Basis von WordPress-Taxonomien - eine flexible Struktur, da WordPress kaum Grenzen für individuelle Felder setzt. Shopifys Produktmodell ist enger begrenzt: ein fester Satz an Kernfeldern, bis zu drei Varianten-Optionsdimensionen und Metafelder für alles Weitere. Produkte mit vielen individuellen WooCommerce-Attributen oder ACF-Daten (Advanced Custom Fields) brauchen eine bewusst geplante Metafeldstruktur statt einer blinden feldweisen Kopie.

WooCommerce-Produktkategorien und -Tags sind WordPress-Taxonomien und können frei verschachtelt und kreuzweise zugeordnet werden. Shopify-Collections sind entweder manuelle Listen oder regelbasierte ("Smart") Collections statt eines echten Taxonomiebaums, daher muss eine tiefe WooCommerce-Kategoriestruktur meist als flacheres Collection-Set neu entworfen werden, nicht unverändert exportiert.

#### URLs, Weiterleitungen und die Content-Frage

WordPress-Permalinks sind vollständig konfigurierbar, daher können WooCommerce-Produkt- und Kategorie-URLs beinahe jede Form haben, für die sich eine Seite entschieden hat. Shopify erzwingt eigene Muster (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`, `/blogs/{blog}/{handle}`), daher braucht jede indexierte WooCommerce-URL, die nicht bereits passt, eine 301-Weiterleitung, um den Umzug ohne Rankingverlust zu überstehen.

Es gibt außerdem eine für dieses Paar spezifische Content-Frage: WordPress ist ein vollständiges CMS, und viele WooCommerce-Shops verlassen sich darauf für Blog-Inhalte, Landingpages und individuelle Seitenvorlagen. Shopifys Blog- und Seiten-Tools sind einfacher als die von WordPress. Shops mit umfangreichem WordPress-Content brauchen einen Plan dafür - ihn in Shopify-Seiten/-Blog migrieren, oder eine separate WordPress-Instanz für Inhalte behalten, während Shopify Commerce übernimmt -, bewusst entschieden statt erst nach dem Umzug entdeckt.

#### Plugins, Checkout und Zahlungsgateways

WooCommerces Plugin-Ökosystem deckt alles von Versandrechnern über Abo-Abrechnung bis zu individuellen Checkout-Feldern ab, oft über Drittanbieter-Plugins ohne direktes Shopify-Gegenstück. Jedes aktive Plugin braucht während der Migration eine explizite Entscheidung: eine äquivalente Shopify-App, eine individuelle App oder Theme-Anpassung, oder die Bestätigung, dass die Funktion nicht mehr benötigt wird. Auch Zahlungsgateways müssen neu konfiguriert werden - WooCommerce unterstützt eine breite Palette an Gateway-Plugins, während Shopify Zahlungen über Shopify Payments oder ein unterstütztes Drittanbieter-Gateway zentralisiert, daher muss jede individuelle Checkout-Logik, die an ein bestimmtes WooCommerce-Zahlungs-Plugin gebunden ist, für Shopifys Checkout-Modell neu aufgebaut werden.

#### FAQ

Q: Überstehen meine WooCommerce-SEO-Rankings den Wechsel zu Shopify?
A: Das können sie, aber nur mit bewusstem Weiterleitungs-Mapping. WordPress-Permalinks und Shopifys feste URL-Struktur passen selten exakt zusammen, daher braucht jede indexierte WooCommerce-URL vor dem Launch eine explizite 301-Weiterleitung zu ihrem Shopify-Äquivalent - siehe unseren Service SEO- und Weiterleitungsmigration.

Q: Was passiert mit meinem WordPress-Blog und meinen Landingpages?
A: Sie migrieren nicht automatisch, da Shopifys Content-Tools enger gefasst sind als die von WordPress. Sie können Blogbeiträge und Seiten in Shopify migrieren oder eine separate WordPress-Instanz für Inhalte behalten, während Shopify Commerce übernimmt - wir helfen bei der Entscheidung, je nachdem, wie stark Ihr Traffic von diesem Content abhängt.

Q: Kann Shopify alle meine WooCommerce-Plugins ersetzen?
A: Die meisten haben ein Shopify-App-Äquivalent, aber nicht alle - manche WooCommerce-Plugin-Funktionalität benötigt eine individuelle App oder Theme-Anpassung auf Shopify, und manche entfällt, wenn sie nicht mehr benötigt wird. Wir erfassen Ihre aktiven Plugins während der Bewertung, bevor der Umfang der Arbeit festgelegt wird.

Q: Was passiert mit WooCommerce-Produktvariationen und individuellen Attributen?
A: Standardvariationen werden auf Shopifys Variantensystem gemappt, begrenzt auf drei Optionsdimensionen. Individuelle WooCommerce-Attribute und ACF-Felder darüber hinaus müssen bewusst auf Shopify-Metafelder gemappt werden - es gibt keine automatische Eins-zu-eins-Umwandlung aus WordPress-individuellen Feldern.

Sources:
- Shopify - Migrate your store to Shopify: https://www.shopify.com/migrate
- WooCommerce documentation: https://woocommerce.com/documentation/

### Migration von WooCommerce zu Shoptet

URL: https://prevedshop.com/de/migrationen/woocommerce-zu-shoptet
Language: de
Last reviewed: 2026-09-02
Route: woocommerce -> shoptet

Shoptet ist eine gehostete Plattform für tschechische und slowakische Händler mit nativer Unterstützung lokaler Versanddienstleister, Zahlungsanbieter, Rechnungsregeln und Preisvergleichs-Feeds. Der Wechsel von WooCommerce bedeutet, einen selbst gehosteten WordPress-Stack gegen ein verwaltetes System mit festem Datenmodell zu tauschen. Die eigentliche Migration übersetzt WordPress-Produktbeiträge, Taxonomien und Plugin-Daten in die Importstruktur von Shoptet, erhält Kunden- und Bestellhistorie dort, wo sie zählt, und schützt die URLs, die Ihren Suchtraffic tragen.

#### Warum Händler von WooCommerce zu Shoptet wechseln

Die meisten Shops wechseln, weil ein sauber betriebenes WordPress Zeit kostet: Plugin-Updates, Hosting-Performance, Sicherheitspatches und PCI-Verantwortung liegen beim Händler. Shoptet ersetzt das durch eine Monatsgebühr und eine verwaltete Umgebung, die Zásilkovna, PPL, GoPay, Comgate, Heureka und Zboží.cz bereits anbindet. Wenn Ihre Kunden in Tschechien oder der Slowakei sitzen, ersetzen die eingebauten Integrationen meist mehrere WooCommerce-Plugins auf einmal. Der Preis ist Flexibilität: Das Produkt- und Content-Modell von Shoptet ist enger als WordPress, deshalb braucht alles Individuelle einen bewusst festgelegten Platz.

#### Mapping von Produkten, Varianten und Parametern

WooCommerce speichert Produkte als WordPress-Beiträge mit Attributen, Variationen und Kategorien auf Basis von Taxonomien. Shoptet erwartet einen strukturierten Import, in dem Produkte, Varianten, Parameter, Kategorien und Verfügbarkeit in eigenen Feldern definiert sind. Variationen werden zu Shoptet-Varianten, sofern die Optionsstruktur konsistent ist; Filterattribute werden zu Parametern, die vor dem Import angelegt und benannt werden müssen. Kategoriebäume können in beiden Systemen verschachtelt sein, Shoptet arbeitet aber am besten mit einer sauberen, flachen Hierarchie. Eigene Felder aus ACF oder Plugins haben kein automatisches Ziel und werden einzeln entschieden: Beschreibungstext, Parameter oder Wegfall.

#### Kunden, Bestellungen und URL-Weiterleitungen

Kundenkonten lassen sich mit Kontaktdaten und Adressen importieren; Passwörter können nicht übernommen werden, Kunden erhalten im neuen Shop einen Reset-Ablauf. Die Bestellhistorie wird zur Referenz und für Auswertungen importiert, nicht als erneut bearbeitbare Live-Bestellungen. Der sensibelste Teil sind URLs: WordPress-Permalinks sind frei, Shoptet nutzt eigene Pfadmuster, deshalb braucht jedes indexierte Produkt, jede Kategorie und Seite vor dem Launch eine 301-Weiterleitung auf das Shoptet-Pendant. Weiterleitungen sichern URL-Kontinuität und senken das Risiko; keine Migration kann unveränderte Rankings garantieren.

#### Umstellung und die ersten Tage auf Shoptet

Wir empfehlen, den Shoptet-Shop zunächst im Testmodus mit vollständig importiertem Katalog zu betreiben, eine Stichprobe von Produkten, Preisen, Steuersätzen und Varianten zu prüfen und erst dann den DNS umzustellen. Feeds für Heureka und Zboží.cz sollten aus Shoptet neu erzeugt und eingereicht werden, die Google Search Console erhält am Launch-Tag die neue Sitemap. Lassen Sie WordPress kurz schreibgeschützt erreichbar, damit nichts verloren geht, bis die Weiterleitungskarte bestätigt ist.

#### FAQ

Q: Kann ich WooCommerce-Bestellungen und Kunden zu Shoptet migrieren?
A: Kunden mit Adressen können importiert werden. Bestellungen werden als Historie zur Referenz importiert und werden nicht zu bearbeitbaren Live-Bestellungen. Passwörter sind nie übertragbar, Kunden vergeben beim ersten Login ein neues.

Q: Funktionieren meine WooCommerce-URLs auf Shoptet weiter?
A: Nur mit einer expliziten 301-Weiterleitungskarte. Die URL-Muster von WordPress und Shoptet unterscheiden sich, deshalb bauen wir das Mapping aus Ihren indexierten URLs und prüfen es vor dem Launch.

Q: Was passiert mit den WooCommerce-Plugins?
A: Jedes Plugin wird geprüft. Viele Funktionen für den tschechischen Markt sind in Shoptet nativ, einige haben Add-ons, der Rest braucht eine individuelle Lösung oder entfällt nach Absprache.

Q: Wie lange dauert eine Migration von WooCommerce zu Shoptet?
A: Ein kleiner bis mittlerer Katalog braucht typischerweise zwei bis vier Wochen inklusive Testlauf, Weiterleitungen und Go-live; komplexe Parameterstrukturen oder große Bestellhistorien dauern länger.

Sources:
- Shoptet Developers - Datenimport: https://developers.shoptet.com/shoptet-tools/data-import/
- WooCommerce - Produkt-CSV-Importer und -Exporter: https://woocommerce.com/document/product-csv-importer-exporter/

### Guides

### So wählen Sie eine Ecommerce-Plattform, bevor Sie migrieren

URL: https://prevedshop.com/de/leitfaeden/ecommerce-plattform-auswaehlen
Language: de
Last reviewed: 2026-09-02

Die Plattformwahl ist die Entscheidung, die die Kosten jeder späteren Migration bestimmt. Feature-Listen der Anbieter helfen selten, weil die meisten modernen Plattformen die Grundlagen abdecken. Die nützlichen Fragen betreffen Ihre Katalogstruktur, den Markt, in den Sie verkaufen, die Systeme, die angebunden bleiben müssen, wie viel Datenhoheit Sie wollen und was die Migration selbst verlangt. Dieser Leitfaden geht diese fünf Fragen durch und endet mit einer kurzen Liste von Warnsignalen, die eine Entscheidung stoppen sollten.

#### Beginnen Sie beim Katalog, nicht bei der Feature-Liste

Zählen Sie Produkte, Varianten und Parameter und schauen Sie, wie sie zusammenhängen. Drei Optionsdimensionen mit einem sauberen Satz Filterattribute passen in fast jede Plattform. Nach Produkttyp unterschiedliche Attributsets, Bundles, Konfiguratoren, B2B-Preislisten oder Tausende Varianten engen die Auswahl auf Plattformen mit reicherem Datenmodell ein, etwa Adobe Commerce, Shopware oder einen Composable-Stack. Notieren Sie die fünf sperrigsten Produkte Ihres Katalogs und fragen Sie jede Kandidatin, wie sie diese speichern würde; die Antworten verraten mehr als jede Vergleichstabelle.

#### Markt, Sprache und Integrationen

Ein Shop für tschechische und slowakische Kunden braucht lokale Versanddienstleister, Zahlungsanbieter, Preisvergleichs-Feeds und Rechnungsregeln. Shoptet oder Upgates liefern das nativ; eine globale SaaS-Plattform schafft es über Apps mit Zusatzkosten und Wartung. Verkauf in mehrere Länder wirft andere Fragen auf: Sprachmutationen, Währungen, Mehrwertsteuer und ob ein Shop oder mehrere die richtige Form sind. Listen Sie die Systeme, die angebunden bleiben müssen - ERP, Buchhaltung, Lager, PIM, Marktplatz-Feeds - und prüfen Sie, ob jede Kandidatin einen gepflegten Konnektor hat oder nur eine API, gegen die Sie selbst bauen müssten.

#### Datenhoheit, Kosten und Migrationsweg

Gehostete Plattformen tauschen Kontrolle gegen Komfort: Sie rühren die Datenbank nicht an, patchen aber auch nie einen Server. Open-Source-Plattformen geben Ihnen Daten und Verantwortung. Gesamtkosten umfassen Lizenz oder Tarif, Hosting, Apps oder Extensions, Agenturstunden und die interne Zeit für Updates. Bepreisen Sie zuletzt die Migration selbst: wie viele Daten Sie übernehmen, ob Bestellhistorie und Kundenkonten zählen, wie viele URLs Weiterleitungen brauchen und welche Sonderfunktionen neu gebaut werden müssen. Eine auf dem Papier günstigere Plattform kann mit dem Migrationsaufwand teurer werden.

#### Warnsignale, die die Entscheidung stoppen sollten

Seien Sie vorsichtig, wenn eine Plattform nicht zeigen kann, wie ein bestimmter Datentyp aus Ihrem aktuellen Shop abgebildet wird, wenn eine wesentliche Integration nur als Drittanbieter-App mit unklarer Wartung existiert, wenn der Anbieter verspricht, dass sich Rankings nach der Migration nicht ändern, oder wenn niemand erklären kann, wie Sie die Plattform später wieder verlassen. Eine kurze Discovery mit echten Datenproben klärt das meiste, bevor Sie etwas unterschreiben.

#### FAQ

Q: Sollte ich die Plattform vor oder nach der Migrationsbewertung wählen?
A: Idealerweise fließt die Bewertung in die Wahl ein. Eine kurze Discovery mit echten Produkt-, Kunden- und Bestellproben zeigt, wie jede Kandidatin Ihre Daten speichern würde und wie viel Neuaufbau die Migration bräuchte.

Q: Ist eine gehostete Plattform immer günstiger als Open Source?
A: Nicht immer. Gehostete Plattformen haben planbare Gebühren, aber App-Kosten summieren sich; Open Source hat keine Lizenzgebühr, braucht aber Hosting, Updates und Entwicklerzeit. Vergleichen Sie die Gesamtkosten über drei Jahre inklusive Migration.

Q: Wie wichtig ist die Ecommerce-Plattform für SEO?
A: Weniger als der Migrationsprozess. Jede gängige Plattform kann gut ranken; Sichtbarkeit verliert man durch eine fehlende Weiterleitungskarte, veränderte Inhalte oder langsame Seiten nach dem Umzug.

Q: Kann ich die Plattform später erneut wechseln?
A: Ja, solange Ihre Daten exportierbar bleiben. Prüfen Sie vor der Wahl, dass Produkte, Kunden, Bestellungen und Inhalte strukturiert exportiert werden können, damit die nächste Migration ohne Anbieterhilfe möglich ist.

Sources:
- Google Search Central: Websiteumzug mit URL-Änderungen: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### Die Post-Launch-QA-Checkliste

URL: https://prevedshop.com/de/leitfaeden/qa-checkliste-nach-dem-go-live
Language: de
Last reviewed: 2026-07-21

Die Migration ist nicht in dem Moment fertig, in dem der neue Shop live geht - sie ist fertig, wenn Sie bewusst bestätigt haben, dass alles, worauf Kunden und Suchmaschinen angewiesen sind, unter realen Bedingungen tatsächlich funktioniert. Staging fängt die meisten Probleme ab, aber ein paar zeigen sich erst mit echtem Traffic, echten Zahlungsdienstleistern und Suchmaschinen, die die Seite erneut crawlen. Diese Checkliste behandelt, was Sie in den Tagen und Wochen nach dem Umzug prüfen sollten - unabhängig davon, welche Plattformen beteiligt waren.

#### Prüfen Sie den Checkout-Ablauf komplett unter realen Bedingungen

Führen Sie selbst einen vollständigen Kauf auf der Live-Seite durch - nicht auf Staging - und decken Sie die Pfade ab, die Kunden tatsächlich nutzen: Checkout als Gast und eingeloggt, mindestens ein Produkt mit Varianten sowie aktuell aktive Rabattcodes oder Aktionen. Prüfen Sie, ob Bestellbestätigungs-E-Mails korrekt versendet werden und die Bestellung anschließend richtig in Ihrem Admin-/Bestellsystem erscheint.

Gehen Sie nicht davon aus, dass die Staging-Abdeckung automatisch übertragen wird. Live-Zahlungsgateways, Live-Steuerdienste und Live-Versandkosten-APIs verhalten sich manchmal anders als ihre Staging- oder Sandbox-Äquivalente - genau deshalb braucht es eine echte Prüfung unter Live-Bedingungen, statt sich darauf zu verlassen, was im Staging funktioniert hat.

#### Bestätigen Sie, dass Zahlungsgateways vollständig live und korrekt konfiguriert sind

Prüfen Sie, dass die Zahlungsabwicklung im Live- (nicht Test-/Sandbox-)Modus läuft, dass alle bisher unterstützten Zahlungsmethoden aktiviert sind und funktionieren, und dass eine echte Transaktion durchgängig korrekt abgewickelt wird - Geld kommt tatsächlich an, nicht nur der Bestellstatus ändert sich. Prüfen Sie auch die Rückerstattungsfunktion, da sie seltener genutzt wird als der Checkout und leicht ungeprüft bleibt.

Unterstützen Sie mehrere Zahlungsmethoden oder Währungen, testen Sie jede einzeln, statt anzunehmen, dass alle gleich konfiguriert sind, nur weil eine funktioniert.

#### Prüfen Sie Steuer- und Versandregeln anhand echter Bestellungen

Steuer- und Versandlogik geraten bei einer Migration leicht in feine Fehler, da beide oft von Konfiguration abhängen, die sich nicht sauber zwischen Plattformen mappen lässt. Geben Sie Testbestellungen an Ihre häufigsten Versandziele auf und bestätigen Sie, dass Steuern korrekt berechnet werden und Versandkosten sowie verfügbare Methoden dem entsprechen, was Sie beabsichtigt haben - nicht nur dem, was die neue Plattform standardmäßig eingestellt hat.

Achten Sie besonders auf Sonderfälle, auf die sich Ihr Geschäft verlässt: Steuerbefreiungen, Schwellenwerte für kostenlosen Versand, regionsspezifische Regeln oder Versandbeschränkungen für bestimmte Produkte. Genau diese Konfigurationsdetails gehen bei einer Migration am ehesten verloren oder werden falsch auf Standardwerte gesetzt.

#### Prüfen Sie Weiterleitungen stichprobenartig - nicht nur die, an die Sie sich erinnern

Auch bei einer vollständigen, vor dem Launch erstellten Weiterleitungskarte sollten Sie nach dem Umzug eine echte Stichprobe von URLs prüfen: Ihre meistbesuchten Seiten, eine Handvoll weniger besuchte und einige der bewussten Ausnahmen (eingestellte Produkte, zusammengeführte Kategorien). Bestätigen Sie, dass jede in einem Sprung zum richtigen Ziel weiterleitet, ohne Ketten oder Schleifen.

Prüfen Sie zusätzlich eine Stichprobe von URLs, die es auf der alten Seite eigentlich nicht geben sollte - Tippfehler, alte parameterbasierte URLs, alles, was ein Crawler zufällig indexiert haben könnte -, um sicherzustellen, dass sie sinnvoll aufgelöst werden statt so zu fehlern, dass es wie ein größeres Problem aussieht.

#### Bestätigen Sie die Kontinuität von Analytics und Tracking

Prüfen Sie, dass Ihre Analytics-Plattform, Conversion-Tracking und etwaige Werbe-Pixel auf der neuen Seite korrekt auslösen - eine platzierte Testbestellung sollte in Ihrem Analytics- und Ad-Plattform-Reporting genauso erscheinen wie vorher. Tracking-Code geht bei einem Plattformwechsel leicht unbemerkt verloren, da ein fehlendes oder falsch konfiguriertes Pixel keine Fehlermeldung erzeugt - es meldet einfach keine Daten mehr.

Vergleichen Sie frühe Analytics-Zahlen nach dem Launch mit Ihrer Basislinie vor der Migration für denselben Tagestyp (Wochentag vs. Wochenende, ähnliche Trafficquellen), statt einen rohen Vorher-Nachher-Vergleich anzustellen, da normale Traffic-Schwankungen sonst ein echtes Tracking-Problem verschleiern oder vortäuschen können.

#### Prüfen Sie Kundenkontenzugriff und Bestellhistorie

Lassen Sie einige echte (oder Test-)Kundenkonten bestätigen, dass sie sich einloggen können, ihre korrekte Bestellhistorie sehen und auf Kontofunktionen zugreifen können, auf die sie vorher angewiesen waren - gespeicherte Adressen, gespeicherte Zahlungsmethoden, sofern zutreffend, sowie Treue- oder Bonuspunkte, falls Ihr Shop diese hat. Probleme beim Kontenzugriff sind für betroffene Kunden sehr sichtbar und wirken sich direkt auf das Vertrauen aus - es lohnt sich, sie bewusst zu prüfen, statt anzunehmen, die Kontenmigration habe "wahrscheinlich funktioniert".

War die Passwortmigration nicht Teil der technischen Übertragung (häufig, wenn Plattformen inkompatible Passwort-Hashing-Verfahren nutzen), stellen Sie sicher, dass Kunden einen klaren Passwort-Reset-Weg haben und dieser auch kommuniziert wird, nicht nur technisch verfügbar ist.

#### Beobachten Sie die Search-Console-Abdeckung in den folgenden Wochen

Beobachten Sie Search Console (oder das Äquivalent anderer Suchmaschinen) noch lange nach dem Launch-Tag weiter - Crawling-Fehler, Indexierungsstatus und jeder Anstieg gemeldeter 404-Fehler sind die frühesten Signale für ein Weiterleitungs- oder Canonical-Problem, das die Tests übersehen haben. Vergleichen Sie mit Ihrer Basislinie vor der Migration, damit Sie eine echte Verschlechterung von normalen kurzfristigen Schwankungen nach einer Seitenänderung unterscheiden können.

In dieser Beobachtungsphase lohnt es sich auch, Ihre Sitemap erneut einzureichen, falls noch nicht geschehen, und zu bestätigen, dass Seiten, die Sie indexiert erwarten, in den folgenden Wochen tatsächlich in den Suchergebnissen erscheinen, nicht nur gecrawlt werden.

#### FAQ

Q: Wie lange sollte die Post-Launch-QA nach dem Umzug fortgesetzt werden?
A: Aktive, nahezu tägliche Prüfungen sind meist in den ersten ein bis zwei Wochen am wichtigsten, wenn die meisten Konfigurations- und Weiterleitungsprobleme auftauchen. Die Neuindexierung durch Suchmaschinen und die Stabilisierung der Traffic-Muster dauern länger, daher lohnt sich leichteres Monitoring (Search Console, Analytics-Trends) über einen längeren Zeitraum - mehrere Wochen sind üblich -, statt es zu beenden, sobald die erste Woche sauber aussieht.

Q: Was ist die wichtigste Einzelprüfung direkt nach dem Launch?
A: Ein echter, live durchgeführter Checkout- und Zahlungstest, da er direkt den Umsatz betrifft und der eine Ablauf ist, den jeder Kunde durchläuft. Weiterleitungs- und Trackingprobleme zählen ebenfalls, aber ein defekter Checkout ist das teuerste Problem, wenn es auch nur für ein paar Stunden unentdeckt bleibt.

Q: Ist es normal, dass Suchrankings direkt nach einer Migration leicht sinken?
A: Kurzfristige Schwankungen sind selbst bei einer gut ausgeführten Migration üblich, da Suchmaschinen Zeit brauchen, um die neuen URLs erneut zu crawlen und neu zu bewerten. Nicht normal ist ein anhaltender Rückgang oder ein Anstieg von Crawling-Fehlern - das ist das Signal, Ihre Weiterleitungskarte und Canonical-Tags auf einen echten Fehler zu prüfen, statt abzuwarten.

Q: Wer im Team sollte die Post-Launch-QA verantworten?
A: Idealerweise jemand mit Überblick über den gesamten Shop, nicht nur das technische Migrationsteam - denn mehrere dieser Prüfungen (ob Steuerregeln stimmig wirken, wie sich Kundenkonten verhalten, ob Tracking-Zahlen normal aussehen) profitieren von Geschäftskontext, nicht nur von der technischen Bestätigung, dass eine Funktion vorhanden ist.

Sources:
- Google Search Central: Site moves with URL changes: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### Produktdatenbereinigung vor der Migration

URL: https://prevedshop.com/de/leitfaeden/produktdaten-bereinigen-vor-der-migration
Language: de
Last reviewed: 2026-07-21

Eine Plattformmigration kopiert, was Sie ihr geben - sie räumt nicht hinter Ihnen auf. Doppelte SKUs, verwaiste Bilder, uneinheitliche Kategorien und nicht übereinstimmende Variantenstrukturen, die sich über Jahre still angesammelt haben, ziehen unverändert auf die neue Plattform um, wenn sich niemand vorher darum kümmert. Diese Bereinigung vor der Migration durchzuführen, ist weit günstiger als danach, wenn Kunden und Suchmaschinen sich bereits auf das Ergebnis verlassen. Dieser Leitfaden zeigt, worauf zu achten ist und wie Sie vorgehen.

#### Doppelte SKUs und nahezu doppelte Produkte finden und auflösen

Exportieren Sie Ihre vollständige Produktliste und prüfen Sie zunächst auf exakte SKU-Duplikate - meist ein Erfassungs- oder Importfehler und einfach zu bereinigen, sobald gefunden. Suchen Sie danach nach Beinahe-Duplikaten: dasselbe Produkt, erneut unter einer anderen SKU angelegt, oft Ergebnis eines erneut importierten Lieferanten-Feeds, der nicht mit bestehenden Datensätzen abgeglichen wurde, oder eines Produkts, das nach einer Systemänderung manuell neu angelegt statt bearbeitet wurde.

Entscheiden Sie für jedes Duplikat-Paar, welcher Datensatz der "echte" ist - meist derjenige mit vollständigeren Daten, mehr Bestellhistorie oder besseren SEO-Signalen wie Backlinks oder Bewertungen - und führen Sie den anderen zusammen oder leiten Sie ihn dorthin um, statt beide zu migrieren und es später auf der neuen Plattform zu klären.

#### Verwaiste Bilder und Medien aufspüren

Verwaiste Medien - Bilder und Dateien in Ihrer Mediathek, auf die kein Produkt, keine Kategorie und keine Inhaltsseite mehr verweist - sammeln sich über Jahre von Produktaktualisierungen, saisonalen Kampagnen und Plattformänderungen ganz natürlich an. Sie bringen auf der neuen Plattform keinen Mehrwert und erhöhen nur Migrationszeit und Speicherbedarf, daher lohnt es sich, sie zu identifizieren und auszuschließen.

Achten Sie auch auf den umgekehrten Fall: Bilder, die referenziert, aber defekt sind (fehlende Datei, tote externe URL), sollten Sie jetzt erfassen, da ein defektes Bild auf einer Produktseite ein kleines, aber echtes Vertrauensproblem ist, das sich gegen Ihre aktuellen, vertrauten Daten deutlich leichter beheben lässt als nach dem Umzug.

#### Kategorien und Attribute vereinheitlichen

Jahre ad hoc vorgenommener Ergänzungen führen tendenziell zu uneinheitlichen Kategorien und Attributen: dasselbe Konzept produktübergreifend unterschiedlich geschrieben oder groß-/kleingeschrieben, Kategorien, die sich überschneiden oder duplizieren, Attribute, die in einer Produktlinie einen Zweck erfüllen und in einer anderen einen völlig anderen. Diese Uneinheitlichkeit verursacht auf der alten Plattform meist keine sichtbaren Probleme, da Mitarbeiter gelernt haben, damit umzugehen - sie wird aber zu einem echten Risiko, sobald sie mechanisch auf das Datenmodell einer neuen Plattform gemappt wird.

Bauen Sie vor der Migration eine saubere, abgestimmte Taxonomie auf (oder bestätigen Sie eine bestehende) - einen definierten Kategoriebaum und eine definierte Attributliste mit konsistenter Benennung - und gleichen Sie Ihre tatsächlichen Daten damit ab. Das ist auch der richtige Zeitpunkt zu fragen, welche Attribute für Kunden oder interne Abläufe noch relevant sind und welche nur existieren, weil sie nie entfernt wurden.

#### Konflikte in der Variantenstruktur bereinigen

Variantenstrukturen (Größe, Farbe, Material und wie sie sich zu konkret verkäuflichen SKUs kombinieren) werden plattformübergreifend unterschiedlich gehandhabt, und uneinheitliche Quelldaten verschärfen das. Suchen Sie nach Produkten, bei denen Variantenoptionen keinem einheitlichen Muster folgen - manche Größenvarianten heißen "S/M/L", andere für dieselbe Produktlinie "Klein/Mittel/Groß", oder Produkte, bei denen eine Variantenkombination im System existiert, aber ohne gültigen Preis oder Lagerbestand dahinter.

Legen Sie Ihr Ziel-Variantenmodell vor der Migration fest, nicht währenddessen. Zu wissen, ob die neue Plattform Variantenkombinationen genauso handhabt wie die alte - und wo nicht -, entscheidet, ob sich Ihre bestehenden Variantendaten direkt mappen lassen oder erst umstrukturiert werden müssen.

#### Entscheiden, was tatsächlich mitziehen muss

Nicht alles in Ihrem aktuellen Katalog verdient einen Platz auf der neuen Plattform. Eingestellte Produkte ohne verbleibenden Lagerbestand, Test- oder Platzhaltereinträge und Altfelder, deren ursprünglicher Zweck niemand mehr erklären kann, sind allesamt Kandidaten, um zurückgelassen zu werden - mit einer dokumentierten Entscheidung, nicht einem stillen Wegfall. Bewusst weniger zu migrieren, ist oft besser, als alles zu migrieren und es später auf einem unvertrauten neuen System zu klären.

Bei allem, das Sie nicht migrieren, aber noch eine indexierte URL hat, stellen Sie sicher, dass es in Ihrem Weiterleitungsplan berücksichtigt ist (siehe den Leitfaden zum Weiterleitungs-Mapping), statt versehentlich in einem 404 zu enden.

#### FAQ

Q: Wie viel Zeit sollten wir für die Datenbereinigung vor einer Migration einplanen?
A: Das hängt stark von der Kataloggröße und dem tatsächlichen Zustand der Daten ab - ein kleiner, gut gepflegter Katalog braucht weit weniger Zeit als einer mit zehntausenden SKUs und Jahren an Lieferanten-Feed-Importen. Erst ein Audit der Daten zeigt den tatsächlichen Umfang; das Audit zu überspringen und zu raten, ist der Grund, warum die Bereinigungszeit unterschätzt wird.

Q: Sollten wir Daten vor oder während des Migrationsprojekts bereinigen?
A: Davor, oder mindestens als eigene, frühe Phase mit eigenem Prüfschritt - nicht vermischt mit der technischen Datenübertragung. Bereinigungsentscheidungen (was ist ein Duplikat, was kann gefahrlos entfallen, wofür ein mysteriöses individuelles Feld gedacht war) benötigen meist den Input von jemandem, der die Geschichte des Katalogs kennt, und das ist eine andere Art von Arbeit als das technische Mapping und die Übertragung selbst.

Q: Was, wenn wir nicht sicher sind, ob ein Duplikat wirklich eines ist?
A: Markieren Sie es, statt in die eine oder andere Richtung zu raten. Ein Beinahe-Duplikat mit unterschiedlicher Preisgestaltung, unterschiedlichen Variantenoptionen oder unterschiedlicher Bestellhistorie kann ein eigenständiges, legitimes Produkt sein, das nur ähnlich aussieht. Im Zweifel behalten Sie beide und entscheiden nach Abschluss des Audits, statt auf Verdacht zusammenzuführen.

Q: Kann die Datenbereinigung stattfinden, während der alte Shop noch live ist und Bestellungen entgegennimmt?
A: Ja, für den größten Teil der Audit- und Planungsarbeit - das Prüfen von Exporten, das Entscheiden über Zusammenführungen und der Aufbau der Ziel-Taxonomie erfordern kein Eingreifen in den Live-Shop. Die tatsächliche Umsetzung der Änderungen (Datensätze zusammenführen, verwaiste Medien löschen) ist meist sicherer an einer Kopie oder einem Export durchzuführen, um dann die bereinigten Daten in die Migration einzubringen, statt den Live-Katalog mitten im Audit zu bearbeiten.

### Die Ecommerce-Replatforming-Checkliste

URL: https://prevedshop.com/de/leitfaeden/checkliste-shopsystem-wechsel
Language: de
Last reviewed: 2026-07-21

Das Replatforming eines Onlineshops ist ein Projekt, kein Knopf, den man drückt. Welche Plattformen beteiligt sind, spielt eine kleinere Rolle, als die meisten annehmen - was tatsächlich entscheidet, ob eine Migration glatt läuft, ist, ob Sie die unspektakulären Schritte in der richtigen Reihenfolge erledigt haben: geprüft, was Sie haben, bewusst gemappt, Weiterleitungen geplant, im Staging getestet und den Shop nach dem Umzug genau beobachtet. Diese Checkliste führt durch diese Abfolge, damit Sie sie unabhängig davon anwenden können, welche Plattform Sie verlassen oder zu welcher Sie wechseln.

#### 1. Beginnen Sie mit Bestandsaufnahme und Audit, nicht mit einem Tool-Vergleich

Bevor Sie Zielplattformen vergleichen, prüfen Sie, was Sie auf der aktuellen tatsächlich haben: wie viele Produkte und Varianten, wie viele Kundenkonten und wie viel Bestellhistorie, welche individuellen Felder aktiv genutzt werden und welche verwaiste Altlasten sind, von welchen Apps oder Integrationen der Storefront abhängt, und welche URLs aktuell nennenswerten Traffic bekommen. Dieses Audit macht aus "wir migrieren" ein abgegrenztes Projekt mit einer echten Liste dessen, was mitziehen muss.

Seien Sie an dieser Stelle ehrlich zur Datenqualität. Hat Ihr Katalog bekannte Duplikate, verwaiste Kategorien oder uneinheitliche Attribute, halten Sie das jetzt fest - die Bereinigung ist vor dem Umzug günstiger als danach, und das Audit zu überspringen ist der Weg, wie Teams diese Probleme mitten in der Migration statt vorher entdecken.

#### 2. Mappen Sie Ihr Datenmodell, bevor Sie ein einziges Feld mappen

Jede Plattform strukturiert Produkte, Varianten, Kategorien und Kundendaten leicht unterschiedlich. Bevor Sie irgendwelche Daten verschieben, bauen Sie ein explizites Mapping: welches Quellfeld in welches Zielfeld geht, welche Quellkonzepte (ein individuelles Attribut, ein Tag, ein Bundle-Typ) keine direkte Zielentsprechung haben und eine Entscheidung brauchen, und welche Felder sich gefahrlos ganz weglassen lassen, weil nichts mehr davon abhängt.

Dokumentieren Sie dieses Mapping dauerhaft - eine Tabelle oder ein geteiltes Dokument, nicht das Gedächtnis einer Person. Es wird zur Referenz, gegen die während der QA alle prüfen, und es ist das Erste, das Sie brauchen, wenn nach dem Launch etwas nicht stimmt.

#### 3. Planen Sie Weiterleitungen und URL-Struktur frühzeitig

Die URL-Struktur ist einer der häufigsten Punkte, an denen eine Migration still SEO schädigt und Lesezeichen bricht. Erstellen Sie eine vollständige Liste Ihrer aktuellen URLs - Produktseiten, Kategorie- und Sammlungsseiten, Blog- oder Inhaltsseiten sowie individuelle Landingpages - und legen Sie für jede die neue URL fest, bevor Sie irgendetwas starten. Seiten ohne saubere Entsprechung auf der neuen Plattform brauchen eine explizite Entscheidung (meist eine Weiterleitung zur nächstpassenden Kategorie- oder Hub-Seite), keinen stillen 404.

Diese Planung erfolgt deutlich vor dem Umzug, idealerweise parallel zur Datenmapping-Arbeit, da beides zusammenhängt: Wie Sie Kategorien und Produkte mappen, bestimmt oft, wie die neuen URLs aussehen. Den vollständigen Prozess finden Sie im eigenständigen Leitfaden zum Weiterleitungs-Mapping, der unten verlinkt ist.

#### 4. Bauen Sie eine Staging-Umgebung auf und führen Sie echte QA durch

Behandeln Sie einen ersten Import nie als finalen Import. Laden Sie Ihre gemappten Daten auf eine Staging- oder Testinstanz der Zielplattform und nutzen Sie den Shop tatsächlich: Kategorien durchsuchen, Produktseiten ansehen, Variantenauswahl und Preise prüfen, Warenkorb und Checkout testen, und bestätigen, dass Kundenkonten und Bestellhistorie korrekt angezeigt werden. Binden Sie jemanden außerhalb des Migrationsteams ein - ein frischer Blick entdeckt Dinge, die den Personen, die das Mapping gebaut haben, nicht mehr auffallen.

Behandeln Sie diese Phase als iterativ. Es ist normal, beim ersten Durchgang Mapping-Probleme zu finden; das Ziel ist, sie hier auf Staging zu entdecken und zu beheben, wo ein Fehler einen erneuten Import kostet - nicht einen Ausfall im Live-Betrieb oder einen kundenseitigen Fehler.

#### 5. Planen Sie das Umzugsfenster wie einen Einsatz, nicht wie einen Schalterdruck

Legen Sie schriftlich fest, was während des Umzugs passiert: wie neue Bestellungen auf der alten Plattform behandelt werden, falls die Migration Zeit braucht (ein vorübergehender Bestellstopp, eine Wartungsseite oder Weiterbetrieb bis zu einem definierten finalen Abgleich), wer den finalen Datenabgleich durchführt, wer DNS und SSL auf der neuen Plattform prüft, und wer befugt ist, im Zweifel zurückzurollen oder zu pausieren.

Geben Sie dem Team für den eigentlichen Tag eine gemeinsame Checkliste, nicht nur einen Plan im Kopf einer einzelnen Person. Ein überstürzter oder unklarer Umzug ist der Punkt, an dem sonst gut vorbereitete Migrationen Daten verlieren - etwa eine Handvoll Bestellungen, die in der Lücke zwischen finalem Abgleich und Livegang eingehen -, planen Sie diese Lücke also explizit ein, statt zu hoffen, dass sie nicht ins Gewicht fällt.

#### 6. Beobachten Sie nach dem Launch weiter - die Migration ist mit dem Livegang nicht fertig

In den Tagen und Wochen nach dem Umzug tauchen Probleme auf, die Staging nicht abgefangen hat: ein für Live-Traffic falsch konfiguriertes Zahlungsgateway, eine Steuer- oder Versandregel, die sich bei echten Bestellungen anders verhielt, Weiterleitungen, die für getestete Seiten funktionieren, aber nicht für Randfälle, oder ein Tracking-Pixel, das still aufgehört hat zu feuern. Legen Sie eine bewusste Monitoring-Routine fest, statt anzunehmen, dass Stille Erfolg bedeutet.

Unsere Post-Launch-QA-Checkliste (unten verlinkt) behandelt diese Phase im Detail - Checkout- und Zahlungsprüfung, stichprobenartige Weiterleitungskontrolle, Analytics-Kontinuität und Search-Console-Monitoring -, da sie einen eigenen, dedizierten Prozess verdient, statt eine überstürzte Nachbetrachtung, wenn die Aufmerksamkeit des Teams schon woanders ist.

#### FAQ

Q: Wie lange dauert ein Replatforming-Projekt?
A: Das hängt stark von der Kataloggröße, der Datenkomplexität und der Anzahl beteiligter individueller Integrationen ab. Ein kleiner, sauberer Katalog zieht meist schneller um als einer mit zehntausenden SKUs, jahrelang angesammelten individuellen Feldern und mehreren verbundenen Apps. Eine realistische Schätzung erhalten Sie nach einem Audit Ihres konkreten Shops, nicht durch Vertrauen auf einen allgemeinen Zeitplan.

Q: Sollten wir alles auf einmal migrieren oder in Phasen?
A: Beide Ansätze funktionieren je nach Shop. Ein einzelner Umzug ist einfacher zu überblicken und vermeidet den parallelen Betrieb zweier Plattformen, konzentriert das Risiko aber auf ein Zeitfenster. Ein phasenweiser Ansatz (zum Beispiel zuerst Inhalte und Design, dann Katalog, dann Transaktionsdaten) verteilt das Risiko, erfordert aber sorgfältigere Koordination, was in welcher Phase wo "live" ist. Die richtige Wahl hängt von Ihrer Kataloggröße, Ihrer Toleranz für ein Wartungsfenster und der Integrationstiefe Ihrer Systeme ab.

Q: Was ist die häufigste Ursache für Migrationsprobleme?
A: Das Überspringen oder Überstürzen der Audit- und Mapping-Phasen. Teams, die direkt mit dem Verschieben von Daten beginnen, ohne vorher zu verstehen, was sie tatsächlich haben - doppelte Produkte, undokumentierte individuelle Felder, URLs, an die niemand gedacht hat -, entdecken diese Probleme tendenziell live nach dem Umzug statt im Staging, wo sie günstig zu beheben sind.

Q: Müssen wir den alten Shop während der Migration einfrieren?
A: Nicht zwangsläufig für das gesamte Projekt, aber Sie brauchen einen klaren Plan für das finale Umzugsfenster - meist einen kurzen Einfrierzeitraum oder einen definierten finalen Abgleichspunkt -, damit keine Bestellungen oder Kundenänderungen zwischen dem letzten Datenabruf und dem Livegang des neuen Shops verloren gehen. Wie lang dieses Fenster sein muss, hängt von Ihrem Bestellvolumen und der Handhabung des finalen Abgleichs ab.

Sources:
- Google Search Central: Site moves with URL changes: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### SEO-sicheres Weiterleitungs-Mapping für Ecommerce-Migrationen

URL: https://prevedshop.com/de/leitfaeden/301-weiterleitungen-beim-shop-relaunch
Language: de
Last reviewed: 2026-07-21

Suchrankings und organischer Traffic gehören zu den wertvollsten Dingen, die ein etablierter Shop besitzt - und sie gehören auch zu dem, was bei einer unachtsamen Migration am leichtesten beschädigt wird. Die gute Nachricht: URL-Kontinuität ist ein lösbares, mechanisches Problem. Bauen Sie eine ordentliche Weiterleitungskarte, setzen Sie sie korrekt um und beobachten Sie, wie Suchmaschinen darauf reagieren. Dieser Leitfaden führt Sie durch diesen Prozess von Anfang bis Ende, unabhängig davon, welche Plattformen beteiligt sind.

#### Erstellen Sie zuerst eine vollständige URL-Inventur

Bevor Sie irgendetwas mappen können, brauchen Sie eine vollständige Liste der aktuell genutzten URLs - nicht nur die, an die Sie sich erinnern, sondern jede Produktseite, jede Kategorie- und Sammlungsseite, Blog- oder Inhaltsseiten sowie individuelle Landingpages der aktuellen Seite. Ziehen Sie diese aus Ihrer Sitemap, den Seitenberichten Ihres Analytics-Tools und einem Crawl der Live-Seite, und gleichen Sie alle drei gegeneinander ab, da jede Quelle tendenziell etwas übersieht, das die anderen erfassen.

Achten Sie besonders auf URLs mit organischem Traffic oder externen Backlinks, selbst wenn es Seiten sind, die Sie sonst als nebensächlich einstufen würden. Ein wenig besuchter Blogbeitrag mit ein paar guten Backlinks verdient ein korrektes Mapping; ihn still zu verlieren, ist ein kleiner, aber vermeidbarer Verlust.

#### Mappen Sie jede URL auf ihr neues Äquivalent - und entscheiden Sie Ausnahmen bewusst

Legen Sie für jede URL in Ihrer Inventur das Ziel auf der neuen Plattform fest. Die meisten Produkt- und Kategorieseiten haben eine einigermaßen direkte Entsprechung, sobald Ihr Daten-Mapping steht. Seiten ohne saubere Entsprechung (ein eingestelltes Produkt, eine einmalige Landingpage, eine nicht mehr existierende Kategorie) brauchen dennoch eine explizite Entscheidung - meist eine Weiterleitung zur nächstpassenden Kategorie, einer relevanten Hub-Seite oder in seltenen Fällen ein bewusst akzeptierter 404 -, statt standardmäßig zur Startseite weitergeleitet oder versehentlich zu einem 404 zu werden.

Ein pauschales "alles zur Startseite weiterleiten" ist eine verbreitete Abkürzung, die aktiv schadet: Sie verwässert Relevanzsignale und bietet Nutzern eine schlechtere Erfahrung, als auf der nächstpassenden Seite zu landen.

#### Setzen Sie 301-Weiterleitungen um und prüfen Sie auf Ketten und Schleifen

Verwenden Sie dauerhafte (301-)Weiterleitungen für URLs, die endgültig umgezogen sind - das ist das Signal, das Suchmaschinen anweist, Rankingsignale auf die neue URL zu übertragen. Sobald Ihre Weiterleitungen live sind, prüfen Sie aktiv auf Weiterleitungsketten (URL A → B → C, wenn A → C genügen würde) und Schleifen (A → B → A), da beides häufige Nebenprodukte iterativer Bearbeitungen der Weiterleitungskarte sind und beide Crawling-Budget verschwenden und Latenz hinzufügen. Ziel ist eine Weiterleitung mit einem Sprung von jeder alten URL direkt zu ihrem finalen neuen Ziel.

Testen Sie nach dem Launch eine repräsentative Stichprobe von Weiterleitungen manuell - prüfen Sie stichprobenartig stark besuchte Seiten, eine Handvoll wenig besuchte und einige der bewussten Ausnahmen -, statt anzunehmen, die Karte sei korrekt, nur weil sie in einer Tabelle validiert wurde.

#### Behandeln Sie Canonical-Tags bewusst

Canonical-Tags teilen Suchmaschinen mit, welche URL die maßgebliche Version ist, wenn ähnlicher Inhalt über mehr als eine Adresse erreichbar ist. Stellen Sie nach einer Migration sicher, dass der Canonical-Tag jeder Seite auf ihre eigene, lebende, korrekte neue URL zeigt - nicht auf eine übrig gebliebene alte URL und nicht versehentlich durch eine kopierte Vorlage auf die URL einer anderen Seite. Ein Fehler hier kann Suchmaschinen verwirren, welche Version einer Seite sie indexieren sollen, selbst wenn die Weiterleitungen selbst korrekt sind.

Erzeugt die neue Plattform Canonical-Tags automatisch, prüfen Sie das Standardverhalten, statt anzunehmen, es passe zu Ihrem Setup - automatische Canonicalisierung zeigt bei parametrisierten oder paginierten Seiten gelegentlich auf unerwartete URLs.

#### Reichen Sie Ihre XML-Sitemap erneut ein und aktualisieren Sie interne Links

Sobald die neue Seite mit funktionierenden Weiterleitungen live ist, erzeugen und übermitteln Sie eine aktuelle XML-Sitemap, die die neue URL-Struktur widerspiegelt, über Google Search Central und die Webmaster-Tools anderer Suchmaschinen, damit Crawler die neuen Seiten effizient entdecken können, statt sich ausschließlich auf das Folgen von Weiterleitungen von alten URLs zu verlassen.

Aktualisieren Sie gleichzeitig interne Links auf der gesamten Seite - Navigation, Footer, verwandte Produkte, Blog-Inhalte -, sodass sie direkt auf die neuen URLs zeigen statt über eine Weiterleitung. Interne Links, die noch auf alte URLs zeigen, fügen bei jedem Klick unnötige Weiterleitungssprünge hinzu und werden leicht übersehen, da sie sichtbar nichts kaputtmachen - sie funktionieren nur weniger effizient.

#### Beobachten Sie Crawling- und Indexstatus nach dem Umzug

Die SEO-Arbeit einer Migration endet nicht mit dem Launch. Beobachten Sie in den Wochen nach dem Umzug Search Console (oder das entsprechende Tool anderer Suchmaschinen) auf Crawling-Fehler, einen plötzlichen Anstieg von 404-Fehlern, Seiten, die nicht indexiert werden, oder einen Rückgang von Impressionen/Klicks bei Seiten, die eigentlich normal performen sollten. Vergleichen Sie das mit Ihrer Basislinie vor der Migration, damit Sie echte Verschlechterungen erkennen, nicht normale kurzfristige Schwankungen.

Seien Sie geduldig, aber nicht passiv: Manche Neuindexierung braucht Zeit, selbst wenn alles korrekt eingerichtet ist, aber ein Weiterleitungs- oder Canonical-Fehler, der wochenlang unbemerkt bleibt, ist weit teurer zu beheben als einer, der in den ersten Tagen nach dem Launch entdeckt wird.

#### FAQ

Q: Schadet eine Migration meinen Suchrankings zwangsläufig?
A: Nicht, wenn URL-Kontinuität richtig gehandhabt wird - eine vollständige Weiterleitungskarte, korrekte Canonical-Tags und eine erneut eingereichte Sitemap sind die Kernmaßnahmen dagegen. Niemand kann garantieren, dass bestimmte Rankings gehalten werden, da Ranking von vielen Faktoren jenseits einer einzelnen Migration abhängt, aber korrektes URL-Mapping ist der mit Abstand größte kontrollierbare Faktor, um zu erhalten, was Sie hatten.

Q: Sollte ich 301- oder 302-Weiterleitungen verwenden?
A: Verwenden Sie 301-(dauerhafte) Weiterleitungen für URLs, die endgültig umgezogen sind - der Normalfall bei einer Plattformmigration. 302-(temporäre) Weiterleitungen signalisieren, dass der Umzug nicht dauerhaft ist, und Suchmaschinen übertragen Rankingsignale dann möglicherweise nicht auf dieselbe Weise - für die Weiterleitungskarte einer abgeschlossenen Migration sind sie daher die falsche Wahl.

Q: Was, wenn zwei alte URLs auf dieselbe neue Seite zeigen sollen?
A: Das ist unproblematisch und häufig - zum Beispiel zwei alte Kategorie-URLs, die auf der neuen Plattform zu einer zusammengeführt wurden. Leiten Sie beide alten URLs direkt auf die eine neue URL weiter. Zu vermeiden ist der umgekehrte Fall: eine alte URL, bei der unklar ist, auf welche neue Seite sie gemappt werden soll - das bedeutet meist, dass die Mapping-Entscheidung noch gar nicht getroffen wurde.

Q: Wie lange sollte ich alte Weiterleitungen bestehen lassen?
A: Nach Möglichkeit unbegrenzt. Backlinks, Lesezeichen und alte Suchergebnisse, die auf frühere URLs verweisen, können nach einer Migration noch lange bestehen bleiben, und eine aktive Weiterleitungsregel zu behalten, kostet kaum etwas. Weiterleitungen zu früh zu entfernen, ist ein häufiger Weg, wie aus einer einmaligen Migrationskosten eine wiederkehrende Quelle defekter Links wird.

Sources:
- Google Search Central: 301 redirects: https://developers.google.com/search/docs/crawling-indexing/301-redirects
- Google Search Central: Consolidate duplicate URLs (canonicalization): https://developers.google.com/search/docs/crawling-indexing/canonicalization
- Google Search Central: Build and submit a sitemap: https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap

### Shopify vs. WooCommerce: wohin sollten Sie migrieren?

URL: https://prevedshop.com/de/leitfaeden/shopify-vs-woocommerce
Language: de
Last reviewed: 2026-09-02

Shopify und WooCommerce sind die beiden Plattformen, zu und von denen wir am häufigsten migrieren, und die Wahl zwischen ihnen hat selten mit Features zu tun. Shopify ist ein gehostetes System mit festem Modell, das Betriebsarbeit abnimmt; WooCommerce ist ein offenes Plugin auf WordPress, das Ihnen die Datenbank und die Verantwortung gibt. Dieser Vergleich betrachtet die Unterschiede, die eine Migration wirklich verändern: Datenmodell, Datenhoheit, Kostenstruktur, Umgang mit Inhalten und SEO, und beschreibt dann, welche Shops auf welcher Seite meist zufriedener sind.

#### Datenmodell: fest versus offen

Shopify-Produkte haben ein festes Schema mit bis zu drei Optionsdimensionen und Metafeldern für alles Weitere; Kollektionen sind manuelle oder regelbasierte Listen, kein Taxonomiebaum. WooCommerce-Produkte sind WordPress-Beiträge mit unbegrenzten Attributen, benutzerdefinierten Feldern und verschachtelten Taxonomien. Der Weg zu Shopify ist deshalb Konsolidierung - die Entscheidung, wo jedes eigene Feld hingehört -, der Weg zu WooCommerce meist das Mapping eines kleinen, aufgeräumten Modells in ein größeres. Shops mit stark strukturierten Katalogen migrieren meist leichter Richtung Shopify; Shops mit ungewöhnlichen Daten verlieren Richtung WooCommerce weniger.

#### Datenhoheit, Hosting und Kosten

Shopify berechnet einen Tarif plus Transaktionsgebühren bei fremden Zahlungsdiensten und App-Abos; dafür gibt es keinen Server, kein Patchen und keinen PCI-Umfang auf Ihrer Seite. WooCommerce hat keine Lizenzgebühr, aber Sie zahlen Managed-WordPress-Hosting, Plugin-Lizenzen und die Entwicklerzeit, die Updates sicher hält. Über drei Jahre liegen die Summen oft näher beieinander, als beide Lager behaupten. Der eigentliche Unterschied ist, wo das Risiko sitzt: Bei Shopify kann die Plattform Regeln und Preise ändern; bei WooCommerce kann ein vernachlässigter Plugin-Stack den Shop lahmlegen.

#### Inhalte und SEO

WordPress ist ein vollwertiges CMS, WooCommerce-Shops mit großen Blogs, Landingpages und eigenen Templates behalten also alles an einem Ort. Seiten und Blog von Shopify sind einfacher, und content-starke Shops betreiben oft WordPress für Inhalte neben Shopify für den Verkauf. Bei SEO sind die Plattformen gut konfiguriert gleichwertig; in einer Migration zählt die URL-Änderung. Shopify erzwingt die Pfade `/products/` und `/collections/`, WordPress-Permalinks sind frei, deshalb braucht jede Migration zwischen beiden eine vollständige 301-Weiterleitungskarte. Weiterleitungen senken das Risiko; Rankings sind nie garantiert.

#### Welche Shops zu welcher Plattform passen

Shopify passt meist zu Shops, die planbaren Betrieb wollen, über Markets in mehrere Länder verkaufen, Standard-Fulfilment nutzen und einen Katalog haben, der in drei Optionsdimensionen passt. WooCommerce passt zu Shops, die eigene Checkout-Logik, B2B-Preise, ungewöhnliche Produktstrukturen, tiefe Content-Integration oder strenge Datenresidenz brauchen. Trifft keine Beschreibung klar auf Sie zu, beantwortet eine kurze Discovery mit echten Produkt- und Bestellproben die Frage schneller als jede Vergleichstabelle.

#### FAQ

Q: Ist Shopify besser für SEO als WooCommerce?
A: Keine Plattform hat einen inhärenten Vorteil. Die Sichtbarkeit nach einer Migration hängt von der Weiterleitungskarte, der Content-Parität und der Ladezeit ab, nicht vom Plattformnamen.

Q: Was ist günstiger, Shopify oder WooCommerce?
A: Das hängt von Größe und Anpassung ab. Shopify hat planbare Gebühren plus Apps und Transaktionsgebühren; WooCommerce hat Hosting, Plugin-Lizenzen und Entwicklerzeit. Vergleichen Sie Dreijahressummen inklusive Migration.

Q: Kann ich von Shopify zu WooCommerce wechseln, nicht nur umgekehrt?
A: Ja. Wir migrieren in beide Richtungen; die Route Shopify → WooCommerce ist separat dokumentiert und dreht sich vor allem um das Mapping von Metafeldern und den Neuaufbau von Smart Collections.

Q: Beeinflusst die Wahl die Dauer der Migration?
A: Teilweise. Der Weg zu Shopify dauert bei Katalogen mit vielen eigenen Feldern länger, weil jedes eine Metafeld-Entscheidung braucht; der Weg zu WooCommerce dauert länger, wenn viele Apps durch Plugins ersetzt werden müssen.

Sources:
- Shopify Help Center - Migration zu Shopify: https://help.shopify.com/en/manual/migrating-to-shopify
- WooCommerce - Produkt-CSV-Importer und -Exporter: https://woocommerce.com/document/product-csv-importer-exporter/

### Glossary

### 301-Weiterleitung

URL: https://prevedshop.com/de/glossar/301-weiterleitung
Language: de
Last reviewed: 2026-07-21

Eine 301-Weiterleitung teilt Browsern und Suchmaschinen mit, dass eine Seite dauerhaft zu einer neuen URL umgezogen ist, und schickt jeden - Mensch oder Crawler -, der die alte Adresse aufruft, direkt zur neuen. Die "301" ist der HTTP-Statuscode, den der Server zurückgibt: der Standardweg, dauerhaft zu signalisieren "dieser Inhalt liegt jetzt hier", im Unterschied zu einer temporären (302-)Weiterleitung.

#### Was eine 301-Weiterleitung tatsächlich tut

Ruft jemand eine alte URL auf, antwortet der Server mit dem HTTP-Statuscode 301 und einer neuen Adresse. Der Browser folgt automatisch, sodass ein Besucher davon selten überhaupt etwas bemerkt - er landet auf der neuen Seite statt auf einer Fehlermeldung. Suchmaschinen folgen demselben Signal: Eine 301 sagt ihnen, den Rankingwert der alten URL mit der Zeit auf die neue zu übertragen, statt die neue Seite als unabhängigen, völlig neuen Inhalt zu behandeln.

Das unterscheidet sich von einer 302-Weiterleitung (temporär), die Crawlern signalisiert, dass der Umzug nicht dauerhaft ist und der Suchwert nicht vollständig übertragen werden sollte. Es unterscheidet sich auch von einer manuellen Linkaktualisierung auf Ihrer eigenen Seite - eine 301 erreicht jeden, der die alte URL noch als Lesezeichen gespeichert, von einer anderen Seite verlinkt oder in Suchergebnissen indexiert hat, nicht nur Besucher, die auf von Ihnen kontrollierte Links klicken.

#### Warum 301-Weiterleitungen bei einer Plattformmigration wichtig sind

Ein Wechsel zu einer neuen Plattform verändert fast immer Ihre URL-Struktur, selbst wenn Sie versuchen, sie beizubehalten - Produkt-URLs, Kategoriepfade und Blogbeiträge landen häufig in einer anderen Form als vorher. Jede alte URL, die Suchmaschinen indexiert haben und auf die andere Seiten verlinken, benötigt eine 301-Weiterleitung zu ihrem neuen Äquivalent, sonst verlieren Sie das angesammelte Rankingsignal dieser Seite und schicken Besucher in eine Sackgasse.

Das Risiko ist nicht hypothetisch: Starten Sie einen neuen Shop ohne Weiterleitungsplan, häufen sich typischerweise 404-Fehler, eingehende Links brechen, und der organische Traffic sinkt innerhalb weniger Tage nach dem Launch, da Suchmaschinen indexierte URLs schnell erneut besuchen. Ein vor dem Launch erstellter Weiterleitungsplan - statt einer nachträglichen Reparatur, wenn der Traffic bereits eingebrochen ist - verhindert genau das.

#### Weiterleitungen richtig setzen, nicht nur vorhanden haben

Eine 301 allein genügt nicht - sie muss auf das richtige Ziel zeigen. Jede alte URL auf Ihre neue Startseite weiterzuleiten "löst" den Link technisch, verschenkt aber die spezifische Relevanz, die eine Suchmaschine oder ein Besucher erwartet hat. Wir mappen alte URLs auf ihr nächstliegendes reales Äquivalent auf der neuen Plattform und kennzeichnen Seiten ohne saubere Entsprechung, statt zu raten.

Wir prüfen außerdem auf Weiterleitungsketten (URL A zu B zu C) und Schleifen, die Latenz hinzufügen und dazu führen können, dass Crawler der Kette irgendwann nicht mehr folgen. Eine saubere Migration endet mit einem Sprung pro URL, nicht mit dreien.

#### FAQ

Q: Ist eine 301-Weiterleitung dasselbe wie eine URL-Änderung?
A: Nein - eine URL ohne Weiterleitung zu ändern, bricht einfach den alten Link. Eine 301-Weiterleitung ist die Anweisung, die die alte URL mit der neuen verbindet, sodass jeder (oder alles), der die alte Adresse anfragt, automatisch zur neuen Seite geschickt wird.

Q: Erhalten 301-Weiterleitungen mein Suchranking vollständig?
A: Sie erhalten den größten Teil des mit der alten URL verbundenen Rankingsignals, aber nicht automatisch jede Position für jedes Keyword - andere Faktoren wie Seitenqualität und Wettbewerb spielen weiterhin eine Rolle. Was eine 301 zuverlässig leistet, ist Suchmaschinen mitzuteilen, dass der Inhalt umgezogen ist, statt die neue URL als unabhängig zu behandeln.

Q: Wie lange müssen Weiterleitungen bestehen bleiben?
A: Auf unbestimmte Zeit, oder so nah daran wie praktisch möglich. Alte Links von anderen Websites, gespeicherte Lesezeichen und gedruckte Materialien können jahrelang weiter Traffic zu alten URLs schicken, und Suchmaschinen können einige Zeit brauchen, um eine große Zahl an Weiterleitungen vollständig zu verarbeiten.

Q: Was ist der Unterschied zwischen einer 301- und einer 302-Weiterleitung?
A: Eine 301 signalisiert einen dauerhaften Umzug und gibt Rankingsignal an die neue URL weiter; eine 302 signalisiert einen temporären Umzug, und Suchmaschinen sind bei der Übertragung dieses Signals vorsichtiger. Bei einer Plattformmigration, bei der die alte URL nicht zurückkehrt, ist eine 301 fast immer die richtige Wahl.

Sources:
- Google Search Central: Redirects and Google Search: https://developers.google.com/search/docs/crawling-indexing/301-redirects

### Canonical-Tag

URL: https://prevedshop.com/de/glossar/canonical-tag
Language: de
Last reviewed: 2026-07-21

Ein Canonical-Tag (`<link rel="canonical">`) ist ein HTML-Tag, der Suchmaschinen mitteilt, welche URL die maßgebliche Version einer Seite ist, wenn derselbe oder sehr ähnlicher Inhalt über mehr als eine Adresse erreichbar ist. Er leitet Besucher nirgendwohin weiter - er ist ein Signal an Crawler, welche URL die Wertung erhalten und in Suchergebnissen erscheinen soll.

#### Was ein Canonical-Tag tatsächlich tut

Ecommerce-Plattformen liefern dasselbe Produkt oder dieselbe Kategorie regelmäßig über mehrere URLs aus - mit und ohne abschließenden Schrägstrich, mit unterschiedlichen Sortier- oder Filter-Parametern, oder erreichbar über mehr als einen Kategoriepfad. Ohne Canonical-Tag müssen Suchmaschinen raten, welche Version indexiert werden soll, was das Rankingsignal auf nahezu identische URLs verteilen kann, statt es auf einer zu bündeln.

Der Canonical-Tag steht im `<head>` einer Seite und zeigt auf die eine URL, die als Master-Kopie gelten soll. Jede duplizierte oder nahezu duplizierte Variante trägt einen Canonical-Tag, der auf diese eine URL zurückverweist; die Master-URL hat üblicherweise einen Canonical-Tag, der auf sich selbst zeigt.

#### Warum er bei einer Plattformmigration wichtig ist

Neue Plattformen führen oft eigene URL-Muster für Filterung, Paginierung oder Sortierung ein, die es auf der alten Plattform nicht gab, und es entsteht leicht unbeabsichtigter Duplicate Content, wenn Canonical-Tags nicht von Anfang an korrekt gesetzt sind. Ein Fehler hier verursacht meist keinen dramatischen Einbruch wie eine fehlende Weiterleitung, verwässert aber still das Rankingsignal auf nahezu identischen Seiten, statt es zu bündeln - ein langsameres, schwerer zu diagnostizierendes Problem.

Eine Migration ist zudem ein natürlicher Zeitpunkt, um bereits bestehende Canonicalisierungsprobleme der alten Plattform zu beheben, statt sie unverändert mitzunehmen.

#### Canonical-Tags vs. Weiterleitungen

Ein Canonical-Tag und eine Weiterleitung lösen unterschiedliche Probleme. Eine Weiterleitung (siehe 301-Weiterleitung) ist für eine URL gedacht, die es überhaupt nicht mehr gibt - sie schickt Besucher und Crawler zur neuen Adresse. Ein Canonical-Tag ist für URLs gedacht, die weiterhin existieren und erreichbar sind, aber nicht in Suchergebnissen gegeneinander konkurrieren sollen - beide bleiben live, eine wird nur als Referenzversion markiert.

#### FAQ

Q: Leitet ein Canonical-Tag Besucher zur Haupt-URL weiter?
A: Nein. Besucher können weiterhin auf der nicht-kanonischen URL landen, und sie lädt normal - der Canonical-Tag signalisiert Suchmaschinen nur, welche Version indexiert und gerankt werden soll, er ändert nicht, was ein Browser tut.

Q: Brauche ich Canonical-Tags, wenn ich keinen Duplicate Content habe?
A: Es ist weiterhin gängige Praxis, dass jede Seite einen selbstreferenzierenden Canonical-Tag hat (der auf sich selbst zeigt), was Mehrdeutigkeit beseitigt, falls später doch ein Duplikat auftaucht - etwa durch einen Tracking-Parameter oder eine neue Filter-URL.

Q: Kann ein Canonical-Tag auf eine Seite einer anderen Domain zeigen?
A: Ja, domänenübergreifende Canonicals sind gültig und werden manchmal bewusst eingesetzt, aber bei einer Plattformmigration ist das meist nicht das, was Sie wollen - jede neue URL sollte in der Regel auf sich selbst kanonisieren, während Weiterleitungen (nicht Canonicals) die alte Domain oder alte URLs übernehmen.

Q: Was passiert, wenn meine Canonical-Tags auf die falsche URL zeigen?
A: Suchmaschinen indexieren und ranken dann möglicherweise die falsche Version einer Seite oder ignorieren Ihr Canonical-Signal ganz, wenn es inkonsistent mit anderen Signalen wirkt (wie internen Links oder der Sitemap). Wir prüfen Canonical-Tags als Teil der Migrations-QA, statt anzunehmen, dass die neue Plattform sie standardmäßig korrekt setzt.

Sources:
- Google Search Central: Consolidate duplicate URLs: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

### Datenmigration

URL: https://prevedshop.com/de/glossar/datenmigration
Language: de
Last reviewed: 2026-07-21

Datenmigration ist der Vorgang, die Informationen Ihres Shops - Produkte, Kunden, Bestellungen, Inhalte und alles damit Verbundene - von einer Plattform auf eine andere zu übertragen, in einer Form, die die neue Plattform tatsächlich korrekt nutzen kann. Es ist die technische Kernarbeit eines Plattformwechsels, getrennt vom Design, der Weiterleitungsplanung oder der Integrationsarbeit drumherum, auch wenn all das von der Genauigkeit der Datenmigration abhängt.

#### Was tatsächlich migriert wird

Über den offensichtlichen Produktkatalog hinaus umfasst eine vollständige Datenmigration meist Kundenkonten samt Bestellhistorie, bestehende Bestellungen (offene wie historische), Inhalte wie Blogbeiträge oder statische Seiten, Bewertungen, falls sie plattformseitig gespeichert sind, sowie individuelle Felder oder Metadaten, die für Ihr Geschäft spezifisch sind. Nicht alles muss zwangsläufig mitziehen - manche historischen Daten werden eher archiviert als aktiv migriert, eine Umfangsentscheidung, die während der Bewertung getroffen wird, nicht standardmäßig vorausgesetzt.

#### Warum ein reiner Export/Import nicht genügt

Zwei Plattformen modellieren Daten selten identisch - die flache Produktliste der einen Plattform kann dem hierarchischen Kategorien-und-Attribute-System einer anderen entsprechen; ein einfacher Kundendatensatz der einen Plattform muss auf der neuen unter Umständen auf mehrere Objekttypen aufgeteilt werden. Eine wörtliche, feldweise Kopie aus einer Exportdatei erzeugt oft Daten, die technisch vorhanden, aber strukturell falsch sind - defekte Varianten-Beziehungen, verlorene individuelle Felder oder Kundendatensätze, die nicht korrekt mit ihrer Bestellhistorie verknüpft sind. Echte Datenmigration bedeutet, jeden Datentyp bewusst zu mappen, nicht nur Dateien zu verschieben.

#### Wie wir vorgehen

Wir beginnen mit einem Datenaudit - wir erfassen, was im alten System tatsächlich vorhanden ist, einschließlich Unstimmigkeiten, die sich über die Zeit angesammelt haben (doppelte Kunden, verwaiste Datensätze, uneinheitliche Kategorisierung) -, bevor wir festlegen, wie es auf die neue Plattform gemappt wird. Bereinigung passiert oft schon in diesem Schritt statt danach, denn schlechte Daten originalgetreu zu migrieren, reproduziert dieselben Probleme nur auf der neuen Plattform. Wie das in eine verwaltete Migration passt, lesen Sie unter Datenbereinigung und Mapping.

#### FAQ

Q: Umfasst die Datenmigration meine Bestellhistorie?
A: Das kann sie - ob historische Bestellungen aktiv in die neue Plattform migriert oder separat archiviert werden, ist eine Umfangsentscheidung, da nicht jede Plattform oder jedes Geschäft eine live verfügbare Bestellhistorie im neuen System benötigt. Das besprechen wir während der Bewertung.

Q: Werden meine individuellen Felder automatisch übertragen?
A: Nicht automatisch - individuelle Felder benötigen ein explizites Äquivalent auf der neuen Plattform (oft Metafelder oder individuelle Attribute), und dieses Mapping muss definiert werden, statt standardmäßig vorausgesetzt zu werden.

Q: Kann ich Daten selbst mit einem Plugin oder Import-Tool migrieren?
A: Bei kleinen, einfachen Katalogen kann das funktionieren. Bei Shops mit nennenswerter Individualisierung, Bestellhistorie oder Datenqualitätsproblemen kann ein generisches Import-Tool die Entscheidungen, die ein richtiges Datenaudit und Mapping erfordern, meist nicht treffen - es verschiebt einfach, was in der Datei steht, Fehler inklusive.

Q: Wie vermeiden Sie Datenverlust während der Migration?
A: Indem wir vor jeder Übertragung prüfen und mappen, die Migration zunächst gegen eine Staging-Umgebung testen und nach dem Umzug Datensatzanzahlen verifizieren und Daten stichprobenartig prüfen, statt anzunehmen, dass der Import korrekt gelaufen ist.

### Headless Commerce

URL: https://prevedshop.com/de/glossar/headless-commerce
Language: de
Last reviewed: 2026-07-21

Headless Commerce ist eine Architektur, bei der der Storefront (was Kunden sehen und bedienen) getrennt vom Commerce-Backend (Produktkatalog, Warenkorb, Checkout, Bestellverwaltung) aufgebaut wird, und beide über eine API kommunizieren, statt ein eng gekoppeltes System zu bilden. "Headless" bezieht sich darauf, dass der Storefront - die Präsentationsschicht - vom Backend entkoppelt ist, das dann mehrere unterschiedliche "Köpfe" (eine Website, eine App, ein Kiosk im Laden) aus einer einzigen Datenquelle bedienen kann.

#### Headless vs. traditionelle (monolithische) Plattformen

Eine traditionelle Ecommerce-Plattform bündelt die Storefront-Templates und das Backend miteinander - Shopifys Liquid-Themes oder WooCommerces WordPress-Templates sind Beispiele dafür, dass der Storefront direkt von der Plattform selbst erzeugt wird. Bei einem Headless-Setup ist der Storefront eine separate Anwendung (oft mit einem Framework wie Next.js oder Ähnlichem gebaut), die Daten über die API der Backend-Plattform abruft, statt dass die Plattform Seiten direkt rendert. Manche Plattformen (Shopify, commercetools und einige andere) unterstützen sowohl einen traditionellen als auch einen Headless-Modus.

#### Warum es eine Migration verändert

Eine Migration in ein oder aus einem Headless-Setup ist ein anderes Projekt als eine Migration zwischen zwei traditionellen Plattformen. Der Umzug eines Shops von einer traditionellen Plattform zu einer Headless-Architektur bedeutet meist, einen neuen Storefront von Grund auf zu bauen (statt ein bestehendes Theme zu übertragen), während die Backend-/Katalogmigration denselben Datenmapping-Prinzipien folgt wie jeder andere Umzug. Der Wechsel zwischen zwei Headless-Backends ist auf der Storefront-Seite oft überschaubarer, da das Frontend manchmal einfach auf eine neue API umgestellt statt komplett neu gebaut werden kann - aber Katalog-, Bestell- und Kundendaten des Backends brauchen dennoch dasselbe sorgfältige Mapping wie jede Migration.

#### Wann Headless die richtige Wahl ist (und wann nicht)

Headless-Architekturen tauschen generell mehr Implementierungs- und laufenden Entwicklungsaufwand gegen mehr Flexibilität im Storefront-Erlebnis - individuelle Interaktionen, Kanäle jenseits der Website (Apps, Kioske) oder Performance-Anforderungen, die ein templatebasierter Storefront nicht erfüllen kann. Für einen Shop ohne diesen spezifischen Bedarf ist eine traditionelle Plattform meist einfacher zu betreiben und zu migrieren. Das ist eine Entscheidung, die bewusst während der Bewertung getroffen werden sollte, nicht standardmäßig in die eine oder andere Richtung.

#### FAQ

Q: Ist Headless Commerce immer schneller als ein traditioneller Storefront?
A: Nicht automatisch - die Performance hängt davon ab, wie der Headless-Storefront gebaut ist, nicht nur von der Architekturwahl. Ein schlecht gebautes Headless-Frontend kann langsamer sein als ein gut optimiertes traditionelles Theme.

Q: Brauche ich individuelle Entwickler, um einen Headless-Shop zu betreiben?
A: In der Regel ja, dauerhaft - ein Headless-Storefront kommt nicht mit dem Theme-Editor und den App-Store-Anpassungsoptionen einer traditionellen Plattform, sodass Änderungen meist über individuelle Entwicklung laufen statt über einen visuellen Editor.

Q: Kann ich von einer traditionellen Plattform zu Headless wechseln, ohne SEO zu verlieren?
A: Ja, aber es erfordert dieselbe Weiterleitungs- und URL-Strukturplanung wie jede Migration, plus besondere Aufmerksamkeit dafür, wie das neue Headless-Frontend Inhalte für Suchmaschinen rendert (serverseitiges Rendering spielt hier eine Rolle) - es geschieht nicht automatisch, nur weil die Backend-Daten erhalten bleiben.

Q: Welche Plattformen unterstützen Headless Commerce?
A: Mehrere große Plattformen bieten neben oder anstelle ihres traditionellen Storefronts einen Headless-/API-first-Modus an - die richtige Wahl hängt von Ihren konkreten Backend-Anforderungen ab, die wir gemeinsam bewerten, statt standardmäßig auf die gerade angesagte Plattform zu setzen.

### Hreflang

URL: https://prevedshop.com/de/glossar/hreflang
Language: de
Last reviewed: 2026-07-21

Hreflang ist ein HTML-Attribut (sowie ein entsprechender HTTP-Header oder Sitemap-Eintrag), das Suchmaschinen mitteilt, für welche Sprache und optional für welches Land eine Seite geschrieben ist, und auf die entsprechende Seite in anderen Sprachen oder Regionen verweist. So teilt eine mehrsprachige Seite Google mit "hier ist die spanische Version, hier die deutsche", statt Suchmaschinen raten zu lassen.

#### Was Hreflang tatsächlich tut

Eine Seite mit Hreflang-Markup listet eine Reihe alternativer URLs auf, jeweils mit einem Sprachcode versehen (und optional einer Region, z. B. `es` gegenüber `es-MX`) sowie einem speziellen `x-default`-Eintrag für Besucher, die zu keiner gelisteten Sprache passen. Suchmaschinen nutzen das, um Suchenden die richtige Sprachversion Ihrer Seite auszuliefern, und um zu vermeiden, dass Ihre übersetzten Seiten gegenseitig als Duplicate Content behandelt werden.

Jede Seite im Cluster muss auf jede andere Seite im Cluster verweisen, einschließlich sich selbst - eine häufige Fehlerquelle ist ein einseitiger Link (Seite A verweist auf Seite B, aber B verweist nicht zurück auf A).

#### Warum es bei einer Plattformmigration wichtig ist

Betreibt Ihr Shop mehrere Sprachen, ist eine Migration genau der Moment, in dem Hreflang tendenziell kaputtgeht - URL-Strukturen ändern sich je Locale, und es passiert leicht, dass der Sprachumschaltmechanismus der neuen Plattform nicht automatisch für jede Route korrekte Hreflang-Cluster verdrahtet, besonders bei Routen, für die noch keine fertige Übersetzung existiert. Ein unvollständiges oder inkonsistentes Hreflang-Setup kann dazu führen, dass die falsche Sprachversion im falschen Land rankt, oder das Rankingsignal auf nahezu identischen lokalisierten Seiten verwässern.

Hreflang sollte für jedes URL-Muster in der neuen Informationsarchitektur geprüft werden, nicht nur für die Startseite - Produktseiten, Kategorieseiten und alle Inhaltsseiten brauchen es, sofern sie mehrsprachig sind.

#### Häufige Fehler

Die häufigsten Probleme sind fehlende Rückverweise (A verlinkt zu B, B verlinkt nicht zurück), Hreflang, das auf eine URL zeigt, die eine Weiterleitung oder einen 404 statt der lebenden Seite zurückgibt, sowie ein falsches Sprach-/Regionscode-Format. Keines davon führt in der Regel zu einer direkten Abwertung, aber sie können bewirken, dass Suchmaschinen das Signal gar nicht berücksichtigen, was den Zweck der Einrichtung untergräbt.

#### FAQ

Q: Ist Hreflang dasselbe wie ein Sprachumschalter auf meiner Seite?
A: Nein - ein Sprachumschalter ist ein UI-Element für Besucher; Hreflang ist ein Signal für Suchmaschinen, meist für Besucher unsichtbar, das im HTML-Head der Seite, einem HTTP-Header oder der Sitemap steckt. Eine Seite kann das eine ohne das andere haben, auch wenn beides gemeinsam Standardpraxis ist.

Q: Brauche ich einen x-default-Eintrag?
A: Er ist empfehlenswert, wenn Sie eine Fallback-Seite für Besucher haben, deren Sprache/Region zu keiner Ihrer spezifischen Versionen passt - meist verweist er auf Ihre Standardsprachseite.

Q: Beeinflusst Hreflang mein Suchranking direkt?
A: Es wirkt nicht als Ranking-Booster - es beeinflusst, welche Ihrer Seiten für Suchende in einer bestimmten Sprache/Region erscheint, und hilft zu verhindern, dass Ihre übersetzten Seiten gegenseitig als unerwünschte Duplikate behandelt werden.

Q: Kann Hreflang in der Sitemap statt auf der Seite gesetzt werden?
A: Ja, laut Suchmaschinen-Dokumentation sind beide Wege gültig - manche Seiten bevorzugen sitemapbasiertes Hreflang, weil es sich für eine große Zahl an URLs leichter programmatisch erzeugen und prüfen lässt, was auch der Ansatz ist, den wir bei migrierten Shops meist verwenden.

Sources:
- Google Search Central: Tell Google about localized versions of your page: https://developers.google.com/search/docs/specialty/international/localized-versions

### Produktfeed

URL: https://prevedshop.com/de/glossar/produktfeed
Language: de
Last reviewed: 2026-07-21

Ein Produktfeed ist ein strukturierter Export Ihres Katalogs - meist als CSV, XML oder JSON -, den ein anderes System nach einem festen Zeitplan einliest: ein Lieferant, der Ihnen seinen Katalog sendet, oder Ihr Shop, der seinen Katalog an einen Marktplatz, ein Preisvergleichsportal oder eine Werbeplattform sendet (etwa einen Google-Shopping-Feed). Jeder Feed folgt einem bestimmten Format, das das empfangende System erwartet: bestimmte Felder, in einer bestimmten Struktur, teils mit eigenen erforderlichen Kennungen.

#### Eingehende vs. ausgehende Feeds

Ein eingehender Feed kommt von einem Lieferanten oder Distributor in Ihren Shop - neue Lagerbestände, Preise und Produktdaten, die Ihre Plattform nach Zeitplan übernehmen muss. Ein ausgehender Feed geht den umgekehrten Weg - der Katalog Ihres Shops wird für einen Marktplatz, eine Preisvergleichsmaschine oder eine Werbeplattform aufbereitet. Eine Migration betrifft in der Regel beides: Ihre neue Plattform muss weiterhin Lieferanten-Feeds in dem Format empfangen, das diese bereits senden, und ausgehende Feeds in dem Format erzeugen, das jedes Ziel erwartet - das ist nicht immer identisch mit dem, was Ihre alte Plattform erzeugt hat.

#### Warum Feeds bei einer Migration ausfallen

Feed-Formate sind selten ein universeller Standard - der Feed eines Lieferanten kann Feldnamen, Kategoriecodes oder Kennungen verwenden, für die die Integration Ihrer alten Plattform eigens angepasst wurde. Der Wechsel zu einer neuen Plattform bedeutet, dass diese Parsing-Logik neu aufgebaut werden muss, statt vorauszusetzen, dass sie einfach übernommen wird - selbst wenn sich die Feed-Datei selbst nicht ändert. Das Gleiche gilt umgekehrt: Ein ausgehender Feed, auf den Ihr Marktplatz- oder Werbekonto angewiesen ist, muss auch nach dem Wechsel dem geforderten Format dieses Kanals entsprechen, sonst kann der Kanal ihn ablehnen oder falsch interpretieren.

#### Was eine verwaltete Migration prüft

Wir mappen jeden aktiven eingehenden und ausgehenden Feed bereits in der Bewertung - welches Format er hat, auf welche Felder er sich bezieht und wie oft er läuft -, damit nach dem Umstieg nichts unbemerkt ausfällt. Ein Lieferanten-Feed, der nicht mehr korrekt verarbeitet wird, meldet meist keinen Fehler; er hört einfach still auf, Lagerbestände oder Preise zu aktualisieren - was schlimmer ist als ein offensichtlicher Ausfall, weil es eine Weile unbemerkt bleiben kann.

#### FAQ

Q: Funktioniert der Feed meines Lieferanten automatisch auf meiner neuen Plattform?
A: Nicht automatisch - die neue Plattform braucht eine Integration, die eigens für dieses Feed-Format gebaut (oder wiederverwendet, falls ein passender Connector existiert) wird. Wir bewerten jeden Lieferanten-Feed einzeln in der Bewertungsphase, statt anzunehmen, dass ein generischer Import damit zurechtkommt.

Q: Was passiert mit meinem Google-Shopping- oder Marktplatz-Feed während einer Migration?
A: Er muss auch nach dem Wechsel dem geforderten Format des Ziels entsprechen. Wir prüfen ausgehende Feeds als Teil des Migrationsplans, damit ein Kanal Ihren Katalog nach dem Umstieg nicht ablehnt oder veraltete Daten anzeigt.

Q: Ist ein Produktfeed dasselbe wie ein CSV-Export?
A: Ein CSV-Export kann ein Produktfeed sein, aber "Feed" impliziert meist einen wiederkehrenden, automatisierten Austausch nach Zeitplan, nicht einen einmaligen manuellen Export - auch wenn das zugrunde liegende Dateiformat identisch sein kann.

Q: Können zwei Systeme für dieselben Daten völlig unterschiedliche Feed-Formate verwenden?
A: Ja, das ist üblich - dieselben Katalogdaten können für einen Marktplatz als eine XML-Struktur und für einen anderen als eine andere CSV-Struktur exportiert werden, oder ganz unterschiedliche Feldnamen und Kategorietaxonomien verwenden, was für jeden ein eigenes Mapping erfordert.

### Replatforming

URL: https://prevedshop.com/de/glossar/replatforming
Language: de
Last reviewed: 2026-07-21

Replatforming bedeutet, einen Ecommerce-Shop von einer Plattform auf eine andere umzuziehen - kein Redesign auf derselben Plattform und kein kleines Versions-Update, sondern ein echter Wechsel des zugrunde liegenden Systems, das Ihren Shop betreibt. Es ist der Oberbegriff für das gesamte Projekt: Datenmigration, Weiterleitungsplanung, Theme-/Storefront-Neuaufbau und die Neuverbindung von Integrationen sind alles Bausteine eines Replatforming-Vorhabens.

#### Was als Replatforming zählt (und was nicht)

Der Wechsel von Magento zu Shopify ist Replatforming. Das Upgrade von Magento 1 auf Magento 2 lässt sich ebenfalls als Replatforming einordnen, da sich die zugrunde liegenden Systeme so stark unterscheiden, dass eine echte Migration nötig ist, kein bloßes Update. Ein Theme-Redesign auf derselben Plattform oder das Hinzufügen einer neuen App bzw. eines Plugins ist dagegen kein Replatforming - das zugrunde liegende System und Ihr Datenmodell bleiben unverändert.

#### Häufige Gründe für Replatforming

Der Auslöser ist meist einer oder mehrere der folgenden: Die aktuelle Plattform kann eine benötigte Funktion oder das Wachstum des Geschäfts nicht mehr abbilden, die laufenden Kosten für den Betrieb einer selbst gehosteten Plattform (Hosting, Sicherheits-Patches, PCI-Compliance) rechnen sich nicht mehr, die Plattform erreicht das Ende ihres Lebenszyklus oder verliert den Herstellersupport, oder das Unternehmen ist über das hinausgewachsen, was ein templatebasierter Storefront leisten kann. Selten ist es ein einzelner Grund - meist summiert sich Reibung so lange, bis sie den Aufwand und das Risiko des Wechsels aufwiegt.

#### Warum Replatforming als Projekt behandelt wird, nicht als Aufgabe

Das größte Risiko beim Replatforming liegt nicht in der Wahl der neuen Plattform - es liegt in allem, was korrekt mitziehen muss, damit das Unternehmen keine Daten, kein SEO-Ranking und keine betriebliche Kontinuität verliert: der Katalog, Kundendatensätze, Bestellhistorie, die URL-Struktur samt Weiterleitungen, Lieferanten-Feeds und jede individuelle Logik, die die alte Plattform ausgeführt hat. Es als einzelne Import-Aufgabe statt als geplantes Projekt zu behandeln, ist die häufigste Quelle des tatsächlichen Risikos in einer Migration.

#### FAQ

Q: Wie lange dauert Replatforming üblicherweise?
A: Das hängt stark von der Kataloggröße, der Datenkomplexität, der Anzahl bestehender Integrationen und dem Umfang individueller Funktionalität ab, die neu aufgebaut werden muss - einen universellen Zeitplan gibt es nicht. Eine realistische Schätzung geben wir erst nach der Bewertung des konkreten Shops, nicht als pauschale Zahl.

Q: Muss ich replatformen, wenn ich nur ein neues Design möchte?
A: Nein - ein Redesign auf Ihrer aktuellen Plattform ist meist einfacher und risikoärmer als Replatforming und erfordert weder Datenmigration noch den Neuaufbau von Integrationen. Replatforming ist sinnvoll, wenn die Plattform selbst die Einschränkung ist, nicht nur ihr Erscheinungsbild.

Q: Was ist das größte Risiko bei einem Replatforming-Projekt?
A: Der Verlust von SEO-Ranking durch fehlerhafte Weiterleitungen sowie Datenqualitätsprobleme (defekte Varianten-Beziehungen, verlorene Kundendatensätze, nicht übereinstimmende Bestellhistorie) durch eine unvollständige oder naive Datenmigration - beides lässt sich durch sorgfältige Planung vermeiden, und beides tritt häufig auf, wenn nicht dafür geplant wird.

Q: Kann ich ohne jegliche Ausfallzeit replatformen?
A: Ausfallzeiten lassen sich durch sorgfältige Planung des Umstiegs minimieren (Staging, Timing des DNS-/Traffic-Wechsels, finaler Datenabgleich), aber null Ausfallzeit als Garantie zuzusagen, ist etwas, das wir ohne Kenntnis Ihres konkreten Setups nicht versprechen - wie wir dieses Thema ehrlich behandeln, lesen Sie auf unserer Security-Seite.

### SKU-Mapping

URL: https://prevedshop.com/de/glossar/sku-mapping
Language: de
Last reviewed: 2026-07-21

SKU-Mapping ist der Prozess, bei dem jede Produktkennung (SKU - Stock Keeping Unit, zu Deutsch etwa Artikelnummer) aus Ihrem alten System der passenden Entsprechung im neuen System zugeordnet wird, damit Bestellungen, Lagerbestände und Lieferanten-Feeds vor und nach einer Migration weiterhin auf dasselbe physische Produkt verweisen. Das klingt mechanisch, ist aber einer der Punkte, an denen eine Migration am häufigsten scheitert, wenn sie blind automatisiert statt geprüft wird.

#### Warum SKUs nicht immer sauber übernommen werden

In einer idealen Migration entspricht jede SKU der alten Plattform 1:1 derselben SKU auf der neuen, und nichts ändert sich. In der Praxis haben Plattformen oft unterschiedliche Regeln dafür, was eine SKU enthalten darf, unterschiedliche Handhabung von SKUs auf Varianten- vs. Produktebene, oder eine Historie doppelter bzw. wiederverwendeter SKUs im alten System, die aufgelöst statt unverändert übernommen werden müssen. Ein reiner Datenbank-Export kann diese Unstimmigkeiten mitschleppen, statt sie zu korrigieren.

#### Wo SKU-Mapping mit anderen Systemen zusammenhängt

Ihre SKU ist häufig der Verknüpfungsschlüssel zwischen Ihrem Shop und allem, was daran hängt - Lieferanten-Feeds, ein Lager- oder Fulfillment-System, Buchhaltungssoftware, Marktplatz-Angebote. Ändert sich Format oder Wert einer SKU während einer Migration, ohne dass jedes verbundene System aktualisiert wird, beginnen diese Integrationen, Produkte nicht mehr zuordnen zu können, obwohl der Shop selbst unauffällig aussieht. Das Mapping muss diese nachgelagerten Systeme mitdenken, nicht nur die neue Plattform selbst.

#### Was wir vor der SKU-Migration prüfen

Wir prüfen den bestehenden SKU-Bestand auf Duplikate, uneinheitliche Formatierung und verwaiste SKUs (die von einer Bestellung oder einem Feed referenziert werden, aber zu keinem aktiven Produkt mehr gehören), bevor wir entscheiden, ob sie unverändert übernommen oder auf der neuen Plattform normalisiert werden. Bestehende SKUs zu erhalten ist meist vorzuziehen, wenn nachgelagerte Systeme davon abhängen; eine Normalisierung ist sinnvoll, wenn das alte SKU-Schema selbst das Problem war.

#### FAQ

Q: Sollte ich meine genauen SKUs auf der neuen Plattform beibehalten?
A: Meist ja, wenn ein Lieferanten-Feed, ein Fulfillment-System oder ein Marktplatz-Angebot davon abhängt - eine Änderung der SKUs bricht diese Integrationen, sofern sie nicht gleichzeitig aktualisiert werden. Wir bewerten das im Einzelfall, statt standardmäßig eine Option zu wählen.

Q: Was passiert mit doppelten SKUs während einer Migration?
A: Sie müssen vor oder während der Migration aufgelöst werden, nicht unverändert übernommen - die meisten Plattformen erlauben keine echten doppelten SKUs, und einen automatisierten Import raten zu lassen, wie dedupliziert wird, riskiert, das falsche Produkt zusammenzuführen oder zu verlieren.

Q: Wirkt sich SKU-Mapping auf meine Bestellhistorie aus?
A: Das kann es, wenn historische Bestellungen SKUs referenzieren, die sich ändern - wir berücksichtigen das, damit vergangene Bestelldatensätze nach dem Wechsel weiterhin dem richtigen Produkt zugeordnet werden, statt nur den aktiven Katalog zu mappen.

Q: Ist SKU-Mapping automatisiert oder manuell?
A: Beides - eindeutige 1:1-Treffer lassen sich automatisiert abgleichen und schnell verifizieren, aber uneindeutige Fälle (Duplikate, uneinheitliche Formate, fehlende SKUs) brauchen eine menschliche Entscheidung statt eines geschätzten Algorithmus.

### Strukturierte Daten

URL: https://prevedshop.com/de/glossar/strukturierte-daten
Language: de
Last reviewed: 2026-07-21

Strukturierte Daten sind Markup, das einer Seite hinzugefügt wird (meist nach dem schema.org-Vokabular, im JSON-LD-Format) und ihren Inhalt maschinenlesbar beschreibt - eine Seite wird als Product mit Preis und Verfügbarkeit ausgezeichnet, oder als Organization mit Name und URL, statt Suchmaschinen das aus dem sichtbaren Text erraten zu lassen. Dadurch können Suchergebnisse erweiterte Darstellungen wie Sternebewertungen, Preise oder FAQ-Dropdowns direkt im Suchergebnis anzeigen.

#### Was strukturierte Daten tatsächlich ermöglichen

Suchmaschinen verstehen gewöhnlichen Seiteninhalt oft gut genug, aber strukturierte Daten beseitigen Mehrdeutigkeit und schalten bestimmte Darstellungsformen frei - Produkt-Rich-Results mit Preis, Verfügbarkeit und Bewertung, FAQ-Akkordeons direkt im Suchergebnis, Breadcrumb-Pfade im Ergebnis-Snippet und mehr. Keine dieser Darstellungen ist garantiert (Suchmaschinen entscheiden selbst, wann sie eingesetzt werden), aber ohne das Markup stehen diese Funktionen in der Regel gar nicht erst zur Verfügung.

#### Warum es bei einer Migration Beachtung braucht

Strukturierte Daten werden nicht von jeder Plattform automatisch erzeugt, und Plattformen, die es tun, tun es nicht alle auf dieselbe Weise - Product-Schema, FAQ-Schema und Breadcrumb-Schema müssen jeweils widerspiegeln, was wirklich auf der Seite steht. Eine Migration ist ein häufiger Punkt, an dem strukturierte Daten entweder ganz verloren gehen (das neue Theme bzw. Template enthält sie nicht) oder ungenau werden (ausgezeichnete Daten, die nicht mehr mit dem sichtbaren Seiteninhalt übereinstimmen - was Suchmaschinen eher abstrafen als belohnen können).

#### Nur auszeichnen, was wirklich stimmt

Die wichtigste Regel bei strukturierten Daten lautet, dass sie etwas Reales und Sichtbares auf der Seite beschreiben müssen - FAQPage-Markup nur dort, wo tatsächlich ein FAQ angezeigt wird, Review-/Rating-Markup nur für Bewertungen, die wirklich existieren, Product-Markup mit echtem Preis und echter Verfügbarkeit. Markup, das nicht zur sichtbaren Seite passt, verstößt gegen die eigenen Richtlinien der Suchmaschinen und kann dazu führen, dass die strukturierten Daten ignoriert oder die Seite abgestraft wird - nicht bloß, dass sie "nicht hilft".

#### FAQ

Q: Garantieren strukturierte Daten Rich Results in der Suche?
A: Nein - sie machen Rich Results möglich, aber Suchmaschinen entscheiden eigenständig, ob sie angezeigt werden, basierend auf Relevanz und eigenen Qualitätsprüfungen. Ein bestimmtes Rich Result lässt sich nicht garantieren.

Q: Fügt meine neue Plattform strukturierte Daten automatisch hinzu?
A: Manche Plattformen erzeugen standardmäßig grundlegende strukturierte Daten (etwa Product-Markup), andere benötigen es explizit über ein Theme oder eine App. Wir prüfen, was die neue Plattform von Haus aus liefert, und schließen Lücken, statt das einfach vorauszusetzen.

Q: Kann das Hinzufügen strukturierter Daten meiner SEO schaden?
A: Nur wenn sie ungenau oder manipulativ sind - Markup, das nicht zum tatsächlichen Seiteninhalt passt, verstößt gegen die Richtlinien der Suchmaschinen. Korrekte strukturierte Daten, die den echten Seiteninhalt widerspiegeln, bergen dieses Risiko nicht.

Q: Was ist der häufigste Fehler bei strukturierten Daten während einer Migration?
A: Sie gehen komplett verloren, wenn das neue Theme oder Template nicht übernimmt, was die alte Plattform hatte, oder veraltetes Markup bleibt live, das nicht mehr zur neu gestalteten Seite passt - beides prüfen wir in der Migrations-QA.

Sources:
- Google Search Central: So funktionieren strukturierte Daten: https://developers.google.com/search/docs/appearance/structured-data/sd-policies

### URL-Slug

URL: https://prevedshop.com/de/glossar/url-slug
Language: de
Last reviewed: 2026-07-21

Ein URL-Slug ist der menschenlesbare Teil der Adresse einer Seite, der sie identifiziert - in `prevedshop.com/platforms/shopify` ist `shopify` der Slug. Er wird meist aus dem Namen eines Produkts oder einer Seite abgeleitet, in Kleinbuchstaben und URL-sicher gesetzt, und ist das, was Besucher und Suchmaschinen tatsächlich sehen und referenzieren, wenn sie eine Seite verlinken oder als Lesezeichen speichern.

#### Warum Slugs mehr als nur Lesbarkeit betreffen

Ein klarer, aussagekräftiger Slug hilft Besuchern, vor dem Klick zu verstehen, worum es auf einer Seite geht, und Suchmaschinen gewichten relevante Wörter in der URL durchaus etwas. Die größere Bedeutung eines Slugs ist jedoch strukturell: Er ist Teil der dauerhaften Adresse der Seite, auf die jeder interne und externe Link, jedes gespeicherte Lesezeichen und jedes indexierte Suchergebnis verweist.

#### Warum Migrationen Slugs oft ändern, absichtlich oder nicht

Jede Plattform hat eigene Regeln dafür, wie Slugs erzeugt und strukturiert werden - Längenbegrenzungen, erlaubte Zeichen, ob Produkt-Slugs unter einem Kategoriepfad verschachtelt oder flach sind, wie doppelte Namen unterschieden werden. Der Wechsel zu einer neuen Plattform ändert häufig zumindest einige Slugs, mal weil die neue Plattform ein anderes Muster erzwingt, mal weil es die Gelegenheit ist, unordentliche Alt-Slugs aus dem alten System zu bereinigen. In jedem Fall bedeutet ein geänderter Slug eine geänderte URL, und eine geänderte URL braucht eine Weiterleitung (siehe 301-Weiterleitung) von der alten Adresse.

#### Slugs dort stabil halten, wo es zählt

Bei Seiten mit relevantem bestehendem Suchranking oder vielen eingehenden Links vermeidet das Beibehalten desselben Slugs auf der neuen Plattform (sofern die Plattform das erlaubt) eine Weiterleitung von vornherein und ist oft der einfachste Weg, das Standing dieser Seite zu erhalten. Muss sich ein Slug ändern, hält die gemeinsame Planung von neuem Slug und Weiterleitung - statt die Plattform automatisch generieren zu lassen und sich erst nachträglich um die URL zu kümmern - den Übergang sauber.

#### FAQ

Q: Kann ich meine genauen alten URL-Slugs auf einer neuen Plattform behalten?
A: Oft ja, wenn die URL-Regeln der neuen Plattform es erlauben und Sie sie bewusst setzen, statt automatisch generierte zu übernehmen - das ist einer der einfachsten Wege, für diese Seite ganz ohne Weiterleitung auszukommen.

Q: Schadet eine Slug-Änderung der SEO?
A: Nicht, wenn sie mit einer korrekten 301-Weiterleitung vom alten zum neuen Slug einhergeht - die Weiterleitung gibt den größten Teil des angesammelten Ranking-Signals weiter. SEO-Schaden entsteht durch eine Slug-Änderung ohne Weiterleitung, nicht durch die Slug-Änderung selbst.

Q: Sollte ich meinen Produktnamen genau als Slug verwenden?
A: Im Allgemeinen ja, vereinfacht auf URL-sicher (Kleinbuchstaben, Bindestriche statt Leerzeichen, keine Sonderzeichen) - Slugs, die mit themenfremden Keywords vollgestopft sind, bringen keinen zusätzlichen Nutzen und wirken auf Besucher wie Suchmaschinen wie Spam.

Q: Was passiert, wenn zwei Produkte denselben Slug erzeugen würden?
A: Die Plattform braucht eine Regel zur Unterscheidung - meist durch Anhängen einer Zahl oder einer zusätzlichen Kennung. Wir prüfen das während der Migration, da doppelte Slugs sonst dazu führen können, dass die URL eines Produkts die eines anderen unbemerkt überschreibt.

### Services

### Datenmigration und Daten-Mapping für Onlineshops

URL: https://prevedshop.com/de/leistungen/datenbereinigung-und-mapping
Language: de
Last reviewed: 2026-07-20

Alte Kataloge sammeln im Lauf der Zeit doppelte Produkte, inkonsistente Kategorien und Felder an, deren Zweck niemand mehr kennt. Das bereinigen wir und mappen, was übrig bleibt, auf das tatsächliche Datenmodell Ihrer neuen Plattform - statt das Durcheinander einfach zu übernehmen.

#### Wonach wir suchen

Doppelte oder nahezu doppelte Produkte, verwaiste Kategorien, inkonsistente Attributbenennung, leere oder fehlerhafte Felder sowie alte individuelle Felder, die nichts Sinnvolles mehr abbilden. Was wir finden, besprechen wir mit Ihnen und einigen uns, was korrigiert, zusammengeführt oder entfernt wird.

#### Mapping statt Raten

Jedes Quellfeld erhält ein explizites Mapping auf ein Zielfeld - oder die explizite Entscheidung, dass es nicht gemappt wird und einen anderen Platz braucht (ein individuelles Feld, einen Tag, oder gar keinen). Wir dokumentieren dieses Mapping, damit es nachvollziehbar ist, keine Blackbox.

#### Warum das vor dem Launch wichtig ist

Daten vor der Migration zu bereinigen und zu mappen ist deutlich günstiger, als sie nach dem Launch zu korrigieren, wenn Kunden und Suchmaschinen bereits darauf angewiesen sind. Diesen Schritt zu überspringen ist einer der häufigsten Gründe, warum Migrationen später in Schwierigkeiten geraten.

#### FAQ

Q: Löscht ihr Daten, ohne mich zu fragen?
A: Nein - wir markieren, was wie ein Problem aussieht, und stimmen die Maßnahme mit Ihnen ab, bevor etwas zusammengeführt oder entfernt wird.

Q: Könnt ihr Duplikate über mehrere alte Importe hinweg entfernen?
A: Ja, das ist eine der häufigeren Bereinigungsanfragen - ältere Shops, die im Lauf der Jahre mehrere Lieferanten-Feed-Importe durchlaufen haben, haben oft echte Duplikate.

Q: Kümmert ihr euch auch um individuelle Felder ohne klaren Zweck?
A: Wir untersuchen, wofür ein Feld vermutlich verwendet wurde (basierend auf Datenmustern und, wo möglich, Ihren Angaben), bevor wir entscheiden, ob es gemappt, umgewidmet oder entfernt wird.

### Shopsystem-Wechsel von der Entscheidung bis zum Go-live

URL: https://prevedshop.com/de/leistungen/shopsystem-wechsel
Language: de
Last reviewed: 2026-09-25

Ein Shopsystem-Wechsel ist zuerst eine Geschäftsentscheidung und erst dann eine Datenmigration. Sie ersetzen das System, auf dem Katalog, Checkout, Schnittstellen und organischer Traffic laufen – meist, weil das bisherige zu teuer, zu begrenzt oder zu riskant geworden ist. Wir helfen, die Entscheidung auf Basis von Fakten zu treffen, und planen und steuern dann den Umzug, damit das neue System mit Daten, URLs und Schnittstellen startet.

#### Wann sich ein Wechsel lohnt – und wann nicht

Gute Gründe: Das System hat sein Lebensende erreicht oder erhält keine Sicherheitsupdates mehr (Magento 1, Shopware 5); Hosting, Patches und Plugin-Pflege kosten mehr, als der Shop trägt; das System blockiert, was das Geschäft braucht – neue Märkte, B2B-Preise, Headless, moderner Checkout; oder das Team hält die Plattform am Leben, statt zu verkaufen.

Schwache Gründe sind ein veraltetes Theme, eine einzelne fehlende Funktion, die eine App liefern könnte, oder eine Vertriebsdemo. Ein Redesign oder eine gezielte Integration ist oft günstiger. Wenn das so ist, sagen wir es.

#### Erst Anforderungen, dann Plattformwahl

Wir beginnen mit dem, was der Shop tatsächlich tut: Katalogstruktur und Produkttypen, Preisregeln und Kundengruppen, Märkte, Sprachen und Währungen, ERP-, Lager- und Versandanbindungen, Marktplätze und Feeds, Inhalte und SEO sowie Sonderfunktionen. Jede Anforderung wird als zwingend, ersetzbar oder verzichtbar markiert; diese Liste – nicht eine Feature-Matrix – ist der Vergleichsmaßstab.

#### Was beim Plattformwechsel bricht

Das Datenmodell passt selten: Eigenschaften, Varianten, Bundles und Kategoriebäume verhalten sich im Zielsystem anders. Die URL-Struktur ändert sich, daher braucht jede relevante URL ein Ziel und eine 301-Weiterleitung. Plugins und Apps ziehen nicht mit um; ihre Daten und Funktionen brauchen Ersatz, Neubau oder eine bewusste Abschaltung. Schnittstellen zu ERP, Buchhaltung, Versanddienstleistern und Marktplätzen müssen umgestellt und getestet werden. Kundenpasswörter lassen sich in gehostete Systeme meist nicht übernehmen.

#### Gesamtkosten statt Lizenzpreis

Vergleichen Sie über mehrere Jahre: Abo oder Lizenz, Hosting und Sicherheit, Zahlungsgebühren, Apps und Plugins, Entwicklung, die Migration selbst und interne Zeit für den Betrieb. Wir helfen, den Vergleich aus Ihren Anforderungen aufzubauen; Lizenzen verkaufen wir nicht.

#### Von der Entscheidung zum Go-live

Ist das Zielsystem gewählt, wird der Wechsel zur betreuten Migration: Quellaudit, Daten-Mapping, Testmigration und Freigabe, SEO- und Weiterleitungsplan, Umstellung der Schnittstellen, Content-Freeze, Delta-Migration, Go-live und QA nach dem Launch. Große Shops ziehen oft in Phasen um, damit jeder Schritt prüfbar bleibt.

#### FAQ

Q: Was ist der Unterschied zwischen Shopsystem-Wechsel und Migration?
A: Der Wechsel ist die Entscheidung und das Projekt, das Geschäft auf ein neues Shopsystem zu bringen. Die Migration ist der Teil, der Daten, URLs und Inhalte überträgt.

Q: Wie lange dauert ein Shopsystem-Wechsel?
A: Das hängt von Katalog, Schnittstellen, Design und Entscheidungsgeschwindigkeit ab. Einen Zeitplan erhalten Sie nach der Analyse.

Q: Shopify, Shopware, BigCommerce – oder bleiben?
A: Das hängt von Anforderungen, Märkten, Schnittstellen und Budget ab. Bleiben ist ein legitimes Ergebnis.

Q: Geht ein Wechsel ohne SEO-Verlust?
A: Rankings lassen sich nicht garantieren. Das Risiko sinkt mit vollständigem URL-Inventar, 301-Weiterleitungen, übernommenen Metadaten, angepassten internen Links und Monitoring nach dem Relaunch.

### Betreute Shopmigration: eine verantwortliche Person bis zum Go-live

URL: https://prevedshop.com/de/leistungen/betreute-migration
Language: de
Last reviewed: 2026-07-20

Eine verantwortliche Migrationsleitung plant, führt durch und validiert Ihren Umzug: Produkte, Varianten, Kunden, Bestellungen, Medien, Inhalte und das Design Ihres Shops - als ein koordiniertes Projekt, nicht als Stapel loser Exporte.

#### Was enthalten ist

Die Verwaltete Migration umfasst Ihren gesamten Katalog - Produkte, Varianten, Kategorien und Attribute -, Kundenkonten und Bestellhistorie, Medien und Inhalte, individuelle Felder sowie einen URL-/Weiterleitungsplan. Das Storefront-Design wird als Teil desselben Projekts übertragen oder neu aufgebaut, nicht als spätere Überraschung separat berechnet.

Wir legen den genauen Umfang bereits in der Bewertung fest, damit Sie nicht bis zur Rechnung raten müssen, was "Migration" eigentlich umfasst.

#### Wie die Designübertragung funktioniert

Wo die Zielplattform Ihr aktuelles Design realistisch nachbilden kann, bauen wir es dort neu auf. Wo die Plattformen zu unterschiedlich für eine 1:1-Übertragung sind, sagen wir das vorab und schlagen einen Ansatz vor - eine Anpassung Ihres Designs an die Möglichkeiten der neuen Plattform, statt so zu tun, als wäre es eine einfache Kopie.

#### Eine Leitung, von Anfang bis Ende

Eine benannte Migrationsleitung ist für das gesamte Projekt verantwortlich - Bewertung, Mapping, Testmigration, Validierung, Launch und Prüfungen nach dem Launch. Wiederholbare automatisierte Kontrollen helfen, Daten zu prüfen und Unstimmigkeiten zu markieren; die Leitung prüft und genehmigt jedoch jede Phase, bevor es weitergeht.

#### FAQ

Q: Wie lange dauert eine verwaltete Migration?
A: Das hängt von der Kataloggröße, der Datenkomplexität und der Anzahl individueller Felder oder Integrationen ab - einen realistischen Zeitplan geben wir Ihnen erst nach der Bewertung, nicht als pauschale Schätzung.

Q: Was, wenn meine aktuelle Plattform keinen sauberen Export hat?
A: Wir arbeiten mit dem, was Sie haben - Datenbankexporte, API-Zugang, XML/CSV-Feeds oder eine Kombination. Unübersichtlichere Quellen benötigen mehr Bewertungszeit, die wir von Anfang an einplanen.

Q: Migriert ihr auch installierte Apps und Integrationen?
A: Wir migrieren die Daten, auf denen diese Apps basieren, aber app-spezifische Konfiguration muss in der Regel im Äquivalent der Zielplattform neu aufgebaut werden, falls vorhanden. Das weisen wir bereits in der Bewertung aus, nicht erst beim Launch.

### SEO-Migration beim Shop-Relaunch und 301-Weiterleitungen

URL: https://prevedshop.com/de/leistungen/seo-und-weiterleitungen
Language: de
Last reviewed: 2026-07-20

URL-Strukturen überstehen einen Plattformwechsel selten unverändert. Wir mappen alte URLs auf ihre neuen Entsprechungen und richten Weiterleitungen als zentralen, geplanten Teil der Migration ein - nicht als nachträgliche Reparatur, wenn die Rankings schon eingebrochen sind.

#### URL-Mapping statt Rätselraten

Wir erstellen eine explizite Zuordnung von jeder relevanten alten URL zu ihrer neuen Entsprechung - Produktseiten, Kategorieseiten, Blog-/Inhaltsseiten und individuelle Landingpages. Seiten ohne saubere Entsprechung erhalten eine dokumentierte Entscheidung, keinen stillen 404-Fehler.

#### Weiterleitungen und Metadaten

301-Weiterleitungen werden vor dem Launch auf der neuen Plattform eingerichtet, und wir übernehmen Metadaten (Titel, Beschreibungen, kanonische Tags) dort, wo sie für die neue URL tatsächlich noch zutreffend sind. Wir prüfen auf Weiterleitungsketten und -schleifen, statt anzunehmen, dass eine 1:1-Zuordnung automatisch sauber ist.

#### Was wir versprechen können - und was nicht

Konkrete Rankings können wir nicht garantieren - das kann niemand ehrlich versprechen, da Rankings von vielen Faktoren außerhalb jeder Migration abhängen. Was wir kontrollieren und als feste Anforderung behandeln, ist URL-Kontinuität: dass alte Links und Lesezeichen auf die richtige neue Seite führen, nicht in eine Sackgasse.

#### FAQ

Q: Überstehen meine Google-Rankings die Migration?
A: Korrektes URL-Mapping und Weiterleitungen sind mit Abstand der wichtigste Faktor, um Rankings bei einer Migration zu erhalten, und wir behandeln sie als zentrales Ergebnis. Konkrete Positionen können wir nicht garantieren, da sie von Faktoren außerhalb der Migration abhängen.

Q: Was passiert mit Seiten, die es auf der neuen Plattform nicht gibt?
A: Wir markieren sie bereits in der Mapping-Phase und stimmen mit Ihnen das beste Weiterleitungsziel ab - meist die nächstliegende passende Kategorie oder eine relevante Übersichtsseite, keine pauschale Weiterleitung auf die Startseite.

Q: Aktualisiert ihr auch interne Links, nicht nur externe Weiterleitungen?
A: Wo praktikabel, ja - interne Links, die auf alte URL-Muster verweisen, werden im Rahmen der Migration aktualisiert, da Weiterleitungsketten Ladezeit kosten und den Link-Wert verwässern.

### Lieferanten-Feed-Integration

URL: https://prevedshop.com/de/leistungen/lieferantenfeed-integration
Language: de
Last reviewed: 2026-07-20

Einen Katalog auf Basis von Lieferanten-Feeds zu betreiben bedeutet, mit inkonsistenten Formaten, doppelten SKUs über mehrere Lieferanten hinweg und einem Update-Timing umzugehen, das nicht immer zu Ihrer Plattform passt. Wir binden diese Feeds an und normalisieren sie, damit Ihr Katalog ohne manuellen Aufwand korrekt bleibt.

#### Was wir normalisieren

Lieferanten-Feeds teilen sich selten ein Format - Feldnamen, Kategoriestrukturen und sogar Maßeinheiten unterscheiden sich von Lieferant zu Lieferant. Wir mappen jeden Feed auf eine einheitliche Struktur in Ihrer Plattform, damit sich Produkte in Ihrem Katalog unabhängig von der Quelle gleich verhalten.

#### Duplikate und Zusammenführung

Führen mehrere Lieferanten dasselbe Produkt, können wir Einträge zusammenführen, eine bevorzugte Quelle wählen, oder sie getrennt halten - je nachdem, wie Sie Preis und Bestand handhaben möchten. Diese Entscheidung treffen wir gemeinsam mit Ihnen, nicht als Standard, den wir Ihnen aufzwingen.

#### Daten aktuell halten

Wie oft ein Feed aktualisiert wird, hängt davon ab, was Ihre Lieferanten tatsächlich liefern und was Ihre Plattform sinnvoll verarbeiten kann - wir vereinbaren einen realistischen Zeitplan, statt Echtzeit-Updates zu versprechen, die ein Quell-Feed nicht leisten kann.

#### FAQ

Q: Könnt ihr Feeds mehrerer Lieferanten in einem Katalog zusammenführen?
A: Ja - das Zusammenführen, Entdoppeln und Normalisieren mehrerer Lieferanten-Feeds zu einem einheitlichen Katalog ist ein üblicher Teil dieser Leistung.

Q: Was passiert, wenn ein Lieferant ein Produkt einstellt?
A: Je nach Ihrer Präferenz können wir es als nicht verfügbar markieren, ausblenden, oder mit Vorbestellstatus sichtbar lassen - einmal konfiguriert, wird es bei zukünftigen Feed-Updates automatisch angewendet.

Q: Können Lieferanten-Feeds für andere Märkte übersetzt werden?
A: Ja, Feed-Inhalte können übersetzt werden, entweder per automatischer Übersetzung oder über ein individuelles Mapping, das Sie uns bereitstellen, je nach gewünschter Genauigkeit.


## Português (pt)

### Platform profiles

### Migrar para ou a partir da Adobe Commerce (Magento)

URL: https://prevedshop.com/pt/plataformas/adobe-commerce-magento
Language: pt
Last reviewed: 2026-07-21

"Magento" cobre hoje várias coisas distintas: a plataforma open-source Magento Open Source, o nível pago Adobe Commerce Cloud e instalações legadas do Magento 1, já fora do fim de vida útil. Qual delas está realmente a usar muda significativamente o plano de migração, por isso identificar a versão e a edição exatas é o primeiro passo, quer o Magento seja a sua origem quer o seu destino.

#### Magento Open Source, Adobe Commerce e Magento 1 vs. 2

O Magento Open Source é um software de ecommerce gratuito, autoalojado e baseado em PHP; a Adobe Commerce (antigo Magento Commerce) é o nível pago, com funcionalidades adicionais de B2B, staging de conteúdo e alojamento na cloud, executado em infraestrutura gerida pela Adobe. O Magento 1 atingiu o fim de vida há anos, e as lojas que ainda o utilizam estão normalmente a migrar só por esse motivo, independentemente de qualquer decisão de comparação entre plataformas.

Dada essa amplitude, um projeto de "migração Magento" pode significar mover uma pequena loja Magento 1 para uma plataforma completamente diferente, mover o Magento 1 para o Magento 2 (continua a ser Magento, mas uma reconstrução de versão major), ou sair da Adobe Commerce Cloud para algo com uma estrutura de custos diferente. Definimos qual destes cenários se aplica antes de estimar seja o que for.

#### O modelo de dados EAV e a configuração multi-loja

O Magento guarda os dados de produto numa estrutura EAV (entidade-atributo-valor), potente para catálogos altamente configuráveis e ricos em atributos, mas estruturalmente diferente das tabelas de produto planas e mais simples que a maioria das outras plataformas utiliza. Os produtos configuráveis (a versão do Magento para variantes), os conjuntos de atributos personalizados e a navegação em camadas orientada por atributos precisam todos de um mapeamento explícito ao migrar para uma plataforma sem equivalente EAV.

A arquitetura multi-loja/multi-site do Magento, que permite correr várias lojas online, moedas ou idiomas a partir de uma única instalação, é outro ponto a mapear com cuidado, já que a maioria das plataformas trata o multi-loja de forma diferente: lojas separadas, uma única loja com definições específicas por mercado, ou nenhum equivalente nativo.

#### Extensões, módulos personalizados e programadores Magento

As lojas Magento dependem normalmente de extensões de marketplace e de módulos construídos à medida para tudo o que vai além da funcionalidade base, como métodos de pagamento, regras de preços B2B ou lógica de catálogo específica do negócio. Por ser uma plataforma muito orientada para programadores, uma parte significativa do que uma loja "faz" vive frequentemente em código PHP personalizado e não em definições de administração, e essa lógica tem de ser identificada e reconstruída ou substituída, não apenas exportada.

Os temas seguem o mesmo padrão: os temas Magento assentam no seu próprio sistema de layout XML/blocos, sem equivalente direto noutro lado, pelo que sair do Magento costuma implicar uma construção de raiz da loja na nova plataforma.

#### SEO, URLs e como tratamos uma migração Magento

O Magento gere internamente os redirecionamentos de URL e suporta estruturas de URL bastante flexíveis, mas os detalhes concretos (caminhos de categoria, sufixos de URL de produto, URLs específicas por store view) variam muito de loja para loja consoante a configuração. É precisamente por essa variabilidade que começamos com uma auditoria aos padrões de URL reais e em produção, em vez de presumir uma definição padrão do Magento.

Numa migração Magento, construímos o mapa de URLs/redirecionamentos com base no que a sua loja realmente faz hoje, tratamos as variantes de URL multi-loja quando relevante e validamos que os metadados e as tags canónicas são transportados corretamente. O nosso serviço de SEO e Migração de Redirecionamentos cobre isto com mais detalhe.

#### FAQ

Q: Ainda estou no Magento 1. Conseguem migrar-me?
A: Sim, sair do Magento 1 é um dos projetos mais comuns que vemos, normalmente motivado pelo fim de vida da plataforma e não por uma preferência entre plataformas. Tratamos isto como uma mudança de plataforma completa, já que o Magento 1 e o 2 têm arquiteturas subjacentes diferentes.

Q: O que acontece aos meus módulos Magento personalizados?
A: Identificamos o que cada módulo personalizado realmente faz, seja uma integração de pagamento, uma regra de preços ou uma funcionalidade de catálogo, e avaliamos se a plataforma de destino tem um equivalente nativo ou por extensão, ou se é preciso desenvolvimento personalizado.

Q: As funcionalidades de B2B da Adobe Commerce migram para uma plataforma não-enterprise?
A: Depende das funcionalidades. Contas empresariais, fluxos de orçamento e preços B2B por níveis não têm um equivalente direto em todas as plataformas, por isso avaliamos isto caso a caso durante o levantamento inicial, sem presumir uma correspondência total.

Q: Como é que a estrutura de atributos EAV afeta o tempo de migração?
A: Catálogos com muitos atributos e conjuntos de atributos personalizados costumam levar mais tempo de mapeamento do que catálogos planos e simples, já que cada atributo precisa de uma decisão explícita sobre onde fica na plataforma de destino.

Sources:
- Adobe Commerce (Magento) - página oficial do produto: https://business.adobe.com/products/magento/magento-commerce.html

### Migrar para ou a partir do BigCommerce

URL: https://prevedshop.com/pt/plataformas/bigcommerce
Language: pt
Last reviewed: 2026-07-21

O BigCommerce é uma plataforma SaaS alojada que surge dos dois lados das migrações que tratamos: comerciantes que migram para ele pela estrutura de categorias nativa e pelas opções headless, e comerciantes que saem dele à medida que as suas necessidades mudam. Tal como noutras plataformas fechadas e orientadas por API, o que mais importa numa migração com o BigCommerce é o que a sua API e modelo de dados expõem, não apenas quantos produtos está a mover. Esta página cobre o que realmente importa quando o BigCommerce está de um dos lados de uma migração.

#### O que é o BigCommerce e onde se encaixa

O BigCommerce é uma plataforma de ecommerce SaaS alojada: o BigCommerce trata do alojamento, dos patches de segurança e do tempo de atividade, e a loja é gerida através do painel de administração e das APIs, e não de um servidor sob o seu controlo. Os planos vão desde os níveis standard, pensados para comerciantes pequenos e médios, até ao Enterprise. O Multi-Storefront está disponível em vários planos com limites diferentes de lojas; o Enterprise pode oferecer limites de API e níveis de suporte superiores, além de mais funcionalidades B2B. O BigCommerce também oferece uma abordagem headless, permitindo usar o seu backend e APIs com um frontend construído à medida em vez da sua própria camada de temas.

As lojas na via standard, não headless, são construídas com a framework de temas Stencil do BigCommerce, com temas disponíveis no BigCommerce Theme Marketplace ou desenvolvidos à medida. Como em qualquer plataforma fechada e alojada, as migrações de e para o BigCommerce trabalham dentro do seu modelo de dados e da sua API, e não através de uma cópia direta da base de dados, pelo que o que a API expõe para produtos, encomendas e clientes determina o que pode ser transferido automaticamente.

#### Produtos, categorias e o modelo de dados

Ao contrário de plataformas que dependem apenas de coleções baseadas em etiquetas, o BigCommerce suporta uma árvore de categorias nativa e aninhada, a par de produtos e das respetivas variantes. Isto torna-o um ajuste comparativamente bom para catálogos com estruturas de categorias multinível, já que não é preciso achatar uma hierarquia de categorias em etiquetas ou coleções inteligentes, como aconteceria noutras plataformas alojadas.

Os clientes e o histórico de encomendas passam pelas APIs REST e GraphQL do BigCommerce, mas, como em qualquer migração de plataforma, as encomendas históricas costumam chegar como registos de referência e não como encomendas totalmente ativas e reeditáveis. Os dados de produto personalizados costumam mapear-se para os campos personalizados do BigCommerce, e as price lists (o mecanismo do BigCommerce para preços específicos por grupo de clientes ou moeda) são uma das primeiras coisas que verificamos quando a plataforma de origem tem a sua própria configuração de preços em níveis.

#### Apps, temas e o que não se transfere automaticamente

Uma loja BigCommerce em funcionamento costuma depender de apps do BigCommerce App Marketplace, para avaliações, subscrições, pesquisa, automação de marketing ou regras de envio. Os dados guardados pelas apps não são transferidos numa migração de plataforma; sair do BigCommerce implica exportar separadamente tudo o que está guardado dentro de uma app, e entrar no BigCommerce implica reinstalar e reconfigurar equivalentes em vez de transportar as definições da app.

Os temas Stencil não se traduzem para o sistema de templates de outra plataforma, pelo que sair do BigCommerce costuma implicar reconstruir o design da loja na nova plataforma, e entrar no BigCommerce significa adaptar um tema do marketplace ou encomendar desenvolvimento de tema personalizado. Se optar pela via headless, o frontend fica totalmente desacoplado da camada de temas do BigCommerce, o que muda o próprio âmbito do que significa "migração de design".

#### SEO, URLs e como tratamos uma migração para/do BigCommerce

O BigCommerce é mais flexível quanto à estrutura de URLs do que alguns concorrentes alojados, permitindo definir URLs personalizadas para produtos, categorias e páginas em vez de impor um único padrão fixo. Essa flexibilidade ajuda quando está a migrar para o BigCommerce e quer que as URLs se assemelhem às antigas, mas isso não acontece automaticamente, e sair do BigCommerce continua a implicar mapear os seus padrões de URL para o que a nova plataforma exigir.

Como parte de uma migração gerida, comparamos a sua estrutura de URLs existente com a do BigCommerce, configuramos os redirecionamentos necessários em qualquer direção, e transportamos os metadados que continuam corretos nas novas URLs, seguindo a mesma abordagem descrita no nosso serviço de SEO e Migração de Redirecionamentos, ajustada às limitações específicas de API e de encaminhamento do BigCommerce.

#### FAQ

Q: Consigo manter a minha estrutura de categorias aninhadas ao migrar para o BigCommerce?
A: Sim. O BigCommerce suporta uma árvore de categorias nativa e multinível, pelo que uma estrutura de categorias profunda vinda de outra plataforma costuma mapear-se de forma mais direta do que aconteceria numa plataforma que só suporta etiquetas ou coleções planas.

Q: O que acontece às minhas apps do BigCommerce se eu migrar?
A: Os dados específicos de cada app geralmente precisam de ser exportados separadamente antes da migração. Migramos os dados centrais da loja de que uma app depende, mas não a sua configuração interna nem os registos que guarda.

Q: A opção headless do BigCommerce muda a forma como uma migração funciona?
A: Muda o que significa migrar o tema, já que uma configuração headless desacopla o frontend da própria camada de temas do BigCommerce, mas os dados subjacentes de produtos, encomendas e clientes continuam a passar da mesma forma pela API.

Q: As minhas URLs mantêm-se se migrar para o BigCommerce?
A: Só se configurar deliberadamente URLs personalizadas correspondentes, o que o BigCommerce permite para produtos, categorias e páginas. Normalmente configuramos redirecionamentos em vez de presumir uma correspondência de 1 para 1.

Sources:
- BigCommerce - site oficial: https://www.bigcommerce.com

### Migrar para ou a partir do OpenCart

URL: https://prevedshop.com/pt/plataformas/opencart
Language: pt
Last reviewed: 2026-07-21

O OpenCart é uma plataforma de ecommerce open-source que vemos regularmente em migrações, normalmente vinda de comerciantes que começaram com ela pelo custo baixo e pela simplicidade e que agora estão a ultrapassar uma configuração autogerida, ou de comerciantes que a escolhem especificamente pela sua pegada leve. Por ser open-source e autoalojado, a complexidade da migração costuma depender de quanto a loja foi personalizada com extensões, não apenas de quantos produtos tem o catálogo. Esta página cobre o que realmente importa quando o OpenCart está de um dos lados de uma migração.

#### O que é o OpenCart e onde se encaixa

O OpenCart é um software de ecommerce open-source construído em PHP e MySQL, autoalojado num servidor sob o controlo do cliente ou do seu fornecedor de alojamento. É conhecido por um núcleo comparativamente leve e uma barreira de entrada mais baixa do que outras plataformas open-source, o que o torna popular entre comerciantes mais pequenos e agências a construir lojas com orçamentos reduzidos. A gestão multi-loja a partir de um único painel de administração é uma funcionalidade nativa, e não um extra.

As lojas usam o sistema de temas próprio do OpenCart, baseado no motor de templates Twig desde o OpenCart 3, com temas e extensões disponíveis através do OpenCart Marketplace oficial ou construídos à medida. Como em qualquer plataforma open-source autoalojada, a quantidade de código personalizado e de extensões de terceiros que uma loja carrega é uma das primeiras coisas que determina o âmbito da migração.

#### Produtos, opções e o modelo de dados

O catálogo do OpenCart assenta em produtos organizados em categorias, com "opções" de produto a tratar a variação, como tamanho ou cor, de uma forma estruturalmente diferente de um sistema de variantes dedicado ao nível de SKU noutras plataformas. As opções no OpenCart podem ajustar preço e quantidade, mas o modelo subjacente não é idêntico a verdadeiras variantes, o que importa ao migrar um catálogo que usa variantes propriamente ditas noutro lado para o OpenCart, ou a partir do OpenCart para uma plataforma com um modelo de variantes mais rígido.

Por ser autoalojado, o acesso direto à base de dados costuma estar disponível para exportações, o que pode simplificar a extração de dados de produtos, clientes e encomendas. Mas lojas que foram personalizadas com extensões ou com ficheiros do núcleo modificados, um padrão comum no ecossistema OpenCart, sobretudo com extensões mais antigas baseadas em VQMod ou OCMOD, precisam de ter essas personalizações identificadas antes de se presumir uma exportação limpa e standard.

#### Extensões, temas e o que não se transfere automaticamente

Uma loja OpenCart em funcionamento depende muitas vezes de extensões instaladas, para pagamentos, envios, ferramentas de marketing ou funcionalidades de catálogo além do núcleo do OpenCart. Os dados e as definições das extensões não se transferem automaticamente numa migração de plataforma; sair do OpenCart implica verificar o que cada extensão guarda e exportá-lo separadamente, e entrar no OpenCart implica instalar e configurar equivalentes a partir do OpenCart Marketplace ou através de desenvolvimento personalizado.

Os temas do OpenCart, baseados em Twig, são específicos do seu sistema de templates e não se transportam para outras plataformas, pelo que sair do OpenCart costuma implicar reconstruir o design da loja noutro lado, e entrar no OpenCart significa adaptar um tema do marketplace ou construir um tema personalizado. Instalações mais antigas do OpenCart, anteriores à versão 3.0, podem ainda usar o sistema de temas anterior, algo que vale a pena sinalizar cedo, já que afeta como um redesign é definido em termos de âmbito.

#### SEO, URLs e como tratamos uma migração para/do OpenCart

O OpenCart suporta reescrita de URLs otimizada para SEO em produtos e categorias, mas isso tem de ser ativado e configurado, não é a predefinição de fábrica, e instalações mais antigas ou fortemente personalizadas por vezes ainda correm com URLs predefinidas, pouco amigáveis. Sair do OpenCart implica verificar qual o modo de URL realmente em uso antes de presumir um mapeamento limpo para a nova plataforma.

Como parte de uma migração gerida, auditamos a sua configuração atual de URLs no OpenCart, ou planeamos a do destino se estiver a entrar no OpenCart, construímos um mapa de redirecionamentos entre URLs antigas e novas, e transportamos os metadados que continuam corretos, seguindo a mesma abordagem descrita no nosso serviço de SEO e Migração de Redirecionamentos, aplicada à configuração específica do OpenCart.

#### FAQ

Q: O OpenCart é gratuito?
A: O núcleo do software OpenCart é open-source e gratuito para descarregar e autoalojar. Os custos contínuos vêm do alojamento, do tempo de programação e de eventuais extensões ou temas pagos do OpenCart Marketplace.

Q: Como se comparam as opções de produto do OpenCart com as variantes noutras plataformas?
A: As opções do OpenCart podem ajustar preço e quantidade por combinação, mas não estão estruturadas de forma idêntica a um sistema de variantes dedicado ao nível de SKU, pelo que mapeá-las de ou para uma plataforma com um modelo de variantes mais rígido exige uma revisão cuidada, e não uma correspondência direta de campos.

Q: Conseguem migrar as minhas extensões do OpenCart e os respetivos dados?
A: Migramos os dados centrais da loja de que uma extensão depende, mas as definições específicas da extensão e os registos que guarda costumam precisar de uma exportação separada a partir dessa extensão, ou de ser reconstruídos com um equivalente na plataforma de destino.

Q: A minha versão do OpenCart afeta a migração?
A: Sim. Instalações mais antigas do OpenCart, sobretudo anteriores à versão 3.0, podem diferir de forma significativa no sistema de temas, no formato das extensões e até no esquema da base de dados, por isso confirmamos a sua versão logo no início da avaliação.

Sources:
- OpenCart - site oficial: https://www.opencart.com

### Migrar para ou a partir do PrestaShop

URL: https://prevedshop.com/pt/plataformas/prestashop
Language: pt
Last reviewed: 2026-07-21

O PrestaShop é uma plataforma de ecommerce open-source que vemos com frequência em migrações, sobretudo por parte de comerciantes na Europa que migram para ele pela flexibilidade de ser autoalojado, ou que saem dele à medida que ultrapassam uma configuração autogerida. Por ser open-source e autoalojado (ou alojado através da própria oferta de cloud do PrestaShop), o que determina a complexidade de uma migração costuma ser a estrutura da base de dados e os módulos de que a loja depende, não apenas o tamanho do catálogo. Esta página cobre o que realmente importa quando o PrestaShop está de um dos lados de uma migração.

#### O que é o PrestaShop e onde se encaixa

O PrestaShop é um software de ecommerce open-source construído em PHP e MySQL, na maioria dos casos autoalojado, embora o PrestaShop também ofereça a sua própria opção de alojamento na cloud. Ser open-source significa que o cliente, ou o seu fornecedor de alojamento, gere diretamente o servidor, a versão de PHP e a base de dados, e tem acesso total ao código subjacente, ao contrário das plataformas SaaS fechadas. Tem uma presença particularmente forte entre comerciantes em França, Espanha e noutros mercados europeus.

As lojas são construídas com o sistema de temas próprio do PrestaShop, com temas e módulos disponíveis no marketplace oficial do PrestaShop (Addons) ou desenvolvidos à medida. Por ter o código aberto, as personalizações de uma loja PrestaShop podem ir de configurações simples a desenvolvimento profundo de módulos personalizados, e a quantidade de código à medida que uma loja transporta é uma das primeiras coisas que molda o âmbito de uma migração.

#### Produtos, categorias e o modelo de dados

O modelo de catálogo do PrestaShop assenta em produtos com combinações (o termo usado para variantes, como tamanho ou cor), organizados numa árvore de categorias nativa e sem limite de profundidade, mais "características" e "atributos" separados para dados de produto estruturados. Essa árvore de categorias nativa torna o PrestaShop um destino razoável para catálogos com estruturas hierárquicas profundas, e é uma das coisas que mapeamos com cuidado ao migrar uma árvore de categorias para lá, ou a partir dele para uma plataforma com um modelo mais plano.

Os clientes e o histórico de encomendas residem diretamente na base de dados MySQL do PrestaShop, o que, numa loja autoalojada, significa que o acesso direto à base de dados costuma estar disponível para exportações, em vez de ficar limitado ao que uma API REST expõe. Isso pode simplificar algumas partes de uma migração, mas também significa que as personalizações específicas da loja ao esquema da base de dados, feitas por exemplo através de módulos personalizados, precisam de ser identificadas antes de se presumir que uma exportação standard captura tudo.

#### Módulos, temas e o que não se transfere automaticamente

Uma loja PrestaShop em funcionamento depende normalmente de módulos instalados, para pagamentos, cálculo de portes, marketing ou funcionalidades de catálogo que não fazem parte do núcleo do PrestaShop. Os dados e a configuração dos módulos não se transferem automaticamente numa migração de plataforma; sair do PrestaShop implica identificar o que cada módulo guarda e exportá-lo separadamente, e entrar no PrestaShop implica instalar e configurar equivalentes a partir do marketplace Addons ou através de desenvolvimento personalizado.

Os temas do PrestaShop estão associados ao seu próprio sistema de templates e não se traduzem para outras plataformas, pelo que sair do PrestaShop costuma implicar reconstruir o design da loja na nova plataforma, e entrar no PrestaShop significa adaptar um tema do marketplace ou encomendar um tema personalizado. As lojas autoalojadas por vezes também carregam código personalizado ao nível do tema, que precisa de ser revisto separadamente do próprio design visual.

#### SEO, URLs e como tratamos uma migração para/do PrestaShop

O PrestaShop permite uma reescrita de URLs bastante flexível e configurável para produtos, categorias e páginas CMS, o que ajuda quando se quer preservar a estrutura de URLs durante uma migração, mas isso continua a exigir uma configuração deliberada e não pode ser presumido. Sair do PrestaShop implica mapear os seus padrões de URL, que podem variar significativamente de loja para loja por serem configuráveis, para os requisitos da nova plataforma.

Como parte de uma migração gerida, revemos a sua configuração de URLs existente no PrestaShop, ou a do destino se estiver a entrar no PrestaShop, construímos um mapa de redirecionamentos entre as URLs antigas e novas, e transportamos os metadados que continuam corretos, seguindo a mesma abordagem descrita no nosso serviço de SEO e Migração de Redirecionamentos, aplicada à configuração de encaminhamento específica do PrestaShop.

#### FAQ

Q: O PrestaShop é gratuito?
A: O núcleo do software PrestaShop é open-source e gratuito para descarregar e autoalojar. Os custos vêm do alojamento, do tempo de programação, de módulos e temas pagos, e de qualquer plano de alojamento na cloud do PrestaShop que escolha em vez de autoalojar.

Q: Conseguem migrar os meus módulos PrestaShop e os respetivos dados?
A: Migramos os dados centrais da loja de que um módulo depende, mas a configuração específica do módulo e os registos que guarda costumam precisar de uma exportação separada a partir desse módulo, ou de ser reconstruídos com um equivalente na plataforma de destino.

Q: A estrutura de categorias do PrestaShop transfere-se bem para outras plataformas?
A: Depende do destino. A árvore de categorias nativa e sem limite de profundidade do PrestaShop mapeia-se de forma limpa para plataformas com um modelo semelhante, mas precisa de ser reconvertida em etiquetas ou coleções em plataformas que não suportam categorias aninhadas verdadeiras.

Q: Qual a importância da versão do PrestaShop numa migração?
A: Importa bastante, já que o esquema da base de dados e a compatibilidade de módulos podem diferir entre versões major. Confirmamos a sua versão do PrestaShop durante a avaliação, antes de finalizar uma abordagem de migração.

Sources:
- PrestaShop - site oficial: https://www.prestashop.com

### Migrar para ou a partir do Shopify

URL: https://prevedshop.com/pt/plataformas/shopify
Language: pt
Last reviewed: 2026-07-21

O Shopify é um dos destinos de migração mais comuns com que trabalhamos, tanto como plataforma de chegada como de saída. Por ser uma plataforma fechada e alojada, grande parte do que determina a fluidez da mudança depende do que a API do Shopify realmente expõe, não apenas do tamanho do seu catálogo. Esta página cobre o que realmente importa quando o Shopify está de um dos lados de uma migração.

#### O que é o Shopify e onde se encaixa

O Shopify é uma plataforma de ecommerce SaaS alojada: não gere servidores, versões de PHP nem cópias de segurança de bases de dados. O Shopify trata da infraestrutura e a sua loja é gerida através do painel de administração e, para personalizações mais profundas, das suas APIs. Os planos vão desde os níveis standard, pensados para comerciantes pequenos e médios, até ao Shopify Plus, dirigido a comerciantes de maior volume que precisam de mais personalização no checkout e limites de API mais elevados.

As lojas são construídas com a linguagem de templates própria do Shopify, o Liquid, e os temas provêm da Shopify Theme Store ou de desenvolvimento à medida. Por ser uma plataforma de código fechado e alojada, trabalha-se dentro do modelo de dados e dos pontos de extensão do Shopify em vez de alterar o código base, o que explica precisamente por que motivo as migrações de e para o Shopify dependem do acesso à API e da configuração das apps, e não de uma cópia direta da base de dados.

#### Produtos, encomendas e clientes: o modelo de dados

O modelo de produtos do Shopify assenta em produtos e variantes (por exemplo, uma t-shirt com variantes de tamanho/cor), organizados em coleções manuais ou automáticas em vez de uma árvore de categorias livre. Migrar um catálogo para o Shopify costuma implicar reconverter a estrutura de categorias ou atributos da plataforma de origem no modelo de produto/variante/coleção do Shopify, o que é direto para catálogos simples e mais trabalhoso para plataformas com categorias profundas e multinível ou produtos altamente configuráveis.

Os clientes e o histórico de encomendas passam através da Admin API, mas os dados das encomendas estão ligados ao próprio modelo de encomendas e de processamento do Shopify, pelo que as encomendas históricas costumam ser migradas como registos de referência, e não como encomendas totalmente ativas e editáveis. Os metafields (o mecanismo de campos personalizados do Shopify) são geralmente onde acabam os dados de produto não standard, e mapear os seus campos personalizados existentes para metafields é uma das primeiras coisas que definimos no âmbito do projeto.

#### Apps, temas e o que não se transfere automaticamente

Uma loja Shopify em funcionamento depende normalmente de um conjunto de apps instaladas, para avaliações, subscrições, fidelização, pesquisa ou regras de envio. Os dados das apps geralmente não são transferidos numa migração de plataforma; se está a sair do Shopify, os dados guardados por essa app (como calendários de subscrição ou pontos de fidelização) precisam de uma exportação separada a partir dessa app, e se está a entrar no Shopify, vai reinstalar equivalentes da Shopify App Store em vez de transportar a configuração da app.

O mesmo se aplica aos temas: um tema Liquid não se traduz para o sistema de templates de outra plataforma, pelo que sair do Shopify implica, em geral, reconstruir o design da loja na nova plataforma, e entrar no Shopify significa personalizar um tema da Theme Store ou encomendar desenvolvimento Liquid à medida.

#### SEO, URLs e como tratamos uma migração para/do Shopify

O Shopify impõe os seus próprios padrões de URL, como /products/{handle}, /collections/{handle} e /pages/{handle}, que raramente coincidem exatamente com a estrutura de URLs de outra plataforma. Migrar para ou a partir do Shopify implica quase sempre um mapa de redirecionamentos das URLs antigas para as novas, já que o Shopify não permite replicar totalmente uma estrutura de URLs arbitrária de outro sistema, e outras plataformas não vão conhecer automaticamente os seus handles do Shopify.

Como parte de uma migração gerida, mapeamos as suas URLs existentes face à estrutura do Shopify (ou o inverso, quando está a sair do Shopify), configuramos redirecionamentos 301 e transportamos os metadados que continuam corretos nas novas URLs, seguindo a mesma abordagem descrita no nosso serviço de SEO e Migração de Redirecionamentos, mas ajustada especificamente às convenções de URL e às limitações de API do Shopify.

#### FAQ

Q: Conseguem migrar as minhas apps do Shopify e os respetivos dados?
A: Migramos os dados da loja de que essas apps dependem, mas a configuração específica da app e os dados que guarda costumam ter de vir de uma exportação separada feita pela própria app, ou ser reconstruídos com uma app equivalente na plataforma de destino.

Q: O Shopify Plus muda a forma como uma migração funciona?
A: O Plus afeta sobretudo a personalização do checkout e os limites de taxa da API. O modelo de dados subjacente de produtos/encomendas é o mesmo do Shopify standard, pelo que a abordagem de migração não muda de forma fundamental, embora limites de API mais elevados possam acelerar a transferência de catálogos grandes.

Q: As URLs dos meus produtos mantêm-se se migrar para o Shopify?
A: Só se as suas URLs atuais já coincidirem com o padrão /products/{handle} do Shopify, o que é pouco comum. Na maioria dos casos, configuramos redirecionamentos das suas URLs antigas para a estrutura exigida pelo Shopify como parte da migração.

Q: O que acontece ao meu tema se sair do Shopify?
A: Os temas Liquid não se transferem para os sistemas de templates de outras plataformas, pelo que o design da loja é reconstruído na nova plataforma, aproximando-se do design existente onde a nova plataforma o permite.

Sources:
- Shopify - site oficial: https://www.shopify.com

### Migrar para ou a partir do Shoptet

URL: https://prevedshop.com/pt/plataformas/shoptet
Language: pt
Last reviewed: 2026-07-21

O Shoptet é uma plataforma de ecommerce alojada, focada especificamente nos mercados checo e eslovaco, e é um destino habitual em migrações de comerciantes que operam nessa região, quer estejam a migrar para o Shoptet pelo suporte local e pela configuração sem código, quer estejam a sair dele à medida que se expandem ou precisam de capacidades que a plataforma não oferece. Por ser uma plataforma SaaS fechada e alojada, uma migração de ou para o Shoptet depende do que a sua administração, as suas ferramentas de exportação e a sua API realmente expõem. Esta página cobre o que realmente importa quando o Shoptet está de um dos lados de uma migração.

#### O que é o Shoptet e onde se encaixa

O Shoptet é uma plataforma de ecommerce SaaS alojada, construída para os mercados checo e eslovaco, com a interface de administração, a documentação e o suporte sobretudo em checo. Como noutras plataformas alojadas, o Shoptet trata do alojamento e da infraestrutura, e os comerciantes gerem a loja através do painel de administração e não por acesso ao servidor. Está direcionado sobretudo para comerciantes regionais pequenos e médios que querem uma loja em funcionamento sem gerir código ou infraestrutura por conta própria.

As lojas são construídas usando o sistema próprio de templates e personalização visual do Shoptet, com extras (add-ons) disponíveis através do seu próprio marketplace para funcionalidades como integrações de contabilidade, ferramentas de marketing e métodos de pagamento ou envio regionais comuns no mercado CZ/SK. Por ser de código fechado e alojado, as migrações de ou para o Shoptet trabalham dentro do seu próprio modelo de dados e das suas opções de exportação ou API, e não através de uma cópia direta da base de dados.

#### Produtos, categorias e o modelo de dados

O modelo de catálogo do Shoptet organiza os produtos em categorias, com suporte para variantes de produto e parâmetros para atributos estruturados. Migrar um catálogo para o Shoptet costuma implicar mapear a estrutura de categorias ou atributos da plataforma de origem para o modelo do Shoptet, o que normalmente é direto para catálogos de complexidade moderada.

O Shoptet disponibiliza opções de exportação de dados e uma API para extrair dados de produtos, encomendas e clientes, sobre as quais assenta uma migração de saída da plataforma. Tal como noutras plataformas alojadas, as encomendas históricas costumam chegar como registos de referência, e não como encomendas totalmente ativas e editáveis na nova plataforma.

#### Extras, design e o que não se transfere automaticamente

Uma loja Shoptet em funcionamento depende muitas vezes de extras instalados, para contabilidade, marketing, feeds de comparação de preços, comuns entre comerciantes CZ/SK que listam produtos em serviços como o Heureka ou o Zboží.cz, ou integrações de pagamento regionais. Os dados e as definições dos extras não se transferem automaticamente numa migração de plataforma; sair do Shoptet implica verificar o que cada extra guarda e exportá-lo separadamente, e entrar no Shoptet implica configurar equivalentes a partir do seu próprio marketplace de extras.

Os templates de design do Shoptet são específicos do seu próprio sistema e não se transferem para outras plataformas, pelo que sair do Shoptet costuma implicar reconstruir o design da loja noutro lado, e entrar no Shoptet significa adaptar um dos seus templates ou trabalhar dentro das suas opções de personalização visual.

#### SEO, URLs e como tratamos uma migração para/do Shoptet

O Shoptet permite alguma personalização da estrutura de URLs para produtos e categorias, mas, como em qualquer mudança de plataforma, os padrões de URL existentes raramente coincidem exatamente com os requisitos de uma nova plataforma. Isto é particularmente relevante para comerciantes CZ/SK, que muitas vezes têm visibilidade orgânica associada às suas URLs atuais e às listagens de feeds em motores regionais de comparação de compras.

Como parte de uma migração gerida, mapeamos as suas URLs existentes no Shoptet, ou as da plataforma de destino se estiver a entrar no Shoptet, contra a nova estrutura, configuramos redirecionamentos e transportamos os metadados e a configuração de feeds de comparação que continuam corretos, seguindo a mesma abordagem descrita no nosso serviço de SEO e Migração de Redirecionamentos, aplicada à configuração específica do Shoptet e ao ecossistema regional de feeds a que costuma estar ligado.

#### FAQ

Q: O Shoptet está disponível fora da República Checa e da Eslováquia?
A: O Shoptet é construído e suportado especificamente para os mercados checo e eslovaco, com a administração e a documentação sobretudo em checo. Não se posiciona como uma plataforma global à semelhança de alguns concorrentes alojados, o que é um fator a considerar se estiver a expandir-se para além do mercado CZ/SK.

Q: Conseguem migrar os meus feeds de produto do Shoptet para o Heureka ou o Zboží.cz?
A: Migramos os dados de produto subjacentes em que esses feeds assentam; a configuração do próprio feed costuma precisar de ser reconstruída na nova plataforma, ou tratada através do nosso serviço de Integração de Feeds de Fornecedores, consoante a forma como a plataforma de destino gere feeds de comparação de compras.

Q: Conseguem migrar os meus extras do Shoptet e os respetivos dados?
A: Migramos os dados centrais da loja de que um extra depende, mas as definições específicas do extra e os registos que guarda costumam precisar de uma exportação separada a partir desse extra, ou de ser reconstruídos com um equivalente na plataforma de destino.

Q: As URLs dos meus produtos mantêm-se se migrar de ou para o Shoptet?
A: Normalmente não de forma exata, já que a estrutura de URLs do Shoptet raramente coincide com os requisitos de outra plataforma. Configuramos redirecionamentos das URLs antigas para as novas como parte da migração, para proteger o posicionamento existente nas pesquisas.

Sources:
- Shoptet - site oficial: https://www.shoptet.cz

### Migrar para ou a partir do Shopware

URL: https://prevedshop.com/pt/plataformas/shopware-6
Language: pt
Last reviewed: 2026-07-21

O Shopware é uma plataforma que vemos sobretudo em comerciantes sediados na Alemanha, Áustria e Suíça, quer a migrar para ela pela sua arquitetura aberta e forte presença na região DACH, quer a sair de uma instalação Shopware mais antiga à medida que as suas necessidades mudam. A natureza dupla do Shopware, software open-source que também pode correr como produto cloud alojado, significa que a abordagem de migração certa depende da versão e do tipo de instalação que realmente utiliza. Esta página cobre o que realmente importa quando o Shopware está de um dos lados de uma migração.

#### O que é o Shopware e onde se encaixa

O Shopware é um software de ecommerce construído sobre a framework PHP Symfony, disponível como software open-source autoalojado (a Community Edition) ou como produto cloud alojado com edições comerciais que acrescentam funcionalidades como ferramentas B2B avançadas e preços baseados em regras. O Shopware 6 é a geração atual, construída em torno de um núcleo com capacidade headless, com uma camada de loja e de administração separadas, substituindo o Shopware 5, estruturalmente diferente e mais antigo.

Por expor uma Store API, o Shopware suporta configurações headless e composable a par da sua própria loja predefinida, o que é relevante em migrações em que o frontend e o backend são tratados separadamente. As lojas na via standard usam o sistema de temas próprio do Shopware, construído sobre Twig, com plugins e temas disponíveis através da Shopware Store.

#### Produtos, canais de venda e o modelo de dados

O Shopware organiza os produtos com "propriedades" e grupos de configurador para variantes, dentro de uma árvore de categorias nativa, e usa "canais de venda" (sales channels) para gerir diferentes lojas ou apresentações de marca a partir de um único backend, um conceito estruturalmente diferente de como plataformas de loja única tratam configurações multimarca. Esse modelo de canais de venda é uma das primeiras coisas que mapeamos quando um comerciante gere várias lojas relacionadas a partir de uma única instalação Shopware.

Os preços baseados em regras, preços ou promoções diferentes despoletados por grupo de clientes, conteúdo do carrinho ou outras condições, são uma funcionalidade do Shopware que vale a pena sinalizar cedo numa migração, já que nem todas as plataformas de destino modelam preços condicionais da mesma forma. Os dados de clientes e encomendas vivem na própria estrutura de base de dados do Shopware, e em instalações autoalojadas o acesso direto à base de dados costuma estar disponível, o que pode simplificar algumas exportações, mas continua a exigir a identificação de quaisquer campos adicionados por plugins antes de se presumir que uma exportação standard capta tudo.

#### Plugins, temas e o que não se transfere automaticamente

Uma loja Shopware em funcionamento costuma depender de plugins da Shopware Store, para pagamentos, envios, marketing ou funcionalidades B2B que não fazem parte do núcleo do Shopware. Os dados e a configuração guardados pelos plugins não se transferem automaticamente numa migração de plataforma; sair do Shopware implica verificar o que cada plugin guarda e exportá-lo separadamente, e entrar no Shopware implica instalar e configurar equivalentes através da Shopware Store ou de desenvolvimento personalizado.

Os temas do Shopware, baseados em Twig, são específicos do seu sistema de templates e não se transportam para outro lado, pelo que sair do Shopware costuma implicar reconstruir o design da loja na nova plataforma, e entrar no Shopware significa adaptar um tema da Store ou construir um tema personalizado. As migrações que envolvem o Shopware 5, que usa uma arquitetura subjacente diferente do Shopware 6, precisam de ser avaliadas como um caso à parte, e não presumidas como funcionando da mesma forma que uma migração do Shopware 6.

#### SEO, URLs e como tratamos uma migração para/do Shopware

O Shopware suporta templates de URL de SEO configuráveis para produtos, categorias e outras páginas, personalizáveis por canal de venda, mas os padrões de URL realmente em uso variam de loja para loja consoante a forma como foram configurados. Sair do Shopware implica verificar a configuração de URL em produção, em vez de presumir um padrão predefinido.

Como parte de uma migração gerida, revemos a sua configuração de URLs existente no Shopware, ou planeamos a do destino se estiver a entrar no Shopware, construímos um mapa de redirecionamentos entre URLs antigas e novas por canal de venda quando relevante, e transportamos os metadados que continuam corretos, seguindo a mesma abordagem descrita no nosso serviço de SEO e Migração de Redirecionamentos, aplicada à estrutura específica de encaminhamento e de canais de venda do Shopware.

#### FAQ

Q: Faz diferença se estou no Shopware 5 ou no Shopware 6?
A: Sim, faz uma diferença considerável. O Shopware 6 tem uma arquitetura subjacente, um sistema de plugins e uma estrutura de temas diferentes do Shopware 5, por isso tratamos migrações a partir de cada versão como casos distintos, sem presumir que se aplica a mesma abordagem.

Q: O Shopware é gratuito?
A: A Community Edition do Shopware é open-source e gratuita para autoalojar. As edições comerciais e a opção de alojamento na cloud acrescentam custos de licenciamento ou subscrição, juntamente com funcionalidades adicionais como ferramentas B2B avançadas.

Q: Como é que os canais de venda do Shopware afetam uma migração?
A: Se estiver a gerir várias lojas ou marcas através da funcionalidade de canais de venda do Shopware, mapeamos cada uma individualmente em vez de tratar a instalação como uma única loja plana, já que as plataformas de destino nem sempre modelam configurações multicanal da mesma forma.

Q: Conseguem migrar os meus plugins do Shopware e os respetivos dados?
A: Migramos os dados centrais da loja de que um plugin depende, mas as definições específicas do plugin e os registos que guarda costumam precisar de uma exportação separada a partir desse plugin, ou de ser reconstruídos com um equivalente na plataforma de destino.

Sources:
- Shopware - site oficial: https://www.shopware.com

### Migrar para ou a partir do WooCommerce

URL: https://prevedshop.com/pt/plataformas/woocommerce
Language: pt
Last reviewed: 2026-07-21

O WooCommerce não é uma plataforma no mesmo sentido de uma ferramenta SaaS alojada. É um plugin gratuito que transforma um site WordPress autoalojado numa loja, o que significa que uma migração do WooCommerce é, na prática, uma migração de WordPress mais base de dados. Essa distinção muda o que realmente precisa de ser transferido, e é a primeira coisa que avaliamos em qualquer projeto envolvendo o WooCommerce.

#### O que é o WooCommerce e quem o gere

O WooCommerce é um plugin de ecommerce open-source para WordPress, desenvolvido e mantido pela Automattic. Por ser autoalojado, é o cliente (ou o seu alojamento) que fica responsável pelo servidor, pela versão de PHP, pelas cópias de segurança e pelas atualizações. Não há um único fornecedor a gerir o tempo de atividade como acontece numa plataforma SaaS, o que dá mais controlo mas também mais responsabilidade de manutenção.

É popular entre comerciantes que já usam o WordPress para conteúdo, ou que querem controlo total sobre alojamento, plugins e código. Essa flexibilidade é também o motivo pelo qual as lojas WooCommerce variam enormemente em complexidade: um catálogo simples com dois ou três plugins é uma migração muito diferente de uma instalação fortemente personalizada com dezenas de plugins a interagir entre si.

#### O modelo de dados: produtos como conteúdo do WordPress

O WooCommerce guarda os produtos como um tipo de conteúdo (post type) personalizado do WordPress, com variações, atributos e preços mantidos em tabelas relacionadas e em post meta, em vez de um esquema de ecommerce dedicado. As categorias e etiquetas reutilizam o sistema de taxonomias do WordPress. Isto funciona bem dentro do WordPress, mas significa que migrar para o WooCommerce implica mapear os dados de origem não apenas para "produtos", mas especificamente para o modelo de conteúdo do WordPress, e migrar a partir do WooCommerce implica extrair dados de ecommerce que estão entrelaçados com conteúdo geral do WordPress.

O armazenamento de encomendas depende da versão e configuração do WooCommerce: lojas mais antigas usam posts e post meta do WordPress, enquanto o High-Performance Order Storage pode guardar encomendas e moradas em tabelas dedicadas. Os clientes continuam ligados aos utilizadores do WordPress e as extensões podem acrescentar outras tabelas. A possibilidade de transferir o histórico como encomendas editáveis ou apenas como dados de referência depende da plataforma de destino e do método de importação; por isso, o esquema de origem deve ser inventariado antes do mapeamento.

#### Plugins, temas e onde vive a lógica personalizada

Uma loja WooCommerce em funcionamento depende normalmente de vários plugins para além do próprio WooCommerce, para regras de envio, gateways de pagamento, subscrições ou campos personalizados através de ferramentas como o Advanced Custom Fields. Os dados específicos de cada plugin geralmente não têm um formato de exportação portátil, pelo que migrar a partir do WooCommerce implica identificar o que cada plugin realmente guarda e se a plataforma de destino tem um equivalente.

Os temas são temas do WordPress, muitas vezes combinados com construtores de páginas (Elementor, WPBakery e semelhantes) que guardam dados de layout de formas que não se traduzem fora do WordPress. Sair do WooCommerce implica, em geral, reconstruir o design da loja na nova plataforma em vez de o exportar.

#### SEO, URLs e como tratamos uma migração para/do WooCommerce

A estrutura de URLs do WooCommerce é controlada pelas definições de ligações permanentes (permalinks) do WordPress, por isso é flexível, mas essa flexibilidade significa que as URLs de cada site WooCommerce estão configuradas de forma ligeiramente diferente, e não existe um único padrão fixo para migrar, como acontece nalgumas plataformas SaaS. Os plugins de SEO mais populares (Yoast, Rank Math) também guardam metadados e redirecionamentos nas suas próprias tabelas, o que tem de ser tratado separadamente dos dados centrais do WooCommerce/WordPress.

Como parte de uma migração gerida, mapeamos a estrutura real de permalinks que utiliza, não um padrão presumido, para o formato de URL da plataforma de destino, extraímos os metadados do plugin de SEO que utiliza e configuramos redirecionamentos para que o posicionamento existente e os links de entrada continuem a resolver corretamente. Veja o nosso serviço de SEO e Migração de Redirecionamentos para perceber como isto funciona em geral.

#### FAQ

Q: Os dados do WooCommerce incluem também o meu conteúdo do WordPress?
A: Apenas o que nos pedir para transferir. O WooCommerce e o conteúdo geral do WordPress (artigos de blog, páginas) vivem na mesma base de dados, por isso definimos exatamente o que conta como "dados da loja" versus conteúdo do site antes de a migração começar.

Q: Conseguem migrar uma loja WooCommerce com muitos plugins personalizados?
A: Sim, mas exige mais tempo de avaliação. Identificamos o que cada plugin realmente guarda e se isso corresponde a algo na nova plataforma ou tem de ser reconstruído de raiz.

Q: O que acontece aos meus dados de SEO do Yoast ou Rank Math se sair do WooCommerce?
A: Extraímos os metadados e redirecionamentos guardados por esses plugins e transportamos o que continua correto para os campos equivalentes na nova plataforma, em vez de começar os seus metadados de SEO do zero.

Q: Posso migrar para o WooCommerce a partir de uma plataforma SaaS?
A: Sim, esta é uma direção comum quando os comerciantes querem mais controlo sobre o alojamento e o código. Mapeamos o seu catálogo de origem para o modelo de tipos de conteúdo do WordPress e configuramos o WooCommerce em conformidade.

Sources:
- WooCommerce - site oficial: https://woocommerce.com

### Migration routes

### Migrar do Magento para o BigCommerce

URL: https://prevedshop.com/pt/migracoes/magento-para-bigcommerce
Language: pt
Last reviewed: 2026-07-21
Route: adobe-commerce -> bigcommerce

Sair da Adobe Commerce ou do Magento Open Source para o BigCommerce troca uma plataforma autoalojada e centrada em código por uma solução SaaS gerida, com um espírito semelhante a uma mudança para o Shopify, mas com um conjunto diferente de compromissos. O BigCommerce suporta nativamente mais combinações de variantes de produto e dá mais controlo sobre a estrutura de URLs do que muitos concorrentes SaaS, o que pode torná-lo um ajuste estrutural mais próximo para um catálogo Magento complexo — mas o alojamento, as extensões e a configuração multi-loja continuam a ter de ser reconstruídos de forma deliberada, e não simplesmente exportados.

#### Porque é que os comerciantes saem do Magento

O Magento Open Source e a Adobe Commerce dão controlo total sobre o código, o alojamento e o checkout, ao custo de ter de gerir essa infraestrutura por conta própria: patches de segurança de PHP e do Magento, alojamento em servidor ou cloud, e conformidade PCI para o checkout que aloja. O BigCommerce, como plataforma SaaS gerida, retira ao cliente o alojamento, a conformidade PCI e a aplicação de patches de segurança da plataforma, em troca de trabalhar dentro das limitações da sua plataforma em vez de código arbitrário.

Um motivo frequente é o mesmo que empurra comerciantes para o Shopify: o custo de manter um programador ou uma agência a cargo de uma instância Magento deixa de fazer sentido quando o crescimento da loja já não justifica esse esforço, sobretudo em lojas ainda a correr uma instância Magento 2 sem patches ou presas ao Magento 1, já fora do fim de vida.

#### O que muda no modelo de dados

A estrutura de catálogo EAV (Entity-Attribute-Value) do Magento permite definir atributos personalizados praticamente arbitrários por tipo de produto. O modelo de produtos do BigCommerce é mais estruturado do que o do Magento, mas geralmente mais flexível em termos de variantes do que plataformas SaaS concorrentes — suporta nativamente um número maior de combinações de variantes de produto, além de campos personalizados e modificadores de produto para atributos fora da estrutura de variantes. Ainda assim, isso significa que os conjuntos de atributos do Magento precisam de ser mapeados de forma deliberada para as opções de variante e os campos personalizados do BigCommerce, e não copiados atributo a atributo.

A árvore de categorias do Magento permite aninhamento arbitrário com definições de apresentação por store view, e um produto pode pertencer a várias categorias em simultâneo. As categorias do BigCommerce estão mais próximas de uma árvore tradicional do que o modelo de coleções planas do Shopify, o que torna a migração de uma estrutura de categorias Magento profundamente aninhada algo mais direta — mas ainda vale a pena rever e simplificar nos casos em que a estrutura do Magento cresceu organicamente ao longo dos anos, em vez de ter sido desenhada.

#### URLs, redirecionamentos e o que é diferente aqui em relação ao Shopify

As URL keys e os rewrites do Magento são totalmente configuráveis por store view. O BigCommerce, ao contrário do Shopify, permite caminhos de URL personalizados para produtos, categorias e páginas, sem impor um prefixo obrigatório como `/products/` ou `/collections/` — o que pode facilitar a preservação de uma estrutura de URLs Magento existente. Isso não elimina a necessidade de um plano de redirecionamentos: qualquer URL que mude continua a precisar de um redirecionamento 301 explícito, e o exercício de auditar cada URL indexada do Magento contra o seu novo equivalente no BigCommerce tem de acontecer de qualquer forma, para evitar uma queda de posicionamento após a migração.

#### Extensões, checkout e multi-loja

O ecossistema de extensões do Magento e a sua capacidade de personalizar o checkout e os fluxos de administração em código não têm equivalente direto no BigCommerce — o BigCommerce usa um marketplace de apps, além das suas próprias APIs e da personalização de loja Stencil/Catalyst para lógica personalizada. Cada extensão Magento ativa exige uma decisão explícita durante a avaliação: uma app equivalente no BigCommerce, uma construção personalizada sobre as APIs do BigCommerce, ou a confirmação de que já não é necessária. O modelo multi-site/multi-loja do Magento também precisa de ser mapeado para as capacidades multi-loja do BigCommerce, que funcionam de forma diferente por baixo, mesmo quando o resultado final parece semelhante.

#### FAQ

Q: O BigCommerce consegue lidar com os atributos personalizados de produto do Magento?
A: Através de uma combinação de opções de variante e campos personalizados, mas o BigCommerce não tem um equivalente automático aos conjuntos de atributos EAV do Magento. Mapeamos a utilização real dos seus atributos durante a avaliação, em vez de migrar todos os atributos que o Magento tenha por acaso definidos.

Q: Migrar URLs do Magento para o BigCommerce é mais fácil do que para o Shopify?
A: Muitas vezes é um pouco mais fácil, porque o BigCommerce permite caminhos de URL personalizados sem prefixo obrigatório, ao contrário da estrutura fixa do Shopify. Isso reduz o número de URLs que precisam de mudar, mas qualquer URL que mude continua a precisar de um redirecionamento 301 explícito — a auditoria tem sempre de acontecer.

Q: O que acontece às minhas extensões e módulos personalizados do Magento?
A: Cada uma é avaliada individualmente durante o levantamento inicial: substituição por uma app existente no BigCommerce, reconstrução sobre as APIs do BigCommerce, ou confirmação de que já não é necessária. Sinalizamos esta lista antes de definir o âmbito do projeto, não depois.

Q: Posso manter a funcionalidade multi-loja ou multi-site?
A: O modelo multi-site do Magento não se mapeia diretamente para a arquitetura do BigCommerce, mesmo que o BigCommerce também suporte várias lojas. Mapeamos a sua necessidade real — marcas, regiões ou moedas separadas — para a estrutura certa no BigCommerce, em vez de presumir uma conversão direta e equivalente.

Sources:
- Site e documentação oficial do BigCommerce: https://www.bigcommerce.com
- Documentação Adobe Commerce / Magento Open Source: https://experienceleague.adobe.com/en/docs/commerce

### Migrar do Magento para o Shopify

URL: https://prevedshop.com/pt/migracoes/magento-para-shopify
Language: pt
Last reviewed: 2026-07-21
Route: adobe-commerce -> shopify

Sair da Adobe Commerce ou do Magento Open Source para o Shopify troca uma plataforma PHP autoalojada e altamente personalizável por uma solução SaaS gerida. Essa troca retira da sua lista de tarefas a manutenção do servidor, das versões de PHP e da conformidade PCI, mas também significa que o modelo de dados do seu catálogo, a estrutura de URLs e a maior parte das suas extensões têm de ser reconstruídos, não copiados. Feita de forma deliberada, é uma mudança bem conhecida; feita como uma simples exportação/importação, é onde o SEO e a lógica personalizada se perdem em silêncio.

#### Porque é que os comerciantes saem do Magento

O Magento Open Source e a Adobe Commerce dão controlo total sobre o código, o alojamento e o checkout — o que explica precisamente por que são caros de manter. Alguém tem de aplicar patches de PHP e do Magento, gerir o servidor ou a infraestrutura cloud, e manter a conformidade PCI atualizada para um checkout alojado pelo próprio comerciante. O Shopify retira ao cliente o alojamento, a conformidade PCI e a aplicação de patches de segurança da plataforma, em troca de menos controlo ao nível técnico.

Um motivo frequente é o custo contínuo de manter um programador ou uma agência a cargo de uma instância Magento deixar de fazer sentido face ao tamanho da loja, sobretudo quando o Magento 1 (há muito fora do fim de vida) ou uma instalação Magento 2 envelhecida começam a acumular extensões sem patches.

#### O que muda de facto no modelo de dados

O catálogo de produtos do Magento assenta numa estrutura EAV (Entity-Attribute-Value), que permite definir atributos personalizados praticamente arbitrários por tipo de produto. O modelo de produtos do Shopify é mais simples: um produto tem um conjunto fixo de campos centrais, até três dimensões de opções de variante (como tamanho e cor) e metafields para tudo o resto. Os produtos configuráveis e as opções personalizadas do Magento mapeiam-se para variantes e metafields no Shopify, mas o mapeamento não é 1 para 1 — conjuntos de atributos com muitos atributos personalizados costumam precisar de um esquema de metafields desenhado de propósito, e não de uma autoconversão atributo a atributo.

As categorias são outra diferença real: o Magento permite aninhar categorias a uma profundidade arbitrária e atribuir um produto a várias delas, com definições de apresentação diferentes por store view. As coleções do Shopify são mais planas — listas manuais ou baseadas em regras ("inteligentes") em vez de uma verdadeira árvore de categorias —, pelo que um catálogo Magento profundamente aninhado exige uma estrutura de coleções pensada de propósito, e não uma exportação direta.

#### URLs, redirecionamentos e o que falha em silêncio

As URL keys e os rewrites do Magento são totalmente configuráveis por store view. O Shopify impõe os seus próprios padrões (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`, `/blogs/{blog}/{handle}`) que não podem ser reestruturados à vontade. Isto significa que cada URL indexada do Magento precisa de um redirecionamento explícito para o seu equivalente no Shopify — esta é, de longe, a causa mais comum de uma queda de posicionamento após a migração, e é totalmente evitável com um mapa de URLs bem construído antes do lançamento, em vez de corrigido depois de o Google detetar erros 404.

#### Extensões, personalizações de checkout e multi-loja

O ecossistema de extensões do Magento e a sua capacidade de personalizar o checkout, as regras de preços e os fluxos de administração em código não têm equivalente direto no Shopify — o Shopify usa uma App Store e, no Shopify Plus, a Checkout Extensibility e as Shopify Functions para lógica de checkout personalizada. Cada módulo personalizado do Magento exige uma decisão explícita: existe uma app equivalente, é preciso construir uma app personalizada sobre as APIs do Shopify, ou a funcionalidade é simplesmente descartada. O mesmo se aplica às configurações multi-site/multi-loja do Magento, que não se traduzem diretamente para o modelo de loja única mais Markets do Shopify para venda internacional.

O nosso processo de migração gerida mapeia tudo isto durante a avaliação — catalogando as suas extensões ativas e módulos personalizados antes de orçamentar o trabalho, e não descobrindo-os a meio da migração.

#### FAQ

Q: O Shopify consegue lidar com os atributos personalizados de produto do Magento?
A: Sim, através de metafields, mas precisam de ser definidos e mapeados de forma deliberada — o Shopify não tem um equivalente automático aos conjuntos de atributos EAV do Magento. Mapeamos a utilização real dos seus atributos durante a avaliação, em vez de migrar todos os atributos que o Magento tenha por acaso definidos.

Q: As minhas URLs do Magento vão redirecionar automaticamente?
A: Não. A estrutura de URLs do Shopify é fixa, por isso cada URL relevante do Magento precisa de um redirecionamento 301 explícito para o seu novo equivalente no Shopify. Isto é central ao plano de migração, não um extra opcional — veja o nosso serviço de SEO e Migração de Redirecionamentos.

Q: O que acontece às minhas extensões e módulos personalizados do Magento?
A: Cada um é avaliado individualmente durante o levantamento inicial: substituição por uma app existente no Shopify, reconstrução como app personalizada ou personalização de tema, ou confirmação de que já não é necessário. Sinalizamos esta lista antes de definir o âmbito do projeto, não depois.

Q: Posso manter a funcionalidade multi-loja ou multi-site?
A: O modelo multi-site do Magento não se mapeia diretamente para o Shopify. Consoante o que realmente precisa — marcas separadas, regiões separadas, moedas separadas —, o equivalente certo no Shopify pode ser o Shopify Markets, uma segunda loja ou uma Shopify Plus Organization. Ajudamo-lo a escolher com base na necessidade real, e não numa resposta genérica.

Sources:
- Shopify - Migre a sua loja para o Shopify: https://www.shopify.com/migrate
- Documentação Adobe Commerce / Magento Open Source: https://experienceleague.adobe.com/en/docs/commerce

### Migração de Magento (Adobe Commerce) para Shoptet

URL: https://prevedshop.com/pt/migracoes/magento-para-shoptet
Language: pt
Last reviewed: 2026-09-02
Route: adobe-commerce -> shoptet

O Magento e o Adobe Commerce são feitos para catálogos complexos, várias store views e muita personalização, à custa de alojamento e desenvolvimento caros. A Shoptet é uma plataforma alojada para comerciantes checos e eslovacos com um modelo de dados fixo mais simples e integrações locais incorporadas. A migração é sobretudo uma consolidação: reduzir os conjuntos de atributos, produtos configuráveis, store views e módulos à medida do Magento ao que a Shoptet consegue representar, mover clientes e histórico de encomendas e proteger os URL que trazem tráfego orgânico.

#### Quem passa do Magento para a Shoptet e porquê

Os comerciantes dão este passo quando a instalação Magento se tornou desproporcionada para o negócio: uma loja checa ou eslovaca média que paga alojamento Magento, correções de segurança, licenças de extensões e horas de agência de que já não precisa. A Shoptet substitui isso por um plano mensal, integrações nativas com Zásilkovna, PPL, GoPay, Comgate, Heureka e Zboží.cz e um ambiente gerido. A contrapartida é a profundidade: sem conjuntos de atributos, sem hierarquia multi-site, sem extensões livres. Se o seu negócio depende delas, a avaliação di-lo-á antes de qualquer trabalho começar.

#### Conjuntos de atributos, produtos configuráveis e categorias

Os conjuntos de atributos do Magento tornam-se uma única lista plana de parâmetros Shoptet, pelo que atributos sobrepostos de conjuntos diferentes têm de ser fundidos e renomeados de forma coerente. Os produtos configuráveis mapeiam para produtos Shoptet com variantes; os filhos simples tornam-se linhas de variante com código, preço e stock próprios. Produtos bundle e agrupados não têm equivalente direto e são reconstruídos como produtos separados ou conjuntos. As árvores de categorias são transferidas, mas as categorias âncora e a navegação por camadas do Magento são substituídas por categorias e filtros de parâmetros da Shoptet, o que normalmente implica achatar a hierarquia.

#### Store views, clientes e encomendas

As store views do Magento são frequentemente usadas para idiomas ou marcas. A Shoptet suporta mutações de idioma por loja mas não sites independentes, por isso cada store view precisa de uma decisão: fundir numa loja Shoptet, operar várias lojas Shoptet ou eliminar. Clientes e moradas são importados, os grupos de clientes mapeiam para níveis de preço da Shoptet e as palavras-passe são redefinidas na nova loja. O histórico de encomendas é importado para relatórios. Módulos à medida, conectores ERP e funções B2B são listados um a um e associados a funções nativas, add-ons ou a uma integração personalizada.

#### Redirecionamentos e mudança

As reescritas de URL do Magento e os caminhos de categoria nos URL de produto diferem dos padrões da Shoptet, por isso exportamos todos os URL indexados, construímos um mapa 301 completo e carregamo-lo na Shoptet antes da mudança de DNS. Uma importação de teste do catálogo completo é verificada em preços, IVA, stock e variantes; depois os feeds são regenerados e o sitemap reenviado. Os redirecionamentos protegem a continuidade dos URL e reduzem o risco; nenhuma migração garante posições.

#### FAQ

Q: Os produtos configuráveis do Magento podem ser migrados para a Shoptet?
A: Sim. Cada produto configurável torna-se um produto Shoptet com variantes, e os filhos simples tornam-se linhas de variante com código, preço e stock próprios.

Q: O que acontece aos conjuntos de atributos do Magento?
A: A Shoptet tem uma única lista plana de parâmetros, pelo que os conjuntos são fundidos. Nomes de atributos duplicados ou em conflito são limpos e renomeados antes da importação.

Q: Como são tratadas as store views do Magento?
A: Cada store view é decidida separadamente: fundir numa loja Shoptet, operar várias lojas ou eliminar. A Shoptet suporta mutações de idioma, não sites independentes.

Q: Mantenho clientes e histórico de encomendas?
A: Clientes, moradas e preços por grupo são importados; as palavras-passe são redefinidas. As encomendas são importadas como histórico para relatórios, não como encomendas ativas editáveis.

Sources:
- Adobe Commerce - Transferência de dados (importação e exportação): https://experienceleague.adobe.com/en/docs/commerce-admin/systems/data-transfer/data-transfer
- Shoptet Developers - Importação de dados: https://developers.shoptet.com/shoptet-tools/data-import/

### Migrar do OpenCart para o Shopify

URL: https://prevedshop.com/pt/migracoes/opencart-para-shopify
Language: pt
Last reviewed: 2026-07-21
Route: opencart -> shopify

O OpenCart é uma plataforma leve, auto-alojada e de código aberto — mais simples de gerir do que o Magento ou o PrestaShop, mas ainda assim exige que giram o próprio servidor, a versão de PHP, a correção de segurança e a conformidade PCI. Mudar para o Shopify troca essa configuração auto-gerida por uma plataforma alojada e gerida. Como o modelo de dados do OpenCart é comparativamente simples, a migração em si costuma ser mais direta do que a partir de uma plataforma empresarial mais pesada, mas as opções de produto, a configuração multiloja e as extensões continuam a precisar de um mapeamento deliberado, e não de uma simples exportação/importação.

#### Porque os comerciantes saem do OpenCart

O atrativo do OpenCart é ser gratuito e leve, mas isso também significa que fica por sua conta o alojamento, as atualizações de segurança, a conformidade PCI e a compatibilidade das extensões entre atualizações da versão principal. Muitas lojas OpenCart são geridas por equipas pequenas sem programadores dedicados, e o esforço contínuo de aplicar correções de segurança e resolver conflitos entre extensões torna-se, com o tempo, desproporcional ao tamanho do negócio. O Shopify remove esse peso de alojamento e correção de segurança em troca de uma mensalidade de plataforma gerida.

Um motivo frequente é o ecossistema de extensões: as extensões do OpenCart (construídas como modificações OCMOD ou VQMOD) variam em qualidade e deixam frequentemente de ser mantidas, o que se torna um risco crescente à medida que a plataforma principal avança e a pilha de extensões de uma loja envelhece.

#### Opções de produto, categorias e o modelo de dados

O OpenCart representa as variantes de produto através de "opções" — escolhas como tamanho ou cor associadas a um produto, cada uma opcionalmente afetando o preço e o stock. Isto está conceptualmente próximo do sistema de variantes do Shopify, o que torna o mapeamento central de produtos mais direto do que a partir de plataformas com um modelo de atributos EAV completo. O Shopify continua a limitar os produtos a três dimensões de opções de variante, pelo que produtos do OpenCart com mais grupos de opções do que isso precisam de ter algumas opções movidas para metafields em vez de variantes.

As categorias do OpenCart podem ser aninhadas e um produto pode pertencer a várias categorias, semelhante em espírito às coleções do Shopify mas estruturado de forma diferente por baixo — a árvore de categorias do OpenCart não se mapeia um a um no modelo de coleções manuais/inteligentes do Shopify, pelo que a estrutura de coleções costuma precisar de ser planeada em vez de copiada tal como está.

#### Multiloja, URLs e extensões

O OpenCart suporta executar várias lojas a partir de uma única instalação, partilhando um único painel de administração e um único catálogo de produtos entre lojas com configurações diferentes. Os equivalentes mais próximos no Shopify são o Shopify Markets para variação regional/de moeda dentro de uma loja, ou lojas Shopify genuinamente separadas para marcas distintas — nenhum é uma correspondência arquitetónica direta, pelo que a abordagem certa depende do que a configuração multiloja está realmente a ser usada para.

As definições de URLs amigáveis para SEO do OpenCart são configuráveis por loja, pelo que os URLs existentes precisam de ser mapeados com redirecionamentos 301 explícitos para os padrões fixos do Shopify (`/products/{handle}`, `/collections/{handle}`) para evitar perder visibilidade nas pesquisas. As extensões do OpenCart que tratam de envio, pagamento ou personalização do catálogo também precisam de avaliação individual — uma substituição por app do Shopify, uma construção personalizada, ou confirmação de que já não são necessárias — durante a avaliação.

#### FAQ

Q: O sistema de opções de produto do OpenCart mapeia-se de forma limpa para as variantes do Shopify?
A: De forma mais limpa do que a partir de plataformas com um modelo completo de atributos personalizados, já que as opções do OpenCart já estão conceptualmente próximas das variantes do Shopify. Produtos com mais de três grupos de opções precisam de ter algumas opções mapeadas para metafields do Shopify em vez de variantes.

Q: O que acontece à minha configuração multiloja do OpenCart?
A: Não existe um equivalente direto um-para-um no Shopify. Consoante precise de um catálogo partilhado com variação regional ou de marcas genuinamente separadas, ajudamo-lo a escolher entre o Shopify Markets e lojas Shopify separadas com base nos seus requisitos reais.

Q: Os meus URLs do OpenCart vão redirecionar automaticamente?
A: Não. A estrutura de URLs do Shopify é fixa, pelo que cada URL indexado do OpenCart precisa de um redirecionamento 301 explícito para o seu equivalente no Shopify — isto é planeado como parte da migração, e não deixado para depois do lançamento.

Q: O que acontece às minhas extensões do OpenCart?
A: Cada extensão ativa é avaliada individualmente durante a avaliação: substituída por uma app do Shopify, reconstruída como uma app personalizada ou personalização de tema, ou descartada se já não for necessária. Sinalizamos isto antes de definir o âmbito do projeto.

Sources:
- Shopify - Migre a sua loja para o Shopify: https://www.shopify.com/migrate
- Site oficial e documentação do OpenCart: https://www.opencart.com

### Migrar do PrestaShop para o Shopify

URL: https://prevedshop.com/pt/migracoes/prestashop-para-shopify
Language: pt
Last reviewed: 2026-07-21
Route: prestashop -> shopify

O PrestaShop é uma plataforma auto-alojada e de código aberto popular por toda a Europa, construída em torno de suporte nativo multi-idioma e multi-moeda e de um sistema flexível de "combinações" para variantes de produto. Mudar para o Shopify significa abdicar do acesso direto ao servidor e à base de dados em troca de alojamento gerido e conformidade PCI, e significa repensar alguns aspetos que o PrestaShop trata nativamente — multiloja, conteúdo multi-idioma e combinações de produto — nos termos próprios do Shopify, em vez de assumir uma exportação igual para igual.

#### Porque os comerciantes saem do PrestaShop

Como plataforma auto-alojada, o PrestaShop coloca a gestão do servidor, as atualizações de versão de PHP, a compatibilidade de módulos e a conformidade PCI do checkout a cargo da sua equipa. Isso é gerível para uma loja com recursos técnicos dedicados, mas torna-se um custo real — tempo de programador, alojamento, correção de segurança — assim que a loja passa a funcionar com uma equipa reduzida. O Shopify absorve o alojamento, a conformidade PCI e a correção de segurança da plataforma, trocando algum controlo de baixo nível por um custo previsível de plataforma gerida.

Um motivo frequente é o ecossistema de módulos: os módulos do PrestaShop variam muito em qualidade e manutenção, e uma loja construída ao longo de anos carrega frequentemente vários módulos que já não são ativamente suportados, o que se torna um risco crescente à medida que o próprio PrestaShop avança.

#### Combinações, categorias e o modelo de dados

Os produtos do PrestaShop usam um sistema de "combinações" — atributos como tamanho ou cor geram linhas de combinação, e o PrestaShop impõe poucos limites rígidos a quantos atributos ou combinações um produto pode ter. O modelo de variantes do Shopify é mais restrito: até três dimensões de opções por produto, com metafields disponíveis para atributos que não se encaixam no modelo de variante. Produtos com muitas combinações de atributos do PrestaShop, ou atributos usados mais como dados descritivos do que como verdadeiras variantes, precisam de um plano de metafields deliberado, e não de uma cópia direta atributo a atributo.

A árvore de categorias do PrestaShop, tal como a do Magento, permite aninhamento arbitrário e atribuição a várias categorias por produto. As coleções do Shopify são mais planas — listas manuais ou baseadas em regras — pelo que um catálogo PrestaShop profundamente aninhado precisa de uma estrutura de coleções redesenhada para funcionar bem no Shopify, e não de uma exportação literal de categorias.

#### Multiloja, multi-idioma e multi-moeda

A funcionalidade multiloja do PrestaShop e o seu suporte nativo multi-idioma e multi-moeda são frequentemente usados por comerciantes europeus que vendem em vários mercados a partir de uma única instalação. O equivalente mais próximo no Shopify é o Shopify Markets para variação de moeda, idioma e loja regional, ou em alguns casos uma loja Shopify separada por marca ou região. Nenhum é uma correspondência arquitetónica direta para o multiloja do PrestaShop, pelo que a abordagem certa depende do que a loja realmente precisa — uma única loja a servir vários mercados, ou lojas genuinamente separadas — e essa decisão deve ser tomada deliberadamente antes de o âmbito da migração ser definido.

#### URLs, redirecionamentos e módulos

As definições de URLs amigáveis do PrestaShop são totalmente configuráveis, pelo que os URLs existentes raramente coincidem, de origem, com os padrões fixos do Shopify (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`). Cada URL indexado do PrestaShop precisa de um redirecionamento explícito para o seu equivalente no Shopify, para proteger o posicionamento nas pesquisas durante a mudança.

Os módulos do PrestaShop que cobrem envio, pagamento, marketing e personalização do checkout não têm equivalente automático no Shopify. Cada módulo ativo precisa de uma decisão explícita durante a avaliação — substituir por uma app do Shopify, reconstruir como uma app personalizada ou personalização de tema, ou descartar — para que o âmbito da migração seja conhecido antes de o trabalho começar, e não descoberto a meio do projeto.

#### FAQ

Q: O Shopify consegue tratar as combinações de produto do PrestaShop?
A: As combinações padrão mapeiam-se para as variantes do Shopify, mas o Shopify limita os produtos a três dimensões de opções de variante. Combinações além disso, ou atributos usados mais como dados descritivos, precisam de ser mapeados para metafields de forma deliberada durante a avaliação.

Q: O que acontece à minha configuração multiloja do PrestaShop?
A: Não existe um equivalente arquitetónico direto no Shopify. Consoante o que realmente precisar — catálogo partilhado entre regiões, moedas separadas ou marcas genuinamente separadas — a estrutura certa no Shopify pode ser o Shopify Markets ou lojas separadas. Ajudamo-lo a escolher com base nos seus requisitos, e não numa resposta por defeito.

Q: Os meus URLs do PrestaShop vão redirecionar automaticamente para o Shopify?
A: Não. O Shopify impõe a sua própria estrutura de URLs, pelo que cada URL relevante do PrestaShop precisa de um redirecionamento 301 explícito mapeado para o seu equivalente no Shopify — isto é essencial ao plano de migração, e não um extra opcional.

Q: O que acontece aos meus módulos do PrestaShop?
A: Cada um é avaliado individualmente: substituído por uma app existente do Shopify, reconstruído como uma app personalizada ou personalização de tema, ou confirmado como já não sendo necessário. Sinalizamos esta lista durante a avaliação, antes de o projeto ser delimitado.

Sources:
- Shopify - Migre a sua loja para o Shopify: https://www.shopify.com/migrate
- Site oficial e documentação do PrestaShop: https://www.prestashop.com

### Migração de PrestaShop para Shoptet

URL: https://prevedshop.com/pt/migracoes/prestashop-para-shoptet
Language: pt
Last reviewed: 2026-09-02
Route: prestashop -> shoptet

O PrestaShop é uma plataforma open source que aloja e mantém por conta própria; a Shoptet é um sistema alojado para comerciantes checos e eslovacos com envios, pagamentos e feeds de marketplaces locais integrados. A migração substitui as combinações, características e dados de módulos do PrestaShop por variantes, parâmetros e add-ons da Shoptet, transfere clientes e histórico de encomendas e reconstrói cada URL indexado como redirecionamento 301, para que a mudança não desperdice anos de visibilidade nos motores de busca.

#### O que os comerciantes PrestaShop ganham e cedem

A Shoptet elimina a administração do servidor, atualizações de PHP e compatibilidade de módulos. Faturação, IVA, Zásilkovna, PPL, GoPay, Comgate, Heureka e Zboží.cz são nativos, o que substitui frequentemente uma dúzia de módulos PrestaShop. Cede-se a personalização ilimitada: no PrestaShop tudo se altera com um módulo ou override, enquanto a Shoptet oferece um conjunto fixo de campos, templates e add-ons. Funcionalidades de módulos à medida têm de ser reavaliadas, não copiadas.

#### Combinações, características e categorias

As combinações do PrestaShop (conjuntos de atributos como tamanho e cor) mapeiam para variantes Shoptet; cada combinação passa a ser uma linha de variante com código, preço e stock próprios. As características do PrestaShop, usadas para filtrar, tornam-se parâmetros Shoptet criados antes da importação. Ambos os sistemas aceitam várias categorias por produto, mas a categoria predefinida do PrestaShop deve ser escolhida explicitamente como categoria principal na Shoptet. Imagens, descrições, títulos e descrições meta são transferidos na importação; regras de preços específicos e preços por grupo de clientes exigem revisão, porque a Shoptet modela descontos de forma diferente.

#### Clientes, encomendas e redirecionamentos

Os clientes são importados com moradas e pertença a grupos; as palavras-passe não podem ser movidas, pelo que a redefinição faz parte da comunicação de lançamento. As encomendas são importadas como histórico para relatórios. Os URL do PrestaShop dependem das definições de URL amigáveis e incluem muitas vezes IDs; a Shoptet usa os seus próprios padrões, por isso geramos um mapa 301 completo a partir do sitemap e dos dados de analytics e verificamo-lo antes da mudança de DNS. Os redirecionamentos protegem a continuidade dos URL e reduzem o risco; as posições nunca são garantidas.

#### Módulos, feeds e arranque

Listamos cada módulo PrestaShop ativo e decidimos: nativo na Shoptet, disponível como add-on, integração à medida ou eliminado. Os feeds de marketplaces são regenerados a partir da Shoptet. O arranque consiste numa importação de teste, verificação de uma amostra de preços, IVA e stock e mudança de DNS, mantendo o PrestaShop em modo de leitura durante um breve período até o mapa de redirecionamentos ser confirmado no Google Search Console.

#### FAQ

Q: As combinações do PrestaShop tornam-se variantes Shoptet?
A: Sim. Cada combinação torna-se uma variante com código, preço e stock próprios; os grupos de atributos tornam-se as dimensões das variantes. Nomes de atributos incoerentes são limpos antes da importação.

Q: Posso manter o histórico de encomendas do PrestaShop?
A: As encomendas são importadas como histórico para consulta e relatórios. Não são encomendas ativas editáveis e as faturas continuam no seu sistema de contabilidade.

Q: Os meus módulos PrestaShop vão funcionar na Shoptet?
A: Nenhum módulo é transferido diretamente. Mapeamos cada um para uma função nativa da Shoptet, um add-on ou uma integração à medida, e eliminamos os que já não são necessários.

Q: Como tratam os URL do PrestaShop com IDs de produto?
A: Cada URL indexado recebe um redirecionamento 301 explícito para o equivalente Shoptet, gerado a partir do sitemap e do analytics e verificado antes do lançamento.

Sources:
- PrestaShop - Documentação do webservice: https://devdocs.prestashop-project.org/9/webservice/
- Shoptet Developers - Importação de dados: https://developers.shoptet.com/shoptet-tools/data-import/

### Migração de Shopify para WooCommerce

URL: https://prevedshop.com/pt/migracoes/shopify-para-woocommerce
Language: pt
Last reviewed: 2026-09-02
Route: shopify -> woocommerce

A maioria dos guias descreve apenas a passagem para a Shopify. A direção contrária é igualmente comum quando uma loja quer a propriedade total dos dados, um site rico em conteúdo no WordPress ou livrar-se de comissões por transação e subscrições de apps. Passar da Shopify para o WooCommerce significa assumir o alojamento, a segurança e as atualizações em troca de um modelo de dados aberto e personalização sem limites. A migração cobre produtos, variantes, metafields, clientes, histórico de encomendas, conteúdo e um mapa de redirecionamentos completo.

#### Porque é que as lojas deixam a Shopify

As razões habituais são custos recorrentes de apps que se acumulam, comissões em gateways de terceiros, um checkout difícil de personalizar e o desejo de ter comércio e conteúdo numa única instalação WordPress. O WooCommerce não cobra taxa de plataforma e guarda toda a base de dados no seu próprio servidor, o que importa a comerciantes com requisitos rigorosos de residência de dados ou muita personalização B2B. O outro lado é operacional: desempenho do alojamento, cópias de segurança, atualizações de plugins e âmbito PCI passam a ser seus ou da sua agência.

#### Produtos, variantes e metafields

Os produtos Shopify com até três dimensões de opções mapeiam bem para produtos variáveis WooCommerce com atributos e variações. A exceção são os metafields: o WooCommerce não tem equivalente nativo, por isso cada metafield é mapeado para um atributo de produto, um campo personalizado ou a estrutura de dados de um plugin específico. As coleções tornam-se categorias ou etiquetas consoante o uso; as coleções inteligentes baseadas em regras têm de ser recriadas como categorias com atribuição manual ou com um plugin de filtragem. Imagens, SKU, pesos e inventário movem-se com o importador CSV ou por um processo direto de API para base de dados.

#### Clientes, encomendas e conteúdo

Os clientes são importados com moradas e consentimento de marketing; as palavras-passe são cifradas de forma diferente em cada plataforma e nunca são transferidas. O histórico de encomendas é importado para relatórios e apoio ao cliente, com estados mapeados para os equivalentes WooCommerce. Páginas e artigos de blog da Shopify tornam-se páginas e artigos WordPress, normalmente um ganho de flexibilidade de edição. Códigos de desconto e cartões-presente exigem revisão, porque os cupões WooCommerce e os plugins de cartões-presente não reproduzem exatamente as regras da Shopify.

#### URL, redirecionamentos e lançamento

A Shopify impõe os prefixos `/products/`, `/collections/` e `/pages/`; o WordPress permite definir as ligações permanentes livremente, uma oportunidade para desenhar uma estrutura mais limpa. Cada URL indexado da Shopify tem de mapear para um URL WooCommerce através de um redirecionamento 301 servido pelo novo site antes de mover o domínio. Testamos o mapa de redirecionamentos, a velocidade e o checkout num servidor de staging e depois mudamos o DNS, deixando a loja Shopify aberta durante um breve período. Os redirecionamentos preservam a continuidade dos URL e reduzem o risco; as posições não podem ser garantidas.

#### FAQ

Q: Os metafields da Shopify podem ser migrados para o WooCommerce?
A: Sim, mas não automaticamente. Cada metafield é mapeado para um atributo WooCommerce, um campo personalizado ou uma estrutura de plugin que o seu tema consiga mostrar.

Q: Os clientes mantêm as palavras-passe ao passar para o WooCommerce?
A: Não. Os hashes de palavra-passe são específicos de cada plataforma. Os clientes recebem uma ligação de redefinição na nova loja, idealmente incluída no anúncio de lançamento.

Q: Que alojamento precisa o WooCommerce depois de deixar a Shopify?
A: Alojamento WordPress gerido com PHP 8, cache de objetos e cópias diárias é o mínimo prático para uma loja que antes estava na infraestrutura da Shopify.

Q: Vou perder SEO ao deixar a Shopify?
A: Os padrões de URL mudam, por isso um mapa completo de redirecionamentos 301 é obrigatório. Com redirecionamentos, tags canónicas e um sitemap reenviado o risco reduz-se, mas nenhuma migração garante posições inalteradas.

Sources:
- WooCommerce - Importador e exportador de produtos CSV: https://woocommerce.com/document/product-csv-importer-exporter/
- Shopify Help Center - Migrar para a Shopify: https://help.shopify.com/en/manual/migrating-to-shopify

### Migrar do Shoptet para o Shopify

URL: https://prevedshop.com/pt/migracoes/shoptet-para-shopify
Language: pt
Last reviewed: 2026-07-21
Route: shoptet -> shopify

O Shoptet é uma plataforma SaaS fechada e alojada, focada nos mercados checo e eslovaco, pelo que esta mudança é diferente de uma migração de auto-alojado para SaaS: ambas as plataformas tratam do alojamento e da conformidade PCI por si. Os verdadeiros motores costumam ser o alcance além do mercado CZ/SK, o ecossistema de apps globalmente maior do Shopify, e mais flexibilidade de design através do sistema de temas Liquid do Shopify. Como o Shoptet é de código fechado, o acesso aos dados depende das suas ferramentas de exportação e da API, e não de acesso direto à base de dados, o que molda a forma como a própria migração tem de ser planeada.

#### Porque os comerciantes saem do Shoptet

O Shoptet é uma plataforma sólida e fácil de gerir para comerciantes CZ/SK, mas é regionalmente focada — o seu marketplace de apps, as integrações de pagamento e envio, e as ferramentas multi-moeda/multi-idioma são construídas sobretudo em torno desse mercado. Comerciantes que expandem para além da Chéquia e da Eslováquia consideram muitas vezes que o ecossistema global de apps do Shopify, as suas ferramentas nativas de multi-moeda e multi-idioma através do Shopify Markets, e a sua base mais ampla de integrações de terceiros se adequam melhor ao crescimento internacional.

A flexibilidade de design é outro motivo comum: a personalização de temas do Shoptet é mais limitada do que o sistema de temas baseado em Liquid do Shopify, pelo que comerciantes que queiram um design de loja altamente personalizado ou uma personalização mais profunda do checkout (disponível para comerciantes Shopify Plus) consideram muitas vezes que o Shopify lhes dá mais margem para construir exatamente o que querem.

#### Tirar dados de uma plataforma fechada

Ao contrário das plataformas de código aberto, onde se pode consultar a base de dados diretamente, o Shoptet não dá acesso direto à base de dados — os dados de produtos, encomendas e clientes têm de sair através das ferramentas de exportação do Shoptet (exportações CSV/XML) e da sua API. Isso significa que a etapa de extração de dados da migração depende do que a superfície de exportação e de API do Shoptet realmente expõe, e quaisquer dados que não sejam acessíveis através desses canais (certos campos personalizados, metadados históricos de encomendas) precisam de ser identificados cedo, já que não podem simplesmente ser retirados de um despejo de base de dados como aconteceria numa plataforma auto-alojada.

#### Dados de produto, categorias e variantes

O modelo de produtos do Shoptet, como a maioria das plataformas SaaS, usa parâmetros/variantes para opções de produto como tamanho ou cor. Mapear estes para o sistema de variantes do Shopify (limitado a três dimensões de opções) costuma ser mais direto do que migrar de uma plataforma com um modelo de atributos personalizados arbitrário, embora quaisquer parâmetros do Shoptet usados mais para filtragem descritiva do que como verdadeiras variantes fiquem melhor em metafields do Shopify. A estrutura de categorias do Shoptet também precisa de ser revista face ao modelo mais plano e baseado em coleções do Shopify, em vez de ser copiada como uma árvore literal.

#### URLs, localização e apps

Os URLs do Shoptet seguem as suas próprias convenções de plataforma e precisam de ser mapeados para os padrões fixos do Shopify (`/products/{handle}`, `/collections/{handle}`) com redirecionamentos 301 explícitos para cada página indexada, para proteger a visibilidade nas pesquisas já conquistada — particularmente importante para o SEO no mercado CZ/SK construído ao longo do tempo. Se a loja vender em vários idiomas ou moedas, o Shopify Markets precisa de ser configurado para replicar essa configuração, já que funciona de forma diferente por baixo em comparação com a localização nativa do Shoptet. Quaisquer apps ou integrações do marketplace Shoptet (gateways de pagamento, transportadoras, ferramentas de marketing) também precisam de avaliação individual face à App Store do Shopify, para confirmar se existe um equivalente ou se é preciso desenvolvimento personalizado.

#### FAQ

Q: Como tiro os meus dados de produtos e encomendas do Shoptet?
A: Através das ferramentas de exportação CSV/XML do Shoptet e da sua API — não há acesso direto à base de dados, já que é uma plataforma SaaS fechada. Identificamos cedo que tipos de dados são realmente exportáveis e sinalizamos o que não é antes de definir o âmbito da migração.

Q: Os meus URLs do Shoptet vão redirecionar automaticamente para o Shopify?
A: Não. A estrutura de URLs do Shopify é fixa e diferente da do Shoptet, pelo que cada URL indexado do Shoptet precisa de um redirecionamento 301 explícito para o seu equivalente no Shopify, o que importa particularmente para a visibilidade de pesquisa CZ/SK construída ao longo do tempo.

Q: O Shopify consegue tratar da venda multi-idioma e multi-moeda como o Shoptet?
A: Sim, através do Shopify Markets, mas configurado de forma diferente da localização nativa do Shoptet — precisa de ser configurado deliberadamente para replicar a sua configuração multi-mercado existente, em vez de se assumir que funciona da mesma forma de origem.

Q: Porquê mudar do Shoptet para o Shopify se ambas são plataformas SaaS alojadas?
A: Os motores habituais são o alcance e a flexibilidade, e não o peso do alojamento — o ecossistema global de apps do Shopify, integrações de pagamento e envio mais amplas para vendas internacionais, e mais opções de personalização de tema e checkout para lojas que ultrapassaram o conjunto de ferramentas mais regionalmente focado do Shoptet.

Sources:
- Shopify - Migre a sua loja para o Shopify: https://www.shopify.com/migrate
- Site oficial do Shoptet: https://www.shoptet.cz

### Migrar do Shopware para o Shopify

URL: https://prevedshop.com/pt/migracoes/shopware-para-shopify
Language: pt
Last reviewed: 2026-07-21
Route: shopware-6 -> shopify

O Shopware é uma plataforma de comércio flexível, baseada em Symfony, popular na região DACH, disponível tanto auto-alojada como em oferta cloud gerida. Mudar para o Shopify significa abdicar do sistema altamente personalizável de entidades e plugins do Shopware em troca da plataforma mais restrita mas totalmente gerida do Shopify. O trabalho central é mapear as propriedades de produto flexíveis e o modelo de canais de venda do Shopware para o esquema fixo de produtos e o ecossistema de apps do Shopify, a par do planeamento habitual de URLs e redirecionamentos que qualquer mudança de plataforma exige.

#### Porque os comerciantes saem do Shopware

O ponto forte do Shopware — uma plataforma altamente extensível construída sobre Symfony, com um sistema flexível de entidades e personalização profunda por plugins/apps — tem um custo real se for auto-alojada: a gestão do servidor, as atualizações de versão de PHP e do Shopware, e a conformidade PCI do checkout ficam a cargo da sua equipa. Mesmo a opção cloud do Shopware ainda implica gerir um ecossistema de plugins que precisa de se manter compatível entre atualizações. O Shopify remove por completo o alojamento e a correção da plataforma da sua responsabilidade, ao custo das opções de personalização mais profundas ao nível do código que o Shopware oferece.

Um motivo frequente é o mesmo que se vê noutras plataformas flexíveis de código aberto: o tempo de programador necessário para manter plugins Shopware personalizados e mantê-los a funcionar entre atualizações de versão deixa de ser proporcional ao que a loja precisa, especialmente para comerciantes que usaram a flexibilidade do Shopware menos do que esperavam.

#### Propriedades de produto, variantes e o modelo de dados

O Shopware representa a variação de produto através de "propriedades" e "opções" que geram combinações de variantes, a par de um sistema flexível de campos personalizados para atributos fora dessa estrutura. Isto está conceptualmente mais próximo do modelo de variantes do Shopify do que um sistema EAV completo, mas o limite rígido do Shopify de três dimensões de opções de variante por produto significa que produtos do Shopware que usem mais grupos de propriedades do que isso precisam de ter algumas propriedades movidas para metafields do Shopify em vez de variantes.

A estrutura de categorias do Shopware, como a da maioria das plataformas com uma verdadeira árvore de categorias, permite categorias aninhadas com atribuição flexível. As coleções do Shopify são mais planas — listas manuais ou baseadas em regras, e não uma árvore aninhada — pelo que uma estrutura de categorias do Shopware precisa de ser redesenhada como um conjunto de coleções do Shopify, e não exportada diretamente.

#### Canais de venda e multi-loja

O conceito de "Canal de Vendas" do Shopware permite que uma única instância Shopware sirva várias lojas, apps ou marketplaces a partir de um catálogo partilhado, cada um com as suas próprias definições. Os equivalentes mais próximos no Shopify são os seus próprios canais de venda múltiplos (loja online, POS, marketplaces) mais o Shopify Markets para variação regional e de moeda dentro de uma loja, ou lojas Shopify separadas para marcas genuinamente distintas. Os conceitos sobrepõem-se mas não são uma correspondência arquitetónica direta, pelo que uma configuração de canais de venda do Shopware precisa de ser mapeada para a estrutura certa no Shopify com base no que está realmente a ser usado, e não assumida como uma tradução um-para-um.

#### URLs, plugins e considerações específicas da UE

Os URLs de SEO do Shopware são configuráveis por canal de vendas, pelo que os URLs existentes precisam de redirecionamentos 301 explícitos mapeados para os padrões fixos do Shopify (`/products/{handle}`, `/collections/{handle}`) para proteger o posicionamento nas pesquisas durante a mudança. Os plugins e apps do Shopware que cobrem envio, pagamento e personalização do checkout não têm equivalente automático no Shopify e precisam de avaliação individual — uma app do Shopify, uma construção personalizada, ou confirmação de que a funcionalidade já não é necessária.

O Shopware é amplamente usado por toda a UE e tem ferramentas incorporadas para tratamento de IVA e requisitos de dados relacionados com o RGPD comuns nesse mercado. O Shopify cobre um terreno semelhante através do Shopify Tax e das suas próprias ferramentas de conformidade, mas a configuração específica — registo fiscal, formatação de faturas, definições de tratamento de dados — precisa de ser revista e reconfigurada para o Shopify, e não assumida como transportável automaticamente.

#### FAQ

Q: As propriedades de produto do Shopware mapeiam-se de forma limpa para as variantes do Shopify?
A: Razoavelmente bem para uso padrão de variantes, já que as propriedades do Shopware são conceptualmente semelhantes às opções de variante do Shopify. Produtos que usem mais de três grupos de propriedades precisam de ter algumas propriedades movidas para metafields do Shopify, já que o Shopify limita os produtos a três dimensões de opções de variante.

Q: O que acontece aos meus Canais de Venda do Shopware?
A: Não há um equivalente exato no Shopify — os próprios canais de venda múltiplos do Shopify, o Shopify Markets e lojas separadas cobrem cada um parte do que uma configuração de Canais de Venda do Shopware consegue fazer. Mapeamos o seu caso de uso real (regiões, marcas, marketplaces) para a estrutura certa no Shopify durante a avaliação.

Q: Os meus URLs do Shopware vão redirecionar automaticamente para o Shopify?
A: Não. A estrutura de URLs do Shopify é fixa, pelo que cada URL indexado do Shopware precisa de um redirecionamento 301 explícito para o seu equivalente no Shopify — parte do plano de migração, e não uma reflexão tardia.

Q: A configuração de IVA da UE e de RGPD do Shopware transfere-se para o Shopify?
A: Não automaticamente. O Shopify tem as suas próprias ferramentas de impostos e conformidade (Shopify Tax e definições relacionadas), mas o registo fiscal, a formatação de faturas e a configuração de tratamento de dados precisam de ser revistos e configurados especificamente para o Shopify, e não assumidos como transferidos do Shopware.

Sources:
- Shopify - Migre a sua loja para o Shopify: https://www.shopify.com/migrate
- Site oficial e documentação do Shopware: https://www.shopware.com

### Migrar do WooCommerce para o BigCommerce

URL: https://prevedshop.com/pt/migracoes/woocommerce-para-bigcommerce
Language: pt
Last reviewed: 2026-07-21
Route: woocommerce -> bigcommerce

O WooCommerce funciona como um plugin do WordPress, pelo que os seus dados, alojamento e desempenho estão presos à sua instalação WordPress. Migrar para o BigCommerce separa o comércio da sua pilha de conteúdo WordPress e entrega o alojamento, a conformidade PCI e a segurança da plataforma ao BigCommerce — ao mesmo tempo que dá mais flexibilidade nativa de variantes e mais controlo sobre URLs do que a maioria dos concorrentes SaaS. O trabalho consiste em mapear os dados de produto e conteúdo do WooCommerce, assentes no WordPress, para a estrutura do BigCommerce sem perder valor de SEO nem quebrar funcionalidade dependente de plugins pelo caminho.

#### Porque é que os comerciantes saem do WooCommerce

O WooCommerce em si é gratuito, mas geri-lo significa assumir as atualizações do núcleo do WordPress e dos plugins, o desempenho do alojamento, a segurança ao nível do servidor e a conformidade PCI para o checkout. À medida que uma loja escala, os conflitos entre plugins e o efeito de uma pilha de plugins cada vez maior na velocidade de página tornam-se custos reais e recorrentes — sem contar com o tempo de programação ou de agência necessário para manter tudo em dia e compatível. O BigCommerce, como plataforma SaaS gerida, elimina esse esforço de alojamento e manutenção, em troca de trabalhar dentro das limitações da sua plataforma.

Lojas que ultrapassam a sua configuração de alojamento WordPress, ou que estão cansadas da fragilidade de uma pilha de plugins à medida que o site escala, são as candidatas mais comuns a esta mudança.

#### Dados de produto: um ajuste mais próximo do que seria de esperar

O WooCommerce guarda os produtos como um tipo de conteúdo (post type) personalizado do WordPress, com variações e atributos construídos sobre as taxonomias do WordPress — flexível, já que o WordPress impõe poucos limites rígidos a campos personalizados. O modelo de produtos do BigCommerce é mais estruturado, mas notoriamente mais permissivo em termos de variantes do que alguns concorrentes SaaS, suportando um número maior de combinações de variantes por produto, a par de campos personalizados e modificadores de produto para atributos que não cabem na estrutura de variantes. Ainda assim, produtos WooCommerce com uso intenso do ACF (Advanced Custom Fields) ou muitos atributos personalizados precisam de um plano de mapeamento deliberado para os campos personalizados do BigCommerce, e não de uma cópia cega.

As categorias e etiquetas do WooCommerce são taxonomias do WordPress que podem ser aninhadas e atribuídas de forma cruzada livremente. A árvore de categorias do BigCommerce está mais próxima de uma hierarquia tradicional do que as coleções planas do Shopify, o que torna a tradução de uma estrutura de categorias do WooCommerce algo mais direta, embora continue a valer a pena revê-la em vez de a exportar sem alterações.

#### URLs, conteúdo e plugins

As ligações permanentes (permalinks) do WordPress são totalmente configuráveis, pelo que as URLs do WooCommerce raramente correspondem, por defeito, a um padrão fixo. O BigCommerce, ao contrário de algumas plataformas SaaS, permite caminhos de URL personalizados sem um prefixo obrigatório, o que pode facilitar a preservação de uma estrutura de URLs WooCommerce existente — mas qualquer URL que mude continua a precisar de um redirecionamento 301 explícito, e todas as URLs indexadas do WooCommerce devem ser auditadas contra o seu equivalente no BigCommerce de qualquer forma.

Há também a questão do conteúdo em WordPress: muitas lojas WooCommerce dependem do WordPress como CMS completo para conteúdo de blog e landing pages, algo sem equivalente direto nas ferramentas de conteúdo mais limitadas do BigCommerce. Lojas com bastante conteúdo em WordPress precisam de um plano — migrá-lo para páginas do BigCommerce, ou manter o WordPress a correr separadamente para o conteúdo enquanto o BigCommerce trata do comércio. Os plugins do WooCommerce que cobrem envios, subscrições ou campos de checkout personalizados também precisam de avaliação individual: um equivalente em app no BigCommerce, uma construção personalizada, ou a confirmação de que já não são necessários.

#### FAQ

Q: O BigCommerce suporta a configuração de variantes e atributos do WooCommerce?
A: O BigCommerce suporta mais combinações de variantes por produto do que alguns concorrentes SaaS, o que ajuda com catálogos WooCommerce complexos, mas continua a não existir um equivalente automático aos campos personalizados do WordPress ou aos dados do ACF — esses precisam de ser mapeados para campos personalizados do BigCommerce de forma deliberada.

Q: O que acontece ao meu blog e às minhas landing pages do WordPress?
A: Não migram automaticamente, já que as ferramentas de conteúdo do BigCommerce são mais limitadas do que as do WordPress. Pode migrar artigos de blog e páginas para o BigCommerce, ou manter o WordPress a correr separadamente para conteúdo enquanto o BigCommerce trata do comércio — ajudamo-lo a decidir com base em quanto tráfego esse conteúdo gera.

Q: As minhas URLs do WooCommerce vão precisar de mudar no BigCommerce?
A: Menos do que seria de esperar ao migrar para outras plataformas SaaS, já que o BigCommerce permite caminhos de URL personalizados sem prefixo obrigatório. Qualquer URL que mude continua a precisar de um redirecionamento 301 explícito, e auditamos todas as URLs indexadas do WooCommerce antes do lançamento de qualquer forma.

Q: O BigCommerce consegue substituir todos os meus plugins do WooCommerce?
A: A maioria tem um equivalente em app no BigCommerce, mas nem todos — alguma funcionalidade de plugins precisa de uma construção personalizada sobre as APIs do BigCommerce, e outra é descartada se já não for necessária. Catalogamos os seus plugins ativos durante a avaliação, antes de definir o âmbito do trabalho.

Sources:
- Site e documentação oficial do BigCommerce: https://www.bigcommerce.com
- Documentação do WooCommerce: https://woocommerce.com/documentation/

### Migrar do WooCommerce para o Shopify

URL: https://prevedshop.com/pt/migracoes/woocommerce-para-shopify
Language: pt
Last reviewed: 2026-07-21
Route: woocommerce -> shopify

O WooCommerce funciona como um plugin sobre o WordPress, o que significa que os dados, o alojamento e o desempenho da sua loja estão entrelaçados com a sua instalação WordPress. Migrar para o Shopify separa o comércio do conteúdo: passa a ter uma plataforma de alojamento gerida e compatível com PCI e um modelo de produto/checkout construído de propósito, mas perde também a flexibilidade nativa do WordPress para conteúdo e a equivalência direta entre plugin e app que talvez esperasse. O trabalho central é mapear o modelo de dados do WooCommerce, assente no WordPress, para o esquema fixo do Shopify sem perder valor de SEO nem quebrar funcionalidade personalizada pelo caminho.

#### Porque é que os comerciantes saem do WooCommerce

O WooCommerce é gratuito de instalar, mas geri-lo bem não é: o cliente é responsável pelas atualizações do núcleo do WordPress e dos plugins, pelo desempenho do alojamento, pela segurança ao nível do servidor e pela conformidade PCI em tudo o que toca em dados de pagamento. À medida que uma loja cresce, os conflitos entre plugins, os problemas de velocidade de página resultantes de uma pilha crescente de plugins, e o custo recorrente de um programador ou agência para manter tudo em dia tornam-se o verdadeiro custo do software "gratuito". O Shopify troca esse esforço de manutenção contínuo por uma mensalidade fixa e um ambiente gerido e compatível com PCI.

Um motivo frequente é a escala: o desempenho do WooCommerce depende fortemente da qualidade do alojamento e da disciplina na gestão de plugins, e lojas que começaram pequenas atingem muitas vezes um ponto em que o tráfego ou o tamanho do catálogo ultrapassa aquilo para que a sua configuração de alojamento WordPress foi pensada.

#### O que muda no modelo de dados

O WooCommerce guarda os produtos como um tipo de conteúdo (post type) personalizado do WordPress, com variações, atributos e categorias construídos sobre as taxonomias do WordPress — uma estrutura flexível, já que o WordPress impõe poucos limites a campos personalizados. O modelo de produtos do Shopify é mais limitado: um conjunto fixo de campos centrais, até três dimensões de opções de variante e metafields para tudo o resto. Produtos com muitos atributos personalizados do WooCommerce ou dados do ACF (Advanced Custom Fields) precisam de uma estrutura de metafields planeada de propósito, e não de uma cópia cega campo a campo.

As categorias e etiquetas de produto do WooCommerce são taxonomias do WordPress e podem ser aninhadas e atribuídas de forma cruzada livremente. As coleções do Shopify são listas manuais ou coleções baseadas em regras ("inteligentes"), e não uma verdadeira árvore de taxonomias, pelo que uma estrutura de categorias profunda do WooCommerce costuma precisar de ser reformulada como um conjunto de coleções mais plano, e não exportada tal como está.

#### URLs, redirecionamentos e a questão do conteúdo

As ligações permanentes (permalinks) do WordPress são totalmente configuráveis, pelo que as URLs de produtos e categorias do WooCommerce podem ter praticamente qualquer aspeto que o site tenha escolhido. O Shopify impõe os seus próprios padrões (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`, `/blogs/{blog}/{handle}`), pelo que cada URL indexada do WooCommerce que não corresponda já a esse padrão precisa de um redirecionamento 301 para sobreviver à mudança sem perder posicionamento nas pesquisas.

Há também uma questão de conteúdo específica deste par de plataformas: o WordPress é um CMS completo, e muitas lojas WooCommerce apoiam-se nele para conteúdo de blog, landing pages e templates de página personalizados. As ferramentas de blog e página do Shopify são mais simples do que as do WordPress. Lojas com bastante conteúdo em WordPress precisam de um plano para esse conteúdo — migrá-lo para páginas/blog do Shopify, ou manter uma instância WordPress separada para o conteúdo enquanto o Shopify trata do comércio —, decidido de forma deliberada, e não descoberto depois do lançamento.

#### Plugins, checkout e gateways de pagamento

O ecossistema de plugins do WooCommerce cobre tudo, desde calculadoras de envio a faturação por subscrição e campos de checkout personalizados, muitas vezes através de plugins de terceiros sem equivalente direto no Shopify. Cada plugin ativo exige uma decisão explícita durante a migração: uma app equivalente no Shopify, uma app personalizada ou personalização de tema, ou a confirmação de que a funcionalidade já não é necessária. Os gateways de pagamento também precisam de ser reconfigurados — o WooCommerce suporta uma grande variedade de plugins de gateway, enquanto o Shopify centraliza os pagamentos através do Shopify Payments ou de um gateway de terceiros suportado, pelo que qualquer lógica de checkout personalizada ligada a um plugin de pagamento específico do WooCommerce tem de ser reconstruída para o modelo de checkout do Shopify.

#### FAQ

Q: O meu posicionamento de SEO do WooCommerce sobrevive à mudança para o Shopify?
A: Pode sobreviver, mas só com um mapeamento de redirecionamentos deliberado. Os permalinks do WordPress e a estrutura fixa de URLs do Shopify raramente coincidem exatamente, pelo que cada URL indexada do WooCommerce precisa de um redirecionamento 301 explícito para o seu equivalente no Shopify antes do lançamento — veja o nosso serviço de SEO e Migração de Redirecionamentos.

Q: O que acontece ao meu blog e às minhas landing pages do WordPress?
A: Não migram automaticamente, porque as ferramentas de conteúdo do Shopify são mais limitadas do que as do WordPress. Pode migrar artigos de blog e páginas para o Shopify, ou manter uma instância WordPress separada para conteúdo enquanto o Shopify trata do comércio — ajudamo-lo a decidir com base em quanto do seu tráfego depende desse conteúdo.

Q: O Shopify consegue substituir todos os meus plugins do WooCommerce?
A: A maioria tem um equivalente em app no Shopify, mas nem todos — alguma funcionalidade de plugins do WooCommerce precisa de uma app personalizada ou de uma personalização de tema no Shopify, e outra é simplesmente descartada se já não for necessária. Catalogamos os seus plugins ativos durante a avaliação, antes de definir o âmbito do trabalho.

Q: O que acontece às variações de produto e aos atributos personalizados do WooCommerce?
A: As variações standard mapeiam-se para o sistema de variantes do Shopify, limitado a três dimensões de opções. Os atributos personalizados do WooCommerce e os campos do ACF além disso precisam de ser mapeados para metafields do Shopify de forma deliberada — não existe uma conversão automática de um para um a partir dos campos personalizados do WordPress.

Sources:
- Shopify - Migre a sua loja para o Shopify: https://www.shopify.com/migrate
- Documentação do WooCommerce: https://woocommerce.com/documentation/

### Migração de WooCommerce para Shoptet

URL: https://prevedshop.com/pt/migracoes/woocommerce-para-shoptet
Language: pt
Last reviewed: 2026-09-02
Route: woocommerce -> shoptet

A Shoptet é uma plataforma alojada criada para comerciantes checos e eslovacos, com suporte nativo a transportadoras locais, gateways de pagamento, regras de faturação e feeds para comparadores. Migrar a partir do WooCommerce significa trocar um WordPress auto-alojado por um sistema gerido com um modelo de dados fixo. A migração em si consiste em traduzir os produtos, taxonomias e dados de plugins do WordPress para a estrutura de importação da Shoptet, manter o histórico de clientes e encomendas onde importa e proteger os URL que trazem o seu tráfego de pesquisa.

#### Porque é que as lojas passam do WooCommerce para a Shoptet

A maioria muda porque manter o WordPress bem custa tempo: atualizações de plugins, desempenho do alojamento, correções de segurança e responsabilidades PCI recaem sobre o comerciante. A Shoptet substitui isso por uma mensalidade e um ambiente gerido que já integra Zásilkovna, PPL, GoPay, Comgate, Heureka e Zboží.cz. Se os seus clientes estão na Chéquia ou na Eslováquia, as integrações nativas costumam eliminar vários plugins de uma vez. O preço é a flexibilidade: o modelo de produtos e conteúdos da Shoptet é mais estreito do que o WordPress, por isso tudo o que é personalizado precisa de um destino decidido antecipadamente.

#### Mapeamento de produtos, variantes e parâmetros

O WooCommerce guarda produtos como artigos do WordPress com atributos, variações e categorias baseadas em taxonomias. A Shoptet espera uma importação estruturada com produtos, variantes, parâmetros, categorias e disponibilidade definidos nos seus próprios campos. As variações tornam-se variantes Shoptet desde que a estrutura de opções seja coerente; os atributos usados para filtrar tornam-se parâmetros, que têm de ser criados e nomeados antes da importação. As árvores de categorias podem ser aninhadas em ambos os sistemas, mas a Shoptet funciona melhor com uma hierarquia limpa e pouco profunda. Campos personalizados de ACF ou de plugins não têm destino automático e são decididos um a um: texto de descrição, parâmetro ou eliminação.

#### Clientes, encomendas e redirecionamentos de URL

As contas de cliente podem ser importadas com contactos e moradas; as palavras-passe não podem ser movidas, pelo que o cliente recebe um fluxo de redefinição na nova loja. O histórico de encomendas é importado como referência e para relatórios, não como encomendas ativas editáveis. A parte mais sensível são os URL: as ligações permanentes do WordPress são livres, enquanto a Shoptet usa os seus próprios padrões de caminho, por isso cada produto, categoria e página indexada precisa de um redirecionamento 301 para o equivalente Shoptet antes do lançamento. Os redirecionamentos preservam a continuidade dos URL e reduzem o risco; nenhuma migração garante posições inalteradas.

#### Mudança e primeiros dias na Shoptet

Recomendamos correr a loja Shoptet em modo de teste com o catálogo completo importado, verificar uma amostra de produtos, preços, taxas de IVA e variantes, e só depois mudar o DNS. Os feeds para Heureka e Zboží.cz devem ser regenerados a partir da Shoptet e reenviados, e o Google Search Console deve receber o novo sitemap no dia do lançamento. Mantenha o WordPress acessível apenas para leitura durante um curto período para não perder nada enquanto o mapa de redirecionamentos é confirmado.

#### FAQ

Q: Posso migrar encomendas e clientes do WooCommerce para a Shoptet?
A: Os clientes com moradas podem ser importados. As encomendas são importadas como histórico de referência; não se tornam encomendas ativas editáveis. As palavras-passe nunca são transferíveis, por isso o cliente define uma nova no primeiro acesso.

Q: Os meus URL do WooCommerce continuam a funcionar na Shoptet?
A: Só com um mapa explícito de redirecionamentos 301. Os padrões de URL do WordPress e da Shoptet diferem, por isso construímos o mapeamento a partir dos seus URL indexados e verificamo-lo antes do lançamento.

Q: O que acontece aos plugins do WooCommerce?
A: Cada plugin é revisto. Muitas funções do mercado checo são nativas na Shoptet, algumas têm add-ons e o resto precisa de uma solução à medida ou é descartado por decisão.

Q: Quanto tempo demora uma migração de WooCommerce para Shoptet?
A: Um catálogo pequeno ou médio demora normalmente duas a quatro semanas, incluindo o teste, os redirecionamentos e o arranque; estruturas de parâmetros complexas ou históricos de encomendas grandes demoram mais.

Sources:
- Shoptet Developers - Importação de dados: https://developers.shoptet.com/shoptet-tools/data-import/
- WooCommerce - Importador e exportador de produtos CSV: https://woocommerce.com/document/product-csv-importer-exporter/

### Guides

### Como escolher uma plataforma de ecommerce antes de migrar

URL: https://prevedshop.com/pt/guias/como-escolher-plataforma-ecommerce
Language: pt
Last reviewed: 2026-09-02

Escolher a plataforma é a decisão que define o custo de qualquer migração posterior. As listas de funcionalidades dos fornecedores ajudam pouco, porque quase todas as plataformas modernas cobrem o básico. As perguntas úteis são sobre a estrutura do catálogo, o mercado para onde vende, os sistemas que tem de ligar, quanta propriedade quer e o que a própria migração vai exigir. Este guia percorre essas cinco perguntas e termina com uma pequena lista de sinais de alerta que devem travar a decisão.

#### Comece pelo catálogo, não pela lista de funcionalidades

Conte produtos, variantes e parâmetros e veja como se relacionam. Três dimensões de opções com um conjunto limpo de atributos de filtro cabem em quase qualquer plataforma. Conjuntos de atributos diferentes por tipo de produto, bundles, configuradores, tabelas de preços B2B ou milhares de variantes reduzem as opções a plataformas com um modelo de dados mais rico, como Adobe Commerce, Shopware ou uma arquitetura composable. Anote os cinco produtos mais incómodos do seu catálogo e pergunte a cada candidata como os armazenaria; as respostas dizem mais do que qualquer tabela comparativa.

#### Mercado, idioma e integrações

Uma loja que vende a clientes checos e eslovacos precisa de transportadoras locais, gateways de pagamento, feeds para comparadores e regras de faturação. A Shoptet ou a Upgates oferecem isso nativamente; uma plataforma SaaS global consegue-o com apps, a troco de mais custo e manutenção. Vender em vários países levanta outras questões: mutações de idioma, moedas, IVA e se a forma certa é uma loja ou várias. Enumere os sistemas que têm de continuar ligados - ERP, contabilidade, armazém, PIM, feeds de marketplaces - e verifique se cada candidata tem um conector mantido ou apenas uma API contra a qual teria de desenvolver.

#### Propriedade, custo e caminho de migração

As plataformas alojadas trocam controlo por comodidade: não toca na base de dados, mas também nunca atualiza um servidor. As plataformas open source dão-lhe os dados e a responsabilidade. O custo total inclui licença ou plano, alojamento, apps ou extensões, horas de agência e o tempo interno gasto em atualizações. Por fim, ponha preço à própria migração: quantos dados transfere, se o histórico de encomendas e as contas de cliente importam, quantos URL precisam de redirecionamento e que funções à medida têm de ser reconstruídas. Uma plataforma mais barata no papel pode ficar mais cara quando se soma o esforço de migração.

#### Sinais de alerta que devem travar a decisão

Desconfie quando uma plataforma não consegue mostrar como representará um tipo de dado específico da sua loja atual, quando uma integração essencial só existe como app de terceiros com manutenção incerta, quando o fornecedor promete que as posições não mudam após a migração ou quando ninguém sabe explicar como sairia da plataforma mais tarde. Uma descoberta curta com amostras reais dos seus dados resolve a maioria destas dúvidas antes de assinar seja o que for.

#### FAQ

Q: Devo escolher a plataforma antes ou depois da avaliação de migração?
A: Idealmente a avaliação informa a escolha. Uma descoberta curta com amostras reais de produtos, clientes e encomendas mostra como cada candidata armazenaria os seus dados e quanta reconstrução a migração exigiria.

Q: Uma plataforma alojada é sempre mais barata do que open source?
A: Nem sempre. As alojadas têm taxas previsíveis mas as apps acumulam-se; o open source não tem licença mas exige alojamento, atualizações e tempo de programação. Compare o custo total a três anos, migração incluída.

Q: Quão importante é a plataforma de ecommerce para o SEO?
A: Menos do que o processo de migração. Qualquer plataforma corrente pode posicionar bem; o que faz perder visibilidade é um mapa de redirecionamentos em falta, conteúdo alterado ou páginas lentas depois da mudança.

Q: Posso mudar de plataforma outra vez mais tarde?
A: Sim, se os seus dados continuarem exportáveis. Antes de escolher, verifique que produtos, clientes, encomendas e conteúdo podem ser exportados num formato estruturado, para que a próxima migração seja possível sem ajuda do fornecedor.

Sources:
- Google Search Central: Mudanças de site com alteração de URL: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### A Checklist de QA Pós-Lançamento

URL: https://prevedshop.com/pt/guias/checklist-qa-apos-lancamento
Language: pt
Last reviewed: 2026-07-21

A migração não termina no momento em que a loja nova entra ao vivo — termina quando confirmar, deliberadamente, que tudo aquilo de que clientes e motores de busca dependem funciona mesmo em condições reais. O staging apanha a maioria dos problemas, mas alguns só aparecem com tráfego real, processadores de pagamento reais e motores de busca a voltar a rastrear o site. Esta checklist cobre o que verificar nos dias e semanas após a mudança, independentemente das plataformas envolvidas.

#### Verifique o fluxo de checkout de ponta a ponta, em condições reais

Faça você mesmo uma compra completa no site ao vivo — não no staging — cobrindo os caminhos que os clientes realmente usam: checkout como convidado e checkout com sessão iniciada, pelo menos um produto com variantes, e quaisquer códigos de desconto ou promoções ativas no momento. Verifique se os emails de confirmação de encomenda são enviados corretamente e se a encomenda aparece devidamente no seu sistema de administração/encomendas depois.

Não assuma que a cobertura do staging se transfere automaticamente. Gateways de pagamento reais, serviços de impostos reais e APIs de taxas de envio reais por vezes comportam-se de forma diferente dos seus equivalentes de staging ou sandbox, o que é exatamente o motivo por que isto precisa de uma verificação real, em condições ao vivo, e não de confiar no que passou no staging.

#### Confirme que os gateways de pagamento estão totalmente ativos e corretamente configurados

Verifique se o processamento de pagamentos está a correr em modo real (não de teste/sandbox), se todos os métodos de pagamento que a sua loja suportava anteriormente estão ativados e a funcionar, e se uma transação real liquida corretamente de ponta a ponta — os fundos a chegarem de facto, não apenas um estado de encomenda a mudar. Verifique também a funcionalidade de reembolso, já que é usada com menos frequência do que o checkout e é fácil de deixar por verificar.

Se suportar vários métodos de pagamento ou moedas, teste cada um individualmente em vez de assumir que, porque um método funciona, os restantes estão configurados da mesma forma.

#### Verifique as regras de impostos e envio com encomendas reais

A lógica de impostos e envio é fácil de errar subtilmente numa migração, já que ambas dependem muitas vezes de configuração que não se mapeia de forma limpa entre plataformas. Faça encomendas de teste para os seus destinos de envio mais comuns e confirme que o imposto é calculado corretamente e que as taxas e métodos de envio disponíveis correspondem ao que pretendia — e não apenas ao que a nova plataforma definiu por defeito.

Preste especial atenção a quaisquer casos especiais de que o seu negócio dependa: isenções de imposto, limiares de envio grátis, regras específicas de região ou restrições de envio em determinados produtos. São exatamente os detalhes de configuração com maior probabilidade de se perderem ou ficarem mal definidos numa migração.

#### Verifique pontualmente os redirecionamentos, não só os que se lembra

Mesmo com um mapa de redirecionamentos completo construído antes do lançamento, verifique pontualmente uma amostra real de URLs depois da mudança: as suas páginas com mais tráfego, algumas com menos tráfego, e algumas das exceções deliberadas (produtos descontinuados, categorias fundidas). Confirme que cada um redireciona para o destino correto num único salto, sem cadeias nem ciclos.

Verifique também uma amostra de URLs que não deveriam existir no site antigo — erros de digitação, URLs antigos baseados em parâmetros, qualquer coisa que um robô possa ter indexado por acidente — para garantir que resolvem de forma sensata em vez de darem erro de uma forma que pareça um problema maior.

#### Confirme a continuidade da análise e do tracking

Verifique se a sua plataforma de análise, o tracking de conversões e quaisquer pixels de publicidade estão a disparar corretamente no site novo — uma encomenda de teste feita deve aparecer nos relatórios da sua análise e plataforma de anúncios da mesma forma que aparecia antes. O código de tracking é fácil de perder silenciosamente numa mudança de plataforma, já que um pixel em falta ou mal configurado não produz uma mensagem de erro; simplesmente deixa de reportar dados.

Compare os primeiros números de análise pós-lançamento com a sua referência pré-migração para o mesmo tipo de dia (dia de semana vs. fim de semana, fontes de tráfego semelhantes), em vez de uma comparação bruta antes/depois, já que a variação normal de tráfego pode, de outra forma, mascarar ou imitar um verdadeiro problema de tracking.

#### Verifique o acesso às contas de cliente e ao histórico de encomendas

Faça com que algumas contas de cliente reais (ou de teste) confirmem que conseguem iniciar sessão, ver o seu histórico de encomendas correto e aceder a quaisquer funcionalidades de conta de que dependiam antes — moradas guardadas, métodos de pagamento guardados quando aplicável, saldos de fidelização ou recompensas se a sua loja os tiver. Os problemas de acesso a contas são altamente visíveis para os clientes que os enfrentam e afetam diretamente a confiança, por isso vale a pena verificá-los deliberadamente em vez de assumir que a migração de contas "provavelmente funcionou".

Se a migração de palavras-passe não fez parte da transferência técnica (comum quando as plataformas usam formas incompatíveis de encriptar palavras-passe), certifique-se de que os clientes têm um caminho claro de redefinição de palavra-passe e que este é comunicado, e não apenas tecnicamente disponível.

#### Monitorize a cobertura no Search Console nas semanas seguintes

Continue a observar o Search Console (ou o equivalente noutros motores de busca) bem depois do dia de lançamento — erros de rastreio, o estado de indexação e qualquer pico de 404s reportados são os sinais mais precoces de um problema de redirecionamento ou de tag canónica que os testes não apanharam. Compare com a sua referência pré-migração para conseguir distinguir uma regressão real de uma flutuação normal de curto prazo depois de uma alteração do site.

Este período de monitorização é também uma boa altura para voltar a submeter o seu sitemap, caso ainda não o tenha feito, e para confirmar que as páginas que espera ver indexadas estão de facto a aparecer nos resultados de pesquisa ao longo das semanas seguintes, e não apenas a serem rastreadas.

#### FAQ

Q: Durante quanto tempo deve continuar o QA pós-lançamento depois da mudança?
A: A verificação ativa e diária costuma importar mais na primeira ou duas semanas, quando surgem a maioria dos problemas de configuração e redirecionamentos. A reindexação pelos motores de busca e a estabilização dos padrões de tráfego demoram mais, por isso vale a pena manter uma monitorização mais leve (Search Console, tendências de análise) durante mais tempo — várias semanas é comum — em vez de parar assim que a primeira semana pareça limpa.

Q: Qual é a coisa mais importante a verificar primeiro depois do lançamento?
A: Um teste real, em condições ao vivo, de checkout e pagamento, já que afeta diretamente a receita e é o único fluxo que todos os clientes tocam. Os problemas de redirecionamentos e tracking também importam, mas um checkout avariado é o problema mais dispendioso de deixar por descobrir, mesmo que por apenas algumas horas.

Q: É normal o posicionamento nas pesquisas cair ligeiramente logo após uma migração?
A: Alguma flutuação de curto prazo é comum mesmo com uma migração bem executada, já que os motores de busca precisam de tempo para voltar a rastrear e a avaliar os URLs novos. O que não é normal é uma queda sustentada ou um pico de erros de rastreio — esse é o sinal para verificar o seu mapa de redirecionamentos e as tags canónicas à procura de um erro real, em vez de esperar que passe.

Q: Quem na equipa deve ficar responsável pelo QA pós-lançamento?
A: Idealmente alguém com visão sobre toda a loja, não apenas a equipa técnica de migração — porque várias destas verificações (as regras de impostos parecerem corretas, o comportamento das contas de cliente, se os números de tracking parecem normais) beneficiam de contexto de negócio, e não apenas de verificação técnica de que uma funcionalidade está presente.

Sources:
- Google Search Central: Site moves with URL changes: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### Limpeza de Dados de Produto Antes da Migração

URL: https://prevedshop.com/pt/guias/limpeza-de-dados-de-produto-antes-da-migracao
Language: pt
Last reviewed: 2026-07-21

Uma migração de plataforma copia tudo o que lhe derem — não limpa nada por si. SKUs duplicados, imagens órfãs, categorias inconsistentes e estruturas de variantes desencontradas que se foram acumulando silenciosamente ao longo de anos passam para a nova plataforma exatamente como estão, a menos que alguém trate disso primeiro. Fazer essa limpeza antes da migração é muito mais barato do que fazê-la depois, quando clientes e motores de busca já dependem do resultado. Este guia cobre o que procurar e como trabalhar nisso.

#### Encontre e resolva SKUs duplicados e produtos quase duplicados

Exporte a lista completa de produtos e verifique primeiro duplicados exatos de SKU — costumam ser um erro de introdução de dados ou de importação e são simples de fundir depois de encontrados. Depois procure quase duplicados: o mesmo produto recriado sob um SKU diferente, muitas vezes resultado de uma reimportação de feed de fornecedor que não correspondeu aos registos existentes, ou um produto recriado manualmente em vez de editado depois de uma mudança de sistema.

Para cada par de duplicados, decida qual registo é o "real" — normalmente o que tem dados mais completos, mais histórico de encomendas ou melhores sinais de SEO, como ligações recebidas ou avaliações — e funda ou redirecione o outro para esse, em vez de migrar ambos e resolver a situação depois na plataforma nova.

#### Localize imagens e media órfãos

Media órfão — imagens e ficheiros carregados para a sua biblioteca de media que já não são referenciados por nenhum produto, categoria ou página de conteúdo — acumula-se naturalmente ao longo de anos de atualizações de produtos, campanhas sazonais e mudanças de plataforma. Não acrescenta valor nenhum na plataforma nova e apenas aumenta o tempo de migração e o armazenamento, por isso vale a pena identificá-lo e excluí-lo.

Tenha também cuidado com o caso inverso: imagens que são referenciadas mas estão quebradas (um ficheiro em falta, um URL externo inativo) valem a pena apanhar agora, já que uma imagem quebrada numa página de produto é um pequeno mas real problema de confiança, muito mais fácil de corrigir nos seus dados atuais e familiares do que depois da mudança.

#### Uniformize categorias e atributos

Anos de acréscimos ad hoc tendem a deixar categorias e atributos inconsistentes: o mesmo conceito escrito ou capitalizado de forma diferente entre produtos, categorias que se sobrepõem ou duplicam entre si, atributos usados para um propósito numa linha de produtos e para um propósito diferente noutra. Esta inconsistência normalmente não causa problemas visíveis na plataforma antiga, onde a equipa já aprendeu a contorná-la, mas torna-se um verdadeiro risco assim que é mapeada mecanicamente para o modelo de dados de uma plataforma nova.

Construa (ou confirme) uma taxonomia limpa e acordada antes da migração — uma árvore de categorias definida e uma lista de atributos definida, com nomenclatura consistente — e reconcilie os seus dados reais com ela. É também o momento de perguntar quais atributos ainda são relevantes para os clientes ou para as operações internas e quais existem apenas porque ninguém os removeu.

#### Reconcilie desencontros na estrutura de variantes

As estruturas de variantes (tamanho, cor, material, e como se combinam em SKUs específicos vendáveis) são tratadas de forma diferente entre plataformas, e dados de origem inconsistentes tornam isto pior. Procure produtos onde as opções de variante não seguem um padrão consistente — algumas variantes de tamanho chamadas "S/M/L" e outras "Pequeno/Médio/Grande" para a mesma linha de produtos, ou produtos onde existe uma combinação de variantes no seu sistema mas sem preço ou stock válido por trás.

Decida o seu modelo de variantes alvo antes da migração, não durante. Saber antecipadamente se a plataforma nova trata as combinações de variantes da mesma forma que a antiga — e onde não trata — determina se os seus dados de variantes existentes se conseguem mapear diretamente ou precisam de ser reestruturados primeiro.

#### Decida o que realmente precisa de se mudar

Nem tudo no seu catálogo atual merece um lugar na plataforma nova. Produtos descontinuados sem stock remanescente, entradas de teste ou placeholder, e campos antigos cujo propósito original já ninguém consegue explicar são todos candidatos a ficar para trás — com uma decisão documentada, e não um abandono silencioso. Migrar menos, deliberadamente, costuma ser melhor do que migrar tudo e resolver a situação depois num sistema novo e pouco familiar.

Para tudo o que decidir não migrar mas que ainda tenha um URL indexado, certifique-se de que fica contemplado no seu plano de redirecionamentos (ver o guia de mapeamento de redirecionamentos) em vez de deixá-lo cair para 404 por acidente.

#### FAQ

Q: Quanto tempo devemos orçamentar para a limpeza de dados antes de uma migração?
A: Depende muito do tamanho do catálogo e de quão desorganizados os dados realmente estão — um catálogo pequeno e bem mantido precisa de muito menos tempo do que um com dezenas de milhares de SKUs e anos de importações de feeds de fornecedores. Auditar os dados primeiro é o que revela o âmbito real; saltar a auditoria e adivinhar é como se subestima o tempo de limpeza.

Q: Devemos limpar os dados antes ou durante o projeto de migração?
A: Antes, ou pelo menos como uma fase inicial explícita com a sua própria etapa de revisão — não misturada na transferência técnica de dados. As decisões de limpeza (o que é um duplicado, o que é seguro descartar, para que servia um campo personalizado misterioso) normalmente precisam do contributo de alguém que conheça o histórico do catálogo, e isso é um tipo de trabalho diferente do mapeamento e transferência técnica em si.

Q: E se não tivermos a certeza se um duplicado é mesmo um duplicado?
A: Sinalize-o em vez de adivinhar de qualquer forma. Um quase duplicado com preços diferentes, opções de variante diferentes ou histórico de encomendas diferente pode ser um produto separado legítimo que apenas parece semelhante. Na dúvida, mantenha ambos e reveja depois de a auditoria estar concluída, em vez de fundir com base num palpite.

Q: A limpeza de dados pode acontecer enquanto a loja antiga ainda está ativa e a receber encomendas?
A: Sim, para a maior parte do trabalho de auditoria e planeamento — rever exportações, decidir fusões e construir a taxonomia alvo não exigem tocar na loja ao vivo. A aplicação efetiva das alterações (fundir registos, eliminar media órfão) costuma ser mais segura numa cópia ou exportação, trazendo depois o conjunto de dados já limpo para a migração, em vez de editar o catálogo ao vivo a meio da auditoria.

### A Checklist de Replatforming de Ecommerce

URL: https://prevedshop.com/pt/guias/checklist-mudanca-de-plataforma-ecommerce
Language: pt
Last reviewed: 2026-07-21

Fazer replatforming de uma loja online é um projeto, não um botão que se carrega. As plataformas envolvidas importam menos do que a maioria assume — o que realmente determina se uma migração corre bem é fazer as partes menos empolgantes pela ordem certa: auditar o que tem, mapear de forma deliberada, planear os redirecionamentos, testar em staging e observar a loja de perto depois da mudança. Esta checklist percorre essa sequência para que a possa aplicar independentemente de qual plataforma está a deixar ou a adotar.

#### 1. Comece com descoberta e auditoria, não com uma comparação de ferramentas

Antes de comparar plataformas de destino, audite o que realmente tem na plataforma atual: quantos produtos e variantes, quantas contas de cliente e quanto histórico de encomendas, quais campos personalizados estão em uso ativo versus abandonados, de que apps ou integrações a loja depende, e quais URLs recebem tráfego significativo neste momento. É esta auditoria que transforma "estamos a migrar" num projeto delimitado com uma lista real do que tem de se mudar.

Seja honesto quanto à qualidade dos dados nesta fase. Se o seu catálogo tem duplicados conhecidos, categorias órfãs ou atributos inconsistentes, escreva isso agora — limpar isso depois é mais caro do que antes da mudança, e saltar a auditoria é como as equipas acabam por descobrir estes problemas a meio da migração.

#### 2. Mapeie o seu modelo de dados antes de mapear um único campo

Cada plataforma estrutura produtos, variantes, categorias e dados de clientes de forma ligeiramente diferente. Antes de mover quaisquer dados, construa um mapeamento explícito: que campo de origem vai para que campo de destino, que conceitos de origem (um atributo personalizado, uma etiqueta, um tipo de bundle) não têm um equivalente direto no destino e precisam de uma decisão, e que campos são seguros para descartar por completo porque nada mais depende deles.

Documente este mapeamento nalgum sítio durável — uma folha de cálculo ou documento partilhado, não a memória de alguém. Torna-se a referência que toda a gente consulta durante o QA, e é a primeira coisa que vai querer quando algo parecer errado depois do lançamento.

#### 3. Planeie os seus redirecionamentos e a estrutura de URLs cedo

A estrutura de URLs é um dos pontos mais comuns em que uma migração prejudica silenciosamente o SEO e quebra favoritos. Obtenha uma lista completa dos seus URLs atuais — páginas de produto, páginas de categoria, páginas de blog ou conteúdo, e quaisquer landing pages personalizadas — e decida o novo URL de cada um antes de lançar seja o que for. Páginas sem um equivalente limpo na plataforma nova ainda precisam de uma decisão explícita (normalmente um redirecionamento para a categoria correspondente mais próxima ou uma página central relevante), e não de um 404 silencioso.

Este planeamento acontece bem antes da mudança, idealmente em paralelo com o trabalho de mapeamento de dados, já que os dois estão relacionados: a forma como mapeia categorias e produtos determina muitas vezes o aspeto dos URLs novos. Veja o guia dedicado de mapeamento de redirecionamentos ligado abaixo para o processo completo.

#### 4. Construa um ambiente de staging e faça QA a sério

Nunca trate a primeira importação como a importação final. Carregue os seus dados mapeados numa instância de staging ou teste da plataforma de destino e use mesmo a loja: navegue por categorias, veja páginas de produto, verifique a seleção de variantes e os preços, teste o carrinho e o fluxo de checkout, e confirme que as contas de cliente e o histórico de encomendas aparecem corretamente. Envolva alguém fora da equipa de migração — um olhar fresco apanha coisas que quem construiu o mapeamento deixa de notar.

Trate esta fase como iterativa. É normal encontrar problemas de mapeamento na primeira passagem; o objetivo é apanhá-los e corrigi-los aqui, em staging, onde um erro custa uma reimportação, e não um período de tempo de inatividade ao vivo ou um erro visível para o cliente.

#### 5. Planeie a janela de mudança como uma operação, não como carregar num interruptor

Decida, por escrito, o que acontece durante a mudança: como as encomendas novas na plataforma antiga são tratadas se a migração demorar (uma pausa temporária de encomendas, uma página de manutenção, ou funcionamento contínuo até um ponto final de sincronização definido), quem faz a sincronização final de dados, quem verifica o DNS e o SSL na plataforma nova, e quem tem autoridade para reverter ou pausar se algo parecer errado.

Dê à equipa uma checklist partilhada para o próprio dia, não apenas um plano na cabeça de alguém. Uma mudança apressada ou ambígua é onde migrações por outro lado bem preparadas perdem dados — algumas encomendas feitas no intervalo entre a sincronização final e a entrada ao vivo, por exemplo — por isso planeie explicitamente para esse intervalo em vez de esperar que não importe.

#### 6. Monitorize depois do lançamento — a migração não termina no go-live

Os dias e semanas depois da mudança são quando os problemas que o staging não apanhou tendem a surgir: um gateway de pagamento mal configurado para tráfego real, uma regra de impostos ou envio que se comportou de forma diferente com encomendas reais, redirecionamentos que funcionam para as páginas que testou mas não para casos limite, ou um pixel de tracking que deixou de disparar silenciosamente. Defina uma rotina de monitorização deliberada em vez de assumir que o silêncio significa sucesso.

A nossa checklist de QA pós-lançamento (ligada abaixo) cobre esta fase em detalhe — verificação de checkout e pagamento, verificações pontuais de redirecionamentos, continuidade da análise e monitorização do Search Console — já que merece o seu próprio processo dedicado, e não uma reflexão apressada depois de a atenção da equipa já ter passado para outro lado.

#### FAQ

Q: Quanto tempo demora um projeto de replatforming?
A: Depende muito do tamanho do catálogo, da complexidade dos dados e de quantas integrações personalizadas estão envolvidas. Um catálogo pequeno e limpo costuma mudar-se mais depressa do que um com dezenas de milhares de SKUs, anos de campos personalizados acumulados e várias apps ligadas. Peça uma estimativa realista depois de uma auditoria à sua loja específica, em vez de confiar num calendário genérico.

Q: Devemos migrar tudo de uma vez, ou por fases?
A: Ambas as abordagens funcionam consoante a loja. Uma mudança única é mais simples de gerir e evita correr duas plataformas em paralelo, mas concentra o risco numa única janela. Uma abordagem faseada (por exemplo, mudar primeiro conteúdo e design, depois o catálogo, depois os dados transacionais) distribui o risco mas exige coordenação mais cuidadosa sobre o que está "ativo" onde em cada fase. A escolha certa depende do tamanho do seu catálogo, da sua tolerância a uma janela de manutenção e de quão interligados estão os seus sistemas.

Q: Qual é a causa mais comum de problemas numa migração?
A: Saltar ou apressar as fases de auditoria e mapeamento. As equipas que avançam diretamente para mover dados sem primeiro perceber o que realmente têm — produtos duplicados, campos personalizados não documentados, URLs de que ninguém se lembrou — tendem a descobrir esses problemas ao vivo, depois da mudança, em vez de em staging, onde são baratos de corrigir.

Q: Precisamos de congelar a loja antiga durante a migração?
A: Não necessariamente durante todo o projeto, mas precisa de um plano claro para a janela final de mudança — normalmente uma pausa curta ou um ponto de sincronização final definido — para que não se percam encomendas nem alterações de clientes entre a última recolha de dados e a entrada ao vivo da loja nova. A duração dessa janela depende do seu volume de encomendas e de como a sincronização final é tratada.

Sources:
- Google Search Central: Site moves with URL changes: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### Mapeamento de Redirecionamentos Seguro para SEO em Migrações de Ecommerce

URL: https://prevedshop.com/pt/guias/mapeamento-de-redirecionamentos-sem-perder-seo
Language: pt
Last reviewed: 2026-07-21

O posicionamento nas pesquisas e o tráfego orgânico estão entre as coisas mais valiosas que uma loja estabelecida tem, e são também das mais fáceis de danificar numa migração descuidada. A boa notícia é que a continuidade de URLs é um problema mecânico e solucionável: construa um mapa de redirecionamentos adequado, implemente-o corretamente e monitorize como os motores de busca reagem. Este guia percorre esse processo de ponta a ponta, independentemente das plataformas envolvidas.

#### Construa primeiro um inventário completo de URLs

Antes de conseguir mapear seja o que for, precisa de uma lista completa dos URLs atualmente em uso — não só os de que se lembra, mas todas as páginas de produto, páginas de categoria e coleção, páginas de blog ou conteúdo, e quaisquer landing pages personalizadas que existam no site atual. Recolha isto a partir do seu sitemap, dos relatórios de páginas da sua ferramenta de análise, e de um rastreio ao site ao vivo, e cruze as três fontes entre si, já que cada uma costuma apanhar algo que as outras deixam escapar.

Preste especial atenção a URLs que recebem tráfego orgânico ou têm ligações externas recebidas, mesmo que sejam páginas que de outra forma consideraria menores. Um artigo de blog com pouco tráfego mas com algumas boas ligações recebidas vale a pena mapear corretamente; perdê-lo silenciosamente é uma perda pequena mas evitável.

#### Mapeie cada URL para o seu equivalente novo — e decida as exceções deliberadamente

Para cada URL no seu inventário, decida o destino na nova plataforma. A maioria das páginas de produto e categoria terá um equivalente razoavelmente direto depois de o seu mapeamento de dados estar definido. Páginas sem um equivalente limpo (um produto descontinuado, uma landing page pontual, uma categoria que já não existe) ainda precisam de uma decisão explícita — normalmente um redirecionamento para a categoria correspondente mais próxima, uma página central relevante, ou em casos raros um 404 deliberado e aceite — em vez de ficarem, por defeito, a redirecionar para a página inicial ou a dar 404 por acidente.

Uma abordagem genérica de "redirecionar tudo para a página inicial" é um atalho comum que na verdade prejudica — dilui os sinais de relevância e dá aos utilizadores uma experiência pior do que chegar à página relevante mais próxima.

#### Implemente redirecionamentos 301, e verifique cadeias e ciclos

Use redirecionamentos permanentes (301) para URLs que se mudaram genuinamente para sempre — é esse o sinal que diz aos motores de busca para transferirem os sinais de posicionamento para o URL novo. Depois de os seus redirecionamentos estarem ativos, verifique ativamente cadeias de redirecionamento (URL A → B → C, quando A → C bastaria) e ciclos (A → B → A), já que ambos são subprodutos comuns de edições iterativas ao mapa de redirecionamentos e ambos desperdiçam orçamento de rastreio e acrescentam latência. O objetivo é um redirecionamento de um único salto, de cada URL antigo diretamente para o seu destino novo final.

Teste manualmente uma amostra representativa de redirecionamentos depois do lançamento — verifique pontualmente páginas de alto tráfego, algumas de baixo tráfego, e algumas das exceções deliberadas — em vez de assumir que o mapa está correto só porque validou numa folha de cálculo.

#### Trate as tags canónicas de forma deliberada

As tags canónicas dizem aos motores de busca qual é a versão de referência de um URL quando conteúdo semelhante está acessível a partir de mais do que um endereço. Depois de uma migração, certifique-se de que a tag canónica de cada página aponta para o seu próprio URL novo, ativo e correto — e não para um URL antigo esquecido, nem para o URL de outra página por engano, resultante de um template copiado e colado. Errar nisto pode confundir os motores de busca sobre qual versão de uma página indexar, mesmo que os próprios redirecionamentos estejam corretos.

Se a nova plataforma gerar tags canónicas automaticamente, verifique o seu comportamento por defeito em vez de assumir que está correto para a sua configuração — a canonicalização automática por vezes aponta para URLs inesperados em páginas com parâmetros ou paginadas.

#### Volte a submeter o sitemap XML e atualize as ligações internas

Assim que o site novo estiver ativo com os redirecionamentos a funcionar, gere e submeta um sitemap XML atualizado que reflita a nova estrutura de URLs através do Google Search Central e das ferramentas de webmaster de outros motores de busca, para que os robôs consigam descobrir as páginas novas de forma eficiente, em vez de depender apenas de seguir redirecionamentos a partir dos URLs antigos.

Ao mesmo tempo, atualize as ligações internas em todo o site — navegação, rodapé, ligações a produtos relacionados, conteúdo de blog — para apontarem diretamente aos URLs novos em vez de passarem por um redirecionamento. As ligações internas que ainda apontam para URLs antigos acrescentam saltos de redirecionamento desnecessários a cada clique e são fáceis de esquecer, já que não quebram nada visivelmente; apenas funcionam de forma menos eficiente.

#### Monitorize o estado de rastreio e indexação depois da mudança

O trabalho de SEO da migração não termina no lançamento. Nas semanas seguintes à mudança, observe o Search Console (ou a ferramenta equivalente noutros motores de busca) à procura de erros de rastreio, um pico repentino de 404s, páginas que não estão a ser indexadas, ou uma queda em impressões/cliques para páginas que deveriam estar a ter um desempenho normal. Compare isto com a sua referência pré-migração para apanhar regressões reais, e não flutuação normal de curto prazo.

Seja paciente mas não passivo: alguma reindexação demora tempo mesmo quando tudo está bem configurado, mas um erro de redirecionamento ou de tag canónica que passe despercebido durante semanas é muito mais caro de corrigir do que um apanhado nos primeiros dias depois do lançamento.

#### FAQ

Q: Uma migração vai definitivamente prejudicar o meu posicionamento nas pesquisas?
A: Não, se a continuidade de URLs for tratada corretamente — um mapa de redirecionamentos completo, tags canónicas corretas e um sitemap reenviado são as defesas essenciais. Ninguém consegue garantir que posições específicas se mantenham, já que o posicionamento depende de muitos fatores além de qualquer migração isolada, mas um mapeamento de URLs adequado é o maior fator controlável para preservar o que já tinha.

Q: Devo usar redirecionamentos 301 ou 302?
A: Use redirecionamentos 301 (permanentes) para URLs que se mudaram para sempre, que é o caso normal numa migração de plataforma. Os redirecionamentos 302 (temporários) sinalizam que a mudança não é permanente e os motores de busca podem não transferir os sinais de posicionamento da mesma forma, por isso são a escolha errada para o mapa de redirecionamentos de uma migração concluída.

Q: E se dois URLs antigos deverem apontar para a mesma página nova?
A: Isso é normal e comum — por exemplo, dois URLs de categoria antigos que foram fundidos num só na plataforma nova. Redirecione ambos os URLs antigos diretamente para o único URL novo. O que quer evitar é o inverso: um URL antigo ambíguo quanto à página nova para a qual deve mapear, o que normalmente significa que a decisão de mapeamento ainda não foi realmente tomada.

Q: Durante quanto tempo devo manter os redirecionamentos antigos ativos?
A: Indefinidamente, se for praticável. Ligações recebidas, favoritos e resultados de pesquisa antigos que referenciem os URLs anteriores podem persistir muito tempo depois de uma migração, e há pouco custo em manter uma regra de redirecionamento ativa. Remover redirecionamentos cedo demais é uma forma comum de transformar o que devia ser um custo único de migração numa fonte recorrente de ligações quebradas.

Sources:
- Google Search Central: 301 redirects: https://developers.google.com/search/docs/crawling-indexing/301-redirects
- Google Search Central: Consolidate duplicate URLs (canonicalization): https://developers.google.com/search/docs/crawling-indexing/canonicalization
- Google Search Central: Build and submit a sitemap: https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap

### Shopify vs WooCommerce: para qual deve migrar?

URL: https://prevedshop.com/pt/guias/shopify-vs-woocommerce
Language: pt
Last reviewed: 2026-09-02

A Shopify e o WooCommerce são as duas plataformas para e de onde mais migramos, e a escolha entre elas raramente é uma questão de funcionalidades. A Shopify é um sistema alojado de modelo fixo que elimina o trabalho operacional; o WooCommerce é um plugin aberto sobre WordPress que lhe dá a base de dados e a responsabilidade. Esta comparação olha para as diferenças que realmente mudam uma migração: modelo de dados, propriedade, estrutura de custos, gestão de conteúdo e SEO, e descreve depois que lojas tendem a ficar mais satisfeitas de cada lado.

#### Modelo de dados: fixo versus aberto

Os produtos Shopify têm um esquema fixo com até três dimensões de opções e metafields para tudo o resto; as coleções são listas manuais ou por regras, não uma árvore de taxonomia. Os produtos WooCommerce são artigos WordPress com atributos ilimitados, campos personalizados e taxonomias aninhadas. Migrar para a Shopify é, por isso, um exercício de consolidação - decidir onde vive cada campo personalizado - enquanto migrar para o WooCommerce é sobretudo mapear um modelo pequeno e arrumado num maior. Lojas com catálogos muito estruturados migram normalmente com mais facilidade para a Shopify; lojas com dados invulgares perdem menos ao ir para o WooCommerce.

#### Propriedade, alojamento e custo

A Shopify cobra um plano mais comissões por transação em gateways externos e subscrições de apps; em troca não há servidor, nem correções, nem âmbito PCI do seu lado. O WooCommerce não tem licença, mas paga alojamento WordPress gerido, licenças de plugins e o tempo de programação que mantém as atualizações seguras. A três anos os totais estão muitas vezes mais próximos do que cada lado afirma. A diferença real é onde está o risco: na Shopify a plataforma pode mudar regras e preços; no WooCommerce um conjunto de plugins negligenciado pode partir a loja.

#### Conteúdo e SEO

O WordPress é um CMS completo, por isso lojas WooCommerce com blogs grandes, landing pages e templates à medida mantêm tudo num só lugar. As páginas e o blog da Shopify são mais simples, e lojas ricas em conteúdo acabam muitas vezes por usar WordPress para conteúdo ao lado da Shopify para comércio. Em SEO as plataformas são equivalentes quando bem configuradas; o que importa numa migração é a mudança de URL. A Shopify impõe os caminhos `/products/` e `/collections/`, as ligações permanentes do WordPress são livres, por isso toda a migração entre ambas precisa de um mapa completo de redirecionamentos 301. Os redirecionamentos reduzem o risco; as posições nunca são garantidas.

#### Que lojas se ajustam a cada plataforma

A Shopify tende a servir lojas que querem operações previsíveis, vendem em vários países através de Markets, usam logística padrão e têm um catálogo que cabe em três dimensões de opções. O WooCommerce tende a servir lojas que precisam de lógica de checkout à medida, preços B2B, estruturas de produto invulgares, integração profunda de conteúdo ou residência de dados rigorosa. Se nenhuma descrição é claramente a sua, uma descoberta curta com amostras reais de produtos e encomendas responde mais depressa do que qualquer tabela comparativa.

#### FAQ

Q: A Shopify é melhor do que o WooCommerce para SEO?
A: Nenhuma plataforma tem vantagem inerente. A visibilidade após uma migração depende do mapa de redirecionamentos, da paridade de conteúdo e da velocidade das páginas, não do nome da plataforma.

Q: Qual é mais barato, Shopify ou WooCommerce?
A: Depende da escala e da personalização. A Shopify tem taxas previsíveis mais apps e comissões; o WooCommerce tem alojamento, licenças de plugins e tempo de programação. Compare totais a três anos incluindo a migração.

Q: Posso passar da Shopify para o WooCommerce e não só ao contrário?
A: Sim. Migramos em ambas as direções; a rota Shopify para WooCommerce está documentada à parte e envolve sobretudo mapear metafields e reconstruir coleções inteligentes.

Q: A escolha afeta a duração da migração?
A: Em parte. Migrar para a Shopify demora mais em catálogos com muitos campos personalizados, porque cada um exige uma decisão de metafield; migrar para o WooCommerce demora mais quando muitas apps têm de ser substituídas por plugins.

Sources:
- Shopify Help Center - Migrar para a Shopify: https://help.shopify.com/en/manual/migrating-to-shopify
- WooCommerce - Importador e exportador de produtos CSV: https://woocommerce.com/document/product-csv-importer-exporter/

### Glossary

### Redirecionamento 301

URL: https://prevedshop.com/pt/glossario/redirecionamento-301
Language: pt
Last reviewed: 2026-07-21

Um redirecionamento 301 diz aos browsers e aos motores de busca que uma página se mudou de forma permanente para um novo URL, e envia quem quer que peça o endereço antigo — pessoa ou robô de indexação — diretamente para o novo. O "301" é o código de estado HTTP devolvido pelo servidor: é a forma padrão e permanente de dizer "este conteúdo passou a viver aqui", ao contrário de um redirecionamento temporário (302).

#### O que um redirecionamento 301 faz na prática

Quando alguém pede um URL antigo, o servidor responde com um código de estado HTTP 301 e uma nova localização. O browser segue automaticamente, pelo que um visitante raramente sequer o nota — chega à página nova, não a um erro. Os motores de busca seguem o mesmo sinal: um 301 diz-lhes para transferirem, ao longo do tempo, o valor de posicionamento do URL antigo para o novo, em vez de tratarem a página nova como conteúdo novo e sem relação.

Isto é diferente de um redirecionamento 302 (temporário), que diz aos robôs que a mudança não é permanente e que o valor de pesquisa não deve ser totalmente transferido. Também é diferente de uma simples atualização de ligações no seu próprio site — um 301 apanha toda a gente que ainda tenha o URL antigo nos favoritos, ligado a partir de outro site ou indexado nos resultados de pesquisa, e não apenas quem clica em ligações que você controla.

#### Porque os redirecionamentos 301 importam numa migração de plataforma

Mudar para uma nova plataforma quase sempre altera a estrutura de URLs, mesmo quando se tenta mantê-la próxima — URLs de produtos, caminhos de categorias e artigos de blog acabam frequentemente com um formato diferente do anterior. Cada URL antigo que os motores de busca já indexaram, e para o qual outros sites têm ligações, precisa de um 301 a apontar para o seu equivalente novo, ou perde-se o sinal de posicionamento acumulado dessa página e envia-se os visitantes para um beco sem saída.

O risco não é hipotético: lançar uma loja nova sem um plano de redirecionamentos costuma resultar em erros 404 a acumularem-se, ligações recebidas quebradas e uma queda no tráfego orgânico dias após o lançamento, já que os motores de busca voltam a visitar URLs indexados rapidamente. Um plano de redirecionamentos construído antes do lançamento, e não remendado depois de o tráfego cair, é o que evita que isso aconteça.

#### Fazer os redirecionamentos corretamente, não só tê-los

Ter um 301 não basta por si só — tem de apontar para o alvo certo. Redirecionar todos os URLs antigos para a nova página inicial tecnicamente "resolve" a ligação, mas deita fora a relevância específica que um motor de busca ou visitante esperava. Mapeamos os URLs antigos para o equivalente real mais próximo na nova plataforma, e sinalizamos páginas sem correspondência limpa em vez de adivinhar.

Também verificamos cadeias de redirecionamento (URL A para B para C) e ciclos, que acrescentam latência e podem levar os robôs a deixar de seguir a cadeia por completo. Uma migração limpa termina com um único salto por URL, não três.

#### FAQ

Q: Um redirecionamento 301 é o mesmo que mudar um URL?
A: Não — mudar um URL sem redirecionamento limita-se a quebrar a ligação antiga. Um redirecionamento 301 é a instrução que liga o URL antigo ao novo, para que quem (ou o que) pedir o endereço antigo seja enviado automaticamente para a página nova.

Q: Os redirecionamentos 301 preservam totalmente o meu posicionamento nas pesquisas?
A: Preservam a maior parte do sinal de posicionamento associado ao URL antigo, mas não automaticamente todas as posições para todas as palavras-chave — outros fatores, como a qualidade do site e a concorrência, continuam a aplicar-se. O que um 301 garante de forma fiável é dizer aos motores de busca que o conteúdo se mudou, em vez de os deixar tratar o URL novo como algo sem relação.

Q: Durante quanto tempo preciso de manter os redirecionamentos ativos?
A: Indefinidamente, ou o mais próximo disso que for prático. Ligações antigas de outros sites, favoritos guardados e materiais impressos podem continuar a enviar tráfego para URLs antigos durante anos, e os motores de busca podem demorar a processar totalmente um lote grande de redirecionamentos.

Q: Qual é a diferença entre um redirecionamento 301 e um 302?
A: Um 301 sinaliza uma mudança permanente e transfere o sinal de posicionamento para o novo URL; um 302 sinaliza uma mudança temporária, e os motores de busca são mais cautelosos a transferir esse sinal. Numa migração de plataforma, em que o URL antigo não vai voltar, um 301 é quase sempre a escolha correta.

Sources:
- Google Search Central: Redirects and Google Search: https://developers.google.com/search/docs/crawling-indexing/301-redirects

### Tag Canónica

URL: https://prevedshop.com/pt/glossario/tag-canonical
Language: pt
Last reviewed: 2026-07-21

Uma tag canónica (`<link rel="canonical">`) é uma tag HTML que diz aos motores de busca qual é a versão de referência de uma página quando o mesmo conteúdo, ou um muito semelhante, está acessível a partir de mais do que um endereço. Não redireciona visitantes para lado nenhum — é um sinal para os robôs de indexação sobre qual URL deve receber o crédito e aparecer nos resultados de pesquisa.

#### O que uma tag canónica faz na prática

As plataformas de ecommerce servem frequentemente o mesmo produto ou categoria através de vários URLs — com e sem barra final, com parâmetros de ordenação ou filtros diferentes, ou acessíveis a partir de mais do que um caminho de categoria. Sem uma tag canónica, os motores de busca têm de adivinhar qual versão indexar, o que pode dividir o sinal de posicionamento entre URLs quase duplicados em vez de o consolidar num só.

A tag canónica fica no `<head>` da página e aponta para o URL único que deve ser tratado como a cópia principal. Cada variante duplicada ou quase duplicada leva uma tag canónica a apontar de volta para esse URL; o URL principal costuma ter uma tag canónica a apontar para si mesmo.

#### Porque importa numa migração de plataforma

As plataformas novas introduzem frequentemente os seus próprios padrões de URL para filtros, paginação ou ordenação que não existiam na plataforma antiga, e é fácil acabar com conteúdo duplicado não intencional se as tags canónicas não forem configuradas corretamente desde o primeiro dia. Errar nisto normalmente não causa uma queda dramática como um redirecionamento em falta, mas dilui silenciosamente o sinal de posicionamento entre páginas quase duplicadas em vez de o consolidar — um problema mais lento e mais difícil de diagnosticar.

As migrações são também um ponto natural para corrigir problemas de canonicalização já existentes na plataforma antiga, em vez de os transportar sem alterações.

#### Tags canónicas vs. redirecionamentos

Uma tag canónica e um redirecionamento resolvem problemas diferentes. Um redirecionamento (ver redirecionamento 301) serve para um URL que deixou de existir por completo — envia visitantes e robôs para o novo endereço. Uma tag canónica serve para URLs que continuam a existir e continuam acessíveis, mas que não devem competir entre si nos resultados de pesquisa — ambos ficam ativos, apenas um é marcado como a versão de referência.

#### FAQ

Q: Uma tag canónica redireciona os visitantes para o URL principal?
A: Não. Os visitantes podem continuar a chegar ao URL não canónico e este carrega normalmente — a tag canónica limita-se a indicar aos motores de busca qual versão indexar e posicionar, não altera o que o browser faz.

Q: Preciso de tags canónicas se não tiver conteúdo duplicado?
A: Continua a ser boa prática cada página ter uma tag canónica autorreferente (a apontar para si mesma), o que elimina ambiguidade caso surja mais tarde uma duplicação — por exemplo, através de um parâmetro de rastreio ou de um novo URL de filtro.

Q: Uma tag canónica pode apontar para uma página noutro domínio?
A: Sim, tags canónicas entre domínios são válidas e por vezes usadas deliberadamente, mas numa migração de plataforma normalmente não é isso que se quer — cada URL novo deve, em regra, ser canónico de si mesmo, com redirecionamentos (e não tags canónicas) a tratar do domínio ou dos URLs antigos.

Q: O que acontece se as minhas tags canónicas apontarem para o URL errado?
A: Os motores de busca podem acabar por indexar e posicionar a versão errada de uma página, ou ignorar por completo o seu sinal canónico se este parecer inconsistente com outros sinais (como as ligações internas ou o sitemap). Verificamos as tags canónicas como parte do controlo de qualidade da migração, em vez de assumir que a nova plataforma as define corretamente por defeito.

Sources:
- Google Search Central: Consolidate duplicate URLs: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

### Migração de Dados

URL: https://prevedshop.com/pt/glossario/migracao-de-dados
Language: pt
Last reviewed: 2026-07-21

Migração de dados é o processo de transferir a informação da sua loja — produtos, clientes, encomendas, conteúdo e tudo o que lhes está ligado — de uma plataforma para outra, numa forma que a nova plataforma consiga efetivamente usar corretamente. É o trabalho técnico central de uma mudança de plataforma, distinto do design, do planeamento de redirecionamentos ou do trabalho de integrações que o rodeia, ainda que todos esses aspetos dependam de a migração de dados ser rigorosa.

#### O que é efetivamente migrado

Para além do óbvio catálogo de produtos, uma migração de dados completa costuma cobrir as contas de clientes e o seu histórico de encomendas, encomendas existentes (ativas e históricas), conteúdo como artigos de blog ou páginas estáticas, avaliações se estiverem guardadas na própria plataforma, e quaisquer campos personalizados ou metadados específicos do seu negócio. Nem tudo tem necessariamente de se mudar — alguns dados históricos podem ser arquivados em vez de migrados ativamente, o que é uma decisão de âmbito tomada durante a avaliação, e não algo assumido por defeito.

#### Porque uma simples exportação/importação não chega

Raramente duas plataformas modelam os dados de forma idêntica — a lista plana de produtos de uma plataforma pode corresponder ao sistema hierárquico de categorias e atributos de outra; o registo simples de um cliente numa plataforma pode precisar de ser dividido por vários tipos de objeto na plataforma nova. Uma cópia literal, campo a campo, a partir de um ficheiro de exportação produz muitas vezes dados que estão tecnicamente presentes mas estruturalmente errados — relações de variantes quebradas, campos personalizados perdidos ou registos de clientes que não se ligam corretamente ao seu histórico de encomendas. Uma migração de dados a sério significa mapear cada tipo de dado de forma deliberada, e não apenas mover ficheiros.

#### Como abordamos o processo

Começamos com uma auditoria de dados — perceber o que realmente existe no sistema antigo, incluindo inconsistências acumuladas ao longo do tempo (clientes duplicados, registos órfãos, categorização inconsistente) — antes de decidir como isso se mapeia na nova plataforma. A limpeza acontece muitas vezes como parte desta etapa e não depois, já que migrar dados maus de forma fiel apenas reproduz os mesmos problemas na plataforma nova. Veja Limpeza e Mapeamento de Dados para perceber como isto se encaixa numa migração gerida.

#### FAQ

Q: A migração de dados inclui o meu histórico de encomendas?
A: Pode incluir — se as encomendas históricas são migradas ativamente para a nova plataforma ou arquivadas em separado é uma decisão de âmbito, já que nem toda a plataforma ou negócio precisa de histórico de encomendas ativo no novo sistema. Discutimos isto durante a avaliação.

Q: Os meus campos personalizados transferem-se automaticamente?
A: Não automaticamente — os campos personalizados precisam de um equivalente explícito na plataforma nova (muitas vezes metafields ou atributos personalizados), e esse mapeamento tem de ser definido, e não assumido como existente por defeito.

Q: Posso migrar os dados eu próprio usando uma app ou ferramenta de importação?
A: Para catálogos pequenos e simples, isso pode funcionar. Para lojas com personalização significativa, histórico de encomendas ou problemas de qualidade de dados, uma ferramenta de importação genérica normalmente não consegue tomar as decisões que uma auditoria de dados e um processo de mapeamento adequados exigem — limita-se a mover o que está no ficheiro, erros incluídos.

Q: Como evitam a perda de dados durante a migração?
A: Auditando e mapeando antes de mover seja o que for, testando a migração num ambiente de staging primeiro, e verificando a contagem de registos e fazendo verificações pontuais aos dados depois da mudança, em vez de assumir que a importação correu bem.

### Comércio Headless

URL: https://prevedshop.com/pt/glossario/headless-commerce
Language: pt
Last reviewed: 2026-07-21

Comércio headless é uma arquitetura em que a loja online (o que os clientes veem e com que interagem) é construída em separado do back-end de comércio (catálogo de produtos, carrinho, checkout, gestão de encomendas), e os dois comunicam através de uma API em vez de serem um único sistema fortemente ligado. "Headless" refere-se à loja — a camada de apresentação — estar desacoplada do back-end, que pode depois servir várias "cabeças" diferentes (um site, uma app móvel, um quiosque na loja física) a partir de uma única fonte de verdade.

#### Headless vs. plataformas tradicionais (monolíticas)

Uma plataforma de ecommerce tradicional agrupa os templates da loja e o back-end num só bloco — os temas Liquid do Shopify ou os templates WordPress do WooCommerce são exemplos de a loja ser gerada diretamente pela própria plataforma. Numa configuração headless, a loja é uma aplicação separada (muitas vezes construída com uma framework como Next.js ou semelhante), que vai buscar dados à API da plataforma de back-end em vez de a plataforma renderizar as páginas diretamente. Algumas plataformas (Shopify, commercetools, entre várias outras) suportam tanto um modo tradicional como um modo headless.

#### Porque muda uma migração

Migrar para dentro ou para fora de uma configuração headless é um tipo de projeto diferente de migrar entre duas plataformas tradicionais. Mudar uma loja de plataforma tradicional para uma arquitetura headless costuma significar construir uma loja nova de raiz (e não adaptar um tema existente), enquanto a migração do back-end/catálogo segue os mesmos princípios de mapeamento de dados de qualquer outra mudança. Migrar entre dois back-ends headless é muitas vezes mais contido do lado da loja, já que o frontend pode por vezes ser atualizado para apontar para uma nova API em vez de ser reconstruído por completo — mas os dados de catálogo, encomendas e clientes do back-end continuam a precisar do mesmo mapeamento cuidadoso de qualquer migração.

#### Quando o headless é (e não é) a decisão certa

As arquiteturas headless trocam, de forma geral, mais esforço de implementação e engenharia contínua por mais flexibilidade na experiência da loja — interações personalizadas, canais fora do site (apps, quiosques) ou requisitos de desempenho que uma loja baseada em templates não consegue cumprir. Para uma loja sem essa necessidade específica, uma plataforma tradicional costuma ser mais simples de gerir e de migrar. É uma decisão que vale a pena tomar deliberadamente durante a avaliação, e não por defeito para nenhuma das opções.

#### FAQ

Q: O comércio headless é sempre mais rápido do que uma loja tradicional?
A: Não automaticamente — o desempenho depende de como a loja headless é construída, não apenas da escolha de arquitetura. Um frontend headless mal construído pode ser mais lento do que um tema tradicional bem otimizado.

Q: Preciso de programadores dedicados para gerir uma loja headless?
A: Geralmente sim, de forma contínua — uma loja headless não vem com o editor de temas e as opções de personalização via app store que uma plataforma tradicional oferece, pelo que as alterações costumam passar por desenvolvimento à medida em vez de um editor visual.

Q: Posso migrar de uma plataforma tradicional para headless sem perder SEO?
A: Sim, mas exige o mesmo planeamento de redirecionamentos e de estrutura de URLs de qualquer migração, mais atenção específica a como o novo frontend headless renderiza conteúdo para os motores de busca (a renderização no servidor é importante aqui) — não é automático só porque os dados do back-end foram preservados.

Q: Que plataformas suportam comércio headless?
A: Várias plataformas de referência oferecem um modo headless/API-first a par de, ou em vez de, a sua loja tradicional — a escolha certa depende dos seus requisitos específicos de back-end, que ajudamos a avaliar em vez de assumir por defeito a plataforma que está na moda.

### Hreflang

URL: https://prevedshop.com/pt/glossario/hreflang
Language: pt
Last reviewed: 2026-07-21

Hreflang é um atributo HTML (e o cabeçalho HTTP ou entrada de sitemap equivalentes) que diz aos motores de busca para que idioma, e opcionalmente para que país, uma página está escrita, e aponta para a página equivalente noutros idiomas ou regiões. É como um site multilingue diz ao Google "aqui está a versão em espanhol, aqui está a versão em alemão", em vez de deixar os motores de busca a adivinhar.

#### O que o hreflang faz na prática

Uma página com marcação hreflang lista um conjunto de URLs alternativos, cada um identificado com um código de idioma (e opcionalmente uma região, como `es` versus `es-MX`) mais uma entrada especial `x-default` para visitantes que não correspondam a nenhum idioma listado. Os motores de busca usam isto para servir a versão de idioma correta ao pesquisador certo, e para evitar tratar as suas páginas traduzidas como conteúdo duplicado entre si.

Cada página do conjunto tem de referenciar todas as outras páginas do conjunto, incluindo a si mesma — uma fonte comum de erros é uma ligação num único sentido (a página A aponta para a página B, mas B não aponta de volta para A).

#### Porque importa numa migração de plataforma

Se a sua loja opera em vários idiomas, uma migração é exatamente o momento em que o hreflang tende a quebrar-se — as estruturas de URL mudam por idioma, e é fácil o mecanismo de troca de idioma da nova plataforma não configurar automaticamente conjuntos de hreflang corretos para todas as rotas, especialmente as que ainda não têm uma tradução ativa. Uma configuração de hreflang incompleta ou inconsistente pode fazer com que a versão de idioma errada seja posicionada no país errado, ou diluir o sinal de posicionamento entre páginas localizadas quase duplicadas.

O hreflang deve ser verificado em todos os padrões de URL da nova arquitetura de informação, não só na página inicial — páginas de produto, páginas de categoria e quaisquer páginas de conteúdo precisam dele se forem multilingues.

#### Erros comuns

Os problemas mais frequentes são ligações de retorno em falta (A liga para B, B não liga de volta), apontar o hreflang para um URL que devolve um redirecionamento ou um 404 em vez da página ativa, e usar o formato errado de código de idioma/região. Nenhum destes costuma causar uma penalização direta, mas significam que os motores de busca podem simplesmente não respeitar o sinal, anulando o propósito de o ter adicionado.

#### FAQ

Q: O hreflang é o mesmo que um seletor de idioma no meu site?
A: Não — um seletor de idioma é um elemento de interface para visitantes; o hreflang é um sinal para motores de busca, normalmente invisível para os visitantes, que vive no head HTML da página, num cabeçalho HTTP ou no sitemap. Um site pode ter um sem o outro, embora ter ambos seja a prática habitual.

Q: Preciso de uma entrada x-default?
A: É recomendado se tiver uma página de recurso para visitantes cujo idioma/região não corresponda a nenhuma das suas versões específicas — normalmente aponta para a sua página de idioma predefinido.

Q: O hreflang afeta diretamente o meu posicionamento nas pesquisas?
A: Não funciona como um impulso de posicionamento — afeta qual das suas páginas aparece para pesquisadores num determinado idioma/região, e ajuda a evitar que as suas páginas traduzidas sejam tratadas como duplicações indesejadas entre si.

Q: O hreflang pode ser definido no sitemap em vez de na página?
A: Sim, ambos são válidos segundo a documentação dos motores de busca — alguns sites preferem o hreflang baseado em sitemap porque é mais fácil de gerar e validar de forma programática para um grande número de URLs, que é a abordagem que geralmente usamos em sites migrados.

Sources:
- Google Search Central: Tell Google about localized versions of your page: https://developers.google.com/search/docs/specialty/international/localized-versions

### Feed de Produtos

URL: https://prevedshop.com/pt/glossario/feed-de-produtos
Language: pt
Last reviewed: 2026-07-21

Um feed de produtos é uma exportação estruturada do seu catálogo — normalmente em CSV, XML ou JSON — construída para outro sistema ler de forma periódica: um fornecedor a enviar-lhe o seu catálogo, ou a sua loja a enviar o catálogo para um marketplace, um comparador de preços ou uma plataforma de anúncios (como um feed do Google Shopping). Cada feed segue um formato específico esperado pelo sistema recetor: determinados campos, numa determinada estrutura, por vezes com os seus próprios identificadores obrigatórios.

#### Feeds de entrada vs. de saída

Um feed de entrada vem de um fornecedor ou distribuidor para a sua loja — novos níveis de stock, preços e dados de produto que a sua plataforma precisa de importar de forma periódica. Um feed de saída vai no sentido contrário — o catálogo da sua loja formatado para um marketplace, um motor de comparação de compras ou uma plataforma de anúncios consumir. Uma migração costuma tocar em ambos: a sua nova plataforma precisa de continuar a receber os feeds dos fornecedores no formato que já enviam, e precisa de produzir feeds de saída no formato que cada destino espera, que nem sempre é idêntico ao que a plataforma antiga produzia.

#### Porque os feeds se quebram numa migração

Os formatos de feed raramente são um padrão universal — o feed de um fornecedor pode usar nomes de campos, códigos de categoria ou identificadores que a integração da sua plataforma antiga foi construída à medida para interpretar. Mudar para uma nova plataforma significa que essa lógica de leitura tem de ser reconstruída, e não assumida como transportável, mesmo que o próprio ficheiro do feed não mude. O mesmo se aplica ao contrário: um feed de saída de que o seu marketplace ou conta de anúncios depende precisa de continuar a corresponder ao formato exigido por esse canal depois da mudança, ou o canal pode rejeitá-lo ou interpretá-lo mal.

#### O que uma migração gerida verifica

Mapeamos todos os feeds de entrada e saída ativos durante a avaliação — em que formato estão, a que campos correspondem e com que frequência correm — para que nada se quebre silenciosamente depois da mudança. Um feed de fornecedor que deixa de ser interpretado corretamente não costuma devolver um erro; simplesmente deixa de atualizar stock ou preços em silêncio, o que é pior do que uma falha óbvia porque pode passar despercebido durante algum tempo.

#### FAQ

Q: O feed do meu fornecedor vai funcionar automaticamente na nova plataforma?
A: Não automaticamente — a nova plataforma precisa de uma integração construída (ou reutilizada, se existir um conector compatível) para interpretar o formato específico desse feed. Avaliamos cada feed de fornecedor individualmente durante a avaliação, em vez de assumir que uma importação genérica trata do assunto.

Q: O que acontece ao meu feed do Google Shopping ou de marketplace durante uma migração?
A: Precisa de continuar a corresponder ao formato exigido pelo destino depois da mudança. Verificamos os feeds de saída como parte do plano de migração para que um canal não rejeite o seu catálogo nem mostre dados desatualizados depois da mudança.

Q: Um feed de produtos é o mesmo que uma exportação CSV?
A: Uma exportação CSV pode ser um feed de produtos, mas "feed" costuma implicar uma troca recorrente e automatizada, com periodicidade definida, e não uma exportação manual pontual — ainda que o formato de ficheiro subjacente possa ser idêntico.

Q: Dois sistemas podem usar formatos de feed completamente diferentes para os mesmos dados?
A: Sim, isto é comum — os mesmos dados de catálogo podem ser exportados como uma estrutura XML para um marketplace e uma estrutura CSV diferente para outro, ou usar nomes de campos e taxonomias de categoria totalmente distintos, exigindo um mapeamento separado para cada um.

### Replatforming

URL: https://prevedshop.com/pt/glossario/replatforming
Language: pt
Last reviewed: 2026-07-21

Replatforming significa mudar uma loja de ecommerce de uma plataforma para outra — não é um redesign na mesma plataforma, nem uma simples atualização de versão, mas uma verdadeira mudança do sistema subjacente que faz a sua loja funcionar. É o termo guarda-chuva para todo o projeto: migração de dados, planeamento de redirecionamentos, reconstrução de tema/loja e reconexão de integrações são todas peças de um esforço de replatforming.

#### O que conta como replatforming (e o que não conta)

Mudar do Magento para o Shopify é replatforming. Atualizar do Magento 1 para o Magento 2 pode-se argumentar que também é, já que os sistemas subjacentes são suficientemente diferentes para exigir uma verdadeira migração, e não apenas uma atualização. Um redesign de tema na mesma plataforma, ou adicionar uma nova app/plugin, não é replatforming — o sistema subjacente e o seu modelo de dados mantêm-se iguais.

#### Motivos comuns para as lojas fazerem replatforming

O gatilho costuma ser um ou mais destes: a plataforma atual não consegue suportar uma funcionalidade ou escalar conforme o negócio precisa, o custo contínuo de manter uma plataforma auto-alojada (alojamento, correção de segurança, conformidade PCI) deixa de fazer sentido, a plataforma está a chegar ao fim de vida ou a perder o suporte do fornecedor, ou o negócio ultrapassou o que uma loja baseada em templates consegue fazer. Raramente é um único motivo — costuma ser uma acumulação de fricção que acaba por ultrapassar o custo e o risco de mudar.

#### Porque o replatforming é tratado como um projeto, não uma tarefa

A parte mais arriscada do replatforming não é escolher a plataforma nova — é tudo o que tem de se mudar corretamente para que o negócio não perca dados, posicionamento de SEO ou continuidade operacional: o catálogo, os registos de clientes, o histórico de encomendas, a estrutura de URLs e os seus redirecionamentos, os feeds de fornecedores e qualquer lógica personalizada que a plataforma antiga executasse. Tratá-lo como uma única tarefa de importação em vez de um projeto planeado é de onde vem a maior parte do risco real numa migração.

#### FAQ

Q: Quanto tempo costuma demorar um replatforming?
A: Depende muito do tamanho do catálogo, da complexidade dos dados, de quantas integrações existem e de quanta funcionalidade personalizada precisa de ser reconstruída — não há um calendário universal. Damos uma estimativa realista depois de avaliar a loja específica, não um número genérico.

Q: Preciso de fazer replatforming se só quiser um design novo?
A: Não — um redesign na plataforma atual costuma ser mais simples e de menor risco do que um replatforming, e não exige migrar dados nem reconstruir integrações. O replatforming faz sentido quando a própria plataforma, e não só a sua aparência, é a limitação.

Q: Qual é o maior risco num projeto de replatforming?
A: Perder posicionamento de SEO por redirecionamentos mal feitos, e problemas de qualidade de dados (relações de variantes quebradas, registos de clientes perdidos, histórico de encomendas desencontrado) resultantes de uma migração de dados incompleta ou ingénua — ambos são evitáveis com planeamento adequado, e ambos são comuns quando não há esse planeamento.

Q: Posso fazer replatforming sem qualquer tempo de inatividade?
A: O tempo de inatividade pode ser minimizado com um planeamento cuidadoso da mudança (staging, momento da troca de DNS/tráfego, sincronização final de dados), mas prometer zero tempo de inatividade como garantia não é algo que estejamos dispostos a assumir sem conhecer a sua configuração específica — veja a nossa página de Segurança para perceber como tratamos esta conversa com honestidade.

### Mapeamento de SKU

URL: https://prevedshop.com/pt/glossario/mapeamento-de-sku
Language: pt
Last reviewed: 2026-07-21

O mapeamento de SKU é o processo de fazer corresponder cada identificador de produto (SKU — stock keeping unit) do sistema antigo ao seu equivalente correto no novo, para que encomendas, inventário e feeds de fornecedores continuem a referir-se ao mesmo produto físico antes e depois de uma migração. Soa mecânico, mas é um dos pontos onde uma migração mais frequentemente falha quando é automatizada às cegas em vez de revista.

#### Porque os SKUs nem sempre se transferem de forma limpa

Numa migração ideal, cada SKU da plataforma antiga corresponde 1:1 ao mesmo SKU na nova e nada muda. Na prática, as plataformas têm frequentemente regras diferentes sobre o que um SKU pode conter, tratamento diferente de SKUs ao nível da variante versus ao nível do produto, ou um histórico de SKUs duplicados/reutilizados no sistema antigo que precisa de ser resolvido em vez de simplesmente copiado tal como está. Uma exportação direta da base de dados pode transportar estas inconsistências em vez de as corrigir.

#### Onde o mapeamento de SKU se liga a outros sistemas

O seu SKU é muitas vezes a chave de ligação entre a sua loja e tudo à sua volta — feeds de fornecedores, um sistema de armazém ou logística, software de contabilidade, listagens em marketplaces. Se um SKU mudar de formato ou de valor durante uma migração sem atualizar todos os sistemas ligados, essas integrações começam a falhar na correspondência de produtos mesmo que a loja em si pareça correta. O mapeamento tem de ser feito com esses sistemas a jusante em mente, e não apenas dentro da nova plataforma.

#### O que verificamos antes de migrar SKUs

Auditamos o conjunto de SKUs existente à procura de duplicados, formatação inconsistente e SKUs órfãos (referenciados por uma encomenda ou feed mas sem produto ativo correspondente) antes de decidir se os preservamos tal como estão ou se os normalizamos na nova plataforma. Preservar os SKUs existentes costuma ser preferível quando sistemas a jusante dependem deles; normalizar faz sentido quando o próprio esquema antigo de SKUs era o problema.

#### FAQ

Q: Devo manter exatamente os mesmos SKUs na nova plataforma?
A: Geralmente sim, se algum feed de fornecedor, sistema de logística ou listagem em marketplace depender deles — mudar os SKUs quebra essas integrações a menos que sejam atualizadas ao mesmo tempo. Avaliamos isto caso a caso, em vez de assumir uma resposta por defeito.

Q: O que acontece aos SKUs duplicados durante uma migração?
A: Precisam de ser resolvidos antes ou durante a migração, e não transportados — a maioria das plataformas não permite SKUs verdadeiramente duplicados, e deixar uma importação automatizada adivinhar como os deduplicar arrisca fundir ou eliminar o produto errado.

Q: O mapeamento de SKU afeta o meu histórico de encomendas?
A: Pode afetar, se as encomendas históricas referenciarem SKUs que mudam — tomamos isso em conta para que os registos de encomendas antigas continuem a resolver-se corretamente para o produto certo depois da mudança, em vez de mapearmos apenas o catálogo ativo.

Q: O mapeamento de SKU é automático ou manual?
A: É uma mistura — correspondências 1:1 diretas podem ser automatizadas e verificadas rapidamente, mas os casos ambíguos (duplicados, formatos inconsistentes, SKUs em falta) precisam de uma decisão humana, e não de um algoritmo de melhor palpite.

### Dados Estruturados

URL: https://prevedshop.com/pt/glossario/dados-estruturados
Language: pt
Last reviewed: 2026-07-21

Dados estruturados são marcação adicionada a uma página (mais frequentemente seguindo o vocabulário schema.org, em formato JSON-LD) que descreve o seu conteúdo de forma legível por máquina — marcar uma página como um Product com preço e disponibilidade, ou uma Organization com nome e URL, em vez de deixar os motores de busca a inferir isso a partir do texto visível. É o que permite aos resultados de pesquisa mostrar funcionalidades avançadas como classificações por estrelas, preço ou perguntas frequentes diretamente nos resultados.

#### O que os dados estruturados realmente permitem

Os motores de busca costumam conseguir compreender razoavelmente bem o conteúdo comum de uma página, mas os dados estruturados removem a ambiguidade e desbloqueiam funcionalidades de apresentação específicas — resultados avançados de produto com preço/disponibilidade/classificação, secções de perguntas frequentes mostradas diretamente nos resultados de pesquisa, trilhos de navegação (breadcrumbs) no excerto do resultado, entre outros. Nada disto está garantido (os motores de busca decidem quando usar), mas sem a marcação, essas funcionalidades geralmente não estão disponíveis de todo.

#### Porque precisa de atenção numa migração

Nem todas as plataformas geram dados estruturados automaticamente, e as que geram não o fazem de forma idêntica — a marcação de produto, de perguntas frequentes e de breadcrumbs precisa cada uma de refletir o que está genuinamente na página. Uma migração é um ponto comum em que os dados estruturados ou são perdidos por completo (o novo tema/template não os inclui) ou se tornam incorretos (marcação que já não corresponde ao conteúdo visível da página, algo que os motores de busca podem penalizar em vez de recompensar).

#### Marcar apenas o que é genuinamente verdadeiro

A regra mais importante com dados estruturados é que devem descrever algo real e visível na página — marcação FAQPage só onde uma secção de perguntas frequentes é efetivamente mostrada, marcação de avaliação/classificação só para avaliações que efetivamente existem, marcação Product com preço e disponibilidade reais. Marcação que não corresponda à página visível vai contra as próprias diretrizes dos motores de busca e pode levar a que os dados estruturados sejam ignorados ou a que a página seja penalizada, e não apenas a que "não ajudem".

#### FAQ

Q: Os dados estruturados garantem resultados avançados na pesquisa?
A: Não — tornam os resultados avançados possíveis, mas os motores de busca decidem de forma independente se os mostram, com base na relevância e nas suas próprias verificações de qualidade. Não há forma de garantir que um resultado avançado específico vá aparecer.

Q: A minha nova plataforma vai adicionar dados estruturados automaticamente?
A: Algumas plataformas geram dados estruturados básicos (como marcação de produto) por defeito; outras precisam de os adicionar explicitamente através de um tema ou app. Verificamos o que a nova plataforma oferece de origem e preenchemos as lacunas em vez de assumir que está tratado.

Q: Adicionar dados estruturados pode prejudicar o meu SEO?
A: Só se for incorreto ou manipulador — marcação que não corresponda ao conteúdo real da página viola as diretrizes dos motores de busca. Dados estruturados precisos que refletem o conteúdo real da página não carregam esse risco.

Q: Qual é o erro mais comum com dados estruturados numa migração?
A: Perdê-los por completo quando o novo tema ou template não transporta o que a plataforma antiga tinha, ou deixar ativa marcação desatualizada que já não corresponde à página redesenhada — ambos são aspetos que verificamos no controlo de qualidade da migração.

Sources:
- Google Search Central: Understand how structured data works: https://developers.google.com/search/docs/appearance/structured-data/sd-policies

### Slug de URL

URL: https://prevedshop.com/pt/glossario/url-slug
Language: pt
Last reviewed: 2026-07-21

Um slug de URL é a parte do endereço de uma página que identifica de forma legível para pessoas — em `prevedshop.com/platforms/shopify`, `shopify` é o slug. Costuma derivar do nome de um produto ou página, tornado minúsculo e seguro para URL, e é o que tanto visitantes como motores de busca realmente veem e referenciam quando ligam a uma página ou a guardam nos favoritos.

#### Porque os slugs importam para além da legibilidade

Um slug claro e descritivo ajuda os visitantes a perceber do que trata uma página antes de clicarem, e os motores de busca dão algum peso a palavras relevantes que apareçam no URL. Mas a maior importância de um slug é estrutural: faz parte do endereço permanente da página, referenciado por cada ligação interna e externa, favorito guardado e resultado de pesquisa indexado que aponte para ela.

#### Porque as migrações mudam frequentemente os slugs, de propósito ou não

Cada plataforma tem as suas próprias regras para como os slugs são gerados e estruturados — limites de comprimento, caracteres permitidos, se os slugs de produto ficam aninhados sob um caminho de categoria ou são planos, como nomes duplicados são desambiguados. Mudar para uma plataforma nova altera frequentemente pelo menos alguns slugs, por vezes porque a nova plataforma impõe um padrão diferente, por vezes porque é uma oportunidade para corrigir slugs antigos e confusos do sistema anterior. De qualquer forma, um slug alterado significa um URL alterado, e um URL alterado precisa de um redirecionamento (ver redirecionamento 301) a partir do endereço antigo.

#### Manter os slugs estáveis onde importa

Para páginas com posicionamento de pesquisa relevante já existente ou muitas ligações recebidas, manter exatamente o mesmo slug na nova plataforma (quando a plataforma o permite) evita por completo a necessidade de um redirecionamento e costuma ser a forma mais simples de preservar a posição dessa página. Onde um slug tiver mesmo de mudar, planear o novo slug e o seu redirecionamento em conjunto — em vez de deixar a plataforma gerar um automaticamente e tratar do URL como uma reflexão tardia — é o que mantém a transição limpa.

#### FAQ

Q: Posso manter exatamente os meus slugs de URL antigos numa plataforma nova?
A: Muitas vezes sim, se as regras de URL da nova plataforma o permitirem e os definir de forma deliberada em vez de aceitar os gerados automaticamente — esta é uma das formas mais simples de evitar por completo a necessidade de um redirecionamento para essa página.

Q: Mudar um slug prejudica o SEO?
A: Não, se for acompanhado de um redirecionamento 301 adequado do slug antigo para o novo — o redirecionamento transporta a maior parte do sinal de posicionamento acumulado. Mudar um slug sem redirecionamento é o que causa dano ao SEO, e não a mudança de slug em si.

Q: Devo usar o nome do meu produto exatamente como slug?
A: Geralmente sim, simplificado para ser seguro para URL (minúsculas, hífenes em vez de espaços, sem caracteres especiais) — slugs cheios de palavras-chave sem relação com o verdadeiro tema da página não trazem benefício extra e lêem-se como spam, tanto para visitantes como para motores de busca.

Q: O que acontece se dois produtos gerarem o mesmo slug?
A: A plataforma precisa de uma regra de desambiguação — normalmente acrescentar um número ou um identificador extra. Verificamos isto durante a migração, já que colisões de slugs duplicados podem, de outra forma, fazer com que a página de um produto sobreponha silenciosamente o URL de outro.

### Services

### Migração e mapeamento de dados de ecommerce

URL: https://prevedshop.com/pt/servicos/limpeza-e-mapeamento-de-dados
Language: pt
Last reviewed: 2026-07-20

Catálogos antigos acumulam produtos duplicados, categorias inconsistentes e campos cujo propósito já ninguém recorda. Limpamos isso e mapeamos o que resta para o modelo de dados real da sua nova plataforma, em vez de copiar a confusão tal como está.

#### O que procuramos

Produtos duplicados ou quase duplicados, categorias órfãs, nomenclatura de atributos inconsistente, campos vazios ou malformados, e campos personalizados antigos que já não correspondem a nada relevante. Sinalizamos o que encontramos e combinamos consigo o que corrigir, unir ou descartar.

#### Mapeamento, não suposições

Cada campo de origem recebe um mapeamento explícito para um campo de destino — ou uma decisão explícita de que não mapeia e precisa de outro lugar (um campo personalizado, uma etiqueta, ou nenhum). Documentamos este mapeamento para que seja auditável, não uma caixa preta.

#### Porque importa antes do lançamento

Limpar e mapear dados antes da migração é muito mais barato do que corrigi-los depois do lançamento, quando clientes e motores de busca já dependem deles. Saltar este passo é uma das razões mais comuns para problemas posteriores numa migração.

#### FAQ

Q: Vão apagar dados sem me perguntar?
A: Não — sinalizamos o que parece ser um problema e combinamos consigo a ação antes de qualquer coisa ser unida ou removida.

Q: Conseguem eliminar duplicados de várias importações antigas?
A: Sim, é um dos pedidos de limpeza mais comuns — lojas antigas que passaram por várias importações de feeds de fornecedores ao longo dos anos costumam ter duplicados reais.

Q: Lidam com campos personalizados sem propósito claro?
A: Investigamos para que um campo era provavelmente usado (com base em padrões de dados e, quando possível, na sua informação) antes de decidir se deve ser mapeado, reaproveitado ou eliminado.

### Mudança de plataforma de ecommerce, da decisão ao lançamento

URL: https://prevedshop.com/pt/servicos/mudanca-de-plataforma-ecommerce
Language: pt
Last reviewed: 2026-09-25

Mudar de plataforma (replatforming) é primeiro uma decisão de negócio e só depois uma migração de dados. Está a substituir o sistema que gere o catálogo, o checkout, as integrações e o tráfego orgânico, normalmente porque o atual ficou caro, limitado ou arriscado. Ajudamos a decidir com base em factos e depois planeamos e conduzimos a mudança para que a nova plataforma arranque com dados, URLs e integrações.

#### Quando compensa mudar de plataforma e quando não

Razões sólidas: a plataforma chegou ao fim de vida ou deixou de receber atualizações de segurança (Magento 1, Shopware 5); alojamento, patches e manutenção de extensões custam mais do que a loja justifica; a plataforma bloqueia algo de que o negócio precisa, como novos mercados, preços B2B, frontend headless ou um checkout moderno; ou a equipa passa o tempo a manter a plataforma em vez de vender.

Razões fracas: um tema desatualizado, uma única funcionalidade que uma app resolveria ou uma demonstração comercial. Um redesign ou uma integração pontual costuma ser mais barato, e nós dizemos-lho.

#### Primeiro requisitos, depois plataforma

Partimos do que a loja faz de facto: estrutura do catálogo e tipos de produto, regras de preço e grupos de clientes, mercados, idiomas e moedas, integrações com ERP, armazém e transportadoras, marketplaces e feeds, conteúdo e SEO, e funcionalidades à medida. Cada requisito é marcado como essencial, substituível ou dispensável, e é com essa lista que comparamos as plataformas candidatas.

#### O que se parte numa mudança de plataforma

O modelo de dados raramente coincide: atributos, variantes, packs e árvores de categorias comportam-se de forma diferente no destino. A estrutura de URLs muda, por isso cada URL relevante precisa de destino e de um redirecionamento 301. Extensões e apps não passam; os seus dados e funções precisam de substituto, reconstrução ou retirada. Integrações com ERP, contabilidade, transportadoras e marketplaces têm de ser religadas e testadas. As palavras-passe dos clientes normalmente não passam para uma plataforma alojada.

#### Custo total, não apenas a licença

Compare o quadro completo a vários anos: subscrição ou licença, alojamento e segurança, comissões de pagamento, apps e extensões, desenvolvimento, a própria migração e o tempo interno de operação. Ajudamos a montar essa comparação a partir dos seus requisitos; não vendemos licenças.

#### Da decisão ao lançamento

Escolhido o destino, a mudança torna-se uma migração gerida: auditoria da origem, mapeamento de dados, migração de teste e aprovação, plano de SEO e redirecionamentos, mudança das integrações, congelamento de conteúdo, migração delta, lançamento e controlo posterior. Lojas grandes migram muitas vezes por fases para verificar cada passo.

#### FAQ

Q: Qual a diferença entre mudança de plataforma e migração?
A: A mudança de plataforma é a decisão e o projeto de levar o negócio para um novo sistema de ecommerce. A migração é a parte que transfere dados, URLs e conteúdo.

Q: Quanto tempo demora uma mudança de plataforma?
A: Depende do catálogo, das integrações, do design e da rapidez das decisões. Damos um calendário após a avaliação.

Q: Shopify, WooCommerce, PrestaShop ou ficar?
A: Depende dos seus requisitos, mercados, integrações e orçamento. Ficar é um resultado legítimo.

Q: É possível mudar de plataforma sem perder SEO?
A: Não é possível garantir posições. O risco diminui com um inventário completo de URLs, redirecionamentos 301, metadados transferidos, links internos atualizados e monitorização após o lançamento.

### Migração de ecommerce gerida: um responsável da auditoria ao lançamento

URL: https://prevedshop.com/pt/servicos/migracao-gerida
Language: pt
Last reviewed: 2026-07-20

Um responsável de migração designado planeia, executa e valida a sua mudança: produtos, variantes, clientes, encomendas, media, conteúdo e o design da sua loja, geridos como um único projeto coordenado, não como exportações soltas.

#### O que está incluído

A Migração Gerida cobre todo o seu catálogo — produtos, variantes, categorias e atributos —, contas de clientes e histórico de encomendas, media e conteúdo, campos personalizados e um plano de URLs/redirecionamentos. O design da loja é transferido ou reconstruído na plataforma de destino como parte do mesmo projeto, não como uma surpresa faturada à parte.

Definimos exatamente o que está incluído durante a avaliação, para não ter de adivinhar o que a "migração" abrange até a fatura chegar.

#### Como funciona a transferência de design

Onde a plataforma de destino consegue reproduzir razoavelmente o seu design atual, reconstruímo-lo lá. Onde as plataformas são demasiado diferentes para uma transferência idêntica, dizemos isso antecipadamente e propomos uma abordagem — adaptar o seu design às limitações da nova plataforma, em vez de fingir que é uma cópia direta.

#### Um responsável, do início ao fim

Um responsável de migração designado responde por todo o projeto — avaliação, mapeamento, migração de teste, validação, lançamento e verificações pós-lançamento. Verificações automatizadas e repetíveis ajudam a rever os dados e a sinalizar inconsistências, enquanto o responsável revê e aprova cada etapa antes de avançar.

#### FAQ

Q: Quanto tempo demora uma migração gerida?
A: Depende do tamanho do catálogo, da complexidade dos dados e de quantos campos personalizados ou integrações estão envolvidos — damos-lhe um calendário realista após a avaliação, não uma estimativa genérica.

Q: E se a minha plataforma atual não tiver uma exportação limpa?
A: Trabalhamos com o que tiver — exportações de base de dados, acesso a API, feeds XML/CSV, ou uma combinação. Origens mais confusas exigem mais tempo de avaliação, que contabilizamos antecipadamente.

Q: Migram aplicações e integrações instaladas?
A: Migramos os dados de que essas aplicações dependem, mas a configuração específica de cada aplicação normalmente tem de ser reconstruída no equivalente da plataforma de destino, se existir. Sinalizamos isto durante a avaliação, não apenas no lançamento.

### Migração de SEO de lojas online e mapa de redirecionamentos 301

URL: https://prevedshop.com/pt/servicos/seo-e-redirecionamentos
Language: pt
Last reviewed: 2026-07-20

As estruturas de URL raramente sobrevivem intactas a uma mudança de plataforma. Mapeamos as URLs antigas para os seus equivalentes novos e configuramos redirecionamentos como parte central e planeada da migração — não como uma correção posterior depois de o posicionamento já ter caído.

#### Mapeamento de URLs, não suposições

Construímos um mapa explícito de cada URL antiga relevante para o seu equivalente novo — páginas de produto, categorias, páginas de blog ou conteúdo, e quaisquer landing pages personalizadas. Páginas sem um equivalente claro recebem uma decisão documentada, não um 404 silencioso.

#### Redirecionamentos e metadados

Os redirecionamentos 301 são implementados na nova plataforma antes do lançamento, e transferimos os metadados (títulos, descrições, tags canónicas) onde continuam genuinamente precisos para a nova URL. Verificamos cadeias e ciclos de redirecionamento em vez de presumir que um mapeamento um-para-um é automaticamente correto.

#### O que podemos e não podemos prometer

Não podemos garantir posições concretas — ninguém honesto pode fazê-lo, já que o posicionamento depende de muitos fatores fora de qualquer migração. O que controlamos, e tratamos como um requisito inegociável, é a continuidade das URLs: que links e favoritos antigos levem à página nova correta, não a um beco sem saída.

#### FAQ

Q: As minhas posições no Google vão sobreviver à migração?
A: O mapeamento correto de URLs e os redirecionamentos são, de longe, o fator mais importante para preservar o posicionamento numa migração, e tratamo-los como um entregável central. Não podemos garantir posições concretas, pois dependem de fatores fora da migração.

Q: O que acontece às páginas que não existem na nova plataforma?
A: Sinalizamo-las durante a fase de mapeamento e combinamos consigo o melhor destino de redirecionamento — normalmente a categoria correspondente mais próxima ou uma página hub relevante, não um redirecionamento genérico para a página inicial.

Q: Atualizam também os links internos, não só os redirecionamentos externos?
A: Quando é viável, sim — os links internos que apontam para padrões de URL antigos são atualizados como parte da migração, já que cadeias de redirecionamento acrescentam latência e diluem o valor do link.

### Integração de feeds de fornecedores

URL: https://prevedshop.com/pt/servicos/integracao-de-feeds-de-fornecedores
Language: pt
Last reviewed: 2026-07-20

Gerir o seu catálogo a partir de feeds de fornecedores implica lidar com formatos inconsistentes, SKUs duplicados entre fornecedores, e um ritmo de atualização que nem sempre corresponde ao que a sua plataforma espera. Ligamos e normalizamos esses feeds para que o seu catálogo se mantenha preciso sem manutenção manual.

#### O que normalizamos

Os feeds de fornecedores raramente partilham um formato — nomes de campos, estruturas de categorias e até unidades de medida variam de fornecedor para fornecedor. Mapeamos cada feed para uma estrutura consistente na sua plataforma, para que os produtos se comportem da mesma forma no seu catálogo independentemente da origem.

#### Duplicados e fusão

Quando vários fornecedores têm o mesmo produto, podemos fundir as fichas, escolher uma fonte preferencial, ou mantê-las separadas — dependendo de como quer gerir preço e stock. Esta decisão é tomada consigo, não é uma predefinição que impomos.

#### Manter os dados atualizados

A frequência de atualização dos feeds depende do que os seus fornecedores realmente fornecem e do que a sua plataforma consegue absorver de forma razoável — combinamos um calendário realista em vez de prometer atualizações em tempo real que um feed de origem não consegue suportar.

#### FAQ

Q: Conseguem combinar feeds de vários fornecedores num único catálogo?
A: Sim — fundir, eliminar duplicados e normalizar vários feeds de fornecedores num catálogo único e consistente é uma parte comum deste serviço.

Q: O que acontece quando um fornecedor deixa de ter um produto?
A: Consoante a sua preferência, podemos marcá-lo como indisponível, ocultá-lo, ou mantê-lo visível com estado de pré-encomenda — configurado uma vez, aplicado automaticamente em futuras atualizações do feed.

Q: Os feeds de fornecedores podem ser traduzidos para outros mercados?
A: Sim, o conteúdo do feed pode ser traduzido, através de tradução automática ou de um mapeamento personalizado que nos forneça, consoante a precisão pretendida.


## Polski (pl)

### Platform profiles

### Migracja do lub z Adobe Commerce (Magento)

URL: https://prevedshop.com/pl/platformy/adobe-commerce-magento
Language: pl
Last reviewed: 2026-07-21

„Magento” obejmuje dziś kilka różnych rzeczy: otwartoźródłową platformę Magento Open Source, płatny wariant Adobe Commerce Cloud oraz przestarzałe instalacje Magento 1, które osiągnęły już koniec wsparcia. To, którą z nich faktycznie wykorzystujesz, znacząco zmienia plan migracji, więc ustalenie dokładnej wersji i edycji to pierwszy krok, niezależnie od tego, czy Magento jest u Ciebie źródłem, czy celem.

#### Magento Open Source, Adobe Commerce oraz Magento 1 kontra 2

Magento Open Source to darmowe, samodzielnie hostowane oprogramowanie e-commerce oparte na PHP; Adobe Commerce (wcześniej Magento Commerce) to płatny wariant z dodatkowymi funkcjami B2B, stagingiem treści i hostingiem w chmurze, działający na infrastrukturze zarządzanej przez Adobe. Magento 1 zakończyło wsparcie lata temu, a sklepy nadal na nim działające migrują zwykle właśnie z tego powodu, niezależnie od jakiejkolwiek decyzji porównawczej dotyczącej platform.

Z uwagi na tę rozpiętość, projekt „migracji z Magento” może oznaczać przeniesienie małego sklepu na Magento 1 na zupełnie inną platformę, przeniesienie z Magento 1 na Magento 2 (nadal Magento, ale przebudowa w ramach głównej wersji) albo przeniesienie się z Adobe Commerce Cloud na coś o innej strukturze kosztów. Ustalamy, który z tych scenariuszy dotyczy Ciebie, zanim cokolwiek wycenimy.

#### Model danych EAV i konfiguracja wielosklepowa

Magento przechowuje dane produktowe w strukturze EAV (encja-atrybut-wartość), która świetnie sprawdza się w wysoce konfigurowalnych katalogach bogatych w atrybuty, ale strukturalnie różni się od prostszych, płaskich tabel produktowych stosowanych na większości innych platform. Produkty konfigurowalne (odpowiednik wariantów w Magento), niestandardowe zestawy atrybutów oraz nawigacja warstwowa oparta na atrybutach wymagają jawnego mapowania przy przenoszeniu na platformę, która nie ma odpowiednika EAV.

Architektura wielosklepowa/wielowitrynowa Magento — prowadzenie kilku witryn sklepowych, walut czy lokalizacji z jednej instalacji — to kolejna rzecz wymagająca starannego mapowania, ponieważ większość platform obsługuje wielosklepowość inaczej: jako oddzielne sklepy, jeden sklep z ustawieniami specyficznymi dla rynku albo bez żadnego natywnego odpowiednika.

#### Rozszerzenia, moduły niestandardowe i deweloperzy Magento

Sklepy na Magento zazwyczaj polegają na rozszerzeniach z marketplace i dedykowanych modułach do wszystkiego, co wykracza poza podstawową funkcjonalność — metod płatności, reguł cenowych B2B czy logiki katalogowej specyficznej dla firmy. Ponieważ Magento to platforma mocno deweloperska, znacząca część tego, co sklep „robi”, często żyje w niestandardowym kodzie PHP, a nie w ustawieniach panelu administracyjnego, więc taką logikę trzeba zidentyfikować i albo odbudować, albo zastąpić — a nie tylko wyeksportować.

Motywy podlegają tej samej zasadzie: motywy Magento są zbudowane na własnym systemie layout XML/bloków, który nie ma bezpośredniego odpowiednika gdzie indziej, więc przeniesienie z Magento zazwyczaj oznacza budowę witryny sklepowej od nowa na nowej platformie.

#### SEO, adresy URL i jak podchodzimy do migracji Magento

Magento zarządza przepisywaniem adresów URL wewnętrznie i obsługuje dość elastyczne struktury URL, ale szczegóły (ścieżki kategorii, przyrostki adresów produktów, adresy URL specyficzne dla widoku sklepu) różnią się znacznie w zależności od konfiguracji danego sklepu. Ta zmienność jest właśnie powodem, dla którego zaczynamy od audytu faktycznych, aktywnych wzorców URL, a nie od założenia domyślnej konfiguracji Magento.

Przy migracji Magento budujemy mapę adresów URL i przekierowań w oparciu o to, co Twój sklep faktycznie robi dzisiaj, obsługujemy warianty URL dla wielu sklepów tam, gdzie ma to zastosowanie, i weryfikujemy, czy metadane oraz tagi kanoniczne przenoszą się poprawnie. Nasza usługa SEO i migracji przekierowań opisuje to bardziej szczegółowo.

#### FAQ

Q: Nadal używam Magento 1. Czy możecie to zmigrować?
A: Tak, migracja z Magento 1 to jeden z częstszych projektów, z jakimi się spotykamy, zwykle wynikający z zakończenia wsparcia, a nie z preferencji platformowej. Traktujemy to jako pełną zmianę platformy, ponieważ Magento 1 i 2 mają różne architektury bazowe.

Q: Co stanie się z moimi niestandardowymi modułami Magento?
A: Ustalamy, co faktycznie robi każdy niestandardowy moduł — na przykład integracja płatności, reguła cenowa czy funkcja katalogowa — i sprawdzamy, czy platforma docelowa ma wbudowany lub rozszerzeniowy odpowiednik, czy potrzebny jest niestandardowy development.

Q: Czy funkcje B2B Adobe Commerce mogą zostać przeniesione na platformę spoza segmentu enterprise?
A: Zależy, o które funkcje chodzi. Konta firmowe, procesy ofertowe i wielopoziomowe ceny B2B nie mają bezpośredniego odpowiednika na każdej platformie, więc oceniamy to indywidualnie na etapie ustalania zakresu, a nie zakładamy odpowiedniości jeden do jednego.

Q: Jak struktura atrybutów EAV wpływa na czas trwania migracji?
A: Katalogi z wieloma niestandardowymi atrybutami i zestawami atrybutów zwykle wymagają więcej czasu na mapowanie niż proste, płaskie katalogi, ponieważ każdy atrybut wymaga jawnej decyzji o tym, gdzie znajdzie się na platformie docelowej.

Sources:
- Adobe Commerce (Magento) – oficjalna strona produktu: https://business.adobe.com/products/magento/magento-commerce.html

### Migracja do lub z BigCommerce

URL: https://prevedshop.com/pl/platformy/bigcommerce
Language: pl
Last reviewed: 2026-07-21

BigCommerce to hostowana platforma SaaS, która pojawia się po obu stronach migracji, którymi się zajmujemy: sprzedawców przenoszących się na nią ze względu na natywną strukturę kategorii i opcje headless, oraz sprzedawców odchodzących z niej, gdy zmieniają się ich potrzeby. Podobnie jak w przypadku innych zamkniętych, opartych na API platform, w migracji BigCommerce najważniejsze jest to, co udostępnia jego API i model danych, a nie tylko liczba przenoszonych produktów. Ta strona opisuje, co naprawdę ma znaczenie, gdy BigCommerce jest jedną ze stron migracji.

#### Czym jest BigCommerce i gdzie się sprawdza

BigCommerce to hostowana platforma e-commerce w modelu SaaS: BigCommerce zarządza hostingiem, poprawkami bezpieczeństwa i dostępnością, a Ty zarządzasz sklepem przez jego panel administracyjny i API, a nie przez serwer, nad którym masz kontrolę. Plany obejmują warianty standardowe skierowane do małych i średnich sprzedawców, aż po Enterprise. Multi-Storefront jest dostępny w kilku planach z różnymi limitami liczby witryn; Enterprise może oferować wyższe limity API, poziomy wsparcia i dodatkowe funkcje B2B. BigCommerce oferuje też podejście headless, pozwalające używać jego backendu i API z niestandardowym frontendem zamiast własnej warstwy motywów.

Witryny sklepowe w standardowej, nie-headless ścieżce są budowane na frameworku motywów Stencil od BigCommerce, z motywami pochodzącymi z BigCommerce Theme Marketplace lub tworzonymi na zamówienie. Jak w przypadku każdej zamkniętej, hostowanej platformy, migracje do lub z BigCommerce działają w ramach jego modelu danych i powierzchni API, a nie jako bezpośrednia kopia bazy danych — więc to, co API udostępnia dla produktów, zamówień i klientów, decyduje o tym, co może zostać przeniesione automatycznie.

#### Produkty, kategorie i model danych

W przeciwieństwie do platform opierających się wyłącznie na kolekcjach opartych na tagach, BigCommerce obsługuje natywne, zagnieżdżone drzewo kategorii obok produktów i ich wariantów. Dzięki temu jest to stosunkowo dobre dopasowanie dla katalogów z wielopoziomową strukturą kategorii, ponieważ nie trzeba spłaszczać hierarchii kategorii do tagów czy inteligentnych kolekcji tak, jak na niektórych innych hostowanych platformach.

Klienci i historia zamówień są przenoszone przez API REST i GraphQL BigCommerce, ale — jak w przypadku każdej migracji platformy — historyczne zamówienia zwykle trafiają jako rekordy referencyjne, a nie w pełni aktywne, edytowalne zamówienia. Niestandardowe dane produktowe zwykle mapowane są na pola niestandardowe BigCommerce, a listy cen (mechanizm BigCommerce do cen specyficznych dla grupy klientów lub waluty) to jedna z pierwszych rzeczy, które sprawdzamy, gdy platforma źródłowa ma własną konfigurację cen wielopoziomowych.

#### Aplikacje, motywy i to, co nie przenosi się automatycznie

Działający sklep na BigCommerce zwykle opiera się na aplikacjach z BigCommerce App Marketplace — do opinii, subskrypcji, wyszukiwania, automatyzacji marketingu czy reguł wysyłki. Dane przechowywane przez aplikacje nie przenoszą się w ramach migracji platformy; przeniesienie z BigCommerce oznacza osobny eksport wszystkiego, co jest przechowywane w aplikacji, a przeniesienie na BigCommerce oznacza ponowną instalację i konfigurację odpowiedników, a nie przeniesienie ustawień aplikacji.

Motywy Stencil nie przekładają się na system szablonów innej platformy, więc przeniesienie z BigCommerce zwykle oznacza odbudowę designu witryny na nowej platformie, a przeniesienie na BigCommerce oznacza dostosowanie motywu z marketplace lub zlecenie dedykowanego developmentu motywu. Jeśli zamiast tego wybierzesz podejście headless, frontend jest całkowicie odseparowany od warstwy motywów BigCommerce, co zmienia zakres tego, co w ogóle oznacza „migracja designu”.

#### SEO, adresy URL i jak podchodzimy do migracji BigCommerce

BigCommerce jest bardziej elastyczny w kwestii struktury URL niż niektórzy hostowani konkurenci, pozwalając ustawić niestandardowe adresy URL dla produktów, kategorii i stron, zamiast wymuszać jeden stały wzorzec. Ta elastyczność pomaga, gdy migrujesz na BigCommerce i chcesz, aby adresy URL przypominały poprzednie, ale nie dzieje się to automatycznie, a przeniesienie z BigCommerce nadal oznacza zmapowanie jego wzorców URL na wymagania nowej platformy.

W ramach zarządzanej migracji porównujemy Twoją istniejącą strukturę URL ze strukturą BigCommerce, konfigurujemy potrzebne przekierowania w obu kierunkach i przenosimy metadane, które nadal są aktualne pod nowymi adresami URL — stosując to samo podejście, które opisujemy w naszej usłudze SEO i migracji przekierowań, dopasowane do specyficznych ograniczeń API i routingu BigCommerce.

#### FAQ

Q: Czy mogę zachować zagnieżdżoną strukturę kategorii, przenosząc się na BigCommerce?
A: Tak. BigCommerce obsługuje natywne, wielopoziomowe drzewo kategorii, więc głęboka struktura kategorii z innej platformy zwykle mapuje się bardziej bezpośrednio niż na platformę obsługującą wyłącznie płaskie tagi lub kolekcje.

Q: Co stanie się z moimi aplikacjami BigCommerce, jeśli się przeniosę?
A: Dane specyficzne dla aplikacji zwykle trzeba wyeksportować osobno z każdej aplikacji przed migracją. Migrujemy podstawowe dane sklepu, na których opiera się aplikacja, ale nie jej wewnętrzną konfigurację ani przechowywane rekordy.

Q: Czy opcja headless BigCommerce zmienia sposób przeprowadzania migracji?
A: Zmienia to, co oznacza migracja motywu, ponieważ konfiguracja headless odseparowuje frontend od własnej warstwy motywów BigCommerce, ale podstawowe dane produktów, zamówień i klientów nadal przenoszą się tak samo, przez API.

Q: Czy moje adresy URL pozostaną takie same po przejściu na BigCommerce?
A: Tylko jeśli świadomie skonfigurujesz pasujące niestandardowe adresy URL, na co BigCommerce pozwala dla produktów, kategorii i stron. Zwykle konfigurujemy przekierowania, zamiast zakładać dokładne dopasowanie 1:1.

Sources:
- BigCommerce – oficjalna strona internetowa: https://www.bigcommerce.com

### Migracja do lub z OpenCart

URL: https://prevedshop.com/pl/platformy/opencart
Language: pl
Last reviewed: 2026-07-21

OpenCart to platforma e-commerce o otwartym kodzie źródłowym, którą regularnie widzimy w migracjach — zwykle od sprzedawców, którzy zaczęli od niej ze względu na niski koszt i prostotę, a teraz wyrastają z samodzielnie zarządzanej konfiguracji, albo od sprzedawców wybierających ją specjalnie za jej lekkość. Ponieważ OpenCart jest otwartoźródłowy i samodzielnie hostowany, złożoność migracji zwykle zależy od tego, jak bardzo sklep został dostosowany za pomocą rozszerzeń, a nie tylko od liczby produktów w katalogu. Ta strona opisuje, co naprawdę ma znaczenie, gdy OpenCart jest jedną ze stron migracji.

#### Czym jest OpenCart i gdzie się sprawdza

OpenCart to oprogramowanie e-commerce o otwartym kodzie źródłowym zbudowane na PHP i MySQL, hostowane samodzielnie na serwerze, nad którym Ty lub Twój dostawca hostingu macie kontrolę. Jest znany ze stosunkowo lekkiego rdzenia i niższego progu wejścia niż niektóre inne platformy open source, co czyni go popularnym wśród mniejszych sprzedawców i agencji budujących sklepy z ograniczonym budżetem. Zarządzanie wieloma sklepami z jednego panelu administracyjnego jest funkcją wbudowaną, a nie dodatkiem.

Witryny sklepowe korzystają z własnego systemu motywów OpenCart, opartego na silniku szablonów Twig od OpenCart 3, z motywami i rozszerzeniami dostępnymi przez oficjalny OpenCart Marketplace lub tworzonymi na zamówienie. Jak w przypadku każdej samodzielnie hostowanej platformy open source, ilość niestandardowego kodu i rozszerzeń firm trzecich, jakie niesie sklep, jest jedną z pierwszych rzeczy decydujących o zakresie migracji.

#### Produkty, opcje i model danych

Katalog OpenCart opiera się na produktach zorganizowanych w kategorie, a „opcje” produktu obsługują wariancje, takie jak rozmiar czy kolor, w sposób strukturalnie odmienny od dedykowanego systemu wariantów na poziomie SKU stosowanego na niektórych innych platformach. Opcje w OpenCart mogą wpływać na cenę i ilość, ale bazowy model nie jest identyczny z prawdziwymi wariantami, co ma znaczenie przy migracji katalogu, który gdzie indziej korzysta z właściwych wariantów, do OpenCart, lub z OpenCart na platformę z bardziej rygorystycznym modelem wariantów.

Ponieważ OpenCart jest samodzielnie hostowany, bezpośredni dostęp do bazy danych do eksportów jest często dostępny, co może uprościć pobieranie danych produktów, klientów i zamówień. Ale sklepy dostosowane za pomocą rozszerzeń lub zmodyfikowanych plików rdzenia — częsty wzorzec w ekosystemie OpenCart, zwłaszcza przy starszych rozszerzeniach opartych na VQMod lub OCMOD — wymagają zidentyfikowania tych dostosowań, zanim założy się czysty, standardowy eksport.

#### Rozszerzenia, motywy i to, co nie przenosi się automatycznie

Działający sklep na OpenCart często zależy od zainstalowanych rozszerzeń — do płatności, wysyłki, narzędzi marketingowych czy funkcji katalogowych spoza rdzenia OpenCart. Dane i ustawienia rozszerzeń nie przenoszą się automatycznie podczas migracji platformy; przeniesienie z OpenCart oznacza sprawdzenie, co przechowuje każde rozszerzenie, i osobny eksport tych danych, a przeniesienie na OpenCart oznacza instalację i konfigurację odpowiedników z OpenCart Marketplace lub poprzez niestandardowy development.

Motywy OpenCart oparte na Twig są specyficzne dla jego systemu szablonów i nie przenoszą się na inne platformy, więc przeniesienie z OpenCart zwykle oznacza odbudowę designu witryny gdzie indziej, a przeniesienie na OpenCart oznacza dostosowanie motywu z marketplace lub zbudowanie niestandardowego. Starsze instalacje OpenCart, sprzed wersji 3.0, mogą nadal korzystać z wcześniejszego systemu motywów, co warto zaznaczyć na wczesnym etapie, ponieważ wpływa to na zakres prac przy redesignie.

#### SEO, adresy URL i jak podchodzimy do migracji OpenCart

OpenCart obsługuje przyjazne dla SEO przepisywanie adresów URL dla produktów i kategorii, ale trzeba je włączyć i skonfigurować — nie jest to domyślne ustawienie od razu po instalacji, a starsze lub mocno dostosowane instalacje czasem nadal działają na domyślnych, nieprzyjaznych adresach URL. Przeniesienie z OpenCart oznacza sprawdzenie, jaki tryb URL jest faktycznie używany, zanim założy się czyste mapowanie na nową platformę.

W ramach zarządzanej migracji analizujemy Twoją bieżącą konfigurację URL w OpenCart (lub planujemy docelową, jeśli przenosisz się na OpenCart), budujemy mapę przekierowań między starymi a nowymi adresami URL i przenosimy metadane, które nadal są aktualne — stosując to samo podejście, które opisujemy w naszej usłudze SEO i migracji przekierowań, dopasowane do konkretnej konfiguracji OpenCart.

#### FAQ

Q: Czy OpenCart jest darmowy w użyciu?
A: Podstawowe oprogramowanie OpenCart jest otwartoźródłowe i darmowe do pobrania oraz samodzielnego hostowania. Bieżące koszty wynikają z hostingu, czasu pracy deweloperów oraz ewentualnych płatnych rozszerzeń lub motywów z OpenCart Marketplace.

Q: Jak opcje produktu w OpenCart wypadają w porównaniu z wariantami na innych platformach?
A: Opcje w OpenCart mogą wpływać na cenę i ilość dla poszczególnych kombinacji, ale nie są ustrukturyzowane identycznie jak dedykowany system wariantów na poziomie SKU, więc zmapowanie ich na platformę z bardziej rygorystycznym modelem wariantów lub z niej wymaga uważnego przeglądu, a nie bezpośredniego dopasowania pól.

Q: Czy możecie zmigrować moje rozszerzenia OpenCart i ich dane?
A: Migrujemy podstawowe dane sklepu, na których opiera się rozszerzenie, ale ustawienia specyficzne dla rozszerzenia i przechowywane rekordy zwykle wymagają osobnego eksportu z tego rozszerzenia albo odbudowy przy użyciu odpowiednika na platformie docelowej.

Q: Czy moja wersja OpenCart wpływa na migrację?
A: Tak. Starsze instalacje OpenCart, zwłaszcza sprzed wersji 3.0, mogą znacząco różnić się systemem motywów, formatem rozszerzeń, a nawet schematem bazy danych, więc potwierdzamy Twoją wersję na wczesnym etapie oceny.

Sources:
- OpenCart – oficjalna strona internetowa: https://www.opencart.com

### Migracja do lub z PrestaShop

URL: https://prevedshop.com/pl/platformy/prestashop
Language: pl
Last reviewed: 2026-07-21

PrestaShop to platforma e-commerce o otwartym kodzie źródłowym, którą często widzimy w migracjach — szczególnie u sprzedawców w Europie przechodzących na nią ze względu na elastyczność samodzielnego hostingu, lub odchodzących z niej, gdy wyrastają z samodzielnie zarządzanej konfiguracji. Ponieważ PrestaShop jest otwartoźródłowy i samodzielnie hostowany (lub hostowany za pośrednictwem własnej oferty chmurowej PrestaShop), o złożoności migracji zwykle decyduje struktura bazy danych i to, od jakich modułów zależy sklep, a nie tylko wielkość katalogu. Ta strona opisuje, co naprawdę ma znaczenie, gdy PrestaShop jest jedną ze stron migracji.

#### Czym jest PrestaShop i gdzie się sprawdza

PrestaShop to oprogramowanie e-commerce o otwartym kodzie źródłowym zbudowane na PHP i MySQL, najczęściej hostowane samodzielnie, choć PrestaShop oferuje też własną opcję hostingu w chmurze. Otwarty kod źródłowy oznacza, że Ty lub Twój dostawca hostingu bezpośrednio zarządzacie serwerem, wersją PHP i bazą danych oraz macie pełny dostęp do kodu źródłowego, w przeciwieństwie do zamkniętych platform SaaS. Ma szczególnie silną pozycję wśród sprzedawców we Francji, Hiszpanii i na innych rynkach europejskich.

Witryny sklepowe są budowane we własnym systemie motywów PrestaShop, z motywami i modułami pochodzącymi z oficjalnego PrestaShop Marketplace (Addons) lub tworzonymi na zamówienie. Ponieważ kod źródłowy jest otwarty, personalizacje sklepu na PrestaShop mogą sięgać od prostej konfiguracji po głęboki, niestandardowy development modułów, a to, ile niestandardowego kodu niesie ze sobą sklep, jest jedną z pierwszych rzeczy kształtujących zakres migracji.

#### Produkty, kategorie i model danych

Model katalogu PrestaShop opiera się na produktach z kombinacjami (ich określenie na warianty, np. rozmiar czy kolor) zorganizowanych w natywne drzewo kategorii o nieograniczonej głębokości, plus osobnych „cechach” i „atrybutach” dla ustrukturyzowanych danych produktowych. To natywne drzewo kategorii sprawia, że PrestaShop jest rozsądnym celem dla katalogów o głębokiej strukturze hierarchicznej i jest jedną z rzeczy, które starannie mapujemy przy przenoszeniu drzewa kategorii na tę platformę lub z niej na platformę o płaskim modelu.

Klienci i historia zamówień żyją bezpośrednio w bazie danych MySQL PrestaShop, co przy samodzielnie hostowanym sklepie oznacza, że bezpośredni dostęp do bazy danych do eksportów jest często dostępny, zamiast ograniczać się do tego, co udostępnia API REST. Może to uprościć niektóre elementy migracji, ale oznacza też, że personalizacje sklepu w schemacie bazy danych, na przykład wynikające z niestandardowych modułów, trzeba zidentyfikować, zanim założy się, że standardowy eksport przechwyci wszystko.

#### Moduły, motywy i to, co nie przenosi się automatycznie

Działający sklep na PrestaShop zwykle zależy od zainstalowanych modułów — do płatności, obliczania wysyłki, marketingu czy funkcji katalogowych spoza rdzenia PrestaShop. Dane i konfiguracja modułów nie przenoszą się automatycznie podczas migracji platformy; przeniesienie z PrestaShop oznacza ustalenie, co przechowuje każdy moduł, i osobny eksport tych danych, a przeniesienie na PrestaShop oznacza instalację i konfigurację odpowiadających modułów z marketplace Addons lub poprzez niestandardowy development.

Motywy PrestaShop są związane z jego własnym systemem szablonów i nie przekładają się na inne platformy, więc przeniesienie z PrestaShop zwykle oznacza odbudowę designu witryny na nowej platformie, a przeniesienie na PrestaShop oznacza dostosowanie motywu z marketplace lub zlecenie motywu na zamówienie. Sklepy samodzielnie hostowane niosą też czasem niestandardowy kod na poziomie motywu, który trzeba przejrzeć osobno od samego designu wizualnego.

#### SEO, adresy URL i jak podchodzimy do migracji PrestaShop

PrestaShop pozwala na dość elastyczne, konfigurowalne przepisywanie adresów URL dla produktów, kategorii i stron CMS, co pomaga przy próbie zachowania struktury URL podczas migracji, ale nadal wymaga to świadomej konfiguracji, a nie założeń. Przeniesienie z PrestaShop oznacza zmapowanie jego wzorców URL, które mogą się znacznie różnić między sklepami, ponieważ są konfigurowalne, na wymagania nowej platformy.

W ramach zarządzanej migracji analizujemy Twoją istniejącą konfigurację URL w PrestaShop (lub docelową, jeśli przenosisz się na PrestaShop), budujemy mapę przekierowań między starymi a nowymi adresami URL i przenosimy metadane, które nadal są aktualne — stosując to samo podejście, które opisujemy w naszej usłudze SEO i migracji przekierowań, dopasowane do konkretnej konfiguracji routingu PrestaShop.

#### FAQ

Q: Czy PrestaShop jest darmowy w użyciu?
A: Podstawowe oprogramowanie PrestaShop jest otwartoźródłowe i darmowe do pobrania oraz samodzielnego hostowania. Koszty wynikają z hostingu, czasu pracy deweloperów, płatnych modułów i motywów oraz ewentualnego planu hostingu chmurowego PrestaShop, jeśli wybierzesz go zamiast hostingu własnego.

Q: Czy możecie zmigrować moje moduły PrestaShop i ich dane?
A: Migrujemy podstawowe dane sklepu, na których opiera się dany moduł, ale konfiguracja i dane przechowywane przez konkretny moduł zwykle wymagają osobnego eksportu z tego modułu albo odbudowy przy użyciu odpowiednika na platformie docelowej.

Q: Czy struktura kategorii PrestaShop dobrze przenosi się na inne platformy?
A: Zależy od celu migracji. Natywne, nieograniczone głębokościowo drzewo kategorii PrestaShop mapuje się bezproblemowo na platformy o podobnym modelu, ale wymaga przemapowania na tagi lub kolekcje na platformach, które nie obsługują prawdziwych kategorii zagnieżdżonych.

Q: Która wersja PrestaShop ma znaczenie dla migracji?
A: Ma spore znaczenie, ponieważ schemat bazy danych i zgodność modułów mogą różnić się między głównymi wersjami. Potwierdzamy Twoją wersję PrestaShop podczas oceny, zanim ustalimy ostateczne podejście do migracji.

Sources:
- PrestaShop – oficjalna strona internetowa: https://www.prestashop.com

### Migracja do lub z Shopify

URL: https://prevedshop.com/pl/platformy/shopify
Language: pl
Last reviewed: 2026-07-21

Shopify to jeden z najczęstszych punktów końcowych migracji, z którymi pracujemy — zarówno jako platforma, na którą sklepy się przenoszą, jak i ta, którą opuszczają. Ponieważ jest to platforma zamknięta i hostowana, wiele z tego, jak gładko przebiegnie przeniesienie, zależy od tego, co faktycznie udostępnia API Shopify, a nie tylko od wielkości katalogu. Ta strona opisuje, co naprawdę ma znaczenie, gdy Shopify jest jedną ze stron migracji.

#### Czym jest Shopify i gdzie się sprawdza

Shopify to hostowana platforma e-commerce w modelu SaaS: nie zarządzasz serwerami, wersjami PHP ani kopiami zapasowymi bazy danych. Shopify utrzymuje infrastrukturę, a Ty zarządzasz sklepem przez jego panel administracyjny oraz — w przypadku głębszych personalizacji — przez API. Plany obejmują standardowe warianty dla małych i średnich sprzedawców, aż po Shopify Plus, skierowany do sprzedawców o wyższym wolumenie, którzy potrzebują większej personalizacji kasy i wyższych limitów API.

Witryny sklepowe są budowane we własnym języku szablonów Shopify, Liquid, a motywy pochodzą ze Shopify Theme Store lub z dedykowanego developmentu. Ponieważ platforma jest zamkniętym, hostowanym rozwiązaniem, pracujesz w ramach modelu danych i punktów rozszerzeń Shopify, a nie modyfikując kod źródłowy — dlatego właśnie migracje do lub z Shopify opierają się na dostępie do API i konfiguracji aplikacji, a nie na bezpośredniej kopii bazy danych.

#### Produkty, zamówienia i klienci: model danych

Model produktów Shopify opiera się na produktach i wariantach (na przykład koszulka z wariantami rozmiaru i koloru), zorganizowanych w kolekcje manualne lub automatyczne, a nie w swobodne drzewo kategorii. Migracja katalogu do Shopify zwykle oznacza przemapowanie struktury kategorii lub atrybutów platformy źródłowej na model produkt/wariant/kolekcja Shopify — co jest proste przy prostych katalogach, a bardziej złożone przy platformach z głębokimi, wielopoziomowymi kategoriami lub silnie konfigurowalnymi produktami.

Klienci i historia zamówień są przenoszone przez Admin API, ale dane zamówień są związane z własnym modelem zamówień i realizacji Shopify, więc historyczne zamówienia zwykle migrowane są jako rekordy referencyjne, a nie w pełni edytowalne, aktywne zamówienia. Metafields (mechanizm pól niestandardowych Shopify) to zwykle miejsce, w którym lądują niestandardowe dane produktowe, a zmapowanie istniejących pól niestandardowych na metafields jest jedną z pierwszych rzeczy, które ustalamy w zakresie prac.

#### Aplikacje, motywy i to, co nie przenosi się automatycznie

Działający sklep na Shopify zwykle zależy od kilku zainstalowanych aplikacji — do opinii, subskrypcji, programów lojalnościowych, wyszukiwania czy reguł wysyłki. Dane aplikacji z reguły nie przenoszą się razem z migracją platformy; jeśli przenosisz się z Shopify, dane przechowywane przez aplikację (jak harmonogramy subskrypcji czy punkty lojalnościowe) wymagają osobnego eksportu z tej aplikacji, a jeśli przenosisz się na Shopify, będziesz instalować odpowiedniki ze Shopify App Store, zamiast przenosić konfigurację aplikacji.

To samo dotyczy motywów: motyw w Liquid nie przekłada się na system szablonów innej platformy, więc przeniesienie z Shopify zwykle oznacza odbudowę designu witryny na nowej platformie, a przeniesienie na Shopify oznacza albo dostosowanie motywu z Theme Store, albo zlecenie dedykowanego developmentu w Liquid.

#### SEO, adresy URL i jak podchodzimy do migracji Shopify

Shopify wymusza własne wzorce adresów URL, takie jak /products/{handle}, /collections/{handle} i /pages/{handle}, które rzadko idealnie pasują do struktury URL innej platformy. Przeniesienie do lub z Shopify niemal zawsze oznacza mapę przekierowań ze starych adresów URL na nowe, ponieważ Shopify nie pozwala w pełni odtworzyć dowolnej struktury URL z innego systemu, a inne platformy nie znają automatycznie Twoich uchwytów (handles) z Shopify.

W ramach zarządzanej migracji mapujemy Twoje istniejące adresy URL względem struktury Shopify (lub odwrotnie, gdy opuszczasz Shopify), konfigurujemy przekierowania 301 i przenosimy metadane, które nadal są aktualne na nowych adresach URL — stosując to samo podejście, które opisujemy w naszej usłudze SEO i migracji przekierowań, tyle że dopasowane konkretnie do konwencji URL i ograniczeń API Shopify.

#### FAQ

Q: Czy możecie zmigrować moje aplikacje Shopify i ich dane?
A: Migrujemy dane sklepu, na których te aplikacje się opierają, ale konfiguracja i dane przechowywane przez konkretną aplikację zwykle muszą pochodzić z osobnego eksportu z tej aplikacji albo zostać odtworzone przy użyciu odpowiednika na platformie docelowej.

Q: Czy Shopify Plus zmienia sposób przeprowadzania migracji?
A: Plus wpływa głównie na personalizację kasy i limity API. Podstawowy model danych produktów i zamówień jest taki sam jak w standardowym Shopify, więc podejście do migracji zasadniczo się nie zmienia, choć wyższe limity API mogą przyspieszyć transfer dużych katalogów.

Q: Czy moje adresy URL produktów pozostaną takie same po przejściu na Shopify?
A: Tylko jeśli Twoje obecne adresy URL już pasują do wzorca /products/{handle} Shopify, co zdarza się rzadko. W większości przypadków w ramach migracji konfigurujemy przekierowania ze starych adresów URL na wymaganą strukturę Shopify.

Q: Co stanie się z moim motywem, jeśli zmigruję się z Shopify?
A: Motywy w Liquid nie przenoszą się do systemów szablonów innych platform, więc design witryny jest odbudowywany na nowej platformie, dopasowany do istniejącego designu w zakresie, na jaki pozwala nowa platforma.

Sources:
- Shopify – oficjalna strona internetowa: https://www.shopify.com

### Migracja do lub ze Shoptet

URL: https://prevedshop.com/pl/platformy/shoptet
Language: pl
Last reviewed: 2026-07-21

Shoptet to hostowana platforma e-commerce skupiona specjalnie na rynku czeskim i słowackim, i jest częstym punktem końcowym migracji dla sprzedawców działających w tym regionie — czy to przenoszących się na Shoptet ze względu na lokalne wsparcie i konfigurację bez kodu, czy odchodzących z niej w miarę ekspansji lub potrzeby możliwości, których platforma nie oferuje. Ponieważ Shoptet to zamknięta, hostowana platforma SaaS, migracja do lub z niej zależy od tego, co faktycznie udostępniają jej panel administracyjny, narzędzia eksportu i API. Ta strona opisuje, co naprawdę ma znaczenie, gdy Shoptet jest jedną ze stron migracji.

#### Czym jest Shoptet i gdzie się sprawdza

Shoptet to hostowana platforma e-commerce w modelu SaaS zbudowana dla rynku czeskiego i słowackiego, z panelem administracyjnym, dokumentacją i wsparciem głównie w języku czeskim. Podobnie jak inne platformy hostowane, Shoptet zarządza hostingiem i infrastrukturą, a sprzedawcy zarządzają swoim sklepem przez panel administracyjny, a nie dostęp do serwera. Jest skierowany głównie do małych i średnich sprzedawców regionalnych, którzy chcą prowadzić sklep bez samodzielnego zarządzania kodem czy infrastrukturą.

Fronty sklepowe są budowane przy użyciu własnego systemu szablonów i personalizacji designu Shoptet, z dodatkami dostępnymi przez jego własny marketplace dla funkcjonalności takich jak integracje księgowe, narzędzia marketingowe czy regionalne metody płatności i wysyłki typowe dla rynku CZ/SK. Ponieważ jest to platforma zamknięta i hostowana, migracje do lub ze Shoptet działają w ramach jego własnego modelu danych i opcji eksportu czy API, a nie bezpośredniej kopii bazy danych.

#### Produkty, kategorie i model danych

Model katalogu Shoptet organizuje produkty w kategorie z obsługą wariantów produktów i parametrów dla ustrukturyzowanych atrybutów. Migracja katalogu na Shoptet zwykle oznacza zmapowanie struktury kategorii lub atrybutów platformy źródłowej na model Shoptet, co jest zwykle proste dla katalogów o umiarkowanej złożoności.

Shoptet udostępnia opcje eksportu danych oraz API do pobierania danych produktów, zamówień i klientów, na czym opiera się migracja z tej platformy. Podobnie jak w przypadku innych platform hostowanych, historyczne zamówienia zwykle trafiają jako rekordy referencyjne, a nie w pełni aktywne, edytowalne zamówienia na nowej platformie.

#### Dodatki, design i to, co nie przenosi się automatycznie

Działający sklep na Shoptet często zależy od zainstalowanych dodatków — do księgowości, marketingu, feedów porównywarek cen, powszechnych wśród sprzedawców CZ/SK notowanych w serwisach takich jak Heureka czy Zboží.cz, albo regionalnych integracji płatności. Dane i ustawienia dodatków nie przenoszą się automatycznie przy migracji platformy; przenosiny ze Shoptet oznaczają sprawdzenie, co przechowuje każdy dodatek, i wyeksportowanie tego osobno, a przenosiny na Shoptet oznaczają skonfigurowanie odpowiedników z jego własnego marketplace'u dodatków.

Szablony designu Shoptet są specyficzne dla jego własnego systemu i nie przenoszą się na inne platformy, więc przenosiny ze Shoptet zwykle oznaczają odbudowę designu frontu sklepu gdzie indziej, a przenosiny na Shoptet oznaczają dostosowanie jednego z jego szablonów lub pracę w ramach jego opcji personalizacji designu.

#### SEO, adresy URL i jak podchodzimy do migracji Shoptet

Shoptet pozwala na pewną personalizację struktury adresów URL dla produktów i kategorii, ale jak przy każdej zmianie platformy, istniejące wzorce URL rzadko dokładnie pasują do wymagań nowej platformy. Ma to szczególne znaczenie dla sprzedawców CZ/SK, którzy często mają widoczność organiczną powiązaną z obecnymi adresami URL oraz notowaniami w feedach produktowych na regionalnych porównywarkach zakupów.

W ramach zarządzanej migracji mapujemy Twoje istniejące adresy URL Shoptet, albo adresy platformy docelowej, jeśli przenosisz się na Shoptet, względem nowej struktury, konfigurujemy przekierowania i przenosimy metadane oraz konfigurację feedów porównawczych, które nadal są aktualne, stosując to samo podejście opisane w naszej usłudze SEO i migracji przekierowań, dopasowane do konkretnej konfiguracji Shoptet i regionalnego ekosystemu feedów, z którym zwykle się łączy.

#### FAQ

Q: Czy Shoptet jest dostępny poza Czechami i Słowacją?
A: Shoptet jest zbudowany i wspierany specjalnie dla rynku czeskiego i słowackiego, z panelem administracyjnym i dokumentacją głównie w języku czeskim. Nie jest pozycjonowany jako platforma globalna tak, jak niektórzy hostowani konkurenci, co warto wziąć pod uwagę, jeśli planujesz ekspansję poza CZ/SK.

Q: Czy możecie zmigrować moje feedy produktowe Shoptet dla Heureka czy Zboží.cz?
A: Migrujemy dane produktowe leżące u podstaw tych feedów; sama konfiguracja feedu zwykle musi zostać odbudowana na nowej platformie, albo obsłużona przez naszą usługę integracji feedów dostawców, w zależności od tego, jak platforma docelowa zarządza feedami porównywarek zakupów.

Q: Czy możecie zmigrować moje dodatki Shoptet i ich dane?
A: Migrujemy podstawowe dane sklepu, na których opiera się dany dodatek, ale ustawienia specyficzne dla dodatku i przechowywane rekordy zwykle wymagają osobnego eksportu z tego dodatku albo muszą zostać odbudowane przy użyciu odpowiednika na platformie docelowej.

Q: Czy moje adresy URL produktów pozostaną takie same, jeśli przeniosę się do lub ze Shoptet?
A: Zwykle nie dokładnie, ponieważ struktura adresów URL Shoptet rzadko pasuje do wymagań innej platformy. W ramach migracji konfigurujemy przekierowania ze starych adresów URL na nowe, aby chronić istniejące pozycje w wyszukiwarce.

Sources:
- Shoptet - oficjalna strona: https://www.shoptet.cz

### Migracja do lub z Shopware

URL: https://prevedshop.com/pl/platformy/shopware-6
Language: pl
Last reviewed: 2026-07-21

Shopware to platforma, którą najczęściej widzimy u sprzedawców z Niemiec, Austrii i Szwajcarii — albo przenoszących się na nią ze względu na otwartą architekturę i silną obecność w regionie DACH, albo odchodzących ze starszej instalacji Shopware w miarę zmiany potrzeb. Podwójna natura Shopware — oprogramowanie open source, które można też uruchomić jako hostowany produkt chmurowy — oznacza, że właściwe podejście do migracji zależy od tego, jaką wersję i jaki sposób wdrożenia faktycznie wykorzystujesz. Ta strona opisuje, co naprawdę ma znaczenie, gdy Shopware jest jedną ze stron migracji.

#### Czym jest Shopware i gdzie się sprawdza

Shopware to oprogramowanie e-commerce zbudowane na frameworku Symfony w PHP, dostępne jako samodzielnie hostowane oprogramowanie open source (Community Edition) lub jako hostowany produkt chmurowy z komercyjnymi edycjami dodającymi funkcje takie jak zaawansowane narzędzia B2B i ceny oparte na regułach. Shopware 6 to aktualna generacja, zbudowana wokół rdzenia z możliwością pracy w trybie headless, z oddzielną warstwą witryny sklepowej i administracji, zastępująca starsze, strukturalnie odmienne Shopware 5.

Ponieważ Shopware udostępnia Store API, obsługuje konfiguracje headless i kompozycyjne obok własnej domyślnej witryny sklepowej, co ma znaczenie przy migracjach, gdzie frontend i backend są obsługiwane osobno. Witryny sklepowe w standardowej ścieżce korzystają z własnego systemu motywów Shopware, zbudowanego na Twig, z wtyczkami i motywami dostępnymi przez Shopware Store.

#### Produkty, kanały sprzedaży i model danych

Shopware organizuje produkty za pomocą „właściwości” i grup konfiguratora dla wariantów, w ramach natywnego drzewa kategorii, i wykorzystuje „kanały sprzedaży” do zarządzania różnymi witrynami sklepowymi lub prezentacjami marek z jednego backendu — koncepcja strukturalnie odmienna od tego, jak platformy z jedną witryną sklepową obsługują konfiguracje wielomarkowe. Ten model kanałów sprzedaży to jedna z pierwszych rzeczy, które mapujemy, gdy sprzedawca prowadzi kilka powiązanych sklepów z jednej instalacji Shopware.

Ceny oparte na regułach — różne ceny lub promocje wyzwalane przez grupę klientów, zawartość koszyka czy inne warunki — to funkcja Shopware warta wczesnego wskazania w migracji, ponieważ nie każda platforma docelowa modeluje ceny warunkowe w ten sam sposób. Dane klientów i zamówień żyją we własnej strukturze bazy danych Shopware, a przy instalacjach samodzielnie hostowanych bezpośredni dostęp do bazy danych jest często dostępny, co może uprościć niektóre eksporty, ale nadal wymaga zidentyfikowania pól dodanych przez niestandardowe wtyczki, zanim założy się, że standardowy eksport przechwyci wszystko.

#### Wtyczki, motywy i to, co nie przenosi się automatycznie

Działający sklep na Shopware zwykle opiera się na wtyczkach ze Shopware Store — do płatności, wysyłki, marketingu czy funkcji B2B spoza rdzenia Shopware. Dane i konfiguracja przechowywane przez wtyczki nie przenoszą się automatycznie podczas migracji platformy; przeniesienie z Shopware oznacza sprawdzenie, co przechowuje każda wtyczka, i osobny eksport tych danych, a przeniesienie na Shopware oznacza instalację i konfigurację odpowiedników przez Shopware Store lub niestandardowy development.

Motywy Shopware oparte na Twig są specyficzne dla jego systemu szablonów i nie przenoszą się nigdzie indziej, więc przeniesienie z Shopware zwykle oznacza odbudowę designu witryny na nowej platformie, a przeniesienie na Shopware oznacza dostosowanie motywu ze Store lub zbudowanie niestandardowego. Migracje obejmujące Shopware 5, które wykorzystuje inną architekturę bazową niż Shopware 6, trzeba ustalać jako osobny przypadek, a nie zakładać, że będą działać jak migracja Shopware 6.

#### SEO, adresy URL i jak podchodzimy do migracji Shopware

Shopware obsługuje konfigurowalne szablony URL SEO dla produktów, kategorii i innych stron, które można dostosować dla poszczególnych kanałów sprzedaży, ale faktycznie stosowane wzorce URL różnią się między sklepami w zależności od konfiguracji. Przeniesienie z Shopware oznacza sprawdzenie aktywnej konfiguracji URL, a nie założenie domyślnego wzorca.

W ramach zarządzanej migracji analizujemy Twoją istniejącą konfigurację URL w Shopware (lub planujemy docelową, jeśli przenosisz się na Shopware), budujemy mapę przekierowań między starymi a nowymi adresami URL dla poszczególnych kanałów sprzedaży tam, gdzie ma to zastosowanie, i przenosimy metadane, które nadal są aktualne — stosując to samo podejście, które opisujemy w naszej usłudze SEO i migracji przekierowań, dopasowane do specyficznego routingu i struktury kanałów sprzedaży Shopware.

#### FAQ

Q: Czy ma znaczenie, czy korzystam ze Shopware 5, czy Shopware 6?
A: Tak, i to znacznie. Shopware 6 ma inną architekturę bazową, system wtyczek i strukturę motywów niż Shopware 5, więc traktujemy migracje z każdej z tych wersji jako odrębne przypadki, a nie zakładamy, że stosuje się to samo podejście.

Q: Czy Shopware jest darmowy w użyciu?
A: Community Edition Shopware jest open source i darmowy do samodzielnego hostowania. Edycje komercyjne oraz opcja hostingu chmurowego wiążą się z kosztami licencji lub subskrypcji wraz z dodatkowymi funkcjami, jak zaawansowane narzędzia B2B.

Q: Jak kanały sprzedaży Shopware wpływają na migrację?
A: Jeśli prowadzisz kilka witryn sklepowych lub marek za pomocą funkcji kanałów sprzedaży Shopware, mapujemy każdą z nich osobno, zamiast traktować instalację jako jeden płaski sklep, ponieważ platformy docelowe nie zawsze modelują konfiguracje wielokanałowe w ten sam sposób.

Q: Czy możecie zmigrować moje wtyczki Shopware i ich dane?
A: Migrujemy podstawowe dane sklepu, na których opiera się wtyczka, ale ustawienia specyficzne dla wtyczki i przechowywane rekordy zwykle wymagają osobnego eksportu z tej wtyczki albo odbudowy przy użyciu odpowiednika na platformie docelowej.

Sources:
- Shopware – oficjalna strona internetowa: https://www.shopware.com

### Migracja do lub z WooCommerce

URL: https://prevedshop.com/pl/platformy/woocommerce
Language: pl
Last reviewed: 2026-07-21

WooCommerce nie jest platformą w takim sensie jak hostowane narzędzie SaaS. To darmowa wtyczka, która zamienia samodzielnie hostowaną witrynę WordPress w sklep, co oznacza, że migracja WooCommerce jest w istocie migracją WordPressa razem z bazą danych. To rozróżnienie zmienia to, co faktycznie trzeba przenieść, i jest pierwszą rzeczą, którą ustalamy po obu stronach projektu związanego z WooCommerce.

#### Czym jest WooCommerce i kto nim zarządza

WooCommerce to wtyczka e-commerce o otwartym kodzie źródłowym dla WordPressa, tworzona i utrzymywana przez Automattic. Ponieważ jest samodzielnie hostowana, to Ty (lub Twój dostawca hostingu) odpowiadasz za serwer, wersję PHP, kopie zapasowe i aktualizacje. Nie ma tu jednego dostawcy zarządzającego dostępnością tak jak na platformie SaaS, co daje więcej kontroli, ale też więcej obowiązków związanych z utrzymaniem.

Jest popularny wśród sprzedawców, którzy już korzystają z WordPressa do treści albo chcą mieć pełną kontrolę nad hostingiem, wtyczkami i kodem. Ta elastyczność jest też powodem, dla którego sklepy na WooCommerce mocno różnią się złożonością: skromny katalog z kilkoma wtyczkami to zupełnie inna migracja niż mocno dostosowana instalacja z dziesiątkami współpracujących ze sobą wtyczek.

#### Model danych: produkty jako treść WordPressa

WooCommerce przechowuje produkty jako niestandardowy typ wpisu WordPressa, z wariantami, atrybutami i cenami trzymanymi w powiązanych tabelach oraz metadanych wpisu, a nie w dedykowanym schemacie e-commerce. Kategorie i tagi wykorzystują system taksonomii WordPressa. Sprawdza się to dobrze w ramach WordPressa, ale oznacza, że migracja do WooCommerce wymaga zmapowania danych źródłowych nie tylko na „produkty”, ale konkretnie na model treści WordPressa, a migracja z WooCommerce oznacza wydobycie danych e-commerce, które są przemieszane z ogólną treścią WordPressa.

Sposób przechowywania zamówień zależy od wersji i konfiguracji WooCommerce: starsze sklepy używają wpisów i metadanych WordPressa, a High-Performance Order Storage może zapisywać zamówienia i adresy w dedykowanych tabelach. Klienci pozostają powiązani z użytkownikami WordPressa, a rozszerzenia mogą dodawać kolejne tabele. To, czy historię można przenieść jako edytowalne zamówienia, czy tylko jako dane referencyjne, zależy od platformy docelowej i metody importu; przed mapowaniem trzeba więc zinwentaryzować schemat źródłowy.

#### Wtyczki, motywy i gdzie żyje niestandardowa logika

Działający sklep na WooCommerce zwykle zależy od kilku wtyczek poza samym WooCommerce — do reguł wysyłki, bramek płatności, subskrypcji czy pól niestandardowych za pomocą narzędzi takich jak Advanced Custom Fields. Dane specyficzne dla wtyczek zwykle nie mają przenośnego formatu eksportu, więc migracja z WooCommerce oznacza ustalenie, co faktycznie przechowuje każda wtyczka i czy platforma docelowa ma jej odpowiednik.

Motywy to motywy WordPressa, często połączone z kreatorami stron (Elementor, WPBakery i podobne), które przechowują dane układu w sposób nieprzekładalny poza WordPressem. Przeniesienie z WooCommerce zwykle oznacza odbudowę designu witryny na nowej platformie, a nie jego eksport.

#### SEO, adresy URL i jak podchodzimy do migracji WooCommerce

Struktura adresów URL WooCommerce jest kontrolowana przez ustawienia bezpośrednich odnośników (permalinków) WordPressa, więc jest elastyczna, ale ta elastyczność oznacza, że adresy URL każdej witryny na WooCommerce są skonfigurowane nieco inaczej i nie ma jednego stałego wzorca, względem którego można migrować, tak jak na niektórych platformach SaaS. Popularne wtyczki SEO (Yoast, Rank Math) przechowują też metadane i przekierowania we własnych tabelach, co trzeba uwzględnić osobno od podstawowych danych WooCommerce/WordPress.

W ramach zarządzanej migracji mapujemy Twoją rzeczywistą strukturę permalinków, a nie zakładany domyślny wzorzec, na strukturę URL platformy docelowej, pobieramy metadane z wtyczki SEO, której używasz, i konfigurujemy przekierowania, aby istniejące pozycje w wynikach wyszukiwania i linki przychodzące nadal działały. Sposób działania tego procesu opisujemy szerzej w naszej usłudze SEO i migracji przekierowań.

#### FAQ

Q: Czy dane WooCommerce obejmują też moją treść WordPressa?
A: Tylko to, o co poprosisz. WooCommerce i ogólna treść WordPressa (wpisy blogowe, strony) żyją w tej samej bazie danych, więc przed rozpoczęciem migracji dokładnie ustalamy, co liczy się jako „dane sklepu”, a co jako treść witryny.

Q: Czy możecie zmigrować sklep na WooCommerce z wieloma wtyczkami niestandardowymi?
A: Tak, ale wymaga to więcej czasu na ocenę. Ustalamy, co faktycznie przechowuje każda wtyczka i czy da się to zmapować na coś na nowej platformie, czy trzeba to odbudować od zera.

Q: Co stanie się z moimi danymi SEO z Yoast lub Rank Math, jeśli przeniosę się z WooCommerce?
A: Wydobywamy metadane i przekierowania przechowywane przez te wtyczki i przenosimy to, co nadal jest aktualne, do odpowiadających pól na nowej platformie, zamiast zaczynać Twoje metadane SEO od zera.

Q: Czy mogę przenieść się do WooCommerce z platformy SaaS?
A: Tak, to częsty kierunek, gdy sprzedawcy chcą mieć więcej kontroli nad hostingiem i kodem. Mapujemy Twój katalog źródłowy na model typów wpisów WordPressa i odpowiednio konfigurujemy WooCommerce.

Sources:
- WooCommerce – oficjalna strona internetowa: https://woocommerce.com

### Migration routes

### Migracja z Magento na BigCommerce

URL: https://prevedshop.com/pl/migracje/magento-do-bigcommerce
Language: pl
Last reviewed: 2026-07-21
Route: adobe-commerce -> bigcommerce

Przejście z Adobe Commerce lub Magento Open Source na BigCommerce zamienia samodzielnie hostowaną, opartą na kodzie platformę na zarządzaną platformę SaaS — podobnie w duchu do przejścia na Shopify, ale z innym zestawem kompromisów. BigCommerce natywnie obsługuje więcej kombinacji wariantów produktów i daje większą kontrolę nad strukturą adresów URL niż wielu konkurentów SaaS, co może czynić go bliższym strukturalnie dopasowaniem dla złożonego katalogu Magento — ale hosting, rozszerzenia i konfigurację wielosklepową nadal trzeba celowo odbudować, a nie po prostu wyeksportować w całości.

#### Dlaczego sprzedawcy odchodzą z Magento

Magento Open Source i Adobe Commerce dają pełną kontrolę nad kodem, hostingiem i kasą, kosztem konieczności samodzielnego zarządzania tą infrastrukturą: łataniem bezpieczeństwa PHP i Magento, hostingiem serwerowym czy chmurowym oraz zgodnością PCI dla samodzielnie hostowanej kasy. BigCommerce, jako zarządzana platforma SaaS, zdejmuje z Twojego zespołu hosting, zgodność PCI i łatanie bezpieczeństwa platformy, w zamian za pracę w ramach ograniczeń platformy zamiast dowolnego kodu.

Częstym wyzwalaczem jest ten sam, który popycha sprzedawców w stronę Shopify: koszt utrzymywania dewelopera lub agencji na stałe do obsługi instancji Magento przestaje mieć sens, gdy wzrost sklepu nie uzasadnia już tego nakładu, zwłaszcza dla sklepów wciąż działających na niezałatanej instancji Magento 2 lub pozostających przy Magento 1, które wyszło już z okresu wsparcia.

#### Co zmienia się w modelu danych

Struktura katalogu EAV (Entity-Attribute-Value) w Magento pozwala definiować w dużej mierze dowolne atrybuty niestandardowe dla każdego typu produktu. Model produktów BigCommerce jest bardziej ustrukturyzowany niż w Magento, ale generalnie bardziej elastyczny w zakresie wariantów niż konkurencyjne platformy SaaS — natywnie obsługuje większą liczbę kombinacji wariantów produktów, a także pola niestandardowe i modyfikatory produktów dla atrybutów poza strukturą wariantów. To wciąż oznacza, że zestawy atrybutów Magento trzeba celowo zmapować na opcje wariantów i pola niestandardowe BigCommerce, a nie kopiować atrybut po atrybucie.

Drzewo kategorii w Magento pozwala na dowolne zagnieżdżanie z ustawieniami wyświetlania per widok sklepu, a produkt może należeć do wielu kategorii jednocześnie. Kategorie BigCommerce są bliższe tradycyjnemu drzewu niż płaski model kolekcji Shopify, co czyni migrację głęboko zagnieżdżonej struktury kategorii Magento nieco bardziej bezpośrednią — ale nadal powinna zostać przejrzana i uproszczona tam, gdzie struktura Magento rozrosła się organicznie przez lata, a nie została zaprojektowana.

#### Adresy URL, przekierowania i czym różni się to od Shopify

Klucze URL i przepisania adresów w Magento są w pełni konfigurowalne per widok sklepu. BigCommerce, w przeciwieństwie do Shopify, pozwala na niestandardowe ścieżki URL dla produktów, kategorii i stron bez wymuszania obowiązkowego prefiksu `/products/` czy `/collections/` — co może ułatwić zachowanie istniejącej struktury URL z Magento. To jednak nie usuwa potrzeby planu przekierowań: każdy adres URL, który się zmienia, nadal potrzebuje jawnego przekierowania 301, a ćwiczenie polegające na zweryfikowaniu każdego zaindeksowanego adresu URL Magento wobec jego nowego odpowiednika w BigCommerce i tak musi się odbyć, aby uniknąć spadku pozycji po migracji.

#### Rozszerzenia, kasa i wielosklepowość

Ekosystem rozszerzeń Magento oraz jego możliwość personalizacji kasy i przepływów panelu administracyjnego w kodzie nie mają bezpośredniego odpowiednika w BigCommerce — BigCommerce korzysta z marketplace'u aplikacji oraz własnych API i personalizacji frontu Stencil/Catalyst dla niestandardowej logiki. Każde aktywne rozszerzenie Magento wymaga jawnej decyzji podczas oceny: odpowiadająca mu aplikacja BigCommerce, niestandardowa budowa na bazie API BigCommerce, albo potwierdzenie, że nie jest już potrzebne. Model wielu witryn/sklepów w Magento również wymaga zmapowania na możliwości wielosklepowe BigCommerce, które pod maską działają inaczej, nawet gdy końcowy efekt wygląda podobnie.

#### FAQ

Q: Czy BigCommerce obsłuży niestandardowe atrybuty produktów z Magento?
A: Poprzez połączenie opcji wariantów i pól niestandardowych, ale BigCommerce nie ma automatycznego odpowiednika zestawów atrybutów EAV z Magento. Mapujemy Twoje rzeczywiste wykorzystanie atrybutów podczas oceny, zamiast migrować każdy atrybut, jaki akurat zdefiniowało Magento.

Q: Czy migracja adresów URL z Magento na BigCommerce jest łatwiejsza niż na Shopify?
A: Często nieco tak, ponieważ BigCommerce pozwala na niestandardowe ścieżki URL bez obowiązkowego prefiksu, w przeciwieństwie do stałej struktury Shopify. To zmniejsza liczbę adresów URL wymagających zmiany, ale każdy zmieniany adres URL nadal potrzebuje jawnego przekierowania 301 — audyt i tak musi się odbyć.

Q: Co dzieje się z moimi rozszerzeniami i niestandardowymi modułami Magento?
A: Każde jest oceniane indywidualnie podczas oceny: zastąpienie istniejącą aplikacją BigCommerce, odbudowa na bazie API BigCommerce albo potwierdzenie, że nie jest już potrzebne. Oznaczamy tę listę przed wyceną projektu, nie po.

Q: Czy mogę zachować funkcjonalność wielosklepową lub wielowitrynową?
A: Model wielu witryn Magento nie mapuje się bezpośrednio na architekturę BigCommerce, mimo że BigCommerce również obsługuje wiele frontów sklepowych. Mapujemy Twoją rzeczywistą potrzebę — osobne marki, regiony czy waluty — na właściwą strukturę BigCommerce, zamiast zakładać konwersję jeden do jednego.

Sources:
- BigCommerce - oficjalna strona i dokumentacja: https://www.bigcommerce.com
- Dokumentacja Adobe Commerce / Magento Open Source: https://experienceleague.adobe.com/en/docs/commerce

### Migracja z Magento na Shopify

URL: https://prevedshop.com/pl/migracje/magento-do-shopify
Language: pl
Last reviewed: 2026-07-21
Route: adobe-commerce -> shopify

Przejście z Adobe Commerce lub Magento Open Source na Shopify zamienia samodzielnie hostowaną, wysoce personalizowalną platformę PHP na zarządzaną platformę SaaS. Ta zamiana zdejmuje z Ciebie utrzymanie serwera, wersji PHP i zgodności PCI, ale oznacza też, że model danych katalogu, struktura adresów URL i większość rozszerzeń muszą zostać odbudowane, a nie skopiowane. Zrobione celowo, to dobrze poznane przenosiny; zrobione jako surowy eksport/import, to właśnie tam po cichu psuje się SEO i niestandardowa logika.

#### Dlaczego sprzedawcy odchodzą z Magento

Magento Open Source i Adobe Commerce dają pełną kontrolę nad kodem, hostingiem i kasą — dokładnie dlatego są drogie w utrzymaniu. Ktoś musi łatać wydania bezpieczeństwa PHP i Magento, zarządzać serwerem lub infrastrukturą chmurową i utrzymywać aktualną zgodność PCI dla samodzielnie hostowanej kasy. Shopify zdejmuje z Twojego zespołu hosting, zgodność PCI i łatanie bezpieczeństwa platformy, w zamian za mniejszą kontrolę na niskim poziomie.

Częstym wyzwalaczem jest to, że bieżący koszt dewelopera lub agencji utrzymującej instancję Magento przestaje odpowiadać wielkości sklepu, zwłaszcza gdy Magento 1 (dawno po końcu wsparcia) lub starzejąca się instancja Magento 2 zaczyna gromadzić niezałatane rozszerzenia.

#### Co faktycznie zmienia się w modelu danych

Katalog produktów Magento jest zbudowany na strukturze EAV (Entity-Attribute-Value), która pozwala definiować dowolne atrybuty niestandardowe dla każdego typu produktu. Model produktów Shopify jest prostszy: produkt ma stały zestaw podstawowych pól plus do trzech wymiarów opcji wariantów (jak rozmiar i kolor) oraz metafields dla wszystkiego innego. Produkty konfigurowalne i opcje niestandardowe Magento mapują się na warianty i metafields Shopify, ale to mapowanie nie jest 1:1 — zestawy atrybutów z wieloma niestandardowymi atrybutami zwykle wymagają celowo zaprojektowanego schematu metafields, a nie automatycznej konwersji atrybut po atrybucie.

Kategorie to kolejna realna różnica: Magento pozwala zagnieżdżać kategorie dowolnie głęboko i przypisywać produkt do wielu z nich z różnymi ustawieniami wyświetlania per widok sklepu. Kolekcje Shopify są płaskie — listy manualne lub oparte na regułach („smart”), a nie prawdziwe drzewo kategorii — więc głęboko zagnieżdżony katalog Magento wymaga celowo zaprojektowanej struktury kolekcji, nie prostego eksportu.

#### Adresy URL, przekierowania i co psuje się po cichu

Klucze URL i przepisania adresów w Magento są w pełni konfigurowalne per widok sklepu. Shopify wymusza własne wzorce adresów URL (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`, `/blogs/{blog}/{handle}`), których nie da się dowolnie restrukturyzować. To oznacza, że każdy zaindeksowany adres URL Magento potrzebuje jawnego przekierowania do swojego odpowiednika w Shopify — to pojedyncze najczęstsze źródło spadku pozycji po migracji, i jest całkowicie do uniknięcia dzięki właściwej mapie URL zbudowanej przed uruchomieniem, a nie łatanej po tym, jak Google zauważy błędy 404.

#### Rozszerzenia, personalizacje kasy i wielosklepowość

Ekosystem rozszerzeń Magento oraz jego możliwość personalizacji kasy, reguł cenowych i przepływów panelu administracyjnego w kodzie nie mają bezpośredniego odpowiednika w Shopify — Shopify korzysta ze sklepu z aplikacjami, a na Shopify Plus dodatkowo z Checkout Extensibility i Shopify Functions dla niestandardowej logiki kasy. Każdy niestandardowy moduł Magento wymaga jawnej decyzji: czy istnieje odpowiadająca mu aplikacja, czy potrzebna jest niestandardowa aplikacja zbudowana na API Shopify, czy funkcjonalność zostaje porzucona. To samo dotyczy konfiguracji wielu witryn/sklepów w Magento, która nie przekłada się bezpośrednio na model pojedynczego sklepu Shopify plus Markets dla sprzedaży międzynarodowej.

Nasz proces zarządzanej migracji mapuje to podczas oceny — katalogujemy Twoje aktywne rozszerzenia i moduły niestandardowe przed wyceną prac, a nie odkrywamy je w połowie migracji.

#### FAQ

Q: Czy Shopify obsłuży niestandardowe atrybuty produktów z Magento?
A: Tak, przez metafields, ale trzeba je celowo zdefiniować i zmapować — Shopify nie ma automatycznego odpowiednika zestawów atrybutów EAV z Magento. Mapujemy Twoje rzeczywiste wykorzystanie atrybutów podczas oceny, zamiast migrować każdy atrybut, jaki akurat zdefiniowało Magento.

Q: Czy moje adresy URL z Magento przekierują się automatycznie?
A: Nie. Struktura adresów URL Shopify jest stała, więc każdy istotny adres URL Magento potrzebuje jawnego przekierowania 301 do swojego nowego odpowiednika w Shopify. To rdzeń planu migracji, nie opcjonalny dodatek — zobacz naszą usługę SEO i migracji przekierowań.

Q: Co dzieje się z moimi rozszerzeniami i modułami niestandardowymi Magento?
A: Każde jest oceniane indywidualnie podczas oceny: zastąpienie istniejącą aplikacją Shopify, odbudowa jako niestandardowa aplikacja lub personalizacja motywu, albo potwierdzenie, że nie jest już potrzebne. Oznaczamy tę listę przed wyceną projektu, nie po.

Q: Czy mogę zachować funkcjonalność wielosklepową lub wielowitrynową?
A: Model wielu witryn Magento nie mapuje się bezpośrednio na Shopify. W zależności od tego, czego faktycznie potrzebujesz — osobnych marek, osobnych regionów, osobnych walut — właściwym odpowiednikiem w Shopify może być Shopify Markets, drugi sklep albo Shopify Plus Organization. Pomagamy wybrać na podstawie rzeczywistej potrzeby, a nie ogólnej odpowiedzi.

Sources:
- Shopify - migracja Twojego sklepu na Shopify: https://www.shopify.com/migrate
- Dokumentacja Adobe Commerce / Magento Open Source: https://experienceleague.adobe.com/en/docs/commerce

### Migracja z Magento (Adobe Commerce) do Shoptet

URL: https://prevedshop.com/pl/migracje/magento-do-shoptet
Language: pl
Last reviewed: 2026-09-02
Route: adobe-commerce -> shoptet

Magento i Adobe Commerce są zbudowane pod złożone katalogi, wiele store views i głęboką personalizację, kosztem drogiego hostingu i rozwoju. Shoptet to hostowana platforma dla czeskich i słowackich sprzedawców z prostszym, stałym modelem danych i wbudowanymi lokalnymi integracjami. Migracja to głównie konsolidacja: zredukowanie zestawów atrybutów, produktów konfigurowalnych, store views i własnych modułów Magento do tego, co Shoptet potrafi odwzorować, przeniesienie klientów i historii zamówień oraz ochrona adresów URL, które przynoszą ruch organiczny.

#### Kto przechodzi z Magento do Shoptet i dlaczego

Sprzedawcy robią ten krok, gdy konfiguracja Magento stała się nieproporcjonalna do biznesu: średniej wielkości czeski lub słowacki sklep płaci za hosting Magento, łatki bezpieczeństwa, licencje rozszerzeń i godziny agencji, których już nie potrzebuje. Shoptet zastępuje to miesięcznym planem, natywnymi integracjami z Zásilkovną, PPL, GoPay, Comgate, Heureką i Zboží.cz oraz zarządzanym środowiskiem. Ceną jest głębia: brak zestawów atrybutów, brak hierarchii wielu witryn, brak dowolnych rozszerzeń. Jeśli Twój biznes na nich polega, ocena powie to, zanim zacznie się jakakolwiek praca.

#### Zestawy atrybutów, produkty konfigurowalne i kategorie

Zestawy atrybutów Magento stają się jedną płaską listą parametrów Shoptet, więc nakładające się atrybuty z różnych zestawów trzeba scalić i spójnie nazwać. Produkty konfigurowalne mapują się na produkty Shoptet z wariantami; proste produkty podrzędne stają się wierszami wariantów z własnymi kodami, cenami i stanami. Produkty bundle i grupowane nie mają bezpośredniego odpowiednika i są odbudowywane jako osobne produkty lub zestawy. Drzewa kategorii przechodzą, ale kategorie kotwiczące i nawigacja warstwowa Magento są zastępowane kategoriami i filtrami parametrów Shoptet, co zwykle oznacza spłaszczenie hierarchii.

#### Store views, klienci i zamówienia

Store views Magento są często używane dla języków lub marek. Shoptet obsługuje mutacje językowe w ramach sklepu, ale nie niezależne witryny, więc każdy store view wymaga decyzji: scalić w jeden sklep Shoptet, prowadzić kilka sklepów Shoptet albo pominąć. Klienci i adresy są importowani, grupy klientów mapują się na poziomy cenowe Shoptet, a hasła są resetowane w nowym sklepie. Historia zamówień jest importowana do raportów. Własne moduły, konektory ERP i funkcje B2B są spisywane pojedynczo i dopasowywane do funkcji natywnych, dodatków lub integracji na zamówienie.

#### Przekierowania i przełączenie

Przepisy URL Magento i ścieżki kategorii w adresach produktów różnią się od wzorców Shoptet, dlatego eksportujemy wszystkie zaindeksowane adresy, budujemy pełną mapę 301 i wgrywamy ją do Shoptet przed przełączeniem DNS. Import testowy pełnego katalogu sprawdzamy pod kątem cen, VAT, stanów i wariantów, potem generujemy feedy na nowo i przesyłamy mapę witryny. Przekierowania chronią ciągłość URL i ograniczają ryzyko; pozycji nie gwarantuje żadna migracja.

#### FAQ

Q: Czy produkty konfigurowalne Magento można zmigrować do Shoptet?
A: Tak. Każdy produkt konfigurowalny staje się produktem Shoptet z wariantami, a proste produkty podrzędne wierszami wariantów z własnym kodem, ceną i stanem.

Q: Co dzieje się z zestawami atrybutów Magento?
A: Shoptet ma jedną płaską listę parametrów, więc zestawy są scalane. Zduplikowane lub sprzeczne nazwy atrybutów są czyszczone i zmieniane przed importem.

Q: Jak obsługiwane są store views Magento?
A: O każdym store view decydujemy osobno: scalić w jeden sklep Shoptet, prowadzić kilka sklepów albo pominąć. Shoptet obsługuje mutacje językowe, nie niezależne witryny.

Q: Czy zachowam klientów i historię zamówień?
A: Klienci, adresy i ceny grupowe są importowane; hasła są resetowane. Zamówienia są importowane jako historia do raportów, nie jako edytowalne aktywne zamówienia.

Sources:
- Adobe Commerce - Transfer danych (import i eksport): https://experienceleague.adobe.com/en/docs/commerce-admin/systems/data-transfer/data-transfer
- Shoptet Developers - Import danych: https://developers.shoptet.com/shoptet-tools/data-import/

### Migracja z OpenCart na Shopify

URL: https://prevedshop.com/pl/migracje/opencart-do-shopify
Language: pl
Last reviewed: 2026-07-21
Route: opencart -> shopify

OpenCart to lekka, samodzielnie hostowana platforma open source — prostsza w prowadzeniu niż Magento czy PrestaShop, ale nadal wymagająca samodzielnego zarządzania serwerem, wersją PHP, łataniem bezpieczeństwa i zgodnością PCI. Przejście na Shopify zamienia tę samodzielnie zarządzaną konfigurację na hostowaną, zarządzaną platformę. Ponieważ model danych OpenCart jest stosunkowo prosty, sama migracja jest zwykle bardziej bezpośrednia niż z cięższej platformy klasy enterprise, ale opcje produktów, konfiguracja wielosklepowa i rozszerzenia nadal wymagają celowego mapowania, a nie surowego eksportu/importu.

#### Dlaczego sprzedawcy odchodzą z OpenCart

Atutem OpenCart jest to, że jest darmowy i lekki, ale oznacza to też, że jesteś sam ze sobą, jeśli chodzi o hosting, aktualizacje bezpieczeństwa, zgodność PCI i utrzymanie kompatybilności rozszerzeń przy aktualizacjach wersji rdzenia. Wiele sklepów na OpenCart jest prowadzonych przez małe zespoły bez dedykowanych deweloperów, a bieżące obciążenie związane z wprowadzaniem łatek bezpieczeństwa i rozwiązywaniem konfliktów rozszerzeń z czasem staje się nieproporcjonalne do wielkości biznesu. Shopify usuwa to obciążenie hostingiem i łataniem bezpieczeństwa w zamian za opłatę za zarządzaną platformę.

Częstym wyzwalaczem jest ekosystem rozszerzeń: rozszerzenia OpenCart (zbudowane jako modyfikacje OCMOD lub VQMOD) mocno różnią się jakością i często przestają być utrzymywane, co staje się rosnącym ryzykiem w miarę rozwoju samej platformy i starzenia się stosu rozszerzeń sklepu.

#### Opcje produktów, kategorie i model danych

OpenCart reprezentuje warianty produktów przez „opcje” — wybory takie jak rozmiar czy kolor przypisane do produktu, z których każdy opcjonalnie wpływa na cenę i stan magazynowy. Jest to koncepcyjnie bliskie systemowi wariantów Shopify, co czyni podstawowe mapowanie produktów bardziej bezpośrednim niż z platform z pełnym modelem atrybutów EAV. Shopify nadal ogranicza produkty do trzech wymiarów opcji wariantów, więc produkty OpenCart z większą liczbą grup opcji wymagają przeniesienia części opcji do metafields zamiast wariantów.

Kategorie w OpenCart mogą być zagnieżdżone, a produkt może należeć do wielu kategorii, podobnie w duchu do kolekcji Shopify, ale ustrukturyzowane inaczej pod maską — drzewo kategorii OpenCart nie mapuje się jeden do jednego na model kolekcji manualnych/smart w Shopify, więc strukturę kolekcji zwykle trzeba zaplanować, a nie skopiować w całości.

#### Wielosklepowość, adresy URL i rozszerzenia

OpenCart obsługuje prowadzenie wielu frontów sklepowych z jednej instalacji, dzieląc jeden panel administracyjny i jeden katalog produktów między sklepy z różnymi ustawieniami. Najbliższe odpowiedniki w Shopify to Shopify Markets dla wariacji regionalnych/walutowych w ramach jednego sklepu, albo faktycznie osobne sklepy Shopify dla odrębnych marek — żadne z nich nie jest bezpośrednim dopasowaniem architektonicznym, więc właściwe podejście zależy od tego, do czego faktycznie służy konfiguracja wielosklepowa.

Ustawienia przyjaznych dla SEO adresów URL w OpenCart są konfigurowalne per sklep, więc istniejące adresy URL trzeba zmapować z jawnymi przekierowaniami 301 na stałe wzorce URL Shopify (`/products/{handle}`, `/collections/{handle}`), aby uniknąć utraty widoczności w wyszukiwarce. Rozszerzenia OpenCart obsługujące wysyłkę, płatność czy personalizację katalogu również wymagają indywidualnej oceny podczas oceny — zastąpienia aplikacją Shopify, niestandardowej budowy, albo potwierdzenia, że nie są już potrzebne.

#### FAQ

Q: Czy system opcji produktów OpenCart mapuje się czysto na warianty Shopify?
A: Czyściej niż z platform z pełnym modelem atrybutów niestandardowych, ponieważ opcje OpenCart są już koncepcyjnie bliskie wariantom Shopify. Produkty z więcej niż trzema grupami opcji wymagają zmapowania części opcji na metafields Shopify zamiast wariantów.

Q: Co dzieje się z moją konfiguracją wielosklepową OpenCart?
A: Nie ma bezpośredniego odpowiednika jeden do jednego w Shopify. W zależności od tego, czy potrzebujesz wspólnego katalogu z wariacją regionalną, czy faktycznie osobnych marek, pomagamy wybrać między Shopify Markets a osobnymi sklepami Shopify na podstawie Twoich rzeczywistych potrzeb.

Q: Czy moje adresy URL z OpenCart przekierują się automatycznie?
A: Nie. Struktura adresów URL Shopify jest stała, więc każdy zaindeksowany adres URL OpenCart potrzebuje jawnego przekierowania 301 do swojego odpowiednika w Shopify — jest to planowane jako część migracji, nie pozostawiane na czas po uruchomieniu.

Q: Co dzieje się z moimi rozszerzeniami OpenCart?
A: Każde aktywne rozszerzenie jest oceniane indywidualnie podczas oceny: zastępowane aplikacją Shopify, odbudowywane jako niestandardowa aplikacja lub personalizacja motywu, albo porzucane, jeśli nie jest już potrzebne. Oznaczamy to przed wyceną projektu.

Sources:
- Shopify - migracja Twojego sklepu na Shopify: https://www.shopify.com/migrate
- OpenCart - oficjalna strona i dokumentacja: https://www.opencart.com

### Migracja z PrestaShop na Shopify

URL: https://prevedshop.com/pl/migracje/prestashop-do-shopify
Language: pl
Last reviewed: 2026-07-21
Route: prestashop -> shopify

PrestaShop to samodzielnie hostowana platforma open source, popularna w całej Europie, zbudowana wokół natywnego wsparcia wielojęzyczności i wielowalutowości oraz elastycznego systemu „kombinacji” dla wariantów produktów. Przejście na Shopify oznacza rezygnację z bezpośredniego dostępu do serwera i bazy danych w zamian za zarządzany hosting i zgodność PCI, a także przemyślenie na nowo, w kategoriach Shopify, kilku rzeczy, które PrestaShop obsługuje natywnie — multistore, treść wielojęzyczną i kombinacje produktów — zamiast zakładać eksport jeden do jednego.

#### Dlaczego sprzedawcy odchodzą z PrestaShop

Jako platforma samodzielnie hostowana, PrestaShop przenosi na Twój zespół zarządzanie serwerem, aktualizacje wersji PHP, kompatybilność modułów oraz zgodność PCI dla kasy. To do opanowania dla sklepu z dedykowanymi zasobami technicznymi, ale staje się realnym kosztem — czas dewelopera, hosting, łatanie bezpieczeństwa — gdy sklep działa oszczędnie. Shopify przejmuje hosting, zgodność PCI i łatanie bezpieczeństwa platformy, w zamian za pewną kontrolę na niskim poziomie za przewidywalne koszty zarządzanej platformy.

Częstym wyzwalaczem jest ekosystem modułów: moduły PrestaShop bardzo różnią się jakością i utrzymaniem, a sklep budowany przez lata często niesie ze sobą kilka modułów, które nie są już aktywnie wspierane, co staje się rosnącym obciążeniem w miarę rozwoju samego PrestaShop.

#### Kombinacje, kategorie i model danych

Produkty w PrestaShop wykorzystują system „kombinacji” — atrybuty takie jak rozmiar czy kolor generują wiersze kombinacji, a PrestaShop nakłada niewiele twardych ograniczeń na to, ile atrybutów czy kombinacji może mieć produkt. Model wariantów Shopify jest bardziej ograniczony: do trzech wymiarów opcji na produkt, z metafields dostępnymi dla atrybutów, które nie pasują do modelu wariantów. Produkty z wieloma kombinacjami atrybutów PrestaShop, albo atrybutami używanymi bardziej jako dane opisowe niż prawdziwe warianty, wymagają celowego planu metafields, a nie prostej kopii atrybut po atrybucie.

Drzewo kategorii PrestaShop, podobnie jak w Magento, pozwala na dowolne zagnieżdżanie i przypisanie wielu kategorii do produktu. Kolekcje Shopify są płaskie — listy manualne lub oparte na regułach — więc głęboko zagnieżdżony katalog PrestaShop wymaga przeprojektowanej struktury kolekcji, by dobrze działać na Shopify, nie dosłownego eksportu kategorii.

#### Multistore, wielojęzyczność i wielowalutowość

Funkcja multistore w PrestaShop oraz jego natywne wsparcie wielojęzyczności i wielowalutowości są powszechnie używane przez sprzedawców z UE sprzedających na kilku rynkach z jednej instalacji. Najbliższym odpowiednikiem w Shopify jest Shopify Markets dla wariacji walut, języka i regionalnego frontu sklepu w ramach jednego sklepu, albo w niektórych przypadkach osobny sklep Shopify dla każdej marki czy regionu. Żadne z nich nie jest bezpośrednim dopasowaniem architektonicznym do multistore PrestaShop, więc właściwe podejście zależy od tego, czego sklep faktycznie potrzebuje — jednego frontu obsługującego kilka rynków, czy faktycznie osobnych frontów sklepowych — a tę decyzję należy podjąć celowo przed wyceną migracji.

#### Adresy URL, przekierowania i moduły

Ustawienia przyjaznych adresów URL w PrestaShop są w pełni konfigurowalne, więc istniejące adresy URL PrestaShop rzadko pasują domyślnie do stałych wzorców Shopify (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`). Każdy zaindeksowany adres URL PrestaShop potrzebuje jawnego przekierowania do swojego odpowiednika w Shopify, aby chronić pozycje w wyszukiwarce podczas przenosin.

Moduły PrestaShop obejmujące wysyłkę, płatność, marketing i personalizację kasy nie mają automatycznego odpowiednika w Shopify. Każdy aktywny moduł wymaga jawnej decyzji podczas oceny — zastąpienia aplikacją Shopify, odbudowy jako niestandardowa aplikacja lub personalizacja motywu, albo porzucenia — więc zakres migracji jest znany przed rozpoczęciem prac, a nie odkrywany w połowie projektu.

#### FAQ

Q: Czy Shopify obsłuży kombinacje produktów z PrestaShop?
A: Standardowe kombinacje mapują się na warianty Shopify, ale Shopify ogranicza produkty do trzech wymiarów opcji wariantów. Kombinacje wykraczające poza to, albo atrybuty używane bardziej jako dane opisowe, trzeba celowo zmapować na metafields podczas oceny.

Q: Co dzieje się z moją konfiguracją multistore PrestaShop?
A: Nie ma bezpośredniego odpowiednika architektonicznego w Shopify. W zależności od tego, czego faktycznie potrzebujesz — wspólnego katalogu z wariacją regionalną, osobnych walut czy faktycznie osobnych marek — właściwą strukturą w Shopify może być Shopify Markets albo osobne sklepy. Pomagamy wybrać na podstawie Twoich wymagań, nie domyślnej odpowiedzi.

Q: Czy moje adresy URL z PrestaShop przekierują się automatycznie na Shopify?
A: Nie. Shopify wymusza własną strukturę adresów URL, więc każdy istotny adres URL PrestaShop potrzebuje jawnego przekierowania 301 zmapowanego na swój odpowiednik w Shopify — to rdzeń planu migracji, nie opcjonalny dodatek.

Q: Co dzieje się z moimi modułami PrestaShop?
A: Każdy jest oceniany indywidualnie: zastępowany istniejącą aplikacją Shopify, odbudowywany jako niestandardowa aplikacja lub personalizacja motywu, albo potwierdzany jako już niepotrzebny. Oznaczamy tę listę podczas oceny, przed wyceną projektu.

Sources:
- Shopify - migracja Twojego sklepu na Shopify: https://www.shopify.com/migrate
- PrestaShop - oficjalna strona i dokumentacja: https://www.prestashop.com

### Migracja z PrestaShop do Shoptet

URL: https://prevedshop.com/pl/migracje/prestashop-do-shoptet
Language: pl
Last reviewed: 2026-09-02
Route: prestashop -> shoptet

PrestaShop to platforma open source, którą hostujesz i utrzymujesz samodzielnie; Shoptet to hostowany system dla czeskich i słowackich sprzedawców z wbudowaną wysyłką, płatnościami i feedami do porównywarek. Migracja zastępuje kombinacje, cechy i dane modułów PrestaShop wariantami, parametrami i dodatkami Shoptet, przenosi klientów i historię zamówień oraz odtwarza każdy zaindeksowany adres jako przekierowanie 301, aby zmiana nie zmarnowała lat widoczności w wyszukiwarkach.

#### Co sprzedawcy PrestaShop zyskują i z czego rezygnują

Shoptet zdejmuje administrację serwerem, aktualizacje PHP i pilnowanie zgodności modułów. Fakturowanie, VAT, Zásilkovna, PPL, GoPay, Comgate, Heureka i Zboží.cz są natywne, co często zastępuje kilkanaście modułów PrestaShop. Rezygnujesz z nieograniczonej personalizacji: w PrestaShop wszystko zmienia się modułem lub override'em, Shoptet daje stały zestaw pól, szablonów i dodatków. Funkcje z modułów pisanych na zamówienie trzeba ocenić na nowo, a nie kopiować.

#### Kombinacje, cechy i kategorie

Kombinacje PrestaShop (zestawy atrybutów, np. rozmiar i kolor) mapują się na warianty Shoptet; każda kombinacja staje się wierszem wariantu z własnym kodem, ceną i stanem. Cechy PrestaShop używane do filtrowania stają się parametrami Shoptet tworzonymi przed importem. Oba systemy obsługują przypisanie do wielu kategorii, ale domyślną kategorię z PrestaShop trzeba jawnie wskazać jako główną w Shoptet. Zdjęcia, opisy, tytuły i opisy meta przechodzą w imporcie; reguły cen specjalnych i ceny dla grup klientów wymagają przeglądu, bo Shoptet modeluje rabaty inaczej.

#### Klienci, zamówienia i przekierowania

Klienci są importowani z adresami i przynależnością do grup; haseł nie da się przenieść, więc reset hasła jest częścią komunikacji startowej. Zamówienia są importowane jako historia do raportów. Adresy URL PrestaShop zależą od ustawień przyjaznych adresów i często zawierają ID; Shoptet używa własnych wzorców, dlatego z mapy witryny i danych analitycznych generujemy pełną mapę 301 i weryfikujemy ją przed przełączeniem DNS. Przekierowania chronią ciągłość URL i ograniczają ryzyko; pozycje nigdy nie są gwarantowane.

#### Moduły, feedy i start

Spisujemy każdy aktywny moduł PrestaShop i decydujemy: natywny w Shoptet, dostępny jako dodatek, integracja na zamówienie albo pominięty. Feedy do porównywarek generujemy na nowo z Shoptet. Sam start to import testowy, sprawdzenie próbki cen, VAT i stanów, a potem przełączenie DNS, przy czym PrestaShop zostaje na krótko tylko do odczytu, dopóki mapa przekierowań nie zostanie potwierdzona w Google Search Console.

#### FAQ

Q: Czy kombinacje PrestaShop stają się wariantami Shoptet?
A: Tak. Każda kombinacja staje się wariantem z własnym kodem, ceną i stanem; grupy atrybutów stają się wymiarami wariantów. Niespójne nazwy atrybutów w PrestaShop są czyszczone przed importem.

Q: Czy mogę zachować historię zamówień z PrestaShop?
A: Zamówienia są importowane jako historia do wglądu i raportów. Nie są edytowalnymi aktywnymi zamówieniami, a faktury pozostają w systemie księgowym.

Q: Czy moje moduły PrestaShop będą działać w Shoptet?
A: Żaden moduł nie przenosi się bezpośrednio. Każdy mapujemy na natywną funkcję Shoptet, dodatek lub integrację na zamówienie, a zbędne pomijamy.

Q: Jak obsługujecie adresy PrestaShop z ID produktów?
A: Każdy zaindeksowany adres dostaje jawne przekierowanie 301 na odpowiednik w Shoptet, wygenerowane z mapy witryny i analityki oraz zweryfikowane przed startem.

Sources:
- PrestaShop - Dokumentacja webservice: https://devdocs.prestashop-project.org/9/webservice/
- Shoptet Developers - Import danych: https://developers.shoptet.com/shoptet-tools/data-import/

### Migracja z Shopify do WooCommerce

URL: https://prevedshop.com/pl/migracje/shopify-do-woocommerce
Language: pl
Last reviewed: 2026-09-02
Route: shopify -> woocommerce

Większość poradników opisuje tylko przejście na Shopify. Kierunek odwrotny jest równie częsty, gdy sklep chce pełnej własności danych, bogatej w treści witryny na WordPressie albo uwolnienia od prowizji transakcyjnych i subskrypcji aplikacji. Przejście z Shopify do WooCommerce oznacza przejęcie odpowiedzialności za hosting, bezpieczeństwo i aktualizacje w zamian za otwarty model danych i nieograniczoną personalizację. Sama migracja obejmuje produkty, warianty, metapola, klientów, historię zamówień, treści i pełną mapę przekierowań.

#### Dlaczego sklepy odchodzą z Shopify

Typowe powody to narastające koszty aplikacji, prowizje przy zewnętrznych bramkach płatniczych, trudny do dostosowania checkout i chęć prowadzenia sprzedaży i treści na jednej instalacji WordPressa. WooCommerce nie pobiera opłaty za platformę i przechowuje całą bazę na Twoim serwerze, co ma znaczenie dla sprzedawców z rygorystycznymi wymaganiami co do lokalizacji danych lub rozbudowaną personalizacją B2B. Druga strona medalu to operacje: wydajność hostingu, kopie zapasowe, aktualizacje wtyczek i zakres PCI są teraz po Twojej stronie albo po stronie agencji.

#### Produkty, warianty i metapola

Produkty Shopify z maksymalnie trzema wymiarami opcji czysto mapują się na produkty zmienne WooCommerce z atrybutami i wariantami. Wyjątkiem są metapola: WooCommerce nie ma wbudowanego odpowiednika, więc każde metapole jest mapowane na atrybut produktu, pole niestandardowe lub strukturę danych konkretnej wtyczki. Kolekcje stają się kategoriami lub tagami zależnie od użycia; inteligentne kolekcje oparte na regułach trzeba odtworzyć jako kategorie z ręcznym przypisaniem albo z wtyczką filtrującą. Zdjęcia, SKU, wagi i stany magazynowe przechodzą przez importer CSV lub bezpośredni proces z API do bazy danych.

#### Klienci, zamówienia i treści

Klientów można zaimportować z adresami i zgodą marketingową; hasła są haszowane inaczej na obu platformach i nigdy nie są przenoszone. Historia zamówień jest importowana do raportów i obsługi klienta, a statusy mapowane na odpowiedniki WooCommerce. Strony i wpisy blogowe z Shopify stają się stronami i wpisami WordPressa, co zwykle daje większą elastyczność edycji. Kody rabatowe i karty podarunkowe wymagają przeglądu, bo kupony WooCommerce i wtyczki kart podarunkowych nie odwzorowują dokładnie zasad Shopify.

#### Adresy URL, przekierowania i start

Shopify wymusza prefiksy `/products/`, `/collections/` i `/pages/`; WordPress pozwala ustawić bezpośrednie odnośniki dowolnie, co jest okazją do zaprojektowania czystszej struktury. Każdy zaindeksowany adres Shopify musi przed przeniesieniem domeny mapować się na adres WooCommerce przez przekierowanie 301 serwowane przez nową witrynę. Mapę przekierowań, szybkość stron i checkout testujemy na serwerze stagingowym, a potem przełączamy DNS, zostawiając sklep Shopify na krótko otwarty. Przekierowania zachowują ciągłość URL i ograniczają ryzyko; pozycji nie da się zagwarantować.

#### FAQ

Q: Czy metapola Shopify można zmigrować do WooCommerce?
A: Tak, ale nie automatycznie. Każde metapole jest mapowane na atrybut WooCommerce, pole niestandardowe lub strukturę wtyczki, którą Twój motyw potrafi wyświetlić.

Q: Czy klienci zachowają hasła po przejściu na WooCommerce?
A: Nie. Hasze haseł są specyficzne dla platformy. Klienci dostają link do resetu w nowym sklepie, najlepiej jako część ogłoszenia o starcie.

Q: Jakiego hostingu potrzebuje WooCommerce po odejściu z Shopify?
A: Zarządzany hosting WordPress z PHP 8, cache obiektowym i codziennymi kopiami zapasowymi to praktyczne minimum dla sklepu, który wcześniej działał na infrastrukturze Shopify.

Q: Czy odchodząc z Shopify stracę SEO?
A: Wzorce URL się zmieniają, więc pełna mapa przekierowań 301 jest obowiązkowa. Z przekierowaniami, tagami kanonicznymi i ponownie przesłaną mapą witryny ryzyko maleje, ale żadna migracja nie gwarantuje niezmienionych pozycji.

Sources:
- WooCommerce - Importer i eksporter produktów CSV: https://woocommerce.com/document/product-csv-importer-exporter/
- Shopify Help Center - Migracja do Shopify: https://help.shopify.com/en/manual/migrating-to-shopify

### Migracja ze Shoptet na Shopify

URL: https://prevedshop.com/pl/migracje/shoptet-do-shopify
Language: pl
Last reviewed: 2026-07-21
Route: shoptet -> shopify

Shoptet to zamknięta, hostowana platforma SaaS skupiona na rynku czeskim i słowackim, więc te przenosiny wyglądają inaczej niż migracja z platformy samodzielnie hostowanej na SaaS: obie platformy zarządzają za Ciebie hostingiem i zgodnością PCI. Prawdziwymi motorami zwykle są zasięg poza rynek CZ/SK, większy globalny ekosystem aplikacji Shopify oraz większa elastyczność designu dzięki systemowi motywów Liquid w Shopify. Ponieważ Shoptet ma zamknięty kod źródłowy, dostęp do danych opiera się na jego narzędziach eksportu i API, a nie na bezpośrednim dostępie do bazy danych, co kształtuje sposób planowania samej migracji.

#### Dlaczego sprzedawcy odchodzą ze Shoptet

Shoptet to solidna, łatwa w prowadzeniu platforma dla sprzedawców z CZ/SK, ale jest skupiona regionalnie — jej marketplace aplikacji, integracje płatności i wysyłki oraz narzędzia wielowalutowe/wielojęzyczne są zbudowane głównie wokół tego rynku. Sprzedawcy rozwijający się poza Czechy i Słowację często uznają globalny ekosystem aplikacji Shopify, jego natywne narzędzia wielowalutowe i wielojęzyczne dzięki Shopify Markets oraz szerszą bazę integracji zewnętrznych za lepsze dopasowanie do wzrostu transgranicznego.

Elastyczność designu to kolejny częsty motor: personalizacja motywów w Shoptet jest bardziej ograniczona niż system motywów oparty na Liquid w Shopify, więc sprzedawcy chcący wysoce niestandardowego designu frontu sklepu lub głębszej personalizacji kasy (dostępnej dla sprzedawców Shopify Plus) często uznają, że Shopify daje im więcej przestrzeni, by zbudować dokładnie to, czego chcą.

#### Wydobywanie danych z zamkniętej platformy

W przeciwieństwie do platform open source, gdzie można zapytać bazę danych bezpośrednio, Shoptet nie daje bezpośredniego dostępu do bazy danych — dane produktów, zamówień i klientów muszą wyjść przez narzędzia eksportu Shoptet (eksporty CSV/XML) i jego API. Oznacza to, że etap ekstrakcji danych w migracji zależy od tego, co faktycznie udostępniają eksport i API Shoptet, a wszelkie dane niedostępne przez te kanały (niektóre pola niestandardowe, historyczne metadane zamówień) trzeba zidentyfikować wcześnie, ponieważ nie da się ich po prostu pobrać z zrzutu bazy danych tak, jak z platformy samodzielnie hostowanej.

#### Dane produktowe, kategorie i warianty

Model produktów Shoptet, jak większość platform SaaS, wykorzystuje parametry/warianty dla opcji produktów takich jak rozmiar czy kolor. Mapowanie ich na system wariantów Shopify (ograniczony do trzech wymiarów opcji) jest zwykle bardziej bezpośrednie niż migracja z platformy z dowolnym modelem atrybutów niestandardowych, choć wszelkie parametry Shoptet używane bardziej do filtrowania opisowego niż jako prawdziwe warianty lepiej umieścić w metafields Shopify. Struktura kategorii Shoptet również wymaga przeglądu wobec płaskiego, opartego na kolekcjach modelu Shopify, zamiast kopiowania jako dosłowne drzewo.

#### Adresy URL, lokalizacja i aplikacje

Adresy URL Shoptet podążają za własnymi konwencjami platformy i muszą zostać zmapowane na stałe wzorce URL Shopify (`/products/{handle}`, `/collections/{handle}`) z jawnymi przekierowaniami 301 dla każdej zaindeksowanej strony, aby chronić istniejącą widoczność w wyszukiwarce — szczególnie ważne dla SEO na rynku CZ/SK budowanego przez lata. Jeśli sklep sprzedaje w wielu językach lub walutach, trzeba skonfigurować Shopify Markets, aby odtworzyć tę konfigurację, ponieważ działa on inaczej pod maską niż wbudowana lokalizacja Shoptet. Wszelkie aplikacje czy integracje z marketplace'u Shoptet (bramki płatności, przewoźnicy, narzędzia marketingowe) również wymagają indywidualnej oceny wobec sklepu z aplikacjami Shopify, aby potwierdzić, że istnieje odpowiednik lub że potrzebna jest niestandardowa budowa.

#### FAQ

Q: Jak wydobyć moje dane produktowe i dane zamówień ze Shoptet?
A: Przez narzędzia eksportu CSV/XML Shoptet i jego API — nie ma bezpośredniego dostępu do bazy danych, ponieważ to zamknięta platforma SaaS. Wcześnie identyfikujemy, które typy danych są faktycznie eksportowalne, i oznaczamy to, co nie jest, przed wyceną migracji.

Q: Czy moje adresy URL ze Shoptet przekierują się automatycznie na Shopify?
A: Nie. Struktura adresów URL Shopify jest stała i różni się od Shoptet, więc każdy zaindeksowany adres URL Shoptet potrzebuje jawnego przekierowania 301 do swojego odpowiednika w Shopify, co ma szczególne znaczenie dla widoczności w wyszukiwarce na rynku CZ/SK budowanej przez lata.

Q: Czy Shopify obsłuży sprzedaż wielojęzyczną i wielowalutową tak jak Shoptet?
A: Tak, dzięki Shopify Markets, ale konfiguruje się to inaczej niż wbudowana lokalizacja Shoptet — trzeba to celowo skonfigurować, by odtworzyć Twoją istniejącą konfigurację wielorynkową, a nie zakładać, że zadziała tak samo od razu.

Q: Dlaczego przechodzić ze Shoptet na Shopify, skoro obie to hostowane platformy SaaS?
A: Zwykłymi motorami są zasięg i elastyczność, nie obciążenie hostingiem — globalny ekosystem aplikacji Shopify, szersze integracje płatności i wysyłki dla sprzedaży transgranicznej oraz więcej opcji personalizacji motywu i kasy dla sklepów, które wyrosły z bardziej regionalnie skupionego zestawu narzędzi Shoptet.

Sources:
- Shopify - migracja Twojego sklepu na Shopify: https://www.shopify.com/migrate
- Shoptet - oficjalna strona: https://www.shoptet.cz

### Migracja z Shopware na Shopify

URL: https://prevedshop.com/pl/migracje/shopware-do-shopify
Language: pl
Last reviewed: 2026-07-21
Route: shopware-6 -> shopify

Shopware to elastyczna platforma handlowa oparta na Symfony, popularna w regionie DACH, dostępna zarówno jako rozwiązanie samodzielnie hostowane, jak i zarządzana oferta w chmurze. Przejście na Shopify oznacza rezygnację z wysoce personalizowalnego systemu encji i wtyczek Shopware na rzecz bardziej ograniczonej, ale w pełni zarządzanej platformy Shopify. Kluczowa praca to zmapowanie elastycznych właściwości produktów i modelu kanałów sprzedaży Shopware na stały schemat produktów i ekosystem aplikacji Shopify, obok zwyczajowego planowania adresów URL i przekierowań, jakiego wymaga każde przenosiny platformy.

#### Dlaczego sprzedawcy odchodzą z Shopware

Mocna strona Shopware — wysoce rozszerzalna platforma zbudowana na Symfony, z elastycznym systemem encji i głęboką personalizacją wtyczek/aplikacji — wiąże się z realnym obciążeniem przy samodzielnym hostowaniu: zarządzanie serwerem, aktualizacje wersji PHP i Shopware oraz zgodność PCI dla kasy spoczywają na Twoim zespole. Nawet opcja Shopware hostowana w chmurze nadal oznacza zarządzanie ekosystemem wtyczek, które muszą pozostać kompatybilne przy aktualizacjach. Shopify całkowicie zdejmuje z Twoich obowiązków hosting i łatanie platformy, kosztem głębszych opcji personalizacji na poziomie kodu, jakie oferuje Shopware.

Częstym wyzwalaczem jest to samo, co widać przy innych elastycznych platformach open source: czas dewelopera potrzebny do utrzymania niestandardowych wtyczek Shopware i zachowania ich działania przy aktualizacjach wersji przestaje być proporcjonalny do potrzeb sklepu, zwłaszcza dla sprzedawców, którzy wykorzystywali elastyczność Shopware mniej, niż zakładali.

#### Właściwości produktów, warianty i model danych

Shopware reprezentuje wariacje produktów przez „właściwości” i „opcje” generujące kombinacje wariantów, obok elastycznego systemu pól niestandardowych dla atrybutów poza tą strukturą. Jest to koncepcyjnie bliższe modelowi wariantów Shopify niż pełny system EAV, ale twardy limit trzech wymiarów opcji wariantów na produkt w Shopify oznacza, że produkty Shopware używające większej liczby grup właściwości wymagają przeniesienia części właściwości do metafields Shopify zamiast wariantów.

Struktura kategorii Shopware, jak większość platform z prawdziwym drzewem kategorii, pozwala na zagnieżdżone kategorie z elastycznym przypisaniem. Kolekcje Shopify są płaskie — listy manualne lub oparte na regułach, a nie zagnieżdżone drzewo — więc strukturę kategorii Shopware trzeba przeprojektować jako zestaw kolekcji Shopify, a nie eksportować bezpośrednio.

#### Kanały sprzedaży i wielosklepowość

Koncepcja „Kanału Sprzedaży” w Shopware pozwala jednej instancji Shopware obsługiwać wiele frontów sklepowych, aplikacji czy marketplace'ów z wspólnego katalogu, każdy z własnymi ustawieniami. Najbliższymi odpowiednikami w Shopify są jego własne wielokrotne kanały sprzedaży (sklep internetowy, POS, marketplace'y) plus Shopify Markets dla wariacji regionalnych i walutowych w ramach jednego sklepu, albo osobne sklepy Shopify dla faktycznie odrębnych marek. Te koncepcje się pokrywają, ale nie są bezpośrednim dopasowaniem architektonicznym, więc konfigurację kanałów sprzedaży Shopware trzeba zmapować na właściwą strukturę Shopify na podstawie tego, do czego faktycznie służy, a nie zakładać przełożenie jeden do jednego.

#### Adresy URL, wtyczki i kwestie specyficzne dla UE

Przyjazne adresy URL SEO w Shopware są konfigurowalne per kanał sprzedaży, więc istniejące adresy URL wymagają jawnych przekierowań 301 zmapowanych na stałe wzorce Shopify (`/products/{handle}`, `/collections/{handle}`), aby chronić pozycje w wyszukiwarce podczas przenosin. Wtyczki i aplikacje Shopware obejmujące wysyłkę, płatność i personalizację kasy nie mają automatycznego odpowiednika w Shopify i wymagają indywidualnej oceny — aplikacji Shopify, niestandardowej budowy, albo potwierdzenia, że funkcjonalność nie jest już potrzebna.

Shopware jest szeroko używany w całej UE i ma wbudowane narzędzia do obsługi VAT oraz wymagań związanych z RODO typowych dla tego rynku. Shopify pokrywa podobny zakres przez Shopify Tax i własne narzędzia zgodności, ale konkretna konfiguracja — rejestracja podatkowa, formatowanie faktur, ustawienia obsługi danych — musi zostać przejrzana i skonfigurowana od nowa dla Shopify, a nie zakładana jako automatycznie przenoszona.

#### FAQ

Q: Czy właściwości produktów Shopware mapują się czysto na warianty Shopify?
A: Całkiem dobrze dla standardowego użycia wariantów, ponieważ właściwości Shopware są koncepcyjnie podobne do opcji wariantów Shopify. Produkty używające więcej niż trzech grup właściwości wymagają przeniesienia części właściwości do metafields Shopify, ponieważ Shopify ogranicza produkty do trzech wymiarów opcji wariantów.

Q: Co dzieje się z moimi Kanałami Sprzedaży Shopware?
A: Nie ma dokładnego odpowiednika w Shopify — własne wielokrotne kanały sprzedaży Shopify, Shopify Markets i osobne sklepy każde pokrywają część tego, co potrafi konfiguracja Kanału Sprzedaży Shopware. Mapujemy Twój rzeczywisty przypadek użycia (regiony, marki, marketplace'y) na właściwą strukturę Shopify podczas oceny.

Q: Czy moje adresy URL z Shopware przekierują się automatycznie na Shopify?
A: Nie. Struktura adresów URL Shopify jest stała, więc każdy zaindeksowany adres URL Shopware potrzebuje jawnego przekierowania 301 do swojego odpowiednika w Shopify — jest to część planu migracji, nie refleksja po fakcie.

Q: Czy konfiguracja VAT i RODO z Shopware przenosi się na Shopify?
A: Nie automatycznie. Shopify ma własne narzędzia podatkowe i zgodności (Shopify Tax i powiązane ustawienia), ale rejestrację podatkową, formatowanie faktur i konfigurację obsługi danych trzeba przejrzeć i skonfigurować specjalnie dla Shopify, a nie zakładać, że przeniosą się z Shopware.

Sources:
- Shopify - migracja Twojego sklepu na Shopify: https://www.shopify.com/migrate
- Shopware - oficjalna strona i dokumentacja: https://www.shopware.com

### Migracja z WooCommerce na BigCommerce

URL: https://prevedshop.com/pl/migracje/woocommerce-do-bigcommerce
Language: pl
Last reviewed: 2026-07-21
Route: woocommerce -> bigcommerce

WooCommerce działa jako wtyczka do WordPressa, więc jego dane, hosting i wydajność są powiązane z Twoją instalacją WordPressa. Przejście na BigCommerce oddziela handel od Twojego stosu treści WordPress i przekazuje hosting, zgodność PCI i bezpieczeństwo platformy do BigCommerce — dając jednocześnie większą natywną elastyczność wariantów i kontrolę nad adresami URL niż większość konkurentów SaaS. Praca polega na zmapowaniu opartych na WordPressie danych produktowych i treściowych WooCommerce na strukturę BigCommerce bez utraty wartości SEO czy zepsucia funkcjonalności zależnej od wtyczek.

#### Dlaczego sprzedawcy odchodzą z WooCommerce

Sam WooCommerce jest darmowy, ale jego prowadzenie oznacza odpowiedzialność za aktualizacje rdzenia WordPressa i wtyczek, wydajność hostingu, bezpieczeństwo na poziomie serwera i zgodność PCI dla kasy. W miarę skalowania sklepu konflikty wtyczek i wpływ rosnącego stosu wtyczek na szybkość strony stają się realnymi, powtarzającymi się kosztami — nie wspominając o czasie dewelopera lub agencji potrzebnym, by utrzymać wszystko załatane i kompatybilne. BigCommerce, jako zarządzana platforma SaaS, usuwa to obciążenie hostingiem i łataniem w zamian za pracę w ramach ograniczeń swojej platformy.

Sklepy, które wyrosły ze swojej konfiguracji hostingu WordPress, albo są zmęczone kruchością stosu wtyczek w miarę skalowania strony, to najczęstsi kandydaci do tych przenosin.

#### Dane produktowe: bliższe dopasowanie, niż mogłoby się wydawać

WooCommerce przechowuje produkty jako niestandardowy typ wpisu WordPressa, z wariacjami i atrybutami zbudowanymi na taksonomiach WordPressa — elastyczne, ponieważ WordPress nakłada niewiele twardych ograniczeń na pola niestandardowe. Model produktów BigCommerce jest bardziej ustrukturyzowany, ale zauważalnie bardziej permisywny w zakresie wariantów niż niektórzy konkurenci SaaS, obsługując większą liczbę kombinacji wariantów na produkt, obok pól niestandardowych i modyfikatorów produktów dla atrybutów niepasujących do struktury wariantów. Mimo to produkty WooCommerce intensywnie wykorzystujące ACF (Advanced Custom Fields) lub wiele niestandardowych atrybutów wymagają celowego planu mapowania na pola niestandardowe BigCommerce, a nie ślepej kopii.

Kategorie i tagi WooCommerce to taksonomie WordPressa, które można dowolnie zagnieżdżać i przypisywać krzyżowo. Drzewo kategorii BigCommerce jest bliższe tradycyjnej hierarchii niż płaskie kolekcje Shopify, co czyni tłumaczenie struktury kategorii WooCommerce nieco bardziej bezpośrednim, choć nadal warto ją przejrzeć, a nie eksportować bez zmian.

#### Adresy URL, treści i wtyczki

Bezpośrednie linki (permalinki) WordPressa są w pełni konfigurowalne, więc adresy URL WooCommerce rzadko domyślnie pasują do jakiegokolwiek stałego wzorca. BigCommerce, w przeciwieństwie do niektórych platform SaaS, pozwala na niestandardowe ścieżki URL bez obowiązkowego prefiksu, co może ułatwić zachowanie istniejącej struktury URL WooCommerce — ale każdy adres URL, który się zmienia, nadal potrzebuje jawnego przekierowania 301, a każdy zaindeksowany adres URL WooCommerce i tak powinien zostać zweryfikowany wobec swojego odpowiednika w BigCommerce.

Jest też kwestia treści WordPressa: wiele sklepów WooCommerce polega na WordPressie jako pełnym CMS dla treści bloga i stron docelowych, co nie ma bezpośredniego odpowiednika w bardziej ograniczonych narzędziach treściowych BigCommerce. Sklepy z istotną ilością treści WordPress potrzebują planu — zmigrować ją na strony BigCommerce, albo utrzymać WordPress działający osobno dla treści, podczas gdy BigCommerce obsługuje handel. Wtyczki WooCommerce obejmujące wysyłkę, subskrypcje czy niestandardowe pola kasy również wymagają indywidualnej oceny: odpowiednika aplikacji BigCommerce, niestandardowej budowy, albo potwierdzenia, że nie są już potrzebne.

#### FAQ

Q: Czy BigCommerce obsłuży konfigurację wariantów i atrybutów WooCommerce?
A: BigCommerce obsługuje więcej kombinacji wariantów na produkt niż niektórzy konkurenci SaaS, co pomaga przy złożonych katalogach WooCommerce, ale nadal nie ma automatycznego odpowiednika dla pól niestandardowych WordPressa czy danych ACF — te trzeba celowo zmapować na pola niestandardowe BigCommerce.

Q: Co dzieje się z moim blogiem WordPress i stronami docelowymi?
A: Nie migrują automatycznie, ponieważ narzędzia treściowe BigCommerce są węższe niż WordPressa. Możesz zmigrować wpisy blogowe i strony na BigCommerce, albo utrzymać WordPress działający osobno dla treści, podczas gdy BigCommerce obsługuje handel — pomagamy zdecydować na podstawie tego, ile ruchu generuje ta treść.

Q: Czy moje adresy URL WooCommerce będą musiały się zmienić na BigCommerce?
A: Mniej, niż mógłbyś się spodziewać przy przejściu na niektóre inne platformy SaaS, ponieważ BigCommerce pozwala na niestandardowe ścieżki URL bez obowiązkowego prefiksu. Każdy adres URL, który się zmienia, nadal potrzebuje jawnego przekierowania 301, a i tak audytujemy każdy zaindeksowany adres URL WooCommerce przed uruchomieniem.

Q: Czy BigCommerce zastąpi wszystkie moje wtyczki WooCommerce?
A: Większość ma odpowiednik w postaci aplikacji BigCommerce, ale nie wszystkie — część funkcjonalności wtyczek wymaga niestandardowej budowy na bazie API BigCommerce, a część jest porzucana, jeśli nie jest już potrzebna. Katalogujemy Twoje aktywne wtyczki podczas oceny przed wyceną prac.

Sources:
- BigCommerce - oficjalna strona i dokumentacja: https://www.bigcommerce.com
- Dokumentacja WooCommerce: https://woocommerce.com/documentation/

### Migracja z WooCommerce na Shopify

URL: https://prevedshop.com/pl/migracje/woocommerce-do-shopify
Language: pl
Last reviewed: 2026-07-21
Route: woocommerce -> shopify

WooCommerce działa jako wtyczka na WordPressie, co oznacza, że dane, hosting i wydajność Twojego sklepu są splątane z Twoją instalacją WordPressa. Przejście na Shopify oddziela handel od treści: otrzymujesz zarządzaną, zgodną z PCI platformę hostingową i model produktu/kasy zaprojektowany celowo, ale tracisz też natywną elastyczność WordPressa dla treści i bezpośrednią równoważność wtyczka-aplikacja, jakiej mógłbyś oczekiwać. Kluczowa praca to zmapowanie opartego na WordPressie modelu danych WooCommerce na stały schemat Shopify bez utraty wartości SEO czy zepsucia niestandardowej funkcjonalności po drodze.

#### Dlaczego sprzedawcy odchodzą z WooCommerce

WooCommerce jest darmowy do zainstalowania, ale jego dobre prowadzenie już nie: odpowiadasz za aktualizacje rdzenia WordPressa i wtyczek, wydajność hostingu, bezpieczeństwo na poziomie serwera oraz zgodność PCI dla wszystkiego, co dotyka danych płatności. W miarę wzrostu sklepu konflikty wtyczek, problemy z szybkością strony wynikające z rosnącego stosu wtyczek oraz powtarzający się koszt dewelopera lub agencji utrzymującej wszystko załatane stają się prawdziwym kosztem „darmowego” oprogramowania. Shopify zamienia to bieżące obciążenie utrzymaniem na stałą opłatę za platformę i zarządzane, zgodne z PCI środowisko.

Częstym wyzwalaczem jest skala: wydajność WooCommerce mocno zależy od jakości hostingu i dyscypliny w zarządzaniu wtyczkami, a sklepy, które zaczynały małe, często osiągają punkt, w którym ruch lub wielkość katalogu przerastają to, do czego zbudowana była ich konfiguracja hostingu WordPress.

#### Co zmienia się w modelu danych

WooCommerce przechowuje produkty jako niestandardowy typ wpisu WordPressa, z wariacjami, atrybutami i kategoriami zbudowanymi na taksonomiach WordPressa — elastyczna struktura, ponieważ WordPress nakłada niewiele ograniczeń na pola niestandardowe. Model produktów Shopify jest bardziej ograniczony: stały zestaw podstawowych pól, do trzech wymiarów opcji wariantów oraz metafields dla wszystkiego poza tym. Produkty z wieloma niestandardowymi atrybutami WooCommerce lub danymi ACF (Advanced Custom Fields) wymagają celowo zaplanowanej struktury metafields, a nie ślepej kopii pole po polu.

Kategorie i tagi produktów WooCommerce to taksonomie WordPressa, które można dowolnie zagnieżdżać i przypisywać krzyżowo. Kolekcje Shopify to albo listy manualne, albo kolekcje oparte na regułach („smart”), a nie prawdziwe drzewo taksonomii, więc głęboką strukturę kategorii WooCommerce zwykle trzeba przeprojektować jako płaższy zestaw kolekcji, nie eksportować bez zmian.

#### Adresy URL, przekierowania i kwestia treści

Bezpośrednie linki (permalinki) WordPressa są w pełni konfigurowalne, więc adresy URL produktów i kategorii WooCommerce mogą wyglądać niemal dowolnie, w zależności jak strona zdecydowała się je skonfigurować. Shopify wymusza własne wzorce (`/products/{handle}`, `/collections/{handle}`, `/pages/{handle}`, `/blogs/{blog}/{handle}`), więc każdy zaindeksowany adres URL WooCommerce, który jeszcze nie pasuje, potrzebuje przekierowania 301, by przetrwać przenosiny bez utraty pozycji w wyszukiwarce.

Jest też kwestia treści specyficzna dla tej pary: WordPress to pełny CMS, a wiele sklepów WooCommerce opiera się na nim dla treści bloga, stron docelowych i niestandardowych szablonów stron. Narzędzia bloga i stron w Shopify są prostsze niż w WordPressie. Sklepy z istotną ilością treści WordPress potrzebują planu dla tej treści — zmigrować ją na strony/blog Shopify, albo utrzymać osobną instancję WordPressa dla treści, podczas gdy Shopify obsługuje handel — decyzję podjętą celowo, a nie odkrytą po przełączeniu.

#### Wtyczki, kasa i bramki płatności

Ekosystem wtyczek WooCommerce obejmuje wszystko od kalkulatorów wysyłki po fakturowanie subskrypcyjne po niestandardowe pola kasy, często przez wtyczki zewnętrzne bez bezpośredniego odpowiednika w Shopify. Każda aktywna wtyczka wymaga jawnej decyzji podczas migracji: odpowiadająca jej aplikacja Shopify, niestandardowa aplikacja lub personalizacja motywu, albo potwierdzenie, że funkcjonalność nie jest już potrzebna. Bramki płatności również wymagają rekonfiguracji — WooCommerce obsługuje szeroki zakres wtyczek bramek, podczas gdy Shopify centralizuje płatności przez Shopify Payments lub wspieraną bramkę zewnętrzną, więc wszelka niestandardowa logika kasy powiązana z konkretną wtyczką płatniczą WooCommerce musi zostać odbudowana dla modelu kasy Shopify.

#### FAQ

Q: Czy moje pozycje SEO z WooCommerce przetrwają przejście na Shopify?
A: Mogą, ale tylko przy celowym mapowaniu przekierowań. Permalinki WordPressa i stała struktura URL Shopify rzadko pasują dokładnie, więc każdy zaindeksowany adres URL WooCommerce potrzebuje jawnego przekierowania 301 do swojego odpowiednika w Shopify przed uruchomieniem — zobacz naszą usługę SEO i migracji przekierowań.

Q: Co dzieje się z moim blogiem WordPress i stronami docelowymi?
A: Nie migrują automatycznie, ponieważ narzędzia treściowe Shopify są węższe niż WordPressa. Możesz zmigrować wpisy blogowe i strony na Shopify, albo utrzymać osobną instancję WordPressa dla treści, podczas gdy Shopify obsługuje handel — pomagamy zdecydować na podstawie tego, jak duża część Twojego ruchu zależy od tej treści.

Q: Czy Shopify zastąpi wszystkie moje wtyczki WooCommerce?
A: Większość ma odpowiednik w postaci aplikacji Shopify, ale nie wszystkie — część funkcjonalności wtyczek WooCommerce wymaga niestandardowej aplikacji lub personalizacji motywu na Shopify, a część jest porzucana, jeśli nie jest już potrzebna. Katalogujemy Twoje aktywne wtyczki podczas oceny przed wyceną prac.

Q: Co dzieje się z wariacjami produktów i niestandardowymi atrybutami WooCommerce?
A: Standardowe wariacje mapują się na system wariantów Shopify, ograniczony do trzech wymiarów opcji. Niestandardowe atrybuty WooCommerce i pola ACF wykraczające poza to trzeba celowo zmapować na metafields Shopify — nie ma automatycznej konwersji jeden do jednego z pól niestandardowych WordPressa.

Sources:
- Shopify - migracja Twojego sklepu na Shopify: https://www.shopify.com/migrate
- Dokumentacja WooCommerce: https://woocommerce.com/documentation/

### Migracja z WooCommerce do Shoptet

URL: https://prevedshop.com/pl/migracje/woocommerce-do-shoptet
Language: pl
Last reviewed: 2026-09-02
Route: woocommerce -> shoptet

Shoptet to hostowana platforma stworzona dla czeskich i słowackich sprzedawców, z natywną obsługą lokalnych przewoźników, bramek płatniczych, zasad fakturowania i feedów do porównywarek. Przejście z WooCommerce oznacza porzucenie samodzielnie hostowanego WordPressa na rzecz zarządzanego systemu ze stałym modelem danych. Sama migracja to głównie przełożenie wpisów produktowych, taksonomii i danych z wtyczek WordPressa na strukturę importu Shoptet, zachowanie historii klientów i zamówień tam, gdzie ma to znaczenie, oraz ochrona adresów URL, które przynoszą ruch z wyszukiwarek.

#### Dlaczego sprzedawcy przechodzą z WooCommerce do Shoptet

Większość sklepów zmienia platformę, bo dobre utrzymanie WordPressa kosztuje czas: aktualizacje wtyczek, wydajność hostingu, łatki bezpieczeństwa i odpowiedzialność za PCI spadają na sprzedawcę. Shoptet zastępuje to miesięczną opłatą i zarządzanym środowiskiem, które od razu obsługuje Zásilkovnę, PPL, GoPay, Comgate, Heurekę i Zboží.cz. Jeśli klienci są w Czechach lub na Słowacji, wbudowane integracje zwykle usuwają kilka wtyczek naraz. Ceną jest elastyczność: model produktów i treści w Shoptet jest węższy niż w WordPressie, więc wszystko niestandardowe potrzebuje z góry ustalonego miejsca.

#### Mapowanie produktów, wariantów i parametrów

WooCommerce przechowuje produkty jako wpisy WordPressa z atrybutami, wariantami i kategoriami opartymi na taksonomiach. Shoptet oczekuje ustrukturyzowanego importu, w którym produkty, warianty, parametry, kategorie i dostępność są zdefiniowane w jego własnych polach. Warianty przechodzą na warianty Shoptet, o ile struktura opcji jest spójna; atrybuty używane do filtrowania stają się parametrami, które trzeba utworzyć i nazwać przed importem. Drzewa kategorii mogą być zagnieżdżone w obu systemach, ale Shoptet działa najlepiej z czystą, płytką hierarchią. Pola niestandardowe z ACF lub wtyczek nie mają automatycznego celu i są rozstrzygane pojedynczo: tekst opisu, parametr albo pominięcie.

#### Klienci, zamówienia i przekierowania URL

Konta klientów można zaimportować z danymi kontaktowymi i adresami; haseł nie da się przenieść, więc klient przechodzi w nowym sklepie procedurę resetu. Historia zamówień jest importowana jako podgląd i do raportów, nie jako edytowalne aktywne zamówienia. Najbardziej wrażliwą częścią są adresy URL: bezpośrednie odnośniki WordPressa są dowolne, a Shoptet używa własnych wzorców ścieżek, dlatego każdy zaindeksowany produkt, kategoria i strona potrzebują przed startem przekierowania 301 na odpowiednik w Shoptet. Przekierowania zachowują ciągłość URL i ograniczają ryzyko; żadna migracja nie gwarantuje niezmienionych pozycji.

#### Przełączenie i pierwsze dni w Shoptet

Zalecamy uruchomienie sklepu Shoptet najpierw w trybie testowym z pełnym zaimportowanym katalogiem, sprawdzenie próbki produktów, cen, stawek VAT i wariantów, a dopiero potem przełączenie DNS. Feedy dla Heureki i Zboží.cz trzeba wygenerować ponownie z Shoptet i przesłać, a Google Search Console powinno w dniu startu otrzymać nową mapę witryny. Zostaw WordPressa krótko w trybie tylko do odczytu, aby nic nie przepadło, dopóki mapa przekierowań nie zostanie potwierdzona.

#### FAQ

Q: Czy mogę zmigrować zamówienia i klientów z WooCommerce do Shoptet?
A: Klientów z adresami można zaimportować. Zamówienia są importowane jako historia do wglądu; nie stają się edytowalnymi aktywnymi zamówieniami. Haseł nigdy nie da się przenieść, więc klient ustawia nowe przy pierwszym logowaniu.

Q: Czy moje adresy URL z WooCommerce będą działać w Shoptet?
A: Tylko z jawną mapą przekierowań 301. Wzorce URL WordPressa i Shoptet różnią się, dlatego budujemy mapowanie na podstawie zaindeksowanych adresów i weryfikujemy je przed startem.

Q: Co stanie się z wtyczkami WooCommerce?
A: Każdą wtyczkę przeglądamy. Wiele funkcji dla rynku czeskiego jest natywnych w Shoptet, część ma dodatki, a reszta wymaga rozwiązania na zamówienie lub zostaje pominięta decyzją.

Q: Ile trwa migracja z WooCommerce do Shoptet?
A: Typowy mały lub średni katalog zajmuje dwa do czterech tygodni wraz z testem, przekierowaniami i startem; złożone struktury parametrów lub duża historia zamówień trwają dłużej.

Sources:
- Shoptet Developers - Import danych: https://developers.shoptet.com/shoptet-tools/data-import/
- WooCommerce - Importer i eksporter produktów CSV: https://woocommerce.com/document/product-csv-importer-exporter/

### Guides

### Jak wybrać platformę e-commerce, zanim zaczniesz migrację

URL: https://prevedshop.com/pl/poradniki/jak-wybrac-platforme-ecommerce
Language: pl
Last reviewed: 2026-09-02

Wybór platformy to decyzja, która kształtuje koszt każdej późniejszej migracji. Listy funkcji od dostawców rzadko pomagają, bo większość nowoczesnych platform pokrywa podstawy. Przydatne pytania dotyczą struktury katalogu, rynku, na który sprzedajesz, systemów, które muszą pozostać podłączone, tego, ile własności danych chcesz, i tego, czego wymaga sama migracja. Ten poradnik przechodzi przez te pięć pytań i kończy się krótką listą sygnałów ostrzegawczych, które powinny zatrzymać decyzję.

#### Zacznij od katalogu, nie od listy funkcji

Policz produkty, warianty i parametry i przyjrzyj się, jak są powiązane. Trzy wymiary opcji z czystym zestawem atrybutów filtrowania zmieszczą się niemal w każdej platformie. Zestawy atrybutów różne dla typów produktów, bundle, konfiguratory, cenniki B2B lub tysiące wariantów zawężają wybór do platform z bogatszym modelem danych, takich jak Adobe Commerce, Shopware czy architektura composable. Zapisz pięć najbardziej kłopotliwych produktów z katalogu i zapytaj każdą kandydującą platformę, jak by je przechowała; odpowiedzi mówią więcej niż jakakolwiek tabela porównawcza.

#### Rynek, język i integracje

Sklep sprzedający klientom czeskim i słowackim potrzebuje lokalnych przewoźników, bramek płatniczych, feedów do porównywarek i zasad fakturowania. Shoptet lub Upgates dają to natywnie; globalna platforma SaaS zrobi to przez aplikacje kosztem dodatkowych opłat i utrzymania. Sprzedaż do kilku krajów rodzi inne pytania: mutacje językowe, waluty, VAT i to, czy właściwym kształtem jest jeden sklep, czy kilka. Wypisz systemy, które muszą pozostać podłączone - ERP, księgowość, magazyn, PIM, feedy marketplace - i sprawdź, czy każdy kandydat ma utrzymywany konektor, czy tylko API, pod które musiałbyś budować sam.

#### Własność, koszt i ścieżka migracji

Platformy hostowane wymieniają kontrolę na wygodę: nie dotykasz bazy danych, ale też nigdy nie łatasz serwera. Platformy open source dają Ci dane i odpowiedzialność. Koszt całkowity obejmuje licencję lub plan, hosting, aplikacje lub rozszerzenia, godziny agencji i wewnętrzny czas poświęcony na aktualizacje. Na koniec wyceń samą migrację: ile danych przenosisz, czy liczy się historia zamówień i konta klientów, ile adresów potrzebuje przekierowań i które funkcje na zamówienie trzeba odbudować. Platforma tańsza na papierze może wyjść drożej po doliczeniu wysiłku migracji.

#### Sygnały ostrzegawcze, które powinny zatrzymać decyzję

Bądź ostrożny, gdy platforma nie potrafi pokazać, jak odwzoruje konkretny typ danych z Twojego obecnego sklepu, gdy kluczowa integracja istnieje tylko jako aplikacja zewnętrzna o niejasnym utrzymaniu, gdy dostawca obiecuje, że pozycje po migracji się nie zmienią, albo gdy nikt nie umie wyjaśnić, jak później opuściłbyś platformę. Krótkie discovery z prawdziwymi próbkami danych rozstrzyga większość z tych kwestii, zanim cokolwiek podpiszesz.

#### FAQ

Q: Czy platformę wybrać przed oceną migracji, czy po niej?
A: Najlepiej, gdy ocena wpływa na wybór. Krótkie discovery z prawdziwymi próbkami produktów, klientów i zamówień pokazuje, jak każdy kandydat przechowałby Twoje dane i ile odbudowy wymagałaby migracja.

Q: Czy platforma hostowana jest zawsze tańsza niż open source?
A: Nie zawsze. Hostowane mają przewidywalne opłaty, ale koszty aplikacji rosną; open source nie ma licencji, ale wymaga hostingu, aktualizacji i czasu programistów. Porównaj koszt całkowity w trzy lata, łącznie z migracją.

Q: Jak ważna jest platforma e-commerce dla SEO?
A: Mniej niż sam proces migracji. Każda popularna platforma może dobrze rankować; widoczność traci się przez brak mapy przekierowań, zmienioną treść lub wolne strony po przenosinach.

Q: Czy będę mógł później znów zmienić platformę?
A: Tak, jeśli dane pozostaną eksportowalne. Przed wyborem sprawdź, czy produkty, klientów, zamówienia i treści da się wyeksportować w ustrukturyzowanym formacie, aby kolejna migracja była możliwa bez pomocy dostawcy.

Sources:
- Google Search Central: Przenosiny witryny ze zmianą adresów URL: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### Lista kontrolna QA po uruchomieniu

URL: https://prevedshop.com/pl/poradniki/lista-kontrolna-po-uruchomieniu
Language: pl
Last reviewed: 2026-07-21

Migracja nie kończy się w chwili uruchomienia nowego sklepu — kończy się, gdy celowo potwierdzisz, że wszystko, na czym polegają klienci i wyszukiwarki, faktycznie działa w realnych warunkach. Środowisko testowe wyłapuje większość problemów, ale kilka ujawnia się dopiero przy żywym ruchu, prawdziwych operatorach płatności i ponownym indeksowaniu strony przez wyszukiwarki. Ta lista kontrolna obejmuje to, co warto sprawdzić w dniach i tygodniach po przełączeniu, niezależnie od tego, jakie platformy były zaangażowane.

#### Zweryfikuj cały proces zakupowy w realnych warunkach

Przeprowadź kompletny zakup samodzielnie na żywej stronie — nie w środowisku testowym — obejmując ścieżki, z których faktycznie korzystają klienci: zakup jako gość i zakup zalogowanego użytkownika, przynajmniej jeden produkt z wariantami oraz wszelkie aktualnie aktywne kody rabatowe czy promocje. Sprawdź, czy e-maile z potwierdzeniem zamówienia wysyłają się poprawnie i czy zamówienie następnie prawidłowo pojawia się w Twoim panelu administracyjnym/systemie zamówień.

Nie zakładaj, że pokrycie testowe przenosi się automatycznie. Żywe bramki płatności, żywe usługi podatkowe i żywe API stawek wysyłki czasem zachowują się inaczej niż ich odpowiedniki testowe czy sandboksowe, dlatego właśnie potrzeba tu prawdziwej weryfikacji w realnych warunkach, a nie polegania na tym, co przeszło w środowisku testowym.

#### Potwierdź, że bramki płatności są w pełni aktywne i poprawnie skonfigurowane

Zweryfikuj, że przetwarzanie płatności działa w trybie live (nie testowym/sandboksowym), że wszystkie metody płatności wcześniej obsługiwane przez sklep są włączone i działają, oraz że prawdziwa transakcja rozlicza się poprawnie od początku do końca — środki faktycznie docierają, nie tylko zmienia się status zamówienia. Sprawdź też funkcję zwrotów, ponieważ jest używana rzadziej niż kasa i łatwo pozostawić ją niezweryfikowaną.

Jeśli obsługujesz wiele metod płatności lub walut, przetestuj każdą osobno, zamiast zakładać, że skoro jedna metoda działa, pozostałe są skonfigurowane tak samo.

#### Sprawdź zasady podatków i wysyłki na prawdziwych zamówieniach

Logika podatków i wysyłki łatwo ulega subtelnym błędom podczas migracji, ponieważ obie często zależą od konfiguracji, która nie mapuje się czysto między platformami. Złóż testowe zamówienia do Twoich najczęstszych miejsc docelowych wysyłki i potwierdź, że podatek jest naliczany poprawnie, a stawki wysyłki i dostępne metody odpowiadają temu, co zamierzałeś — a nie tylko temu, co nowa platforma ustawiła domyślnie.

Zwróć szczególną uwagę na wszelkie szczególne przypadki, na których polega Twoja firma: zwolnienia podatkowe, progi darmowej wysyłki, zasady specyficzne dla regionu czy ograniczenia wysyłki dla niektórych produktów. To właśnie te szczegóły konfiguracji najczęściej giną albo ustawiają się domyślnie błędnie podczas migracji.

#### Wyrywkowo sprawdź przekierowania, nie tylko te, które pamiętasz

Nawet mając kompletną mapę przekierowań zbudowaną przed uruchomieniem, sprawdź wyrywkowo realną próbkę adresów URL po przełączeniu: strony o najwyższym ruchu, kilka o niższym ruchu oraz kilka celowych wyjątków (wycofane produkty, scalone kategorie). Potwierdź, że każdy przekierowuje na właściwy cel jednym skokiem, bez łańcuchów czy pętli.

Sprawdź też próbkę adresów URL, które nie powinny istnieć na starej stronie — literówki, stare adresy URL oparte na parametrach, cokolwiek, co robot indeksujący mógł przypadkowo zaindeksować — aby upewnić się, że rozwiązują się sensownie, zamiast zwracać błąd w sposób, który wygląda na szerszy problem.

#### Potwierdź ciągłość analityki i śledzenia

Zweryfikuj, że Twoja platforma analityczna, śledzenie konwersji oraz wszelkie piksele reklamowe działają poprawnie na nowej stronie — złożone testowe zamówienie powinno pojawić się w raportowaniu Twojej analityki i platform reklamowych tak samo jak wcześniej. Kod śledzący łatwo zgubić po cichu podczas zmiany platformy, ponieważ brakujący lub źle skonfigurowany piksel nie generuje komunikatu błędu — po prostu przestaje raportować dane.

Porównuj wczesne dane analityczne po uruchomieniu z Twoim wynikiem sprzed migracji dla tego samego typu dnia (dzień roboczy w porównaniu do weekendu, podobne źródła ruchu), a nie surowe porównanie przed/po, ponieważ normalna zmienność ruchu może inaczej maskować lub imitować rzeczywisty problem ze śledzeniem.

#### Sprawdź dostęp do kont klientów i historię zamówień

Poproś kilka prawdziwych (lub testowych) kont klientów o potwierdzenie, że mogą się zalogować, widzą poprawną historię zamówień i mają dostęp do funkcji konta, na których wcześniej polegali — zapisane adresy, zapisane metody płatności tam, gdzie dotyczy, salda punktów lojalnościowych, jeśli sklep je ma. Problemy z dostępem do konta są wysoce widoczne dla klientów, którzy ich doświadczają, i bezpośrednio wpływają na zaufanie, więc warto je zweryfikować celowo, a nie zakładać, że migracja konta „prawdopodobnie zadziałała”.

Jeśli migracja haseł nie była częścią technicznego przeniesienia (co zdarza się, gdy platformy używają niekompatybilnego hashowania haseł), upewnij się, że klienci mają jasną ścieżkę resetu hasła i że jest ona zakomunikowana, a nie tylko technicznie dostępna.

#### Monitoruj pokrycie w Search Console w kolejnych tygodniach

Obserwuj Search Console (lub odpowiednik dla innych wyszukiwarek) długo po dniu uruchomienia — błędy indeksowania, status indeksacji oraz wszelkie skoki zgłaszanych błędów 404 to najwcześniejsze sygnały problemu z przekierowaniem lub tagiem kanonicznym, który umknął testom. Porównuj z wynikiem sprzed migracji, aby odróżnić prawdziwą regresję od normalnej krótkoterminowej fluktuacji po zmianie strony.

Ten okres monitorowania to też dobry moment, by ponownie przesłać mapę strony, jeśli jeszcze tego nie zrobiłeś, i potwierdzić, że strony, które mają być zaindeksowane, faktycznie pojawiają się w wynikach wyszukiwania w kolejnych tygodniach, a nie tylko są odwiedzane przez roboty.

#### FAQ

Q: Jak długo powinno trwać QA po uruchomieniu?
A: Aktywne, codzienne sprawdzanie zwykle ma największe znaczenie w pierwszym lub dwóch tygodniach, gdy ujawnia się większość problemów z konfiguracją i przekierowaniami. Ponowne indeksowanie przez wyszukiwarki i stabilizacja wzorców ruchu trwają dłużej, więc lżejsze monitorowanie (Search Console, trendy analityczne) warto utrzymywać dłużej — częste jest kilka tygodni — zamiast przestawać, gdy tylko pierwszy tydzień wygląda czysto.

Q: Co najważniejsze sprawdzić najpierw po uruchomieniu?
A: Prawdziwy, żywy test kasy i płatności, ponieważ bezpośrednio wpływa on na przychody i jest jedyną ścieżką, z którą styka się każdy klient. Problemy z przekierowaniami i śledzeniem też mają znaczenie, ale zepsuta kasa jest najkosztowniejszym problemem do pozostawienia niewykrytym nawet przez kilka godzin.

Q: Czy to normalne, że pozycje w wyszukiwarce lekko spadają zaraz po migracji?
A: Pewna krótkoterminowa fluktuacja jest częsta nawet przy dobrze przeprowadzonej migracji, ponieważ wyszukiwarki potrzebują czasu na ponowne zaindeksowanie i ocenę nowych adresów URL. Nienormalny jest utrzymujący się spadek lub skok błędów indeksowania — to sygnał, by sprawdzić mapę przekierowań i tagi kanoniczne pod kątem rzeczywistego błędu, zamiast czekać, aż samo minie.

Q: Kto w zespole powinien odpowiadać za QA po uruchomieniu?
A: Najlepiej ktoś z widokiem na cały sklep, nie tylko zespół techniczny migracji — ponieważ kilka z tych kontroli (czy zasady podatkowe wyglądają dobrze, zachowanie kont klientów, czy numery śledzenia wyglądają normalnie) korzysta z kontekstu biznesowego, a nie tylko technicznej weryfikacji, że funkcja jest obecna.

Sources:
- Google Search Central: przenosiny strony ze zmianą adresów URL: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### Czyszczenie danych produktowych przed migracją

URL: https://prevedshop.com/pl/poradniki/czyszczenie-danych-produktowych-przed-migracja
Language: pl
Last reviewed: 2026-07-21

Migracja platformy kopiuje wszystko, co jej dasz — nie sprząta po Tobie. Zduplikowane SKU, osierocone obrazy, niespójne kategorie i niedopasowane struktury wariantów, które po cichu narastały przez lata, przeniosą się na nową platformę dokładnie w takiej postaci, chyba że ktoś zajmie się nimi wcześniej. Wykonanie tego porządkowania przed migracją jest znacznie tańsze niż robienie tego po niej, gdy klienci i wyszukiwarki już polegają na wyniku. Ten przewodnik opisuje, na co zwrócić uwagę i jak się do tego zabrać.

#### Znajdź i rozwiąż zduplikowane SKU oraz niemal identyczne produkty

Wyeksportuj pełną listę produktów i najpierw sprawdź dokładne duplikaty SKU — to zwykle błąd wprowadzania danych lub importu i są proste do scalenia po znalezieniu. Następnie poszukaj bliskich duplikatów: tego samego produktu odtworzonego pod innym SKU, często w wyniku ponownego importu feedu dostawcy, który nie dopasował się do istniejących rekordów, albo produktu ręcznie odtworzonego zamiast edytowanego po zmianie systemu.

Dla każdej pary duplikatów zdecyduj, który rekord jest tym „prawdziwym” — zwykle ten z bardziej kompletnymi danymi, większą historią zamówień lub lepszymi sygnałami SEO jak linki zwrotne czy opinie — i scal albo przekieruj drugi do niego, zamiast migrować oba i rozwiązywać to później na nowej platformie.

#### Wytrop osierocone obrazy i media

Osierocone media — obrazy i pliki wgrane do biblioteki mediów, do których nie odwołuje się już żaden produkt, kategoria czy strona treściowa — naturalnie narastają przez lata aktualizacji produktów, kampanii sezonowych i zmian platformy. Nie dodają żadnej wartości na nowej platformie, a jedynie wydłużają czas migracji i zwiększają zajętość miejsca, więc warto je zidentyfikować i wykluczyć.

Uważaj też na przypadek odwrotny: obrazy, do których się odwołuje, ale które są zepsute (brakujący plik, martwy zewnętrzny adres URL), warto wyłapać teraz, ponieważ zepsuty obraz na stronie produktu to mały, ale realny problem sygnału zaufania, dużo łatwiejszy do naprawienia przy Twoich obecnych, znanych danych niż po przenosinach.

#### Ujednolić kategorie i atrybuty

Lata doraźnych dodatków mają tendencję do pozostawiania kategorii i atrybutów niespójnymi: to samo pojęcie zapisane lub napisane wielkimi literami inaczej w różnych produktach, kategorie, które się nakładają lub dublują, atrybuty używane w jednym celu w jednej linii produktowej i w innym celu w drugiej. Ta niespójność zwykle nie powoduje widocznych problemów na starej platformie, gdzie personel nauczył się jej obchodzić, ale staje się realnym obciążeniem, gdy zostanie mechanicznie zmapowana na model danych nowej platformy.

Zbuduj (lub potwierdź) czystą, uzgodnioną taksonomię przed migracją — zdefiniowane drzewo kategorii i zdefiniowaną listę atrybutów ze spójnym nazewnictwem — i zweryfikuj wobec niej swoje rzeczywiste dane. To też dobry moment, by zapytać, które atrybuty nadal mają znaczenie dla klientów lub operacji wewnętrznych, a które istnieją tylko dlatego, że nikt ich nie usunął.

#### Rozwiąż niedopasowania struktury wariantów

Struktury wariantów (rozmiar, kolor, materiał i sposób ich łączenia w konkretne sprzedawalne SKU) są obsługiwane różnie na różnych platformach, a niespójne dane źródłowe pogarszają sytuację. Poszukaj produktów, w których opcje wariantów nie są spójne — niektóre warianty rozmiaru nazwane „S/M/L”, a inne „Small/Medium/Large” dla tej samej linii produktowej, albo produktów, w których kombinacja wariantów istnieje w Twoim systemie, ale nie ma za sobą ważnej ceny czy stanu magazynowego.

Zdecyduj o docelowym modelu wariantów przed migracją, nie w jej trakcie. Wiedza z wyprzedzeniem, czy nowa platforma obsługuje kombinacje wariantów tak samo jak stara — i gdzie tego nie robi — decyduje o tym, czy Twoje istniejące dane wariantów mogą mapować się bezpośrednio, czy najpierw wymagają restrukturyzacji.

#### Zdecyduj, co naprawdę musi się przenieść

Nie wszystko w Twoim obecnym katalogu zasługuje na miejsce na nowej platformie. Wycofane produkty bez pozostałego stanu magazynowego, wpisy testowe czy zastępcze oraz pola historyczne, których pierwotnego celu nikt nie potrafi wyjaśnić, to wszystko kandydaci do pozostawienia — z udokumentowaną decyzją, a nie cichym pominięciem. Migrowanie mniej, ale celowo, jest często lepsze niż migrowanie wszystkiego i rozwiązywanie tego później na nieznanym nowym systemie.

Dla wszystkiego, czego zdecydujesz się nie migrować, a co nadal ma zaindeksowany adres URL, upewnij się, że jest to uwzględnione w Twoim planie przekierowań (zobacz przewodnik po mapowaniu przekierowań), zamiast zostawić to przypadkowo jako błąd 404.

#### FAQ

Q: Ile czasu powinniśmy przeznaczyć na czyszczenie danych przed migracją?
A: Zależy w dużej mierze od wielkości katalogu i tego, jak bardzo dane są faktycznie zabałaganione — mały, dobrze utrzymany katalog wymaga znacznie mniej czasu niż taki z dziesiątkami tysięcy SKU i latami importów feedów dostawców. Audyt danych na początku pokazuje realny zakres; pominięcie audytu i zgadywanie to sposób, w jaki czas czyszczenia zostaje niedoszacowany.

Q: Czy powinniśmy czyścić dane przed migracją, czy w jej trakcie?
A: Przed, albo przynajmniej jako wyraźny wczesny etap z własnym krokiem przeglądu — nie wmieszane w techniczne przenoszenie danych. Decyzje o czyszczeniu (co jest duplikatem, co bezpiecznie porzucić, do czego służyło tajemnicze pole niestandardowe) zwykle wymagają wkładu osoby znającej historię katalogu, a to inny rodzaj pracy niż samo techniczne mapowanie i przenoszenie.

Q: Co jeśli nie jesteśmy pewni, czy dany duplikat faktycznie jest duplikatem?
A: Oznacz to zamiast zgadywać w jedną lub drugą stronę. Bliski duplikat z inną ceną, innymi opcjami wariantów czy inną historią zamówień może być prawomocnym osobnym produktem, który tylko wygląda podobnie. W razie wątpliwości zachowaj oba i wróć do tego po zakończeniu audytu, zamiast scalać na podstawie domysłu.

Q: Czy czyszczenie danych może odbywać się, gdy stary sklep nadal działa i przyjmuje zamówienia?
A: Tak, dla większości pracy audytowej i planistycznej — przegląd eksportów, decydowanie o scaleniach i budowanie docelowej taksonomii nie wymagają dotykania żywego sklepu. Faktyczne wprowadzanie zmian (scalanie rekordów, usuwanie osieroconych mediów) zwykle bezpieczniej wykonać na kopii lub eksporcie, a następnie wprowadzić oczyszczony zbiór danych do migracji, zamiast edytować żywy katalog w trakcie audytu.

### Lista kontrolna replatformingu e-commerce

URL: https://prevedshop.com/pl/poradniki/checklista-zmiany-platformy-sklepu
Language: pl
Last reviewed: 2026-07-21

Replatforming sklepu internetowego to projekt, nie przycisk, który się naciska. Zaangażowane platformy mają mniejsze znaczenie, niż zakłada większość osób — to, co faktycznie decyduje o tym, czy migracja przebiegnie sprawnie, to czy żmudne etapy wykonano po kolei: zaudytowano to, co się ma, celowo to zmapowano, zaplanowano przekierowania, przetestowano na środowisku testowym i uważnie obserwowano sklep po przełączeniu. Ta lista kontrolna prowadzi przez tę sekwencję, więc można ją zastosować niezależnie od tego, jaką platformę się opuszcza lub na jaką się przechodzi.

#### 1. Zacznij od odkrycia i audytu, nie porównania narzędzi

Zanim porównasz platformy docelowe, zaudytuj to, co faktycznie masz na obecnej: ile produktów i wariantów, ile kont klientów i jak dużo historii zamówień, które pola niestandardowe są aktywnie używane, a które to porzucone pozostałości, od jakich aplikacji czy integracji zależy front sklepu, i które adresy URL obecnie generują znaczący ruch. Ten audyt zamienia „migrujemy” w projekt o określonym zakresie z realną listą tego, co musi się przenieść.

Bądź szczery co do jakości danych na tym etapie. Jeśli Twój katalog ma znane duplikaty, osierocone kategorie czy niespójne atrybuty, zapisz to teraz — uporządkowanie tego jest tańsze przed przenosinami niż po nich, a pominięcie audytu to sposób, w jaki zespoły odkrywają te problemy w połowie migracji zamiast wcześniej.

#### 2. Zmapuj model danych, zanim zmapujesz choćby jedno pole

Każda platforma strukturyzuje produkty, warianty, kategorie i dane klientów nieco inaczej. Zanim przeniesiesz jakiekolwiek dane, zbuduj jawne mapowanie: które pole źródłowe idzie do którego pola docelowego, które pojęcia źródłowe (atrybut niestandardowy, tag, typ zestawu) nie mają bezpośredniego odpowiednika docelowego i wymagają decyzji, oraz które pola można bezpiecznie całkowicie porzucić, bo nic już od nich nie zależy.

Udokumentuj to mapowanie w trwałej formie — arkuszu kalkulacyjnym czy współdzielonym dokumencie, nie w pamięci kogoś. Staje się ono punktem odniesienia, wobec którego wszyscy sprawdzają się podczas QA, i to pierwsza rzecz, po którą sięgniesz, gdy coś wygląda źle po uruchomieniu.

#### 3. Zaplanuj przekierowania i strukturę adresów URL wcześnie

Struktura adresów URL to jedno z najczęstszych miejsc, w których migracja po cichu szkodzi SEO i psuje zakładki. Zdobądź pełną listę obecnych adresów URL — stron produktów, kategorii i kolekcji, blogu czy stron treściowych oraz wszelkich niestandardowych stron docelowych — i zdecyduj o nowym adresie URL dla każdej z nich, zanim cokolwiek uruchomisz. Strony bez czystego odpowiednika na nowej platformie wymagają jawnej decyzji (zwykle przekierowania do najbliższej pasującej kategorii lub strony zbiorczej), a nie cichego błędu 404.

To planowanie dzieje się na długo przed przełączeniem, najlepiej równolegle z pracą nad mapowaniem danych, ponieważ te dwa etapy są powiązane: to, jak mapujesz kategorie i produkty, często decyduje o tym, jak wyglądają nowe adresy URL. Pełny proces znajdziesz w dedykowanym przewodniku po mapowaniu przekierowań, powiązanym poniżej.

#### 4. Zbuduj środowisko testowe i przeprowadź prawdziwe QA

Nigdy nie traktuj pierwszego importu jako ostatecznego. Załaduj zmapowane dane na instancję testową lub próbną platformy docelowej i rzeczywiście korzystaj ze sklepu: przeglądaj kategorie, wyświetlaj strony produktów, sprawdzaj wybór wariantów i ceny, testuj koszyk i proces kasy oraz potwierdź, że konta klientów i historia zamówień wyświetlają się poprawnie. Zaangażuj kogoś spoza zespołu migracji — świeże spojrzenie wyłapuje rzeczy, których osoby budujące mapowanie przestają zauważać.

Traktuj ten etap jako iteracyjny. To normalne, że przy pierwszym podejściu znajdują się problemy z mapowaniem; celem jest wyłapanie i naprawienie ich tutaj, na środowisku testowym, gdzie błąd kosztuje ponowny import, a nie odcinek żywego przestoju czy błąd widoczny dla klienta.

#### 5. Zaplanuj okno przełączenia jak operację, nie przełącznik

Zdecyduj, na piśmie, co dzieje się podczas przełączenia: jak obsługiwane są nowe zamówienia na starej platformie, jeśli migracja trwa dłużej (tymczasowe wstrzymanie zamówień, strona konserwacyjna czy dalsze działanie do zdefiniowanej ostatecznej synchronizacji), kto wykonuje ostateczną synchronizację danych, kto weryfikuje DNS i SSL na nowej platformie oraz kto ma uprawnienia do wycofania lub wstrzymania, jeśli coś wygląda źle.

Daj zespołowi wspólną listę kontrolną na sam dzień, nie tylko plan w czyjejś głowie. Pospieszne lub niejednoznaczne przełączenie to miejsce, w którym nawet dobrze przygotowane migracje tracą dane — na przykład kilka zamówień złożonych w luce między ostateczną synchronizacją a uruchomieniem — więc zaplanuj tę lukę wprost, zamiast liczyć, że nie będzie miała znaczenia.

#### 6. Monitoruj po uruchomieniu — migracja nie kończy się w dniu startu

Dni i tygodnie po przełączeniu to moment, w którym zwykle ujawniają się problemy, których nie wyłapał staging: źle skonfigurowana bramka płatności dla żywego ruchu, zasada podatkowa lub wysyłki, która zachowała się inaczej przy prawdziwych zamówieniach, przekierowania działające dla przetestowanych stron, ale nie dla przypadków brzegowych, albo piksel śledzący, który po cichu przestał działać. Ustal celową rutynę monitorowania, zamiast zakładać, że cisza oznacza sukces.

Nasza lista kontrolna QA po uruchomieniu (powiązana poniżej) omawia ten etap szczegółowo — weryfikację kasy i płatności, wyrywkowe sprawdzanie przekierowań, ciągłość analityki i monitorowanie search console — ponieważ zasługuje na własny dedykowany proces, a nie pospieszną refleksję po fakcie, gdy uwaga zespołu już się przeniosła gdzie indziej.

#### FAQ

Q: Ile trwa projekt replatformingowy?
A: Zależy w dużej mierze od wielkości katalogu, złożoności danych i liczby zaangażowanych integracji niestandardowych. Mały, czysty katalog zwykle przenosi się szybciej niż taki z dziesiątkami tysięcy SKU, latami nagromadzonych pól niestandardowych i wieloma połączonymi aplikacjami. Realny szacunek uzyskasz po audycie swojego konkretnego sklepu, a nie ufając ogólnemu harmonogramowi.

Q: Czy powinniśmy migrować wszystko naraz, czy etapami?
A: Oba podejścia działają w zależności od sklepu. Jednorazowe przełączenie jest prostsze do ogarnięcia i unika równoległego prowadzenia dwóch platform, ale koncentruje ryzyko w jednym oknie czasowym. Podejście etapowe (na przykład najpierw treść i design, potem katalog, potem dane transakcyjne) rozkłada ryzyko, ale wymaga staranniejszej koordynacji tego, co jest „aktywne” gdzie na każdym etapie. Właściwy wybór zależy od wielkości katalogu, Twojej tolerancji na okno konserwacyjne oraz tego, jak ściśle zintegrowane są Twoje systemy.

Q: Jaka jest najczęstsza przyczyna problemów z migracją?
A: Pomijanie lub pospieszanie etapów audytu i mapowania. Zespoły, które od razu przechodzą do przenoszenia danych bez wcześniejszego zrozumienia, co faktycznie mają — zduplikowane produkty, nieudokumentowane pola niestandardowe, adresy URL, o których nikt nie pomyślał — zwykle odkrywają te problemy na żywo, po przełączeniu, zamiast na stagingu, gdzie są tanie do naprawienia.

Q: Czy musimy zamrozić stary sklep podczas migracji?
A: Niekoniecznie na cały projekt, ale potrzebujesz jasnego planu ostatecznego okna przełączenia — zwykle krótkiego zamrożenia lub zdefiniowanego punktu ostatecznej synchronizacji — aby żadne zamówienia ani zmiany klientów nie zostały utracone między ostatnim pobraniem danych a uruchomieniem nowego sklepu. To, jak długie musi być to okno, zależy od wolumenu zamówień i sposobu obsługi ostatecznej synchronizacji.

Sources:
- Google Search Central: przenosiny strony ze zmianą adresów URL: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

### Mapowanie przekierowań bezpieczne dla SEO przy migracjach e-commerce

URL: https://prevedshop.com/pl/poradniki/mapowanie-przekierowan-bez-utraty-seo
Language: pl
Last reviewed: 2026-07-21

Pozycje w wyszukiwarce i ruch organiczny to jedne z najcenniejszych rzeczy, jakie ma ugruntowany sklep, i jedne z najłatwiejszych do uszkodzenia przy nieostrożnej migracji. Dobra wiadomość jest taka, że ciągłość adresów URL to problem rozwiązywalny i mechaniczny: zbuduj właściwą mapę przekierowań, wdróż ją poprawnie i monitoruj, jak reagują wyszukiwarki. Ten przewodnik prowadzi przez ten proces od początku do końca, niezależnie od zaangażowanych platform.

#### Najpierw zbuduj kompletny spis adresów URL

Zanim cokolwiek zmapujesz, potrzebujesz pełnej listy adresów URL obecnie w użyciu — nie tylko tych, które pamiętasz, ale każdej strony produktu, kategorii i kolekcji, strony blogu czy treści oraz wszelkich niestandardowych stron docelowych istniejących na obecnej stronie. Pobierz to z mapy strony, raportów stron narzędzia analitycznego oraz przeskanowania żywej strony i porównaj te trzy źródła ze sobą, ponieważ każde z nich zwykle pomija coś, co wychwytują pozostałe.

Zwróć szczególną uwagę na adresy URL generujące ruch organiczny lub mające zewnętrzne linki zwrotne, nawet jeśli to strony, które uznałbyś za mniej istotne. Wpis na blogu o niskim ruchu, ale z kilkoma dobrymi linkami zwrotnymi, warto poprawnie zmapować; ciche jego utracenie to mała, ale możliwa do uniknięcia strata.

#### Zmapuj każdy adres URL na jego nowy odpowiednik — i celowo zdecyduj o wyjątkach

Dla każdego adresu URL w Twoim spisie zdecyduj o jego celu na nowej platformie. Większość stron produktów i kategorii będzie miała rozsądnie bezpośredni odpowiednik, gdy mapowanie danych zostanie ustalone. Strony bez czystego odpowiednika (wycofany produkt, jednorazowa strona docelowa, kategoria, która już nie istnieje) nadal wymagają jawnej decyzji — zwykle przekierowania do najbliższej pasującej kategorii, odpowiedniej strony zbiorczej lub w rzadkich przypadkach celowego, akceptowanego błędu 404 — zamiast domyślnego przekierowania na stronę główną albo przypadkowego błędu 404.

Podejście „przekieruj wszystko na stronę główną” to powszechny skrót, który aktywnie szkodzi: rozmywa sygnały trafności i daje użytkownikom gorsze doświadczenie w porównaniu do trafienia na najbliższą odpowiednią stronę.

#### Wdróż przekierowania 301 i sprawdź łańcuchy oraz pętle

Używaj trwałych przekierowań (301) dla adresów URL, które faktycznie przeniosły się na stałe — to sygnał informujący wyszukiwarki, by przenieść sygnały rankingowe na nowy adres URL. Gdy Twoje przekierowania będą już aktywne, aktywnie sprawdzaj łańcuchy przekierowań (adres A → B → C, podczas gdy wystarczyłoby A → C) oraz pętle (A → B → A), ponieważ oba są częstym efektem ubocznym iteracyjnych edycji mapy przekierowań i oba marnują budżet indeksowania oraz zwiększają opóźnienie. Celem jest przekierowanie jednym skokiem z każdego starego adresu URL wprost do ostatecznego nowego celu.

Przetestuj ręcznie reprezentatywną próbkę przekierowań po uruchomieniu — wyrywkowo sprawdź strony o wysokim ruchu, kilka o niskim ruchu i kilka celowych wyjątków — zamiast zakładać, że mapa jest poprawna tylko dlatego, że zwalidowała się w arkuszu kalkulacyjnym.

#### Celowo obsłuż tagi kanoniczne

Tagi kanoniczne informują wyszukiwarki, który adres URL jest wersją referencyjną, gdy podobna treść jest dostępna pod więcej niż jednym adresem. Po migracji upewnij się, że tag kanoniczny każdej strony wskazuje na jej własny żywy, poprawny nowy adres URL — nie na pozostały stary adres URL i nie przez pomyłkę na adres URL innej strony ze skopiowanego szablonu. Błąd w tym miejscu może zmylić wyszukiwarki co do tego, którą wersję strony indeksować, nawet gdy same przekierowania są poprawne.

Jeśli nowa platforma generuje tagi kanoniczne automatycznie, zweryfikuj jej domyślne zachowanie, zamiast zakładać, że jest właściwe dla Twojej konfiguracji — automatyczna kanonizacja czasem wskazuje na nieoczekiwane adresy URL na stronach z parametrami czy paginacją.

#### Prześlij ponownie mapę strony XML i zaktualizuj linki wewnętrzne

Gdy nowa strona jest już aktywna z działającymi przekierowaniami, wygeneruj i prześlij świeżą mapę strony XML odzwierciedlającą nową strukturę adresów URL przez Google Search Central i narzędzia dla webmasterów innych wyszukiwarek, aby roboty indeksujące mogły efektywnie odkrywać nowe strony, zamiast polegać wyłącznie na podążaniu za przekierowaniami ze starych adresów URL.

Jednocześnie zaktualizuj linki wewnętrzne w całej witrynie — nawigację, stopkę, linki do powiązanych produktów, treść bloga — aby wskazywały bezpośrednio na nowe adresy URL, a nie przez przekierowanie. Linki wewnętrzne, które nadal wskazują na stare adresy URL, dodają niepotrzebne skoki przekierowań przy każdym kliknięciu i łatwo je przeoczyć, ponieważ nie psują niczego widocznie — po prostu działają mniej efektywnie.

#### Monitoruj status indeksowania po przełączeniu

Praca SEO związana z migracją nie kończy się na uruchomieniu. W tygodniach po przełączeniu obserwuj Search Console (lub odpowiednik dla innych wyszukiwarek) pod kątem błędów indeksowania, nagłego skoku błędów 404, stron, które nie są indeksowane, lub spadku wyświetleń/kliknięć dla stron, które powinny działać normalnie. Porównuj to z wynikiem sprzed migracji, aby wychwytywać rzeczywiste regresje, a nie normalną krótkoterminową fluktuację.

Bądź cierpliwy, ale nie bierny: ponowna indeksacja czasem trwa nawet, gdy wszystko jest ustawione poprawnie, ale błąd przekierowania czy tagu kanonicznego niezauważony przez tygodnie jest dużo droższy do naprawienia niż taki wychwycony w pierwszych dniach po uruchomieniu.

#### FAQ

Q: Czy migracja na pewno zaszkodzi moim pozycjom w wyszukiwarce?
A: Nie, jeśli ciągłość adresów URL jest właściwie obsłużona — kompletna mapa przekierowań, poprawne tagi kanoniczne i ponownie przesłana mapa strony to podstawowe zabezpieczenia. Nikt nie może zagwarantować, że konkretne pozycje się utrzymają, ponieważ ranking zależy od wielu czynników poza samą migracją, ale właściwe mapowanie adresów URL to pojedynczy, największy kontrolowalny czynnik zachowania tego, co miałeś.

Q: Czy powinienem użyć przekierowań 301 czy 302?
A: Używaj przekierowań 301 (trwałych) dla adresów URL, które przeniosły się na stałe — to normalny przypadek przy migracji platformy. Przekierowania 302 (tymczasowe) sygnalizują, że przeniesienie nie jest trwałe, a wyszukiwarki mogą nie przenosić sygnałów rankingowych w ten sam sposób, więc są złym wyborem dla mapy przekierowań zakończonej migracji.

Q: Co jeśli dwa stare adresy URL powinny wskazywać na tę samą nową stronę?
A: To normalne i częste — na przykład dwa stare adresy URL kategorii, które zostały scalone w jeden na nowej platformie. Przekieruj oba stare adresy URL bezpośrednio na ten jeden nowy adres. Czego chcesz unikać, to sytuacji odwrotnej: jednego starego adresu URL, który jest niejednoznaczny co do tego, na którą nową stronę powinien się mapować, co zwykle oznacza, że decyzja o mapowaniu faktycznie jeszcze nie została podjęta.

Q: Jak długo powinienem utrzymywać stare przekierowania?
A: Bezterminowo, jeśli to praktyczne. Linki zwrotne, zakładki i stare wyniki wyszukiwania odwołujące się do poprzednich adresów URL mogą utrzymywać się długo po migracji, a koszt utrzymania reguły przekierowania jest niewielki. Zbyt wczesne usunięcie przekierowań to częsty sposób na zamienienie jednorazowego kosztu migracji w powtarzające się źródło zerwanych linków.

Sources:
- Google Search Central: przekierowania 301: https://developers.google.com/search/docs/crawling-indexing/301-redirects
- Google Search Central: konsolidacja zduplikowanych adresów URL (kanonizacja): https://developers.google.com/search/docs/crawling-indexing/canonicalization
- Google Search Central: budowa i przesyłanie mapy strony: https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap

### Shopify vs WooCommerce: na którą platformę migrować?

URL: https://prevedshop.com/pl/poradniki/shopify-vs-woocommerce
Language: pl
Last reviewed: 2026-09-02

Shopify i WooCommerce to dwie platformy, na które i z których migrujemy najczęściej, a wybór między nimi rzadko dotyczy funkcji. Shopify to hostowany system o stałym modelu, który zdejmuje pracę operacyjną; WooCommerce to otwarta wtyczka do WordPressa, która daje Ci bazę danych i odpowiedzialność. To porównanie patrzy na różnice, które naprawdę zmieniają migrację: model danych, własność, strukturę kosztów, obsługę treści i SEO, a następnie opisuje, które sklepy są zwykle bardziej zadowolone po której stronie.

#### Model danych: stały kontra otwarty

Produkty Shopify mają stały schemat z maksymalnie trzema wymiarami opcji i metapolami na całą resztę; kolekcje to listy ręczne lub oparte na regułach, nie drzewo taksonomii. Produkty WooCommerce to wpisy WordPressa z nieograniczonymi atrybutami, polami niestandardowymi i zagnieżdżonymi taksonomiami. Przejście na Shopify jest więc ćwiczeniem z konsolidacji - decydowaniem, gdzie ma mieszkać każde pole niestandardowe - a przejście na WooCommerce to głównie mapowanie małego, uporządkowanego modelu w większy. Sklepy z bardzo ustrukturyzowanymi katalogami zwykle łatwiej migrują w stronę Shopify; sklepy z nietypowymi danymi tracą mniej w stronę WooCommerce.

#### Własność, hosting i koszty

Shopify pobiera plan plus prowizje transakcyjne przy zewnętrznych bramkach i subskrypcje aplikacji; w zamian nie ma serwera, łatania ani zakresu PCI po Twojej stronie. WooCommerce nie ma licencji, ale płacisz za zarządzany hosting WordPress, licencje wtyczek i czas programisty, który utrzymuje bezpieczne aktualizacje. W skali trzech lat sumy są często bliższe, niż twierdzi każda ze stron. Prawdziwa różnica to miejsce ryzyka: w Shopify platforma może zmienić zasady i ceny; w WooCommerce zaniedbany zestaw wtyczek może zepsuć sklep.

#### Treści i SEO

WordPress to pełny CMS, więc sklepy WooCommerce z dużymi blogami, landing page'ami i własnymi szablonami trzymają wszystko w jednym miejscu. Strony i blog Shopify są prostsze, a sklepy bogate w treści często prowadzą WordPressa do treści obok Shopify do sprzedaży. W SEO platformy są równoważne przy dobrej konfiguracji; w migracji liczy się zmiana URL. Shopify wymusza ścieżki `/products/` i `/collections/`, bezpośrednie odnośniki WordPressa są dowolne, więc każda migracja między nimi wymaga pełnej mapy przekierowań 301. Przekierowania ograniczają ryzyko; pozycje nigdy nie są gwarantowane.

#### Które sklepy pasują do której platformy

Shopify zwykle pasuje do sklepów, które chcą przewidywalnych operacji, sprzedają do kilku krajów przez Markets, korzystają ze standardowej logistyki i mają katalog mieszczący się w trzech wymiarach opcji. WooCommerce pasuje do sklepów, które potrzebują własnej logiki checkoutu, cen B2B, nietypowych struktur produktów, głębokiej integracji treści lub rygorystycznej lokalizacji danych. Jeśli żaden opis nie jest wyraźnie Twój, krótkie discovery z prawdziwymi próbkami produktów i zamówień odpowie szybciej niż jakakolwiek tabela porównawcza.

#### FAQ

Q: Czy Shopify jest lepsze od WooCommerce pod kątem SEO?
A: Żadna platforma nie ma wrodzonej przewagi. Widoczność po migracji zależy od mapy przekierowań, zgodności treści i szybkości stron, nie od nazwy platformy.

Q: Co jest tańsze, Shopify czy WooCommerce?
A: Zależy od skali i personalizacji. Shopify ma przewidywalne opłaty plus aplikacje i prowizje; WooCommerce ma hosting, licencje wtyczek i czas programistów. Porównaj sumy za trzy lata łącznie z migracją.

Q: Czy mogę przejść z Shopify do WooCommerce, nie tylko odwrotnie?
A: Tak. Migrujemy w obu kierunkach; trasa Shopify → WooCommerce jest opisana osobno i polega głównie na mapowaniu metapól i odbudowie inteligentnych kolekcji.

Q: Czy wybór wpływa na czas trwania migracji?
A: Częściowo. Przejście na Shopify trwa dłużej przy katalogach z wieloma polami niestandardowymi, bo każde wymaga decyzji o metapolu; przejście na WooCommerce trwa dłużej, gdy wiele aplikacji trzeba zastąpić wtyczkami.

Sources:
- Shopify Help Center - Migracja do Shopify: https://help.shopify.com/en/manual/migrating-to-shopify
- WooCommerce - Importer i eksporter produktów CSV: https://woocommerce.com/document/product-csv-importer-exporter/

### Glossary

### Przekierowanie 301

URL: https://prevedshop.com/pl/slownik/przekierowanie-301
Language: pl
Last reviewed: 2026-07-21

Przekierowanie 301 informuje przeglądarki i wyszukiwarki, że strona trwale przeniosła się pod nowy adres URL, i wysyła każdego — człowieka czy robota indeksującego — kto prosi o stary adres, wprost pod nowy. „301” to kod statusu HTTP zwracany przez serwer: to standardowy, trwały sposób powiedzenia „ta treść znajduje się teraz tutaj”, w odróżnieniu od przekierowania tymczasowego (302).

#### Co faktycznie robi przekierowanie 301

Gdy ktoś żąda starego adresu URL, serwer odpowiada kodem statusu HTTP 301 wraz z nową lokalizacją. Przeglądarka podąża za nim automatycznie, więc odwiedzający rzadko w ogóle to zauważa — trafia na nową stronę, a nie na błąd. Wyszukiwarki reagują na ten sam sygnał: 301 informuje je, by z czasem przenieść wartość rankingową starego adresu URL na nowy, zamiast traktować nową stronę jako niepowiązaną, zupełnie nową treść.

Różni się to od przekierowania 302 (tymczasowego), które mówi robotom indeksującym, że przeniesienie nie jest trwałe i że wartość SEO nie powinna być w pełni przenoszona. Różni się też od ręcznej aktualizacji linków na własnej stronie — 301 obejmuje wszystkich, którzy nadal mają stary adres URL zapisany w zakładkach, zalinkowany z innej strony czy zaindeksowany w wynikach wyszukiwania, a nie tylko osoby klikające linki, które kontrolujesz.

#### Dlaczego przekierowania 301 mają znaczenie podczas migracji platformy

Przejście na nową platformę niemal zawsze zmienia strukturę adresów URL, nawet gdy starasz się utrzymać ją zbliżoną — adresy produktów, ścieżki kategorii i wpisy na blogu często przybierają inny kształt niż wcześniej. Każdy stary adres URL zaindeksowany przez wyszukiwarki i zalinkowany przez inne strony potrzebuje przekierowania 301 na swój nowy odpowiednik, w przeciwnym razie tracisz zgromadzony przez tę stronę sygnał rankingowy i wysyłasz odwiedzających w ślepy zaułek.

Ryzyko nie jest hipotetyczne: uruchomienie nowego sklepu bez planu przekierowań zwykle skutkuje narastającymi błędami 404, zerwanymi linkami przychodzącymi i spadkiem ruchu organicznego w ciągu kilku dni od startu, ponieważ wyszukiwarki szybko ponownie odwiedzają zaindeksowane adresy URL. Plan przekierowań przygotowany przed uruchomieniem, a nie sklejony naprędce po spadku ruchu, jest tym, co temu zapobiega.

#### Dobrze zrobione przekierowania, nie tylko obecne

Samo posiadanie przekierowania 301 nie wystarczy — musi ono wskazywać właściwy cel. Przekierowanie każdego starego adresu URL na nową stronę główną technicznie „rozwiązuje” link, ale odrzuca konkretną trafność, jakiej oczekiwała wyszukiwarka lub odwiedzający. Mapujemy stare adresy URL na ich najbliższy realny odpowiednik na nowej platformie, a strony bez czystego dopasowania oznaczamy zamiast zgadywać.

Sprawdzamy też łańcuchy przekierowań (adres A do B do C) oraz pętle, które zwiększają opóźnienie i mogą sprawić, że roboty indeksujące przestaną podążać za łańcuchem. Czysta migracja kończy się jednym skokiem na adres URL, nie trzema.

#### FAQ

Q: Czy przekierowanie 301 to to samo co zmiana adresu URL?
A: Nie — zmiana adresu URL bez przekierowania po prostu zrywa stary link. Przekierowanie 301 to instrukcja łącząca stary adres URL z nowym, dzięki czemu każdy, kto zażąda starego adresu, zostaje automatycznie przekierowany na nową stronę.

Q: Czy przekierowania 301 w pełni zachowują moje pozycje w wynikach wyszukiwania?
A: Zachowują większość sygnału rankingowego powiązanego ze starym adresem URL, ale nie automatycznie każdą pozycję dla każdego słowa kluczowego — nadal mają znaczenie inne czynniki, jak jakość strony czy konkurencja. Przekierowanie 301 niezawodnie informuje wyszukiwarki, że treść się przeniosła, zamiast pozwolić im traktować nowy adres URL jako niepowiązany.

Q: Jak długo muszę utrzymywać przekierowania?
A: Bezterminowo, albo tak blisko tego, jak to praktycznie możliwe. Stare linki z innych stron internetowych, zapisane zakładki i materiały drukowane mogą przez lata wysyłać ruch na stare adresy URL, a wyszukiwarkom przetworzenie dużej partii przekierowań może zająć trochę czasu.

Q: Jaka jest różnica między przekierowaniem 301 a 302?
A: 301 sygnalizuje trwałe przeniesienie i przekazuje sygnał rankingowy na nowy adres URL; 302 sygnalizuje przeniesienie tymczasowe, a wyszukiwarki ostrożniej podchodzą do przenoszenia tego sygnału. Przy migracji platformy, gdzie stary adres URL nie wróci, przekierowanie 301 jest niemal zawsze właściwym wyborem.

Sources:
- Google Search Central: przekierowania a wyszukiwarka Google: https://developers.google.com/search/docs/crawling-indexing/301-redirects

### Tag kanoniczny

URL: https://prevedshop.com/pl/slownik/tag-kanoniczny
Language: pl
Last reviewed: 2026-07-21

Tag kanoniczny (`<link rel="canonical">`) to znacznik HTML, który informuje wyszukiwarki, który adres URL jest wersją referencyjną strony, gdy ta sama lub bardzo podobna treść jest dostępna pod więcej niż jednym adresem. Nie przekierowuje odwiedzających — to sygnał dla robotów indeksujących, który adres URL powinien otrzymać uznanie i pojawiać się w wynikach wyszukiwania.

#### Co faktycznie robi tag kanoniczny

Platformy e-commerce regularnie udostępniają ten sam produkt lub kategorię pod wieloma adresami URL — ze ukośnikiem na końcu i bez niego, z różnymi parametrami sortowania czy filtrowania, albo dostępnym z więcej niż jednej ścieżki kategorii. Bez tagu kanonicznego wyszukiwarki muszą zgadywać, którą wersję zaindeksować, co może rozdzielić sygnał rankingowy między niemal identyczne adresy URL zamiast go konsolidować na jednym.

Tag kanoniczny znajduje się w sekcji `<head>` strony i wskazuje pojedynczy adres URL, który powinien być traktowany jako wersja główna. Każdy zduplikowany lub bardzo podobny wariant zawiera tag kanoniczny wskazujący z powrotem na ten jeden adres URL; adres główny zwykle ma tag kanoniczny wskazujący na samego siebie.

#### Dlaczego ma znaczenie podczas migracji platformy

Nowe platformy często wprowadzają własne wzorce adresów URL do filtrowania, paginacji czy sortowania, których nie było na starej platformie, i łatwo skończyć z niezamierzoną zduplikowaną treścią, jeśli tagi kanoniczne nie są ustawione poprawnie od pierwszego dnia. Błąd w tym miejscu zwykle nie powoduje dramatycznego spadku jak brakujące przekierowanie, ale po cichu rozmywa sygnał rankingowy między niemal identycznymi stronami zamiast go konsolidować — to wolniejszy, trudniejszy do zdiagnozowania problem.

Migracje to też naturalny moment, by naprawić istniejące wcześniej problemy z kanonizacją ze starej platformy, zamiast przenosić je bez zmian dalej.

#### Tagi kanoniczne a przekierowania

Tag kanoniczny i przekierowanie rozwiązują różne problemy. Przekierowanie (zobacz przekierowanie 301) dotyczy adresu URL, który w ogóle już nie istnieje — wysyła odwiedzających i roboty indeksujące pod nowy adres. Tag kanoniczny dotyczy adresów URL, które nadal istnieją i są nadal dostępne, ale nie powinny konkurować ze sobą w wynikach wyszukiwania — obie pozostają aktywne, tylko jedna jest oznaczona jako wersja referencyjna.

#### FAQ

Q: Czy tag kanoniczny przekierowuje odwiedzających na główny adres URL?
A: Nie. Odwiedzający nadal mogą trafić na niekanoniczny adres URL i wczytuje się on normalnie — tag kanoniczny sygnalizuje wyszukiwarkom jedynie, którą wersję indeksować i rankingować, nie zmienia tego, co robi przeglądarka.

Q: Czy potrzebuję tagów kanonicznych, jeśli nie mam zduplikowanej treści?
A: To wciąż powszechna praktyka, by każda strona miała samoodwołujący się tag kanoniczny (wskazujący na samą siebie), co usuwa niejednoznaczność, jeśli duplikat kiedyś się pojawi — np. przez parametr śledzący czy nowy adres URL filtra.

Q: Czy tag kanoniczny może wskazywać na stronę w innej domenie?
A: Tak, kanoniczne odwołania między domenami są prawidłowe i czasem stosowane celowo, ale przy migracji platformy zwykle nie jest to pożądane — każdy nowy adres URL powinien zazwyczaj kanonizować sam do siebie, a przekierowania (nie kanoniczne odwołania) powinny obsługiwać starą domenę czy stare adresy URL.

Q: Co się stanie, jeśli moje tagi kanoniczne wskazują na niewłaściwy adres URL?
A: Wyszukiwarki mogą zaindeksować i rankingować niewłaściwą wersję strony albo całkowicie zignorować Twój sygnał kanoniczny, jeśli wygląda on niespójnie z innymi sygnałami (jak linki wewnętrzne czy mapa strony). Sprawdzamy tagi kanoniczne w ramach QA migracji, zamiast zakładać, że nowa platforma ustawia je poprawnie domyślnie.

Sources:
- Google Search Central: konsolidacja zduplikowanych adresów URL: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

### Migracja danych

URL: https://prevedshop.com/pl/slownik/migracja-danych
Language: pl
Last reviewed: 2026-07-21

Migracja danych to proces przenoszenia informacji Twojego sklepu — produktów, klientów, zamówień, treści i wszystkiego, co jest z nimi powiązane — z jednej platformy na drugą, w formie, którą nowa platforma faktycznie może poprawnie wykorzystać. To rdzeń pracy technicznej przy przenosinach platformy, odrębny od designu, planowania przekierowań czy integracji, choć wszystkie one zależą od dokładności migracji danych.

#### Co faktycznie podlega migracji

Poza oczywistym katalogiem produktów, pełna migracja danych zwykle obejmuje konta klientów wraz z historią zamówień, istniejące zamówienia (otwarte i historyczne), treści takie jak wpisy na blogu czy strony statyczne, opinie, jeśli są przechowywane na platformie, oraz wszelkie pola niestandardowe czy metadane specyficzne dla Twojej firmy. Nie wszystko koniecznie musi się przenieść — część danych historycznych może zostać zarchiwizowana zamiast aktywnie migrowana, co jest decyzją o zakresie podejmowaną podczas oceny, a nie zakładaną domyślnie.

#### Dlaczego zwykły eksport/import nie wystarczy

Dwie platformy rzadko modelują dane identycznie — płaska lista produktów jednej platformy może być hierarchicznym systemem kategorii i atrybutów drugiej; prosty rekord klienta na jednej platformie może wymagać podziału na kilka typów obiektów na nowej. Dosłowna kopia pole po polu z pliku eksportu często daje dane, które są technicznie obecne, ale strukturalnie błędne — zerwane relacje wariantów, utracone pola niestandardowe czy rekordy klientów niepoprawnie powiązane z historią zamówień. Prawdziwa migracja danych oznacza celowe mapowanie każdego typu danych, a nie tylko przenoszenie plików.

#### Jak do tego podchodzimy

Zaczynamy od audytu danych — zrozumienia, co faktycznie istnieje w starym systemie, w tym niespójności narosłych z czasem (zduplikowani klienci, osierocone rekordy, niespójna kategoryzacja) — zanim zdecydujemy, jak to mapuje się na nową platformę. Porządkowanie danych często dzieje się w ramach tego etapu, a nie po nim, ponieważ wierne przeniesienie złych danych po prostu odtwarza te same problemy na nowej platformie. Zobacz Czyszczenie i mapowanie danych, by dowiedzieć się, jak to wpisuje się w zarządzaną migrację.

#### FAQ

Q: Czy migracja danych obejmuje historię moich zamówień?
A: Może obejmować — to, czy historyczne zamówienia są aktywnie migrowane na nową platformę, czy archiwizowane osobno, to decyzja o zakresie, ponieważ nie każda platforma czy firma potrzebuje żywej historii zamówień w nowym systemie. Omawiamy to podczas oceny.

Q: Czy moje pola niestandardowe przeniosą się automatycznie?
A: Nie automatycznie — pola niestandardowe wymagają jawnego odpowiednika na nowej platformie (często są to metafields lub atrybuty niestandardowe), a to mapowanie trzeba zdefiniować, a nie zakładać, że istnieje domyślnie.

Q: Czy mogę zmigrować dane samodzielnie za pomocą wtyczki lub narzędzia importu?
A: Przy małych, prostych katalogach to może zadziałać. Dla sklepów ze znaczącą personalizacją, historią zamówień czy problemami z jakością danych generyczne narzędzie importu zwykle nie potrafi podjąć decyzji, jakich wymaga właściwy audyt danych i proces mapowania — po prostu przenosi to, co jest w pliku, wraz z błędami.

Q: Jak unikacie utraty danych podczas migracji?
A: Poprzez audyt i mapowanie przed przeniesieniem czegokolwiek, przetestowanie migracji najpierw na środowisku testowym oraz weryfikację liczby rekordów i wyrywkową kontrolę danych po przeniesieniu, zamiast zakładać, że import przebiegł poprawnie.

### Headless Commerce

URL: https://prevedshop.com/pl/slownik/headless-commerce
Language: pl
Last reviewed: 2026-07-21

Headless commerce to architektura, w której front sklepu (to, co widzą i z czym wchodzą w interakcję klienci) jest budowany oddzielnie od backendu handlowego (katalog produktów, koszyk, kasa, zarządzanie zamówieniami), a oba komunikują się przez API, zamiast być jednym ściśle powiązanym systemem. „Headless” odnosi się do frontu — warstwy prezentacji — odseparowanej od backendu, który może następnie obsługiwać wiele różnych „głów” (stronę internetową, aplikację mobilną, kiosk w sklepie stacjonarnym) z jednego źródła danych.

#### Headless a platformy tradycyjne (monolityczne)

Tradycyjna platforma e-commerce łączy szablony frontu sklepu z backendem w jedną całość — motywy Liquid w Shopify czy szablony WordPress w WooCommerce to przykłady frontu generowanego bezpośrednio przez samą platformę. W konfiguracji headless front sklepu jest osobną aplikacją (często budowaną w frameworku takim jak Next.js lub podobnym) i pobiera dane z API platformy backendowej, zamiast platformy renderującej strony bezpośrednio. Niektóre platformy (Shopify, commercetools i kilka innych) obsługują zarówno tryb tradycyjny, jak i headless.

#### Dlaczego zmienia to charakter migracji

Migracja do lub z konfiguracji headless to inny rodzaj projektu niż migracja między dwiema tradycyjnymi platformami. Przeniesienie sklepu z tradycyjnej platformy na architekturę headless zwykle oznacza zbudowanie nowego frontu od podstaw (a nie przeniesienie istniejącego motywu), podczas gdy migracja backendu/katalogu podlega tym samym zasadom mapowania danych co każde inne przenosiny. Migracja między dwoma backendami headless jest często bardziej ograniczona po stronie frontu, ponieważ front czasem można zaktualizować, by wskazywał na nowe API, zamiast budować go od nowa — ale dane katalogu, zamówień i klientów backendu nadal wymagają tak samo starannego mapowania jak przy każdej migracji.

#### Kiedy headless jest (a kiedy nie jest) właściwym wyborem

Architektury headless generalnie zamieniają większy nakład wdrożenia i bieżącej pracy inżynieryjnej na większą elastyczność doświadczenia frontu sklepu — niestandardowe interakcje, kanały poza stroną internetową (aplikacje, kioski) lub wymagania wydajnościowe, których front oparty na szablonach nie jest w stanie spełnić. Dla sklepu bez takiej konkretnej potrzeby tradycyjna platforma jest zwykle prostsza w prowadzeniu i migracji. To decyzja warta celowego podjęcia podczas oceny, a nie domyślnego wyboru jednej z opcji.

#### FAQ

Q: Czy headless commerce jest zawsze szybszy niż tradycyjny front sklepu?
A: Nie automatycznie — wydajność zależy od sposobu zbudowania frontu headless, nie tylko od wyboru architektury. Źle zbudowany front headless może być wolniejszy niż dobrze zoptymalizowany tradycyjny motyw.

Q: Czy potrzebuję niestandardowych deweloperów, by prowadzić sklep headless?
A: Zasadniczo tak, na bieżąco — front headless nie ma edytora motywów ani opcji personalizacji ze sklepu z aplikacjami, jakie oferuje tradycyjna platforma, więc zmiany zwykle przechodzą przez niestandardowy development, a nie edytor wizualny.

Q: Czy mogę zmigrować się z tradycyjnej platformy na headless bez utraty SEO?
A: Tak, ale wymaga to tego samego planowania przekierowań i struktury URL co każda migracja, plus szczególnej uwagi na to, jak nowy front headless renderuje treść dla wyszukiwarek (renderowanie po stronie serwera ma tu znaczenie) — nie dzieje się to automatycznie tylko dlatego, że dane backendu są zachowane.

Q: Które platformy obsługują headless commerce?
A: Kilka głównych platform oferuje tryb headless/API-first obok lub zamiast tradycyjnego frontu — właściwy wybór zależy od Twoich konkretnych wymagań backendowych, co pomagamy ocenić, zamiast domyślnie wybierać platformę, która akurat jest popularna.

### Hreflang

URL: https://prevedshop.com/pl/slownik/hreflang
Language: pl
Last reviewed: 2026-07-21

Hreflang to atrybut HTML (oraz równoważny nagłówek HTTP czy wpis w mapie strony), który informuje wyszukiwarki, dla jakiego języka i opcjonalnie kraju przeznaczona jest dana strona, oraz wskazuje odpowiadającą jej stronę w innych językach czy regionach. Dzięki temu wielojęzyczna strona mówi Google „oto wersja hiszpańska, oto wersja niemiecka”, zamiast pozostawiać wyszukiwarkom zgadywanie.

#### Co faktycznie robi hreflang

Strona ze znacznikami hreflang wymienia zestaw alternatywnych adresów URL, każdy oznaczony kodem języka (i opcjonalnie regionu, jak `es` w porównaniu do `es-MX`), plus specjalny wpis `x-default` dla odwiedzających, którzy nie pasują do żadnego z wymienionych języków. Wyszukiwarki wykorzystują to, by pokazać właściwą wersję językową Twojej strony właściwemu użytkownikowi wyszukiwarki i uniknąć traktowania przetłumaczonych stron jako wzajemnie zduplikowanej treści.

Każda strona w klastrze musi odwoływać się do każdej innej strony w klastrze, w tym do samej siebie — częstym źródłem błędów jest link jednokierunkowy (strona A wskazuje na stronę B, ale B nie wskazuje z powrotem na A).

#### Dlaczego ma znaczenie podczas migracji platformy

Jeśli Twój sklep działa w wielu językach, migracja to właśnie ten moment, w którym hreflang zwykle się psuje — struktury adresów URL zmieniają się dla każdej wersji językowej i łatwo o sytuację, w której mechanizm przełączania języków nowej platformy nie łączy automatycznie poprawnych klastrów hreflang dla każdej ścieżki, zwłaszcza tych, które nie mają jeszcze aktywnego tłumaczenia. Niekompletna lub niespójna konfiguracja hreflang może sprawić, że w niewłaściwym kraju zajmie wysoką pozycję niewłaściwa wersja językowa, albo rozmyć sygnał rankingowy między niemal identycznymi zlokalizowanymi stronami.

Hreflang powinien być zweryfikowany dla każdego wzorca adresu URL w nowej architekturze informacji, nie tylko dla strony głównej — strony produktów, kategorii i wszelkie strony treściowe też go potrzebują, jeśli są wielojęzyczne.

#### Najczęstsze błędy

Najczęstsze problemy to brakujące linki zwrotne (A linkuje do B, B nie linkuje z powrotem), wskazanie hreflang na adres URL, który zwraca przekierowanie lub błąd 404 zamiast aktywnej strony, oraz użycie niewłaściwego formatu kodu języka/regionu. Żaden z nich zwykle nie powoduje bezpośredniej kary, ale oznaczają, że wyszukiwarki mogą w ogóle nie uwzględnić tego sygnału, co niweczy sens jego dodania.

#### FAQ

Q: Czy hreflang to to samo co przełącznik języka na mojej stronie?
A: Nie — przełącznik języka to element interfejsu dla odwiedzających; hreflang to sygnał dla wyszukiwarek, zwykle niewidoczny dla odwiedzających, który znajduje się w nagłówku HTML strony, nagłówku HTTP albo mapie strony. Strona może mieć jedno bez drugiego, choć posiadanie obu jest standardową praktyką.

Q: Czy potrzebuję wpisu x-default?
A: Jest zalecany, jeśli masz stronę zapasową dla odwiedzających, których język/region nie pasuje do żadnej z Twoich konkretnych wersji — zwykle wskazuje on na Twoją domyślną wersję językową.

Q: Czy hreflang wpływa bezpośrednio na moją pozycję w wyszukiwarce?
A: Nie działa jako podbicie rankingu — wpływa na to, która z Twoich stron pojawia się dla użytkowników w danym języku/regionie, i pomaga zapobiec traktowaniu przetłumaczonych stron jako niepożądanych duplikatów wobec siebie.

Q: Czy hreflang można ustawić w mapie strony zamiast na samej stronie?
A: Tak, oba sposoby są prawidłowe zgodnie z dokumentacją wyszukiwarek — niektóre strony wolą hreflang oparty na mapie strony, ponieważ jest łatwiejszy do programowego generowania i walidacji przy dużej liczbie adresów URL, i to podejście generalnie stosujemy na zmigrowanych stronach.

Sources:
- Google Search Central: informowanie Google o zlokalizowanych wersjach strony: https://developers.google.com/search/docs/specialty/international/localized-versions

### Feed produktowy

URL: https://prevedshop.com/pl/slownik/feed-produktowy
Language: pl
Last reviewed: 2026-07-21

Feed produktowy to ustrukturyzowany eksport Twojego katalogu — zwykle w formacie CSV, XML lub JSON — przygotowany do cyklicznego odczytu przez inny system: dostawcę wysyłającego Ci swój katalog albo Twój sklep wysyłający katalog na marketplace, do porównywarki cen czy platformy reklamowej (jak feed Google Shopping). Każdy feed podlega konkretnemu formatowi, jakiego oczekuje system odbierający: określone pola, w określonej strukturze, czasem z własnymi wymaganymi identyfikatorami.

#### Feedy przychodzące a wychodzące

Feed przychodzący pochodzi od dostawcy lub dystrybutora do Twojego sklepu — nowe stany magazynowe, ceny i dane produktowe, które Twoja platforma musi cyklicznie wchłaniać. Feed wychodzący idzie w drugą stronę — katalog Twojego sklepu sformatowany do odczytu przez marketplace, porównywarkę zakupów czy platformę reklamową. Migracja zwykle dotyka obu: nowa platforma musi nadal odbierać feedy dostawców w formacie, w jakim już je wysyłają, oraz musi produkować feedy wychodzące w formacie oczekiwanym przez każdy kanał docelowy, co nie zawsze jest identyczne z tym, co produkowała stara platforma.

#### Dlaczego feedy się psują podczas migracji

Formaty feedów rzadko są uniwersalnym standardem — feed dostawcy może używać nazw pól, kodów kategorii czy identyfikatorów, do parsowania których integracja starej platformy była zbudowana na zamówienie. Przejście na nową platformę oznacza, że tę logikę parsowania trzeba odbudować, a nie zakładać, że przeniesie się sama, nawet jeśli sam plik feedu się nie zmienia. To samo dotyczy odwrotnej strony: feed wychodzący, od którego zależy Twoje konto na marketplace czy w reklamach, musi po przenosinach nadal pasować do wymaganego formatu tego kanału, w przeciwnym razie kanał może go odrzucić lub błędnie odczytać.

#### Co sprawdza zarządzana migracja

Podczas oceny mapujemy każdy aktywny feed przychodzący i wychodzący — w jakim jest formacie, na jakie pola się mapuje i jak często działa — aby nic nie zepsuło się po cichu po przełączeniu. Feed dostawcy, który przestaje być poprawnie parsowany, przeważnie nie zgłasza błędu; po prostu po cichu przestaje aktualizować stany czy ceny, co jest gorsze od oczywistej awarii, bo może pozostać niezauważone przez jakiś czas.

#### FAQ

Q: Czy feed mojego dostawcy zadziała automatycznie na nowej platformie?
A: Nie automatycznie — nowa platforma potrzebuje zbudowanej (lub ponownie użytej, jeśli istnieje kompatybilny konektor) integracji do parsowania formatu tego konkretnego feedu. Każdy feed dostawcy oceniamy indywidualnie podczas oceny, zamiast zakładać, że poradzi sobie z nim generyczny import.

Q: Co dzieje się z moim feedem Google Shopping czy marketplace podczas migracji?
A: Musi nadal pasować do wymaganego formatu miejsca docelowego po przenosinach. Sprawdzamy feedy wychodzące w ramach planu migracji, aby kanał nie odrzucił Twojego katalogu ani nie pokazywał nieaktualnych danych po przełączeniu.

Q: Czy feed produktowy to to samo co eksport CSV?
A: Eksport CSV może być feedem produktowym, ale „feed” zwykle oznacza cykliczną, zautomatyzowaną wymianę według harmonogramu, a nie jednorazowy eksport ręczny — choć sam format pliku może być identyczny.

Q: Czy dwa systemy mogą używać zupełnie różnych formatów feedów dla tych samych danych?
A: Tak, to powszechne — te same dane katalogowe mogą być eksportowane jako jedna struktura XML dla jednego marketplace i inna struktura CSV dla drugiego, albo używać zupełnie innych nazw pól i taksonomii kategorii, co wymaga osobnego mapowania dla każdego.

### Replatforming

URL: https://prevedshop.com/pl/slownik/replatforming
Language: pl
Last reviewed: 2026-07-21

Replatforming oznacza przeniesienie sklepu e-commerce z jednej platformy na drugą — nie przeprojektowanie na tej samej platformie i nie drobną aktualizację wersji, ale prawdziwą zmianę systemu, który obsługuje Twój sklep. To pojęcie parasolowe dla całego projektu: migracja danych, planowanie przekierowań, odbudowa motywu/frontu sklepu oraz ponowne podpięcie integracji — to wszystko elementy przedsięwzięcia replatformingowego.

#### Co liczy się jako replatforming (a co nie)

Przejście z Magento na Shopify to replatforming. Aktualizacja z Magento 1 do Magento 2 też można argumentować, że jest replatformingiem, ponieważ systemy leżące u podstaw różnią się na tyle, że wymagają prawdziwej migracji, a nie tylko aktualizacji. Przeprojektowanie motywu na tej samej platformie albo dodanie nowej aplikacji/wtyczki nie jest replatformingiem — system leżący u podstaw i model danych pozostają te same.

#### Najczęstsze powody, dla których sklepy przechodzą replatforming

Wyzwalaczem jest zwykle jeden lub więcej z następujących czynników: obecna platforma nie potrafi obsłużyć funkcji ani skalować się w tempie, jakiego potrzebuje firma, bieżący koszt utrzymania platformy samodzielnie hostowanej (hosting, łatanie bezpieczeństwa, zgodność PCI) przestaje mieć sens, platforma zbliża się do końca wsparcia lub traci wsparcie producenta, albo firma wyrosła z tego, co może dać front sklepu oparty na szablonach. Rzadko jest to jeden pojedynczy powód — zwykle to nagromadzenie tarć, które w końcu przeważa nad kosztem i ryzykiem przenosin.

#### Dlaczego replatforming traktuje się jako projekt, nie zadanie

Najbardziej ryzykowną częścią replatformingu nie jest wybór nowej platformy — to wszystko, co musi przenieść się poprawnie, aby firma nie straciła danych, pozycji SEO ani ciągłości operacyjnej: katalog, rekordy klientów, historia zamówień, struktura adresów URL i jej przekierowania, feedy dostawców oraz wszelka niestandardowa logika działająca na starej platformie. Traktowanie tego jako pojedynczego zadania importu zamiast zaplanowanego projektu jest tym, skąd bierze się większość realnego ryzyka w migracji.

#### FAQ

Q: Ile zwykle trwa replatforming?
A: Zależy w dużej mierze od wielkości katalogu, złożoności danych, liczby istniejących integracji oraz tego, ile niestandardowej funkcjonalności trzeba odbudować — nie ma uniwersalnego harmonogramu. Realny szacunek podajemy po ocenie konkretnego sklepu, a nie jako ogólną liczbę.

Q: Czy muszę przechodzić replatforming, jeśli chcę tylko nowego designu?
A: Nie — przeprojektowanie na obecnej platformie jest zwykle prostsze i mniej ryzykowne niż replatforming i nie wymaga migracji danych ani odbudowy integracji. Replatforming ma sens, gdy ograniczeniem jest sama platforma, a nie tylko jej wygląd.

Q: Jakie jest największe ryzyko w projekcie replatformingowym?
A: Utrata pozycji SEO przez zepsute przekierowania oraz problemy z jakością danych (zerwane relacje wariantów, utracone rekordy klientów, niedopasowana historia zamówień) wynikające z niekompletnej lub naiwnej migracji danych — obu można uniknąć przy właściwym planowaniu, i oba są częste, gdy się ich nie zaplanuje.

Q: Czy mogę przejść replatforming bez żadnego przestoju?
A: Przestój można zminimalizować dzięki starannemu planowaniu przełączenia (środowisko testowe, moment przełączenia DNS/ruchu, końcowa synchronizacja danych), ale obiecywanie zerowego przestoju jako gwarancji to coś, czego nie jesteśmy skłonni deklarować bez znajomości Twojej konkretnej konfiguracji — zobacz naszą stronę o bezpieczeństwie, by dowiedzieć się, jak podchodzimy do tej rozmowy uczciwie.

### Mapowanie SKU

URL: https://prevedshop.com/pl/slownik/mapowanie-sku
Language: pl
Last reviewed: 2026-07-21

Mapowanie SKU to proces dopasowania każdego identyfikatora produktu (SKU — jednostka magazynowa) ze starego systemu do jego poprawnego odpowiednika na nowym, tak aby zamówienia, stany magazynowe i feedy dostawców nadal odnosiły się do tego samego fizycznego produktu przed migracją i po niej. Brzmi mechanicznie, ale to jedno z miejsc, w których migracja najczęściej się psuje, gdy jest zautomatyzowana na ślepo zamiast przejrzana.

#### Dlaczego SKU nie zawsze przenoszą się bezproblemowo

W idealnej migracji każde SKU na starej platformie mapuje się 1:1 na to samo SKU na nowej i nic się nie zmienia. W praktyce platformy często mają różne zasady dotyczące tego, co może zawierać SKU, różnie obsługują SKU na poziomie wariantu w porównaniu do poziomu produktu, albo mają w historii zduplikowane czy ponownie użyte SKU ze starego systemu, które trzeba rozwiązać, a nie kopiować bez zmian. Zwykły eksport bazy danych może przenieść te niespójności zamiast je naprawić.

#### Gdzie mapowanie SKU łączy się z innymi systemami

SKU jest często kluczem łączącym Twój sklep z wszystkim wokół niego — feedami dostawców, systemem magazynowym czy realizacji zamówień, oprogramowaniem księgowym, ofertami na marketplace. Jeśli SKU zmieni format lub wartość podczas migracji bez aktualizacji każdego połączonego systemu, te integracje zaczynają nie dopasowywać produktów, mimo że sam sklep wygląda prawidłowo. Mapowanie musi uwzględniać te systemy zależne, nie tylko dziać się wewnątrz nowej platformy.

#### Co sprawdzamy przed migracją SKU

Audytujemy istniejący zbiór SKU pod kątem duplikatów, niespójnego formatowania i osieroconych SKU (przywoływanych przez zamówienie lub feed, ale nie przez aktywny produkt), zanim zdecydujemy, czy zachować je bez zmian, czy znormalizować na nowej platformie. Zachowanie istniejących SKU jest zwykle preferowane, gdy zależą od nich systemy dalej w łańcuchu; normalizacja ma sens, gdy sam stary schemat SKU był problemem.

#### FAQ

Q: Czy powinienem zachować dokładnie te same SKU na nowej platformie?
A: Zwykle tak, jeśli zależy od nich jakikolwiek feed dostawcy, system realizacji zamówień czy oferta na marketplace — zmiana SKU zrywa te integracje, chyba że są zaktualizowane w tym samym czasie. Oceniamy to indywidualnie, zamiast domyślnie wybierać jedną z opcji.

Q: Co się dzieje ze zduplikowanymi SKU podczas migracji?
A: Trzeba je rozwiązać przed migracją lub w jej trakcie, a nie przenosić dalej — większość platform nie pozwala na prawdziwe duplikaty SKU, a pozostawienie zautomatyzowanemu importowi zgadywania, jak je zdeduplikować, ryzykuje scaleniem lub usunięciem niewłaściwego produktu.

Q: Czy mapowanie SKU wpływa na historię moich zamówień?
A: Może, jeśli historyczne zamówienia odwołują się do SKU, które się zmieniają — uwzględniamy to, aby dawne rekordy zamówień nadal poprawnie odnosiły się do właściwego produktu po przenosinach, zamiast mapować tylko żywy katalog.

Q: Czy mapowanie SKU jest zautomatyzowane czy ręczne?
A: To mieszanka — proste dopasowania 1:1 można zautomatyzować i szybko zweryfikować, ale niejednoznaczne przypadki (duplikaty, niespójne formaty, brakujące SKU) wymagają decyzji człowieka, a nie algorytmu opartego na zgadywaniu.

### Dane strukturalne

URL: https://prevedshop.com/pl/slownik/dane-strukturalne
Language: pl
Last reviewed: 2026-07-21

Dane strukturalne to znaczniki dodawane do strony (najczęściej według słownika schema.org, w formacie JSON-LD), które opisują jej treść w sposób zrozumiały dla maszyn — oznaczenie strony jako Product z ceną i dostępnością, albo Organization z nazwą i adresem URL, zamiast pozostawiać wyszukiwarkom wnioskowanie o tym z widocznego tekstu. To dzięki nim wyniki wyszukiwania mogą pokazywać rozszerzone funkcje, jak oceny w gwiazdkach, cenę czy rozwijane FAQ, bezpośrednio w wynikach.

#### Co faktycznie umożliwiają dane strukturalne

Wyszukiwarki często potrafią wystarczająco dobrze zrozumieć zwykłą treść strony, ale dane strukturalne usuwają niejednoznaczność i odblokowują konkretne funkcje prezentacji — rozszerzone wyniki produktowe z ceną/dostępnością/oceną, akordeony FAQ pokazywane wprost w wynikach wyszukiwania, ścieżki nawigacji (breadcrumbs) w fragmencie wyniku i więcej. Żadna z nich nie jest gwarantowana (wyszukiwarki decydują, kiedy z nich skorzystać), ale bez znaczników te funkcje generalnie w ogóle nie są dostępne.

#### Dlaczego wymagają uwagi podczas migracji

Dane strukturalne nie są czymś, co każda platforma generuje automatycznie, a te platformy, które je generują, nie robią tego wszystkie identycznie — schemat produktu, schemat FAQ i schemat ścieżki nawigacji muszą każdorazowo odzwierciedlać to, co faktycznie znajduje się na stronie. Migracja to częsty moment, w którym dane strukturalne albo całkowicie znikają (nowy motyw/szablon ich nie zawiera), albo stają się nieprawidłowe (oznaczone dane przestają zgadzać się z widoczną treścią strony, co wyszukiwarki mogą raczej karać niż nagradzać).

#### Oznaczaj tylko to, co jest naprawdę prawdziwe

Najważniejsza zasada dotycząca danych strukturalnych to opisywanie czegoś realnego i widocznego na stronie — znacznik FAQPage tylko tam, gdzie FAQ faktycznie jest pokazane, znacznik Review/rating tylko dla opinii, które naprawdę istnieją, znacznik Product z prawdziwą ceną i prawdziwą dostępnością. Znaczniki niezgodne z widoczną stroną naruszają własne wytyczne wyszukiwarek i mogą prowadzić do ignorowania danych strukturalnych albo ukarania strony, a nie tylko do tego, że „nie pomagają”.

#### FAQ

Q: Czy dane strukturalne gwarantują rozszerzone wyniki w wyszukiwarce?
A: Nie — umożliwiają rozszerzone wyniki, ale wyszukiwarki niezależnie decydują, czy je wyświetlić, na podstawie trafności i własnych kontroli jakości. Nie ma sposobu, by zagwarantować pojawienie się konkretnego rozszerzonego wyniku.

Q: Czy moja nowa platforma doda dane strukturalne automatycznie?
A: Niektóre platformy domyślnie generują podstawowe dane strukturalne (jak znacznik Product); inne wymagają dodania ich jawnie przez motyw lub aplikację. Sprawdzamy, co nowa platforma oferuje od razu, i uzupełniamy braki, zamiast zakładać, że jest to obsłużone.

Q: Czy dodanie danych strukturalnych może zaszkodzić moim wynikom SEO?
A: Tylko jeśli są niedokładne lub manipulacyjne — znaczniki niezgodne z rzeczywistą treścią strony naruszają wytyczne wyszukiwarek. Dokładne dane strukturalne odzwierciedlające prawdziwą treść strony nie niosą tego ryzyka.

Q: Jaki jest najczęstszy błąd z danymi strukturalnymi podczas migracji?
A: Całkowita ich utrata, gdy nowy motyw czy szablon nie przenosi tego, co miała stara platforma, albo pozostawienie aktywnych nieaktualnych znaczników, które przestały pasować do przeprojektowanej strony — oba sprawdzamy w ramach QA migracji.

Sources:
- Google Search Central: jak działają dane strukturalne: https://developers.google.com/search/docs/appearance/structured-data/sd-policies

### Slug URL

URL: https://prevedshop.com/pl/slownik/url-slug
Language: pl
Last reviewed: 2026-07-21

Slug URL to czytelna dla człowieka część adresu strony, która ją identyfikuje — w `prevedshop.com/platforms/shopify` slugiem jest `shopify`. Zwykle wywodzi się z nazwy produktu lub strony, zapisany małymi literami i w formie bezpiecznej dla adresu URL, i to właśnie go widzą i do niego odwołują się zarówno odwiedzający, jak i wyszukiwarki, gdy linkują do strony lub zapisują ją w zakładkach.

#### Dlaczego slugi mają znaczenie wykraczające poza czytelność

Jasny, opisowy slug pomaga odwiedzającym zrozumieć, o czym jest strona, zanim jeszcze klikną, a wyszukiwarki rzeczywiście przypisują pewną wagę trafnym słowom pojawiającym się w adresie URL. Ale większe znaczenie slugu jest strukturalne: to część trwałego adresu strony, do którego odwołuje się każdy link wewnętrzny i zewnętrzny, zapisana zakładka i zaindeksowany wynik wyszukiwania.

#### Dlaczego migracje często zmieniają slugi, celowo lub nie

Każda platforma ma własne zasady generowania i struktury slugów — limity długości, dozwolone znaki, to, czy slugi produktów są zagnieżdżone pod ścieżką kategorii czy płaskie, jak rozróżniane są zduplikowane nazwy. Przejście na nową platformę często zmienia przynajmniej część slugów, czasem dlatego, że nowa platforma wymusza inny wzorzec, czasem dlatego, że to okazja, by naprawić bałaganiarskie stare slugi ze starego systemu. Tak czy inaczej, zmieniony slug oznacza zmieniony adres URL, a zmieniony adres URL wymaga przekierowania (zobacz przekierowanie 301) ze starego adresu.

#### Utrzymywanie stabilnych slugów tam, gdzie to ważne

Dla stron o znaczącej istniejącej pozycji w wyszukiwarce lub dużej liczbie linków przychodzących zachowanie dokładnie tego samego slugu na nowej platformie (jeśli platforma na to pozwala) całkowicie eliminuje potrzebę przekierowania i jest zwykle najprostszym sposobem na zachowanie pozycji tej strony. Tam, gdzie slug musi się zmienić, zaplanowanie nowego slugu razem z jego przekierowaniem — zamiast pozwolenia platformie na automatyczne wygenerowanie go i traktowania adresu URL jako refleksji po fakcie — utrzymuje przejście czystym.

#### FAQ

Q: Czy mogę zachować dokładnie moje stare slugi URL na nowej platformie?
A: Często tak, jeśli zasady adresów URL nowej platformy na to pozwalają i ustawisz je celowo zamiast akceptować te generowane automatycznie — to jeden z najprostszych sposobów, by w ogóle uniknąć konieczności przekierowania tej strony.

Q: Czy zmiana slugu szkodzi SEO?
A: Nie, jeśli towarzyszy jej właściwe przekierowanie 301 ze starego slugu na nowy — przekierowanie przekazuje dalej większość zgromadzonego sygnału rankingowego. To zmiana slugu bez przekierowania powoduje szkody SEO, nie sama zmiana slugu.

Q: Czy powinienem użyć nazwy produktu dokładnie jako slugu?
A: Generalnie tak, uproszczonej do formy bezpiecznej dla adresu URL (małe litery, myślniki zamiast spacji, bez znaków specjalnych) — slugi napchane niepowiązanymi słowami kluczowymi wykraczającymi poza faktyczny temat strony nie dają dodatkowej korzyści i wyglądają jak spam zarówno dla odwiedzających, jak i wyszukiwarek.

Q: Co się stanie, jeśli dwa produkty wygenerują ten sam slug?
A: Platforma potrzebuje reguły rozróżniającej — zwykle dodania numeru lub dodatkowego identyfikatora. Sprawdzamy to podczas migracji, ponieważ kolizje zduplikowanych slugów mogą inaczej sprawić, że strona jednego produktu po cichu nadpisze adres URL innego.

### Services

### Migracja i mapowanie danych sklepu internetowego

URL: https://prevedshop.com/pl/uslugi/czyszczenie-i-mapowanie-danych
Language: pl
Last reviewed: 2026-07-20

Stare katalogi z czasem gromadzą zduplikowane produkty, niespójne kategorie i pola, których przeznaczenia nikt już nie pamięta. Czyścimy to i mapujemy to, co zostaje, na rzeczywisty model danych nowej platformy — zamiast kopiować bałagan bez zmian.

#### Czego szukamy

Zduplikowanych lub niemal identycznych produktów, osieroconych kategorii, niespójnego nazewnictwa atrybutów, pustych lub błędnie sformatowanych pól oraz starych pól niestandardowych, które niczego już sensownie nie reprezentują. To, co znajdziemy, omawiamy z Tobą i ustalamy, co poprawić, scalić lub usunąć.

#### Mapowanie, a nie zgadywanie

Każde pole źródłowe otrzymuje jawne mapowanie na pole docelowe — albo jawną decyzję, że się nie mapuje i potrzebuje innego miejsca (pole niestandardowe, tag, albo żadne). Dokumentujemy to mapowanie, aby było możliwe do zweryfikowania, a nie czarną skrzynką.

#### Dlaczego to ważne jeszcze przed uruchomieniem

Czyszczenie i mapowanie danych przed migracją jest dużo tańsze niż naprawianie ich po uruchomieniu, gdy polegają na nich już klienci i wyszukiwarki. Pominięcie tego kroku to jeden z najczęstszych powodów problemów, które ujawniają się później.

#### FAQ

Q: Czy usuniecie dane bez pytania mnie?
A: Nie — to, co wygląda na problem, omawiamy z Tobą i ustalamy działanie, zanim cokolwiek zostanie scalone lub usunięte.

Q: Czy potraficie usunąć duplikaty z wielu starych importów?
A: Tak, to jedna z częstszych próśb przy czyszczeniu — starsze sklepy, które przez lata przeszły przez kilka importów feedów dostawców, często mają rzeczywiste duplikaty.

Q: Czy zajmujecie się polami niestandardowymi bez jasnego celu?
A: Sprawdzamy, do czego pole prawdopodobnie służyło (na podstawie wzorców w danych i, jeśli to możliwe, Twoich wskazówek), zanim zdecydujemy, czy je zmapować, wykorzystać inaczej, czy usunąć.

### Zmiana platformy sklepu internetowego od decyzji do uruchomienia

URL: https://prevedshop.com/pl/uslugi/zmiana-platformy-sklepu
Language: pl
Last reviewed: 2026-09-25

Zmiana platformy (replatforming) to najpierw decyzja biznesowa, a dopiero potem migracja danych. Wymieniasz system, na którym działa katalog, koszyk, integracje i ruch organiczny – zwykle dlatego, że obecny stał się zbyt drogi, ograniczający lub ryzykowny. Pomagamy podjąć decyzję na podstawie faktów, a potem planujemy i prowadzimy przejście tak, by nowa platforma wystartowała z danymi, adresami URL i integracjami.

#### Kiedy zmiana platformy się opłaca, a kiedy nie

Dobre powody: platforma osiągnęła koniec życia lub nie dostaje już aktualizacji bezpieczeństwa (Magento 1, Shopware 5); hosting, łatki i utrzymanie rozszerzeń kosztują więcej, niż sklep jest w stanie udźwignąć; platforma blokuje to, czego potrzebuje firma – nowe rynki, ceny B2B, headless, nowoczesny koszyk; albo zespół utrzymuje system zamiast sprzedawać.

Słabe powody to przestarzały szablon, jedna brakująca funkcja, którą rozwiązałaby aplikacja, lub prezentacja handlowca. Redesign albo konkretna integracja często wychodzi taniej – wtedy to powiemy.

#### Najpierw wymagania, potem wybór platformy

Zaczynamy od tego, co sklep naprawdę robi: struktura katalogu i typy produktów, reguły cenowe i grupy klientów, rynki, języki i waluty, integracje z ERP, magazynem i przewoźnikami, marketplace'y i feedy, treści i SEO oraz funkcje niestandardowe. Każde wymaganie oznaczamy jako konieczne, zastępowalne lub do wycofania i z tą listą porównujemy platformy.

#### Co psuje się przy zmianie platformy

Model danych rzadko się zgadza: atrybuty, warianty, zestawy i drzewa kategorii działają w systemie docelowym inaczej. Zmienia się struktura adresów URL, więc każdy istotny adres potrzebuje celu i przekierowania 301. Wtyczki i aplikacje nie przechodzą – ich dane i funkcje wymagają zamiennika, przebudowy lub decyzji o wycofaniu. Integracje z ERP, księgowością, przewoźnikami i marketplace'ami trzeba przepiąć i przetestować. Haseł klientów zwykle nie da się przenieść na platformę hostowaną.

#### Całkowity koszt, nie tylko licencja

Porównaj pełny obraz na kilka lat: abonament lub licencję, hosting i bezpieczeństwo, opłaty za płatności, aplikacje i rozszerzenia, rozwój, samą migrację i wewnętrzny czas na obsługę. Pomagamy zbudować to porównanie z Twoich wymagań; nie sprzedajemy licencji.

#### Od decyzji do uruchomienia

Po wyborze platformy zmiana staje się zarządzaną migracją: audyt źródła, mapowanie danych, migracja próbna i akceptacja, plan SEO i przekierowań, przepięcie integracji, zamrożenie treści, migracja przyrostowa, uruchomienie i kontrola po starcie. Duże sklepy często migrują etapami, aby każdy krok dało się sprawdzić.

#### FAQ

Q: Czym różni się zmiana platformy od migracji?
A: Zmiana platformy to decyzja i projekt przeniesienia biznesu na nowy system e-commerce. Migracja to jego część, która przenosi dane, adresy URL i treści.

Q: Ile trwa zmiana platformy sklepu?
A: Zależy od katalogu, integracji, projektu graficznego i tempa decyzji. Harmonogram podajemy po ocenie.

Q: Shopify, WooCommerce, PrestaShop czy zostać?
A: Zależy od wymagań, rynków, integracji i budżetu. Pozostanie przy obecnej platformie to uprawniony wynik.

Q: Czy można zmienić platformę bez utraty SEO?
A: Pozycji nie da się zagwarantować. Ryzyko zmniejsza pełna inwentaryzacja URL, przekierowania 301, przeniesione metadane, poprawione linki wewnętrzne i monitoring po uruchomieniu.

### Zarządzana migracja sklepu: jedna osoba od audytu do uruchomienia

URL: https://prevedshop.com/pl/uslugi/migracja-zarzadzana
Language: pl
Last reviewed: 2026-07-20

Jeden odpowiedzialny lider migracji planuje, przeprowadza i weryfikuje Twoją migrację: produkty, warianty, klientów, zamówienia, media, treści oraz design sklepu — jako jeden skoordynowany projekt, a nie stos niepowiązanych eksportów.

#### Co obejmuje

Zarządzana migracja obejmuje cały katalog — produkty, warianty, kategorie i atrybuty —, konta klientów i historię zamówień, media i treści, pola niestandardowe oraz plan adresów URL/przekierowań. Design sklepu jest przenoszony lub odtwarzany na platformie docelowej jako część tego samego projektu, a nie jako późniejsza niespodzianka na fakturze.

Dokładny zakres ustalamy już podczas oceny, więc nie musisz zgadywać, co obejmuje „migracja”, dopóki nie przyjdzie faktura.

#### Jak działa przeniesienie designu

Tam, gdzie platforma docelowa realnie na to pozwala, odtwarzamy obecny design. Tam, gdzie platformy są zbyt różne, by przenieść design jeden do jednego, mówimy o tym z wyprzedzeniem i proponujemy podejście — dostosowanie designu do ograniczeń nowej platformy, a nie udawanie, że to prosta kopia.

#### Jeden lider od początku do końca

Wyznaczony lider migracji odpowiada za cały projekt — ocenę, mapowanie, migrację testową, walidację, uruchomienie i kontrole po uruchomieniu. Powtarzalne kontrole automatyczne pomagają sprawdzać dane i oznaczać niespójności, a lider weryfikuje i zatwierdza każdy etap przed przejściem dalej.

#### FAQ

Q: Jak długo trwa zarządzana migracja?
A: Zależy od wielkości katalogu, złożoności danych oraz liczby pól niestandardowych czy integracji — realny harmonogram podajemy dopiero po ocenie, a nie jako ogólny szacunek.

Q: Co jeśli moja obecna platforma nie ma czystego eksportu?
A: Pracujemy z tym, co masz — eksportem bazy danych, dostępem do API, feedami XML/CSV lub ich kombinacją. Bardziej chaotyczne źródła wymagają więcej czasu na ocenę, co uwzględniamy z góry.

Q: Czy migrujecie także zainstalowane aplikacje i integracje?
A: Migrujemy dane, na których te aplikacje się opierają, ale konfigurację konkretnej aplikacji zazwyczaj trzeba odtworzyć w odpowiedniku na platformie docelowej, jeśli taki istnieje. Zaznaczamy to już podczas oceny, a nie dopiero przy uruchomieniu.

### Migracja SEO sklepu internetowego i mapa przekierowań 301

URL: https://prevedshop.com/pl/uslugi/seo-i-przekierowania
Language: pl
Last reviewed: 2026-07-20

Struktury adresów URL rzadko przetrwają zmianę platformy bez zmian. Mapujemy stare adresy URL na ich nowe odpowiedniki i konfigurujemy przekierowania jako kluczowy, zaplanowany element migracji — a nie poprawkę wprowadzaną po tym, jak pozycje już spadły.

#### Mapowanie adresów URL, a nie zgadywanie

Tworzymy jawną mapę każdego istotnego starego adresu URL na jego nowy odpowiednik — strony produktów, kategorie, blog czy strony z treścią oraz wszelkie niestandardowe landing page. Strony bez czystego odpowiednika otrzymują udokumentowaną decyzję, a nie ciche 404.

#### Przekierowania i metadane

Przekierowania 301 wdrażamy na nowej platformie jeszcze przed uruchomieniem, a metadane (tytuły, opisy, tagi kanoniczne) przenosimy tam, gdzie są nadal faktycznie trafne dla nowego adresu URL. Sprawdzamy łańcuchy i pętle przekierowań, zamiast zakładać, że mapowanie 1:1 jest automatycznie poprawne.

#### Co możemy, a czego nie możemy obiecać

Nie możemy zagwarantować konkretnych pozycji w wyszukiwarce — uczciwie nie może tego zrobić nikt, bo pozycja zależy od wielu czynników niezwiązanych z samą migracją. To, co kontrolujemy i traktujemy jako twardy wymóg, to ciągłość adresów URL: aby stare linki i zakładki prowadziły do właściwej nowej strony, a nie donikąd.

#### FAQ

Q: Czy moje pozycje w Google przetrwają migrację?
A: Poprawne mapowanie adresów URL i przekierowania to zdecydowanie najważniejszy czynnik zachowania pozycji podczas migracji i traktujemy je jako kluczowy element usługi. Nie możemy zagwarantować konkretnych pozycji, bo zależą od czynników niezwiązanych z migracją.

Q: Co się dzieje ze stronami, których nie ma na nowej platformie?
A: Oznaczamy je już na etapie mapowania i ustalamy z Tobą najlepszy cel przekierowania — zwykle najbliższą odpowiadającą kategorię lub odpowiednią stronę zbiorczą, a nie ogólne przekierowanie na stronę główną.

Q: Czy aktualizujecie też linki wewnętrzne, nie tylko przekierowania zewnętrzne?
A: Tam, gdzie to praktyczne, tak — linki wewnętrzne prowadzące do starych wzorców adresów URL są aktualizowane w ramach migracji, ponieważ łańcuchy przekierowań spowalniają ładowanie i osłabiają wartość linku.

### Integracja feedów dostawców

URL: https://prevedshop.com/pl/uslugi/integracja-feedow-dostawcow
Language: pl
Last reviewed: 2026-07-20

Prowadzenie katalogu w oparciu o feedy dostawców oznacza radzenie sobie z niespójnymi formatami, zduplikowanymi SKU u różnych dostawców oraz czasem aktualizacji, który nie zawsze odpowiada oczekiwaniom Twojej platformy. Podłączamy i normalizujemy te feedy, aby katalog pozostawał dokładny bez ręcznej obsługi.

#### Co normalizujemy

Feedy dostawców rzadko mają wspólny format — nazwy pól, struktury kategorii, a nawet jednostki miary różnią się między dostawcami. Każdy feed mapujemy na spójną strukturę w Twojej platformie, aby produkty w katalogu zachowywały się tak samo niezależnie od źródła.

#### Duplikaty i łączenie

Gdy ten sam produkt oferuje kilku dostawców, możemy połączyć oferty, wybrać preferowane źródło, albo zostawić je osobno — zależnie od tego, jak chcesz zarządzać ceną i dostępnością. Tę decyzję podejmujemy razem z Tobą, a nie jako domyślne ustawienie, które narzucamy.

#### Aktualność danych

Częstotliwość aktualizacji feedów zależy od tego, co faktycznie dostarczają Twoi dostawcy i co platforma jest w stanie rozsądnie przetworzyć — ustalamy realny harmonogram, zamiast obiecywać aktualizacje w czasie rzeczywistym, których feed źródłowy nie jest w stanie utrzymać.

#### FAQ

Q: Czy możecie połączyć feedy od kilku dostawców w jeden katalog?
A: Tak — łączenie, usuwanie duplikatów i normalizacja wielu feedów dostawców w jeden spójny katalog to standardowa część tej usługi.

Q: Co się dzieje, gdy dostawca wycofa produkt?
A: Zależnie od preferencji możemy oznaczyć go jako niedostępny, ukryć, albo pozostawić widoczny ze statusem przedsprzedaży — konfigurujemy to raz, a przy kolejnych aktualizacjach feedu stosuje się automatycznie.

Q: Czy feedy dostawców można przetłumaczyć na inne rynki?
A: Tak, treść feedu można przetłumaczyć — automatycznie lub według własnego mapowania, które nam dostarczysz, zależnie od wymaganej dokładności.