Shopware to Vendure

Four of the counting queries behind the counts above (the hex value is Shopware's constant for the live, non-draft version of a row):

-- Order line items per type: only product lines become Vendure order linesSELECT type, COUNT(*) FROM order_line_itemWHERE version_id = UNHEX('0fa91ce3e96a4bc2be4bd9ce752c3425') GROUP BY type;-- Order, delivery and payment state combinations that need a Vendure stateSELECT os.technical_name AS order_state, ds.technical_name AS delivery, ts.technical_name AS payment, COUNT(*)FROM `order` oJOIN state_machine_state os ON os.id = o.state_idJOIN order_delivery od ON od.order_id = o.id AND od.version_id = o.version_idJOIN state_machine_state ds ON ds.id = od.state_idJOIN order_transaction ot ON ot.order_id = o.id AND ot.version_id = o.version_idJOIN state_machine_state ts ON ts.id = ot.state_idWHERE o.version_id = UNHEX('0fa91ce3e96a4bc2be4bd9ce752c3425')GROUP BY 1, 2, 3 ORDER BY 4 DESC;-- Size of the rule-price rebuildSELECT r.name, r.priority, COUNT(*) AS tiersFROM product_price pp JOIN rule r ON r.id = pp.rule_idWHERE pp.product_version_id = UNHEX('0fa91ce3e96a4bc2be4bd9ce752c3425')GROUP BY r.id ORDER BY r.priority DESC, r.id;-- Completeness of the redirect mapSELECT route_name, COUNT(*) FROM seo_urlWHERE is_canonical = 1 AND is_deleted = 0 GROUP BY route_name;

Shopware keeps parents and variants in the same product table. A variant is a row with a parent_id. A NULL in one of its 48 inheritable fields means "use the parent's value", not "empty". Variant-defining options and filterable properties both point at the same property_group_option table, through two different mapping tables.

Vendure puts the two roles into separate entities. Customers buy a ProductVariant, never a Product. Every Product has at least one ProductVariant, and the variant holds the SKU, price, tax category and stock. Variant options (ProductOption) and facets (FacetValue) are separate entities with no relation between them.

What this means for the transform:

• Parent rows become Product, child rows become ProductVariant. A Shopware product without children becomes a Vendure product with exactly one variant. Whether a Shopware parent could itself be ordered has to be read from the data. The reference migration made no parent buyable, and it created exactly the expected 1,514 variants. Shopware's cart does accept a parent, though, and orders reference them (see orders below).
• One Shopware property group can become two Vendure objects. "Colour" is a variant option through product_option and a filter through product_property. So Vendure gets both an option group "Colour" and a facet "Colour". The migration's binding table therefore keys on source ID plus target role. With the source ID alone as the key, the second write collides with the first.
• Vendure core has no manufacturer entity. The reference migration loaded manufacturers as values of a facet called "Manufacturer". A custom field on Product would also work.
• product_configurator_setting.price has no counterpart. In Vendure the price lives on the variant, so the transform has to fold any configurator surcharge into the variant price.
• A translation moves to Vendure only if it was written in that language. A language that only inherits a value gets no translation row in Vendure. Vendure then shows the default-language text, as Shopware does. A copied row would keep the old text after the default-language text changes.

Inheritance. Vendure has no inheritance between product and variant, so the migrator writes every variant with its own resolved values. Trap 1 shows what happens when inherited associations are not resolved.

Properties become facets. Shopware properties (product_property) and manufacturers were loaded as Vendure facets. The variant-defining options (product_option) became option groups, as described above.

Categories become collections. A Shopware product belongs to a category through a product_category row or a dynamic product_stream, and whether it is shown at all is a per-sales-channel setting in product_visibility with three levels: 10 (link only), 20 (search) and 30 (everywhere). A Vendure collection stores filters instead of members, and the worker computes the member variants in an apply-collection-filters job; visibility comes down to channel membership, enabled and Collection.isPrivate.

The migration writes each category's members as a variant-ID filter. A Shopware category page also lists the products of all its subcategories, because the listing filters on categoriesRo, which Shopware precomputes into the product_category_tree table (ProductListingRoute). The migrator reads members from that table. Its first run read product_category, and its check compared Vendure with the migrator's own model, so parent collections missed their subcategories' products without a failed check. Dynamic product streams need a copy of their members or a rebuild as Vendure filters. Visibility levels 10 and 20 have no Vendure equivalent.

Shopware stores a product's base price as JSON on the product row, keyed by currency, with gross, net and a linked flag. On top of that, product_price holds rule-bound tiers. Each row ties a product, a rule and a quantity range to another price JSON. A rule is a reusable condition tree, used by twelve different associations, from product prices to shipping availability and flows. Tax is a default rate on tax, overridden per country by tax_rule.

Vendure stores one integer price in minor units per variant, channel and currency. Whether that price includes tax is set on the channel (pricesIncludeTax). A tax rate always belongs to one tax category and one zone, and can be narrowed to a customer group. There is no rule entity and no tier table.

Two consequences follow:

• Tax needs zones that Shopware never had. Shopware's model is a default rate everywhere, with exceptions per country. Vendure's model is one rate per tax category and zone. The migration grouped countries by their set of rates across all tax categories. The reference shop's 3 tax categories produced 26 zones. The largest, "Tax 19/7/0", holds Germany plus the 222 countries that have no tax rule of their own.
• Rule prices do not migrate as data. The base price carries over exactly. The tiers in product_price do not, because Vendure has no rule to attach them to. Reproducing them takes a custom ProductVariantPriceCalculationStrategy plus an order-level strategy that re-implement Shopware's rule evaluation. The alternative is a deliberate switch to flat prices. Trap 2 shows how many prices that changed in the reference shop.

A Shopware order has its own state, and so does each delivery and each payment transaction: 4 x 6 x 12 = 288 possible combinations. Line items come in seven types (product, credit, custom, promotion, discount, container, quantity) and can be nested through parent_id. Their product_id is nullable, so a line whose product was deleted keeps its label and price. The order also stores its own rounding configuration.

A Vendure order has one state. Payments, refunds and fulfilments have their own, simpler states. Customer data and addresses are stored on the order as snapshot fields. An OrderLine must point at a ProductVariant. Anything that is not a product line becomes a Surcharge or an adjustment.

What the migrator does:

• Classify line items by type first. product lines become OrderLines. promotion, credit and custom lines become surcharges, one per tax rate with Shopware's share. discount, container, quantity and nested lines have no mapping, and the migrator refuses such orders.
• Every product line needs a variant. Lines for deleted products and for parent products that Shopware sold directly (4 and 13 lines in the reference shop) point at one disabled placeholder variant. The Shopware label and product number go into order line custom fields.
• Map the combinations that occur, not all 288. A table maps each order, delivery and payment triple to a Vendure order, payment and fulfilment state, and refuses the rest. Shopware's partial states record no quantities or amounts. The migrator therefore keeps the last full state: partly paid stays authorised, partly refunded stays settled with no refund, and partly shipped gets no fulfilment. Each is counted as an approximation. The original triple stays in a custom field.
• Write the history as it was. Order number, order date, amounts, payments, refunds and fulfilments come from Shopware. Nothing is replayed through Vendure's state machine, because transitions run business actions such as stock allocation and mails.

A Shopware guest becomes a Vendure Customer without a User; registered customers get both, with their groups and addresses.

• Shopware creates a customer row per guest checkout. One email can own several guest rows and a registered account. The migration keeps one Vendure customer per email, the registered account if there is one, otherwise the oldest guest, and attaches all their orders to it.
• Email is not a unique key once customers are bound to sales channels. Two registered accounts with one email cannot both live in one Vendure channel. The migrator refuses the second, and its orders, with a reason, instead of attaching them to a stranger. The reference shop had none.
• The password hash is in the database, not in the Admin API. Shopware hashes with PHP's PASSWORD_DEFAULT (CustomerDefinition), bcrypt with a $2y$ prefix. Vendure's bcrypt library answers false to that prefix without an error, and verifies the same hash as $2b$. The migrator rewrites the prefix and writes the hash into Vendure's NativeAuthenticationMethod. All 151 registered customers of the reference shop logged into the Shop API with their Shopware password. legacy_password and legacy_encoder mark hashes from an older system; those need a custom check or a reset.

An export that pages through an API for hours reads each page at a different moment. The extract runs every query on one connection inside a read-only transaction with a consistent snapshot. Every query on a versioned table, including every join, filters on the live version, and every query sorts by primary key, so the same database state always gives the same files. Without the version filter, draft versions of products end up in the export.

const LIVE = `UNHEX('${SHOPWARE.LIVE_VERSION}')`; // 0fa91ce3e96a4bc2be4bd9ce752c3425const hex = col => `LOWER(HEX(${col}))`;const QUERIES = {    products: `SELECT ${hex('id')} id, ${hex('parent_id')} parent_id, product_number, active,            ${hex('tax_id')} tax_id, ${hex('product_manufacturer_id')} manufacturer_id, price, stock        FROM product WHERE version_id = ${LIVE} ORDER BY ${hex('id')}`,    // What the storefront lists per category: every assigned category plus all its ancestors.    product_category_tree: `SELECT ${hex('product_id')} product_id, ${hex('category_id')} category_id        FROM product_category_tree WHERE product_version_id = ${LIVE} AND category_version_id = ${LIVE}        ORDER BY ${hex('product_id')}, ${hex('category_id')}`,    // ... 29 more};await conn.query('SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ');await conn.query('START TRANSACTION WITH CONSISTENT SNAPSHOT, READ ONLY');for (const [name, sql] of Object.entries(QUERIES)) {    const [rows] = await conn.query(sql);    const hash = await writeJson(path.join(snapshotDir, 'raw', `${name}.json`), rows);    manifest.files[name] = { rows: rows.length, sha256: hash };}await conn.query('COMMIT');

The manifest records a SHA-256 hash for every file. The transform stage refuses a snapshot whose files are missing or changed, so every later result names exactly which extract it came from.

Two helper functions resolve inheritance. inherit returns the parent's value when the variant's field is NULL. inheritRows returns the parent's rows when the variant has no rows of its own in a mapping table. Both record whether the value came from the variant or the parent. That record showed trap 1: all 535 variants took their categories from the parent.

export function inherit(own, parent, field) {    if (own[field] !== null && own[field] !== undefined) return { value: own[field], from: 'own' };    if (parent && parent[field] !== null && parent[field] !== undefined) return { value: parent[field], from: 'parent' };    return { value: null, from: 'none' };}// Decide on the complete index and filter the returned rows afterwards,// or a child with only filtered-out rows would wrongly inherit.export function inheritRows(index, own, parent) {    const mine = index.get(own.id) ?? [];    if (mine.length || !parent) return { rows: mine, from: mine.length ? 'own' : 'none' };    const theirs = index.get(parent.id) ?? [];    return { rows: theirs, from: theirs.length ? 'parent' : 'none' };}

Media, the cover image, categories, properties and visibilities all inherit as whole associations, so each goes through inheritRows.

Translations follow Shopware's own order, which goes language by language: for the requested language, first the variant's own translation, then the parent product's; then the same for the parent language; then for the system language (EntityDefinitionQueryHelper::buildTranslationChain in Shopware's source). The transform keeps a translation only if it was written in that language, and Vendure's default-language fallback does the rest.

Shopware applies a tax's default rate everywhere, except in countries that have a tax_rule. Vendure needs a rate per tax category and zone. The transform first picks, per country and tax, the rule in force at extract time (active_from), then computes each country's set of rates across all tax categories and creates one zone per distinct set.

export function groupTaxZones(countries, taxCategories, taxRules) {    // Rate per (country, tax): the tax_rule if present, otherwise the tax's default rate.    const ruleRate = new Map(        taxRules.filter(r => r.type === 'entire_country')            .map(r => [`${r.country_id}|${r.tax_id}`, Number(r.tax_rate)]),    );    const zoneByTuple = new Map();    for (const c of countries) {        const rates = taxCategories.map(t => ruleRate.get(`${c.sourceId}|${t.sourceId}`) ?? t.defaultRate);        const key = rates.join('/');        if (!zoneByTuple.has(key)) zoneByTuple.set(key, { key, rates, countryCodes: [] });        zoneByTuple.get(key).countryCodes.push(c.code);    }    // ... name the zones and mark the one matching the default rates}

For 3 tax categories this produced 26 zones. The transform reports tax rules that apply to a state or a postcode, rules that start in the future and duplicate rules as gaps. It does not merge them into the rate of the whole country.

One Shopware row can become several Vendure objects. A simple product becomes both a Product and a ProductVariant, and a property option can become both a facet value and a product option. The binding key therefore includes the role, which names the kind of Vendure object. The migrator appends every new binding to a journal file before it updates the binding table, and replays the journals on start, so a run after a crash creates no duplicates. It refuses to record an empty id.

static key(entity, sourceId, role) {    return `shopware|${entity}|${sourceId}|${role}`;}async set(entity, sourceId, role, targetId) {    const key = Bindings.key(entity, sourceId, role);    if (isEmptyId(targetId)) {        throw new Error(`Refusing to bind ${key} to the empty id ${JSON.stringify(targetId)}`);    }    const line = `${JSON.stringify({ t: new Date().toISOString(), key, targetId: String(targetId), target: this.target })}\n`;    // ... append the line to the journal, then update the in-memory table    this.map.set(key, String(targetId));    if (++this.dirty >= FLUSH_EVERY) await this.flush();}

Every reference to an object an earlier step created goes through a need() check. Without it, a missing binding would become undefined, which JSON quietly drops: the dependent object would be created without it, bound, and never repaired. With it, the dependent object waits for the next run.

A Vendure collection computes its members from filters. By default, a child collection also inherits its parent's filters, which narrows it to the intersection. The loader writes each category's members as a variant-ID filter and switches filter inheritance off. The members come from Shopware's listing index (product_category_tree), so a parent collection contains the products of its subcategories, as the Shopware category page does.

const members = [...new Set(col.offerSourceIds)].filter(isCreatable);const variantIds = members.map(ref.variant); // need() inside: a missing variant holds the collection backawait client.gql(`mutation($input: CreateCollectionInput!) { createCollection(input: $input) { id } }`, {    input: {        parentId: col.parentSourceId ? ref.collection(col.parentSourceId) : undefined,        isPrivate: col.isPrivate,          // category.active = false        inheritFilters: false,             // members are already the full listing        filters: variantIds.length            ? [{ code: 'variant-id-filter', arguments: [                { name: 'variantIds', value: JSON.stringify(variantIds) },                { name: 'combineWithAnd', value: 'true' },            ] }]            : [],        translations, // names and slugs, slugs from seo_url where present    },});

The model keeps Shopware's sibling order, which Shopware stores as a linked list through after_category_id.

For the catalogue, the verify stage compares Vendure with the migrator's own intermediate model, so it only proves that the load stage wrote the model correctly. The compare stage (oracle.mjs) checks against Shopware instead. Shopware's Admin API with the sw-inheritance: 1 header returns the inherited values as Shopware resolves them, which checks the transform stage. Shopware's Store API returns the price a guest pays. That price is in calculatedPrices, not in calculatedPrice:

// calculatedPrice is always the BASE price; rule prices live in calculatedPrices, sorted by// quantity, and the first tier covers quantity 1. That is what the storefront shows, gross// or net by the same channel mode, so it is compared with the channel-mode Vendure price.const tiers = s.calculatedPrices ?? [];const guest = toMinorUnits(tiers.length ? tiers[0].unitPrice : s.calculatedPrice?.unitPrice);const diff = guest.minor - vendurePrice(v);

My first comparison read calculatedPrice, found all 1,513 prices the Store API returned equal, and reported no price gap. Anyone who validates a migration against Shopware's Store API needs to read calculatedPrices instead.

For customers and orders, verify-sales reads Shopware's database again rather than the migrator's model: order totals, tax per rate, dates and owners, plus a Shop API login for every registered customer.

Customers and orders do not go through the Admin API. The loader is a standalone script: it boots Vendure from the target's own config with bootstrapWorker(). It starts no HTTP server, and no job queue unless the script calls startJobQueue(). Services come from the application's dependency injection container:

const { app } = await core.bootstrapWorker(config); // the server's own vendure-configconst ctx = new core.RequestContext({ apiType: 'admin', isAuthorized: true, authorizedAsOwnerOnly: false, channel });const group = await app.get(core.CustomerGroupService).create(ctx, { name: g.name });// Orders and customers: Vendure's entities, saved through its TypeORM connection.const ds = app.get(core.TransactionalConnection).rawConnection;await ds.transaction(m => writeOrder(m, core, { o, channel, taxZoneId, variants, placeholderId, bindings }));

Each customer and each order is one transaction and publishes no events: no registration or order mails, no history entries. The customer groups, shipping methods and placeholder product go through Vendure's services, though, and those publish events. The target's subscribers run inside the script, and any job they queue waits for the server's worker. After the load, cancel queued jobs that should not run for historical data, such as syncs to an ERP, remove the settled ones, and rebuild the search index. The config has to carry custom fields for the Shopware ids, the original order states and the legacy line labels. Vendure's docs create the context with RequestContextService.create(), with a superadmin user where a service checks permissions; the context built directly here worked for the calls above in the reference migration.

// Shopware's PHP bcrypt hash, made readable for Vendure's bcrypt library.if (hash.startsWith('$2y$')) return { ok: true, hash: `$2b$${hash.slice(4)}`, rewritten: true };

The stored order totals come from Vendure's own OrderTaxCalculationStrategy, so the dashboard's lines and totals agree. Where the result misses Shopware's invoice, the invoice total is stored, but only within one minor unit per surcharge:

const drift = Math.max(Math.abs(calculated.subTotal - invoice.subTotal), Math.abs(calculated.subTotalWithTax - invoice.subTotalWithTax));if (drift > surcharges.length) throw new Error(`calculated totals miss the invoice by ${drift}`);

A first version stored the invoice total at any difference. Its totals check then compared that same figure with Shopware and could never fail. verify-sales now also adds up each order's lines, surcharges and shipping, independently of the stored total.

Read from the Shopware 6.7 source (RuleLoader, CartRuleLoader, ProductPriceCalculator):

1. All rules are loaded in the order priority DESC, id ASC.
2. The rules matching the current customer and cart are kept in that order. Matching is repeated until the set is stable, because prices change the cart total and the cart total changes which rules match.
3. The first matching rule that has prices for the product wins. Not the cheapest.
4. Within that rule, the tier covering the line quantity applies.
5. No matching rule with prices means the base price applies.

Shopware: rule prices on a product, with a quantity tier for the "All customers" rule.

The reference shop shows why the order matters. Seven of its twelve rules had priority 100, so their IDs decided the price. For 1,289 variants the charged price identified the winning rule, and priority DESC, id ASC predicted it for all of them; 17 products whose price matched more than one rule were left out of that test.

Vendure has no rule engine. ProductVariantPrice holds one price per variant, channel and currency. Conditional prices therefore become two strategies: one for catalogue prices, one for cart prices.

Rules and their prices get their own tables. The Shopware rule ID is kept, because it breaks ties between rules with equal priority.

@Entity()export class ShopwareRule extends VendureEntity {  @Column() name: string;  @Column() priority: number;                      // higher wins  @Index({ unique: true }) @Column() sourceId: string; // tie-break: id ASC  @Column('simple-json') conditions: RuleConditionNode;}@Entity()export class ShopwareRulePrice extends VendureEntity {  @Index() @ManyToOne(type => ProductVariant, { onDelete: 'CASCADE' }) variant: ProductVariant;  @Column() variantId: ID;  @ManyToOne(type => ShopwareRule, { onDelete: 'CASCADE' }) rule: ShopwareRule;  @Column() ruleId: ID;  @Column() currencyCode: string;  @Column() quantityStart: number;  @Column({ type: 'int', nullable: true }) quantityEnd: number | null; // null = open-ended  @Column() net: number;                           // minor units  @Column() gross: number;}

One evaluator per Shopware condition type in use; the reference shop uses the six types below. A condition type without an evaluator must stop the import. It must never count as a match.

export const conditionEvaluators: Record<string, Evaluator> = {  alwaysValid: () => true,  andContainer: (node, facts) => node.children.every(child => evaluate(child, facts)),  orContainer: (node, facts) => node.children.some(child => evaluate(child, facts)),  customerCustomerGroup: (node, facts) => { /* TODO(build): group ids + operator */ },  customerBillingCountry: (node, facts) => { /* TODO(build): country ids + operator */ },  dayOfWeek: (node, facts) => { /* TODO(build): evaluated in the shop's timezone */ },  cartCartAmount: (node, facts) => { /* TODO(build): amount + operator, gross or net */ },  cartLineItemProductStates: (node, facts) => { /* TODO(build): download vs physical */ },};

The catalogue strategy sets listing and product page prices at quantity 1 with an empty cart. The order strategy sets the price per order line with its quantity. Each strategy wraps the strategy configured before it and calls that strategy when no rule price applies. Vendure's tax calculation therefore still runs for every price. Extending Vendure's default strategy is not possible, because @vendure/core does not export it.

export class ShopwareRuleCatalogPriceStrategy implements ProductVariantPriceCalculationStrategy {  constructor(private inner: ProductVariantPriceCalculationStrategy) {}  async calculate(args: ProductVariantPriceCalculationArgs): Promise<PriceCalculationResult> {    const facts = await this.facts.getFacts(args.ctx); // empty cart, like a Shopware listing    const rulePrice = await this.resolver.resolve(args.ctx, args.productVariant.id, 1, facts);    return this.inner.calculate(rulePrice === undefined ? args : { ...args, inputPrice: rulePrice });  }}export class ShopwareRuleOrderItemPriceStrategy implements OrderItemPriceCalculationStrategy {  constructor(private inner: OrderItemPriceCalculationStrategy) {}  async calculateUnitPrice(ctx, productVariant, orderLineCustomFields, order, quantity) {    const facts = await this.facts.getFacts(ctx, order);    const rulePrice = await this.resolver.resolve(ctx, productVariant.id, quantity, facts);    if (rulePrice !== undefined) {      return { price: rulePrice, priceIncludesTax: ctx.channel.pricesIncludeTax };    }    return this.inner.calculateUnitPrice(ctx, productVariant, orderLineCustomFields, order, quantity);  }}@VendurePlugin({  imports: [PluginCommonModule],  entities: [ShopwareRule, ShopwareRulePrice],  configuration: config => {    config.catalogOptions.productVariantPriceCalculationStrategy =      new ShopwareRuleCatalogPriceStrategy(config.catalogOptions.productVariantPriceCalculationStrategy);    config.orderOptions.orderItemPriceCalculationStrategy =      new ShopwareRuleOrderItemPriceStrategy(config.orderOptions.orderItemPriceCalculationStrategy);    return config;  },  compatibility: '^3.0.0',})export class ShopwareRulePricesPlugin {}

init() and destroy() are omitted here. Because the wrapped strategy is no longer in the config, the wrapper has to call the inner strategy's init() itself.

• Cart-amount conditions. Shopware repeats rule matching until the result is stable. Vendure prices each line inside a single recalculation, so the sketch evaluates cart conditions against the totals from before that recalculation. A cart that crosses a threshold can get a different price than in Shopware. Either accept and document it, or run a second pass when the matched rule set changes.
• Weekday. dayOfWeek has to use the shop's timezone, not the server's.
• Listings. The catalogue strategy runs once per variant on every listing, so prices have to be loaded in batches per page, not per variant.
• Simpler prices. A team can also replace rule prices with fixed channel prices or customer-group prices. That is a business decision, and the team should record it as one.

The strategy is done when it returns the same prices as Shopware in every test context. For each test case, record the price that Shopware's Store API returns. Then check that the resolver returns the same amount in minor units. The expected values come from Shopware, never from a calculation by hand.