> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wisepim.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Migrate platforms without losing data
> Replatforming without losing product data: use WISEPIM as the middle layer, rehearse the move on a copy, and land on the new store with better content.
Moving stores is the scariest week your catalog will ever have. Years of descriptions, categories, and attributes sit in the old system, and a straight copy usually loses something quietly: an attribute that had nowhere to go, a category tree that flattened, a URL structure that changed underneath your rankings. The way out is to stop treating the move as a copy. Put WISEPIM in the middle, land the old catalog there, improve it while it sits still, and push a better catalog into the new store than the one you took out.
Budget about half a day of hands-on work, plus background import and export time that scales with your catalog size. If there is no old platform to leave and this is simply your first catalog, follow [the first-catalog series](/en/guides/first-catalog/import) instead.
**Before you start:** you need admin access to both platforms so you can connect them as [integrations](/en/essentials/integrations), and a WISEPIM project you are happy to fill with the old catalog. Nothing you do here touches either store until you run an export.
**What you'll get:** your full catalog in WISEPIM with a CSV snapshot you can fall back on, cleaned and re-SEO'd content, and a first push to the new platform that only sends products passing your quality rules.
The route splits once, at the rehearsal, and rejoins before anything reaches the new store:
```mermaid theme={null}
flowchart LR
A["Import old catalog"] --> B["CSV snapshot"]
B --> C["Staging rehearsal"]
B --> D["Clean and re-SEO"]
C --> D
D --> E["Quality Guard gate"]
E --> F["Push to new store"]
```
## Land the old catalog and take a snapshot
Connect both ends before you import anything. The source is what you are pulling from, and having the destination connected already means your export template and skip-unchanged baseline are ready when you get there.
Set up the source integration first, for example [Magento 2](/en/integrations/magento). Only connected platforms show up in the import modal, so this has to happen before anything else.
Do the same for the destination, for example [Shopify](/en/integrations/shopify). Connecting it now, not later, means you can test a small export the moment your data is ready.
On the [Products](/en/essentials/managing-products) page click **Import** in the toolbar and pick the old platform - only connected integrations are listed. On your first platform import WISEPIM pulls your categories and attributes in alongside the products, so the structure comes with the data instead of being rebuilt by hand. See [importing products](/en/essentials/importing-products).
Open your category tree and your attribute list and check they match the old system. A product count that looks right can still hide a category that collapsed or an attribute that arrived empty. If the import was wrong at the source, roll it back from the [Process Tracker](/en/other-features/process-tracker) before you build anything on top of it.
With nothing selected, click **Export** in the Products toolbar so the run covers the whole catalog, choose [CSV](/en/essentials/exporting-products) with all columns and languages, and keep the file. Take it now rather than after the cleanup: it is the only artifact that still holds the original values once you start bulk-editing.
The **Data Sync** category of the [automation gallery](/en/automations/templates) ships ready-made migration workflows, including Magento to Shopify and WooCommerce to Shopify. If your move is one of those pairs, apply the template and point its nodes at your own integrations rather than wiring each step yourself.
## Rehearse the whole thing on a copy
Not every move needs a rehearsal, but the decision has to happen now: a staging [project](/en/essentials/managing-projects) is one action to create today and awkward to retrofit once you have started editing.
| Your situation | Route |
| ---------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Small catalog, few custom attributes, old store stays up a while | Direct cutover - clean in place, export when it passes your rules |
| Thousands of products, or restructuring you cannot eyeball | Staging project - make the expensive mistakes on a copy |
| The old store switches off on a fixed date | Staging project - you want a proven run, not a first attempt |
| Someone has to sign off on what changed before it ships | Staging project - **Compare Projects** turns your edits into a readable diff |
Chose direct cutover? Skip ahead. The rest of this section builds the copy.
Open the **Projects** page from the main menu and choose **Duplicate** in the project's actions menu: products, categories, attributes, and settings come across in one go. For security a duplicate does not carry integration API keys, so reconnect the destination there if you want to test a real export. To rehearse on a subset instead, filter to a few hundred products and **Export** them to another project.
Do the bulk restructuring and the enrichment run in the staging project. This is where you find out that a find-and-replace was too broad, at a point where it does not matter.
Open [Compare Projects](/en/essentials/managing-projects), set the staging project and the live one as A and B, and start on the **Differ** tab. It matches products by SKU and lists the fields that disagree, so you read your own changes back as a diff instead of trusting that they landed.
Once the rehearsal reads right, either repeat the same steps on the real project, or open a product's diff drawer, set the sync direction, and **Sync all** the fields across. The rehearsal is only finished when the live project carries the result.
## Clean and re-SEO before the URLs change
This is the part a plain migration skips. The content is already in one place and nothing is live yet, so it is the cheapest moment you will ever have to fix it.
Select products and click **Bulk Edit** in the Products toolbar to trim whitespace, standardize case, and strip inherited links. Filter to a small set and test each action there first. If the old catalog is genuinely messy, [clean up an inherited catalog](/en/guides/clean-up-an-inherited-catalog) has the full running order rather than this shortlist.
Reassign, replace, or set primary categories in bulk now, from the same **Bulk Edit** modal. Changing a category tree in WISEPIM is a bulk action; changing it after the new store is live is a redirect project.
In [SEO & Sitemap settings](/en/settings/seo), set the **Base URL** and then the slug patterns on the **Slugs** tab, before you generate any meta content. Every slug and sitemap preview is built on that base, so getting it right first is what makes every preview after it honest.
Select the catalog, click **Enrich with AI** in the toolbar, and run [SEO title and meta](/en/ai/seo-meta). Do it after the slug rules, not before: this writes the meta fields only, so your on-page copy stays exactly as you just cleaned it.
If the old descriptions are not worth carrying over, [Bulk Enrich](/en/ai/bulk-enrich) regenerates titles, descriptions, and SEO in one run. It always overwrites, which is exactly what you want here and exactly what you do not want on a selection you did not check first.
## Gate the first push, then cut over
Everything so far was reversible inside WISEPIM. From here you are writing into a live system, so the order flips to defensive: rules first, then a handful of products, then the rest.
In [Quality Guard](/en/quality-guard/overview), open the **Rule Packs** tab and install the pack for the platform you are moving to, or start from a single template on the **Rule Templates** tab. Packs install as drafts, so review them and toggle them active. Quality Guard runs on every export, which makes these the gate the migration has to pass.
On the Quality Guard dashboard, read the compliance rate and the **Top Failing Rules** list. Fix the rule that fails the most products first - one root cause usually clears several rules at once - and empty the [quarantine](/en/quality-guard/quarantine) before the first export, not after a half-broken store is live.
In [Export templates](/en/settings/export-templates), click **New template**, target the destination, then run the preview action to push your first three products through it and read the resulting headers. A wrong column header is a two-second catch here and a support ticket later.
Filter to a handful of representative products, export them, and open them in the new platform. Verify the storefront, not just the admin.
Run the full export. **Skip unchanged** is on by default for platform exports, so every sync after the first one only sends the products that actually changed.
## How to tell it worked
| Signal | Where to look | When it moves |
| ------------------------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| Catalog landed complete | Product count, category tree, and attribute list against the old system | When the import finishes - minutes for a small store, up to a few hours for tens of thousands of products |
| Your changes are the only differences | [Compare Projects](/en/essentials/managing-projects) → **Differ** tab, staging versus live | After each cleanup or enrichment run |
| Content is export-ready | [Quality Guard](/en/quality-guard/overview) compliance rate, and the quarantine count at zero | On the next check after a rule change or a data fix |
| The push actually delivered | The new platform's admin *and* your storefront, on a spot-check | As each export job completes in the [Process Tracker](/en/other-features/process-tracker) |
| Syncs are getting cheaper | Export job results: most products reported as skipped | From the second export onwards, with **Skip unchanged** on |
## When it doesn't work
Shopify sync is single-variant today: import reads the first variant's price, SKU, barcode, and stock onto the product, and export writes those fields back to that same variant. The full option matrix is not synced in either direction, so keep managing multi-variant options in [Shopify](/en/integrations/shopify) itself.
Open the import task in the [Process Tracker](/en/other-features/process-tracker) and choose **Rollback**. It removes what that import brought in. Rollback exists only on import tasks, so do it before you start enriching, or you throw away the work you did on top.
With **Skip unchanged** on, products that have not changed since the last export to that platform are skipped on purpose. Turn it off to force a full re-export, which is what you want after changing the channel's settings. See [exporting products](/en/essentials/exporting-products).
A [Quality Guard](/en/quality-guard/overview) rule with **Block** severity quarantines a product instead of exporting it, and on a large catalog one blocking rule can hold up the whole cutover. Open [quarantine](/en/quality-guard/quarantine), read the failure reason, fix the underlying field in bulk, then use **Bulk Resolve** to release the batch. A product you genuinely want to ship despite the violation can be bypassed with a recorded reason.
If [Pricing & Margins](/en/settings/pricing) rules are active, markups and margins are applied at export time, per channel, while your stored prices stay as they are. Check your pricing rules before you go hunting through product data.
## Related
Every destination, template, and the skip-unchanged option in full.
Duplicate a project and compare two catalogs field by field.
The careful version of a first import, with a test batch before the real one.
Dedupe, normalize, and categorize someone else's data in the right order.