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.
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 Destination 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 |
Record 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. The map establishes responsibilities and migration scope; it is not a complete implementation specification or proof that every source requirement can be migrated.
Preserve Source Access and Recovery 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 available equivalent evidence using its own identifiers. Do not invent Magento store-view codes or database keys in the Source evidence; define their intended destination separately.
Record destination access and configuration prerequisites separately. Confirm the applicable Source and Target setup methods in the platform connection directory, then collect the evidence below. A successful connection proves access, not support for every extension-owned record:
- approved administration or extraction access for the actual Source Platform, plus separate Magento Target administration at the permissions required for preparation;
- database and media backups where available;
- recent exports or reports for Products, Categories, Customers, Orders, coupons, reviews, CMS Pages, Blog Posts, and media where those records exist and the actual Source permits extraction;
- 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 | Applicable backup/export scope, date, protected storage location, and recovery 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 the actual Source Platform core | Every critical module has business and technical owners, accessible evidence and an agreed data-treatment path |
| 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 |
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 Families 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 |
- Preserve original Product, parent and 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.
Govern 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 |
Each major Product class needs an agreed attribute set and a compatible active consumer for every important field.
- Confirm supported selection inputs, global scope and attribute-set membership for configurable variation attributes.
- Prove the intended family: a matching label or translated value alone does not create a usable variation dimension.
- Resolve conflicting field owners before declaring the family ready.
Assign Content, Store Views, and Routes
Prepare a route and content inventory covering:
- Category structure: hierarchy, Product membership, and Categories used only for internal organization or campaigns.
- Content ownership: CMS Pages, CMS blocks, Page Builder or theme-managed content, and extension-owned Blog Posts.
- Localized values: Product, Category and CMS content assigned to the intended store view.
- Routes: Product/Category URL keys, high-value backlinks, paid campaigns, policy and landing pages, URL rewrites, redirects and internal links.
| Source record | Preparation question | Ready evidence |
|---|---|---|
| Category | Is it durable Catalog structure, a browse destination, 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. Use a source-to-destination route ledger to retain those decisions.
Prepare Customer Identity and Order History
Prepare Customer evidence in three groups:
- Identity: registered Customers, guests, multiple addresses, account status and duplicate identities.
- Commercial context: Customer groups and tax treatment.
- Continuing data: 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 |
Preserve Order-time group context, prices, addresses, tax amounts, totals and related documents as historical snapshots.
Record the events that must be contained during import: notifications, payment capture, fulfillment work and another stock deduction. Preserving history must not trigger those live effects 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. Name the identity-provider and customer-communication owners.
Define Inventory and Fulfillment Ownership
Separate physical stock, salable availability and fulfillment ownership. Sources, stocks and website assignments connect those layers; reservations and external inventory systems can change their meaning.
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, pickup, 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, child SKU, website/stock relationship and external authority are explicit.
- Capture dated physical source quantities separately from salable availability and thresholds.
- Preserve reservation evidence for outstanding Orders and agree how pending obligations enter opening stock.
- Contain historical events so they do not create another unintended stock deduction.
Copying a salable number into physical stock can count the same obligation twice. Reconcile the opening-stock basis before declaring the snapshot ready.
Map Extensions 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.
Check the dependency register against the systems actually used:
- Discovery and retention: search, reviews, loyalty and subscriptions.
- Transaction and fulfillment: payment, tax, shipping, and custom checkout or fulfillment logic.
- Connected commerce: marketplaces, ERP, PIM, WMS, CRM and accounting.
- Measurement and permissions: consent and analytics.
Every important dependency needs a continuing target owner, stable key and viable treatment: supported transfer, separately scoped implementation, or an agreed archive/exclusion when continued use is unnecessary.
For required workflows, confirm accessible records and a compatible consumer. An owner name alone does not make the dependency ready. Keep extension records distinct from Magento core fields; use the integration ownership model to identify continuing responsibilities.
Select Representative 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:
- Source evidence: IDs, relevant URL, business reason, original values and relationships.
- Intended output: Magento representation, external identifiers and agreed exclusions.
- Review context: reviewer, plus stock and outstanding-order evidence for inventory samples.
Confirm which samples the selected migration approach can actually exercise. A representative Product with correct parent-child relationships in Magento is useful only when its data type, fields and relationships are included in the agreed migration scope; native functionality does not establish transfer support. Keep expected record output separate from target configuration and integration tests. The ledger must define expectations for later validation; an imported record alone cannot prove the architecture.
Confirm Preparation Readiness
| Readiness question | Required evidence | Ready condition |
|---|---|---|
| Are access and source archives recoverable? | Access record, applicable database/media backups, 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 and viable, agreed treatment |
| Are representative migration samples selected? | Sample ledger | Ordinary and exceptional structures are covered |
| Are unresolved items controlled? | Decision log | Required gaps are resolved, explicitly excluded by agreement, or held; accepted noncritical exceptions retain an owner, due date, boundary, and scope effect |
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.
If a required record or relationship exceeds supported handling, use a Custom Migration assessment to resolve its data scope before declaring that area ready. Keep required target implementation assigned separately.
Conclusion
Magento Open Source preparation should leave a recoverable evidence package and an agreed destination model. Each required record, relationship and continuing system needs a defined owner and treatment.
Use representative samples to exercise that model, then carry their expected results into Magento Open Source validation. The test should confirm prepared decisions rather than become the first attempt to infer them from imported data.
Common Questions
Which Magento Open Source 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. Required records need an accessible source, viable treatment and compatible consumer. Obsolete records can be archived or excluded by agreement; archiving alone cannot satisfy a workflow that must continue.
Can salable quantity be used directly as opening physical stock?
Not without reconciling its meaning. Source quantities describe stock at locations, while salable availability can include thresholds and reservations for outstanding Orders. Preserve those dated evidence sets separately and agree the destination treatment of pending obligations. Historical Order handling must not apply a second unintended stock effect.
Does an attribute label make it ready for configurable Products?
No. Confirm the definition, global scope, compatible selection input, allowed values, attribute-set membership, and associated simple Product identities. A similar source label may instead describe content or a buyer input. Prepare the intended family and consumer before treating the field as a variation dimension.