Magento Open Source catalog and product types setup

The first decision in a Magento Open Source catalog is which product type each sellable item should use, because the type controls what data the item needs, how it is stocked, and whether it ships. Start with a list of your merchandise and sort it into four groups. Physical items that are picked, packed and shipped usually become simple products. Items that differ only by size, color or another option, sold under one listing, usually become configurable products with child simple products. Items sold together as a set, where the customer buys components as one purchase, are candidates for bundle products. Items with no shipment, such as service fees or access passes, are virtual products, and digital files delivered by download are downloadable products. Grouped products, which bundle separate items under one storefront page without a combined price, are a fifth option that many merchants overlook.

Each type requires different data, and missing data is the most common cause of a broken import. A configurable product needs child simple products, each with its own SKU, stock and price, plus the configurable attributes that the storefront uses to let shoppers choose between them. A bundle product needs its option groups and linked products defined before it can sell correctly. A downloadable product needs the file or link to deliver after payment. Virtual products skip the shipping step, so shipping rules that depend on weight or carrier will not apply to them. Ask your team to write down, for each type, which fields are mandatory and who supplies them, before any CSV file is prepared.

Attribute sets decide which fields each product sees in the admin. A clothing set might show size and color, while a set for accessories hides them. Keeping sets narrow reduces data entry errors and keeps the import file readable, but creating too many sets makes maintenance harder. Confirm with your merchandising team which attributes are required for each set, which are optional, and which should appear in the storefront filters. Also decide early whether the category structure and the attribute sets will be governed by a single owner, because changes to either after the import can require rework across many products.

Gift cards need a separate decision. Adobe Commerce provides a dedicated gift card product type, but Magento Open Source does not include it, so you will need a workaround such as a virtual product with custom options, or a third-party extension. Each option has trade-offs for balance tracking, redemption at checkout and reporting, so confirm the approach against your sales and accounting requirements before building it. Do not assume an extension behaves the same way on every version without checking its compatibility notes.

The right model should be confirmed by testing sample products before the full import. Create a small set covering each product type you plan to use, including one configurable item with several children, one bundle, one virtual product and one item with a tax class that differs from the others. Run each through the storefront, add to cart, apply a sample promotion, calculate tax for two destination addresses, quote shipping for both physical and non-physical items, and complete a test order. Record the results and fix any gaps in the model first. Testing at this stage costs far less than correcting thousands of imported records later.

Gift cards are a product type that Adobe Commerce provides and Magento Open Source does not. If your catalog plan assumes a native gift card product, you need a workaround before the build starts. The two realistic options are a virtual product with custom options that capture the gift card amount, or a third-party extension that adds gift card behavior. Neither is a built-in feature, so the choice depends on how much of the gift card lifecycle your business needs to run inside the store and how much custom code you are prepared to own.

The first option uses a virtual product, which has no shipping weight, combined with custom options so the shopper enters a value at the product page. Your team then has to make the amount flow through the cart, the order and the invoice, and to handle the code or balance that the customer later spends. Custom options do not track balances, enforce redemption at checkout or reverse a balance on refund. Each of those behaviors must be built or confirmed separately, and the reporting you rely on for liability and breakage will also need a design. Treat this option as a custom module decision, with the cost of building and testing that code carried by your project.

The second option is a third-party extension. Before you shortlist one, confirm in writing with the vendor that it supports your target Magento Open Source 2.4.x release and the PHP version listed in Adobe's system requirements for that release. Ask whether the extension has been tested against the patch level you plan to run, and how it handles balance tracking, redemption at checkout, partial redemption, refunds to the original tender and reporting exports. Extensions also add upgrade effort: each Adobe patch or minor release may require a compatibility check, and a vendor that lags behind a release can block your upgrade plan.

Whichever route you take, verify the full flow end to end on a staging instance that matches production: purchase of the gift card, delivery of the code or balance to the buyer, redemption across multiple orders, a partially used balance, cancellation and refund of both the gift card purchase and a redeemed order, and the resulting reports for finance. Run the tests after each platform patch as well as at launch. Record who owns the extension or custom code, who fixes defects, and what the vendor's support window is, because those answers determine the ongoing cost of the workaround more than the initial build does.

Most catalog migrations onto Magento Open Source use the built-in CSV import, which covers products from most source platforms once the data has been reshaped into Magento's column model. The Data Migration Tool is the other path Adobe documents, but it applies only when the source is Magento 1. Confirm the source platform and its version with Adobe's current migration documentation before you commit to a tool, because the choice determines how much of the mapping work falls to your team and how much is handled by the tool. Whichever route you take, the catalog design from the rest of this page (attribute sets, product types and category tree) has to exist first, since the import files reference those attributes, sets and category paths by name.

Build a separate import file for each product type rather than one mixed file. Simple and virtual products share a common column structure, while configurable parents, their child products, grouped products and bundles each depend on different columns such as configurable_variations, associated product SKUs and bundle option fields. Configurable children should be imported as simple products with their attribute values populated, and the parent row then links them through the configurable variations column. Bundle selections need their option titles, types and SKU lists to match exactly, so a typo in one SKU can leave a bundle with a missing option. Import the child and component products before the parents that reference them, and test the link structure on a small set first.

Media and URL handling deserve their own checks. Image columns expect paths relative to the media import directory, so confirm the directory layout on the target server and that filenames contain no unexpected characters. Missing images usually surface only on the storefront, so sample a range of product types after import. For URL keys, decide whether the source URLs will be preserved; if they change, generate URL rewrites so existing search traffic and bookmarks still resolve, and plan redirects for anything the rewrite logic cannot match. Category assignments use the category path format, so an unmatched path creates a product with no category rather than failing loudly, which makes it easy to miss.

Test the import with a representative subset before a full load. A useful sample includes at least one product of every type you sell, a configurable with its full set of children, a bundle with several options, products with multiple images, and products in deep category paths. Run the import on a non-production copy of the database, then compare counts, SKUs, attribute values and category memberships against the source export. Record the import log and any rejected rows, and rerun the subset until those rows are clean. Keep the full-load file set versioned so the same process can be repeated in the cutover window.

Plan stock, pricing and tax alongside the catalog rather than after it. Stock sources and stock CSV files are covered on the multi-source inventory page, so the SKU list you export here should match the sources you will load later. Catalog price rules, cart rules and tax classes are covered on the price rules and tax pages, but their identifiers, such as tax class names and customer group IDs, must exist before product rows referencing them can import correctly. Ask your team to confirm these dependencies in writing before the first test run, because a missing tax class or group discovered at cutover is one of the more common reasons a catalog load has to be repeated.