Magento 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 Target Structure
Prepare a concise target-structure map covering websites, stores, store views, languages, currencies, Catalog ownership, Customer groups, inventory, content, and integrations.
| Preparation area | Decision to record | Owner | Ready evidence |
|---|---|---|---|
| Website and store-view scope | Which brands, regions, languages, currencies, domains, and localized values need separate scope | Commerce owner | Website/store/store-view matrix |
| Product architecture | Which source records become simple, configurable, grouped, bundle, virtual, or downloadable Products | Catalog owner | Product-family classification |
| Attribute governance | Which fields become attributes, attribute sets, custom options, content, or external data | Catalog and technical owners | Attribute dictionary and sample values |
| Inventory ownership | Whether Magento, ERP, WMS, supplier, or marketplace owns stock | Inventory owner | Source/stock/system-of-record map |
| Customer and Order history | Which Customer groups, addresses, statuses, adjustments, and external references must remain understandable | Operations and support | Representative Customer and Order packet |
| Extension boundaries | Which modules and custom tables create important records | Technical owner | Dependency register |
The target map should establish destination ownership without becoming a complete Magento implementation specification.
Prepare Access, Backups, and Source Evidence
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.
| Evidence item | Why it is needed | Ready condition |
|---|---|---|
| Database/media backup | Preserves records not exposed through standard exports | Backup date, storage location, and restore owner are documented |
| Attribute dictionary | Explains custom fields and Product-class differences | Every important attribute has purpose, type, scope, and sample values |
| Extension inventory | Identifies records outside Magento core | Every critical module has a business and technical owner |
| URL inventory | Protects route continuity | Priority Product, Category, and content paths have intended destinations |
| External-ID register | Protects integration continuity | Keys are assigned to the correct Product, Customer, Order, or inventory level |
A missing extension export, inaccessible media folder, or undocumented custom table must remain visible as an unresolved preparation item.
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.
| Source behavior | Magento preparation decision | Required evidence |
|---|---|---|
| Choice creates an independent SKU or stock record | Define configurable parent and associated simple Products | Parent/child IDs, SKUs, attributes, stock, prices, and images |
| Products are merchandised together but sold independently | Define grouped Product relationship | Group members and quantities |
| Customer assembles a set | Define bundle components and selection rules | Component Products, quantities, pricing, and inventory owner |
| Value modifies one Product without independent stock | Define custom option or another owner | Option type, values, price effect, and historical Order example |
| Product is digital or non-shipped | Define downloadable or virtual Product structure | File, access, shipping, and Order context |
| Source uses duplicate Products for regional scope | Define website/store-view ownership or intentional separate Products | Regional content, price, URL, and identifier examples |
Normalize duplicate SKUs, orphan child Products, inconsistent option labels, missing parent links, obsolete Products, and unsupported combinations before mapping is finalized.
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.
| Field pattern | Intended Magento owner | Ready evidence |
|---|---|---|
| Variation-defining value | Configurable attribute and associated simple Products | Controlled values and Product-family examples |
| Technical specification | Product attribute assigned through an attribute set | Type, scope, allowed values, and display/search purpose |
| Customer-entered value | Custom option, extension, or Order-line owner | Storefront and historical Order example |
| Integration-only value | Product or child-SKU attribute used by an external system | External-system owner and uniqueness rule |
| Legacy source workaround | Normalized target attribute, content, extension, or exclusion | Decision record explaining the continuing purpose |
The ready condition is that each major Product class has an approved attribute set and no important field remains undefined or assigned to several conflicting owners.
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.
| Source record | Preparation question | Ready evidence |
|---|---|---|
| Category | Is it durable Catalog structure, navigation, campaign grouping, or internal classification? | Category decision and Product-membership sample |
| Localized Product or page | Which store view owns each value? | Store-view value matrix |
| CMS Page/block | Is it reusable content, page content, or theme presentation? | Content inventory and destination owner |
| Blog Post | Which extension or content system will own it? | Post list, media, URLs, and target owner |
| Legacy URL | Which target Product, Category, or content record should receive the redirect? | Source/destination route ledger |
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.
| Preparation item | Owner | Required evidence | Ready condition |
|---|---|---|---|
| Customer identity | Customer operations | Duplicate, guest, address, and external-ID samples | Merge and retain-separate rules are documented |
| Customer groups | Commercial owner | Group list and related pricing/tax/access purpose | Each group has a continuing business meaning |
| Historical Orders | Support and finance | Representative Order packet | Lines, totals, statuses, fulfillment, refunds, and references are explained |
| Sensitive data | Legal/data owner | Approved field list | Unnecessary or unsupported personal data is excluded |
Do not use current Customer groups or Product prices to reinterpret historical Orders. The Order record should preserve its own transaction-time evidence.
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 question | Evidence | Ready condition |
|---|---|---|
| Which system owns quantity? | System-of-record map | Every priority SKU has one declared inventory authority |
| Which source location maps to which Magento source? | Location matrix | Source codes and target source codes are documented |
| Which websites use each stock? | Website/stock relationship | Sales-channel ownership is defined |
| Which Product level owns inventory? | Parent/child SKU examples | Configurable parent and child responsibilities are clear |
| Which values are opening snapshots? | Dated stock report | Snapshot date and refresh owner are recorded |
Inventory is ready when quantity, location, Product level, website relationship, and external-system ownership are all explicit.
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
| Sample | Preparation purpose |
|---|---|
| Simple and configurable Product family | Establish Product type, attributes, child SKUs, media, and inventory |
| Grouped or bundle Product | Expose component relationships and pricing ownership |
| Product with custom options | Expose one-time Customer inputs and historical Order representation |
| Localized Product or Category | Expose website, store-view, content, and URL scope |
| Customer with group and external ID | Expose identity, segmentation, and integration relationships |
| Complex historical Order | Expose options, totals, shipments, credit memos, and references |
| Multi-source inventory SKU | Expose source, stock, website, and external inventory ownership |
| Extension-owned record | Expose custom-table and target-owner decisions |
For each sample, record the source ID, source URL where relevant, business reason, intended Magento owner, related external identifiers, known exclusions, and responsible reviewer. The sample ledger is ready when every selected record has a traceable source expectation and named reviewer.
Complete the Magento Readiness Gate
| Readiness question | Required evidence | Ready condition |
|---|---|---|
| Are access and source archives recoverable? | Access record, database backup, media backup, and exports | Required records can be inspected independently of the live Source Store |
| Are Product families and attribute sets defined? | Product and attribute matrix | Every major Catalog pattern has one intended Magento structure |
| Are Categories, content, and URLs assigned? | Content and route ledger | Priority records have destinations or retirement decisions |
| Are Customer and Order meanings documented? | Customer and Order evidence packet | Identity, status, and historical relationships are explained |
| Is inventory ownership explicit? | Source/stock/system-of-record map | Every priority SKU has a declared quantity owner |
| Are extensions and external systems inventoried? | Dependency register | Every critical dependency has a continuing owner |
| Are representative migration samples selected? | Sample ledger | Ordinary and exceptional structures are covered |
| Are unresolved items controlled? | Decision log | Every open item has an owner and due date |
The preparation gate is complete when no critical Product, attribute, Customer, Order, inventory, URL, or extension decision relies on undocumented assumptions.
Conclusion
Magento 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
Which Magento preparation record should be created first?
Create the target-structure map for websites, store views, Product types, attributes, inventory, Customers, Orders, content, and integrations. It determines the evidence required for the rest of the checklist.
Why are Product samples more important than Product counts?
Counts do not reveal configurable child relationships, bundle components, custom options, localized values, or extension-owned fields. Representative Product families expose the structures the target must support.
Should every source field become a Magento attribute?
No. A value may belong to a variation, custom option, content field, extension, external system, or deliberate exclusion. Assign the field according to its business purpose and continuing consumer.
How should attribute sets be prepared?
Group Products by real management needs, define the attributes required by each group, normalize controlled values, document scope, and remove obsolete or duplicate fields.
When should inventory be prepared separately from Catalog data?
Prepare it separately whenever stock depends on sources, stocks, websites, configurable child SKUs, backorders, reservations, or an external ERP, WMS, marketplace, or supplier feed.
What should happen to extension or custom-module data?
Identify the module, core record, business purpose, tables or fields, external identifiers, and continuing target owner. Important records need an explicit destination; obsolete records can be archived or excluded.