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.
Ecommerce data we migrate, and how it is handled
| Data | What happens | Notes |
|---|---|---|
| Products and SKUs | Migrates | Core fields move directly; SKUs are checked for duplicates and empties before import. |
| Variants and options | Migrates with transformation | Source variant models (combinations, variations, configurable products) are rebuilt in the target's option structure. |
| Attributes and custom fields | Migrates with transformation | Mapped to target attributes, metafields or custom fields by an agreed scheme; unused fields are archived with approval. |
| Categories and collections | Migrates with transformation | 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 | Decided in the assessment | Depends on the target; most hosted platforms require customers to set a new password. |
| Historical orders | Migrates with transformation | Usually imported as historical records; totals, taxes and statuses are reconciled against the source. |
| Reviews | Decided in the assessment | 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 | Decided in the assessment | Each app's data is inventoried and either exported to its replacement, archived or dropped by decision. |
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.
Frequently asked questions
Will you delete data without asking?
No. We report duplicates, empty fields and legacy data, agree the action with you, and list anything excluded in the migration record.
Can you migrate product data from spreadsheets, a PIM or an ERP?
Yes. CSV, XML, API and database sources are all workable once we have samples and have written down how the source is structured.
How do you prove the data migration is complete?
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.
Can customer passwords be migrated?
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.
Do you migrate data stored by apps and plugins?
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.