Magento Pre-Migration Preparation Checklist

A Magento Open Source preparation package should explain which record owns each sellable item and where its values apply. A configurable parent, a child SKU, a store-view description, and stock available to a website are related but different evidence. Resolve those owners before mapping so catalog flexibility does not conceal an undefined destination structure.

Magento Open Source preparation should translate the Source Store into a documented catalog, Customer, Order, content, and extension model before any migration run begins. The Platform is flexible, but that flexibility increases the need to distinguish Product types, configurable child SKUs, custom options, attributes, attribute sets, store views, inventory sources, historical Orders, extension-owned data, and external identifiers.

For every preparation area, define the action, owner, evidence, and ready condition. This makes the representative migration test a controlled sample of the intended Magento structure rather than the first attempt to understand how the Source Store works.

Define the Magento Open Source Target Structure

Prepare a concise target-structure map covering websites, stores, store views, languages, currencies, Catalog ownership, Customer groups, inventory, content, and integrations.

The target map should name the intended Magento Open Source build, deployment, enabled modules, attribute consumers, account scope, and implementation owners. Distinguish core functionality from compatible extensions and Adobe Commerce-only requirements. Establish ownership without turning the map into a complete implementation specification or assuming that every source requirement is within migration coverage.

Prepare Access, Backups, and Source Evidence

Identify the actual Source Platform and preserve its identifiers and relationships before cleanup. When Magento is the Source, record its installed generation, websites, stores, store views, modules, database/media access, and scheduled services. For another Source, collect equivalent evidence without inventing Magento IDs. Record destination access and configuration prerequisites separately. Collect:

• source administrator access and Magento administrator access at the required permission level;
• database and media backups where available;
• recent exports or reports for Products, Categories, Customers, Orders, coupons, reviews, CMS Pages, Blog Posts, and media;
• website, store, store-view, language, currency, and domain lists;
• Product type, attribute, attribute-set, custom-option, and Category references;
• inventory source, stock, warehouse, and external inventory reports;
• Customer group, tax, and account-status examples;
• extension, custom-module, cron, API, and integration inventories;
• URL rewrite, redirect, sitemap, and high-value route lists;
• screenshots or reports explaining unusual source behavior.

Keep original database, files, media, and export evidence dated and protected, with recovery coverage confirmed independently of the live Source. Required missing extension records, inaccessible media, or undocumented custom tables must be resolved, excluded by agreement, or hold the affected scope. A future owner/date is not evidence of readiness.

Prepare Product Types and Sellable Relationships

Select examples for every Product structure that materially affects catalog management or Order history:

• simple Products;
• configurable Products with associated simple Products;
• grouped Products;
• bundle Products;
• virtual and downloadable Products;
• Products with custom options;
• Products with multiple websites or store-view values;
• Products with extension-owned fields, custom tables, or external IDs.

Freeze original Product/parent/child IDs, SKUs, option definitions, attribute assignments, and historical references before normalization. Approve a source-to-intended ledger for duplicate SKUs, orphan children, inconsistent labels, obsolete Products, and changed combinations. Keep historical purchases interpretable even when a live catalog record is excluded.

Clean Attributes and Attribute Sets

Magento attributes can affect editing, filtering, search, comparison, Product creation, and store-view content. Prepare a governed field inventory rather than copying every source field into one oversized attribute set.

For each field, document:

• business purpose;
• data type and allowed values;
• Product classes that use it;
• global, website, or store-view scope;
• whether Customers select it;
• whether search, filtering, comparison, or integration depends on it;
• whether it contains another record's identifier;
• whether it should be retained, normalized, merged, or excluded.

Each major Product class needs an agreed attribute set and a compatible active consumer for every important field. Configurable variation attributes require supported selection inputs and global scope, with definitions included in the intended set. A matching label or translated value alone cannot establish a usable variation dimension. Resolve conflicting field owners before considering the family ready.

Prepare Categories, Content, URLs, and Store-View Values

Prepare a route and content inventory covering:

• Category hierarchy and Product membership;
• Categories used only for internal organization or campaigns;
• Product and Category URL keys;
• CMS Pages, CMS blocks, Page Builder or theme-managed content;
• Blog Posts and content owned by extensions;
• localized Product, Category, and CMS values;
• high-value backlinks, paid campaign routes, policy pages, and landing pages;
• URL rewrites, redirects, and internal links.

The area is ready when every priority public route has a destination or retirement decision and each localized value has an assigned store-view owner.

Prepare Customer Groups, Customers, and Historical Orders

Customer preparation should cover registered Customers, guests, multiple addresses, Customer groups, tax treatment, account status, duplicate identities, custom fields, and external CRM or ERP keys.

For Orders, select examples with:

• configurable Products and custom options;
• grouped or bundle Products;
• discounts, coupons, taxes, shipping, and payment labels;
• invoices, shipments, credit memos, cancellations, and comments;
• marketplace, ERP, fulfillment, accounting, or CRM references;
• each important website, currency, or Customer group.

Preserve Order-time group context, prices, addresses, tax amounts, totals, and related documents as historical snapshots. Record the events that must be contained so importing history does not send notifications, capture payment, create fulfillment work, or deduct stock again.

Prepare account identity using the actual website-specific or shared account setting. Record the exact Source-to-Target password-verification decision or reset, activation, or first-login plan separately, including identity-provider and customer-communication owners.

Prepare Inventory and Fulfillment Ownership

Magento inventory can involve sources, stocks, website assignments, source quantities, salable quantity, reservations, backorders, pickup locations, drop shippers, and external inventory systems.

Prepare examples for:

• simple and configurable child SKUs;
• single-source and multi-source Products;
• backordered, low-stock, out-of-stock, or preorder-like records;
• warehouse, store, supplier, and drop-ship locations;
• Products synchronized with ERP, WMS, marketplace, or fulfillment systems;
• stock that must be refreshed near the migration window.

Inventory is ready when quantity, location, child SKU, website/stock relationship, and external authority are explicit. Capture dated source quantities separately from salable availability, thresholds, and reservations for outstanding Orders. Agree how opening stock and pending obligations will be represented; copying a salable number into physical stock can count the same obligation twice. Historical events must not recreate an unintended stock deduction.

Inventory Extensions, Custom Modules, and External Systems

Create a dependency register for every extension, custom module, modified table, API, scheduled process, and external system that changes Product, Customer, Order, inventory, content, or URL behavior.

Record:

• module or system name;
• business purpose;
• core records extended;
• custom fields, tables, statuses, or IDs created;
• export or API availability;
• business and technical owner;
• continuing target owner or replacement;
• data to archive or exclude.

Priority dependencies include search, reviews, loyalty, subscriptions, payment, tax, shipping, marketplaces, ERP, PIM, WMS, CRM, accounting, consent, analytics, and custom checkout or fulfillment logic.

The register is ready when every important dependency has a named target owner and stable key. Do not describe extension records as ordinary Magento fields unless the core Platform truly owns them.

Select Representative Migration Test Samples

For each sample, record source IDs and URL where relevant, the business reason, original values and relationships, intended Magento representation, external identifiers, agreed exclusions, and a reviewer. Include stock and outstanding-order context for inventory samples. The ledger is ready when it provides source expectations for later validation, rather than assuming that an imported record proves the architecture.

Complete the Magento Open Source Readiness Gate

The preparation gate is complete when no required Product, attribute, Customer, Order, inventory, URL, or extension decision relies on undocumented assumptions. Resolve the gap, agree its explicit exclusion, or hold the affected scope. Record the boundary, impact, and owner of accepted noncritical exceptions separately.

Conclusion

Magento Open Source preparation should create a recoverable, platform-specific evidence package. Product types, attribute sets, Categories, store views, inventory sources, Customer groups, historical Orders, extensions, content, URLs, and external IDs all need explicit owners.

When those decisions are documented before the representative migration test, sample records can represent the intended Magento architecture instead of forcing the team to infer it from imported data.

Common Questions