Your catalog with configurable products unpacked into real variants, your customers, and stock across every source: from System → Data Transfer → Export.
A large catalog takes an afternoon. The configurable-product unpacking is the part that would otherwise take a fortnight.
catalog_product_....csv
read locallyThis is a Adobe Commerce products export
We can tell from the columns and the file name.
Products
128 of 129 ready128 products ready: 1 row will be skipped.
Row 84: this record has no name.
Nothing has been saved yet.
A new attribute, a shipping rule, a landing page. On paper you can do anything; in practice you file a request and wait, because the person who understands the install is not you and is not cheap.
Hosting sized for Magento, a developer on retainer, an agency for upgrades, and an upgrade cycle that is itself a project. The license was never the number that mattered.
Multi-source inventory, complex catalog rules, staged content. Serious capability, and a serious ongoing cost to operate, aimed at a team with people whose whole job this is.
Everything in this list is something an importer we maintain actually reads out of your Adobe Commerce export. It is generated from that importer, so it cannot promise you something we do not do.
Products
System → Data Transfer → Export → Entity Type: Products
catalog_product_....csv
Customers
System → Data Transfer → Export → Entity Type: Customers Main File
customer_....csv
Stock levels
System → Data Transfer → Export → Entity Type: Stock Sources
stock_sources.csv
sparx keeps what you actually use from Magento (real variants, multi-location stock, trade pricing, price lists, a proper API) and removes the part where using it requires someone else. The person who prices the products changes the prices.
Configurable products arrive as real variants with their options, not as a pile of orphan simple products.
Stock arrives per source, so a two-warehouse catalog stays a two-warehouse catalog.
An API and an MCP server, so anything you did automate keeps being automatable.
No hosting to size, no upgrade project, no retainer.
Every migration leaves something behind. Here is ours, so it is not a surprise halfway through.
Per-store-view rows are skipped. You get the default view, which is the catalog your shop is actually built on.
Catalog price rules, cart price rules and custom EAV attributes with their own logic do not come across.
Your theme and any custom modules stay behind.
Still curious? Read the platform docs, browse the API spec, or book a 20-min architecture call. We don't do high-pressure demos.
No. Everything happens on a copy. You export a file, and your Adobe Commerce account carries on exactly as it is. Plenty of people run both for a few weeks before switching their domain over.
Export the file Adobe Commerce already makes for you, drop it in, and look at what would happen before anything is saved. A large catalog takes an afternoon. The configurable-product unpacking is the part that would otherwise take a fortnight.