Evaluate Magento Open Source as a Target Platform by identifying the catalog structures, selling rules and storefront scopes the business must support. The migration decision then separates the records to preserve from the application and systems needed to use them.
Magento Open Source combines a structured catalog with control over the application, database, infrastructure, codebase and deployment. Products can use reusable attributes, attribute sets and category trees across websites, stores and store views.
Modules, themes and integrations extend that model. This flexibility is useful only when the implementation team can govern the connected layers.
Migrated data supplies only part of the Target Store. Configuration scope, search, themes, modules, integrations, infrastructure and deployment practices determine how those records work. Confirm migration support separately from native platform capability.
Magento Open Source and Adobe Commerce share core concepts but have different edition capabilities. Familiar terminology does not establish equivalent features.
Use the Magento migration page to explore migration directions, then the migration approach guide to distinguish supported record transfer from the target implementation.
Self-Hosted Operating Responsibilities
The merchant or implementation team owns the application environment:
- Services: hosting, database, search, caching and media storage.
- Protection: certificates, backups, monitoring and security maintenance.
- Change: deployment, patching and extension compatibility.
Magento supplies the commerce application; an operating team must sustain it.
Products, Customers and Orders can be present while the environment is incomplete:
- Search or indexing has not caught up.
- Extensions are incompatible or templates omit migrated fields.
- Infrastructure is undersized.
These dependencies affect whether the Store can use the records.
| Architecture layer | Typical ownership | Migration significance |
|---|---|---|
| Commerce data | Products, Categories, Customers, Orders, reviews, CMS Pages, and related records | In-scope records must preserve relationships and commercial meaning. |
| Store configuration | Websites, stores, store views, currencies, tax, inventory, email, Order statuses, and catalog settings | Scope and future behavior must be established in the Target Store. |
| Application code | Magento Open Source core, modules, customizations, and APIs | Data may depend on module-owned attributes, tables, or business logic. |
| Presentation | Themes, layouts, blocks, templates, content, and media | Migrated data must be displayed and reached through the intended storefront routes and page layouts. |
| Infrastructure | Web, database, search, cache, queues, storage, deployment, and monitoring | Performance and reliability depend on environment design and maintenance. |
| External systems | ERP, PIM, WMS, CRM, tax, payment, shipping, analytics, and marketplaces | Identifiers and workflows require explicit integration ownership. |
Every retained customization needs a future owner and a reason to exist. Confirm whether it should become native configuration, a compatible module, separately implemented behavior or an accepted retirement; copying code or fields without their consumers is not a migration strategy.
Catalog changes feed derived indexes used by search, browsing, pricing and inventory views. Background processing, caches and deployment artifacts can therefore change what staff and customers see after data loads.
Those mechanisms belong to the operating environment. Their health affects data presentation; they are not part of the migrated record.
A merchant should therefore distinguish a data discrepancy from an environment discrepancy. A Product may be correct in storage while an outdated index, cache, theme template, or integration response makes the storefront appear wrong. That distinction becomes essential during later validation and incident diagnosis.
Catalog Structure and Discovery
Products, Attributes, and Attribute Sets
Products use reusable attributes for identity, selling and description. Attribute sets organize the fields needed by each Product family:
- Identity and selling: name, SKU, price, status, visibility, weight and tax class.
- Description and enrichment: descriptions, media and custom business fields.
Illustrative Product families need different fields:
- Clothing: size, material, care instructions and season.
- Industrial goods: voltage, certification, dimensions and compatibility.
The same structured values can support administration, storefronts, integrations, search or reporting, according to their intended use.
A coherent attribute architecture needs more than imported values:
- attribute codes should be stable and meaningful;
- data types should match their operational use;
- attribute sets should reflect real Product families;
- selectable values should be normalized where reuse matters;
- required fields should not block valid records unexpectedly;
- storefront visibility, search, filtering, comparison, and integration use should be intentional;
- obsolete extension residue should not become permanent catalog structure.
Interpret each source selling pattern through the intended Magento Product type:
- Simple Products and configurable parent-child variations.
- Bundles and grouped relationships.
- Virtual or downloadable items.
- Custom options where a purchase choice belongs to the same Product.
Similar parent-child labels do not prove equivalent behavior. SKU ownership, price, stock, images and shopper selection must agree with the chosen model.
| Catalog concern | Magento Open Source meaning | Early orientation |
|---|---|---|
| Product identity | SKU-centered commerce record with attribute-driven information | Preserve business identifiers, map native record references to destination IDs, and distinguish Product-level from child-level data. |
| Product family | Attribute set and Product type | Organize fields and selling behavior rather than copying every source schema. |
| Variations | Parent-child or other supported Product relationship | Confirm which record owns price, stock, media, and selectable values. |
| Custom information | Product attributes or module-owned data | Keep only fields with a defined Target Store purpose and owner. |
| Inventory | Product and source-level stock structures according to the implementation | Separate historical quantities from current fulfillment design. |
Attributes make poor classification harder to ignore. A catalog can be technically structured yet commercially inconsistent when values, field ownership or Product families remain unexplained. Normalize the meanings the Target Store will actually use.
Categories, Browsing, and Catalog Discovery
Magento Categories form a hierarchy that can shape how customers browse the storefront. Products may be assigned to zero or more Categories, and root Category structure can be associated with store scope. The Category tree is therefore both a data structure and a discovery structure.
Source taxonomies can combine different purposes:
- Browsing, brands and filters.
- Campaigns, internal departments and landing pages.
- SEO paths.
Magento can divide those responsibilities among Categories, attributes, search, layered catalog filters, CMS content and theme/menu components. The catalog filters can use Categories, price ranges and eligible Product attributes.
A Category should not be preserved solely because it exists in the Source Platform. Its future purpose should be clear:
- Does it create a browse destination?
- Does it belong in the main menu?
- Is it a temporary campaign classification?
- Is the same concept better represented as an attribute or filter?
- Does it require Category content, metadata, imagery, or a custom layout?
- Is its old URL important enough to require a mapped destination?
Magento catalog discovery is a coordinated system. Products, Categories, attributes, search, filters, theme layout, and content all contribute to whether customers can find the right item, so migration planning should evaluate these relationships together rather than treating catalog records in isolation.
Websites, Stores, and Store Views
Magento Open Source uses a hierarchy of websites, stores, and store views. This scope model can separate domains, catalogs, currencies, checkout contexts, root Categories, languages, and configuration values. It is a fundamental part of the platform rather than a cosmetic multilingual setting.
At a high level:
- a website can define a major commercial boundary;
- a store can organize a catalog around a root Category;
- a store view can present a storefront variation, commonly for language or localized content.
Scope follows the value’s purpose:
- Product names can vary by store view; SKU identity is global.
- Base Product prices use global or website scope, rather than independent store-view prices.
- Category roots and storefront menu paths follow the chosen store structure.
A translated description can vary by store view without becoming a new sellable SKU or website-level price. Preserve the intended language experience and commercial boundary as separate decisions.
Source storefronts need not map one-to-one. Choose websites, stores or store views from catalog, Customer, currency, tax, checkout and operational requirements. Separate domains may need different target scopes; storefronts can also be consolidated when their distinctions no longer serve the business.
Magento's scope architecture influences the meaning and visibility of migrated records. It is not merely a target-side display preference, so scope relationships need to be understood before data is accepted as complete.
Customers, Orders, and Transaction History
Magento Open Source manages Customer accounts, addresses, Customer groups, Orders, invoices, shipments, credit memos, discounts, tax context, and related transactional records. These structures support both day-to-day administration and historical service continuity.
Customer continuity includes more than name and email:
- Addresses, Customer groups, tax treatment and newsletter state.
- External identifiers and any custom fields supported by the chosen module or implementation.
- Account-sharing scope and usable sign-in.
Native Customer-attribute administration is an Adobe Commerce feature, not an assumed Open Source capability.
Account sharing can be global or per website; password continuity depends on the actual migration path.
Preserve the agreed Order context that staff need:
- Purchased items: line items, SKUs, names, quantities and selected options.
- Commercial evidence: prices, discounts, tax, shipping, totals and payment references.
- Service history: status, addresses, invoices, shipments and refunds.
The supported migration scope and accepted representation determine what is delivered.
History and future configuration have different jobs:
- A shipping-method label does not deploy a carrier integration.
- A payment reference does not configure a gateway.
- Historical tax amounts do not establish current tax rules.
Future checkout and fulfillment still depend on target configuration, modules, credentials and integrations.
Content, Themes, and Storefront Presentation
Magento Open Source includes CMS Pages, content blocks, widgets, media, Product and Category content, and theme-driven storefront rendering. These elements combine commerce data with editorial features, promotions and content that supports browsing.
Layouts, templates, blocks, theme configuration and extensions control presentation. Record presence does not prove the intended experience:
- An attribute can exist without a template rendering it.
- A CMS Page can be unreachable through menus or content links.
- A transferred image can use a different gallery or responsive-image treatment.
Storefront continuity therefore depends on the relationship among:
- migrated records and media;
- Magento configuration and scope;
- theme templates and layout decisions;
- CMS Pages and content blocks;
- search, browsing, filtering, and URL behavior.
Magento URL keys, rewrites, Category paths and content destinations can differ from the Source. Use URL and redirect planning to connect high-value old paths to valid, relevant destinations; do not assume every legacy route can be recreated exactly.
Modules, Customizations, and Integrations
Modules and integrations can extend several areas:
- Payments, shipping and fulfillment.
- Search, merchandising, subscriptions, marketplaces and Product builders.
- Customer fields, Order attributes, reporting and administration.
Custom modules can also change core behavior or define new data structures. Qualify each required extension’s actual compatibility and ownership.
This extensibility is central to the platform, but it is also a major source of hidden ownership. A field may be stored as a Magento attribute, in a custom table, through an extension entity, or in an external system. A workflow may be enforced by code rather than represented directly in the migrated records.
A clean Target Store distinguishes:
- core Magento Open Source records;
- standard target configuration;
- extension-owned data;
- custom module data and logic;
- theme-specific presentation;
- external-system ownership.
Product, Customer and Order records may carry ERP IDs, PIM keys, marketplace references or fulfillment codes. Preserve the agreed external keys and map native references to destination identities. Their continuing integration must know how to use and maintain them.
Magento Open Source and Adobe Commerce
Magento Open Source and Adobe Commerce share a common heritage, but their product boundaries must remain explicit. Magento Open Source provides the open-source core and basic commerce capabilities. Adobe Commerce adds proprietary capabilities and commercial services that should not be attributed automatically to Magento Open Source.
Check the implementation behind required capabilities:
- B2B, merchandising, content and segmentation.
- Operational and cloud services.
They may belong to Adobe Commerce or a third-party extension. Evaluate the selected Open Source environment and modules rather than a blended Adobe feature list.
The same naming discipline applies to source data. A field originating from an Adobe Commerce feature may require a different destination, an extension, or project-specific handling in Magento Open Source. Shared database concepts do not guarantee equivalent business behavior.
Magento Open Source Migration Orientation
Magento Open Source is distinct because it combines a highly structured commerce data model with merchant-controlled infrastructure and code. Four characteristics define its migration identity:
-
Attributes and Product types determine catalog meaning.
The Target Store needs a governed Product architecture, not only imported rows.
-
Website, store, and store-view scope affects visibility and configuration.
Multi-store data must be interpreted through Magento's hierarchy.
-
Extensions and custom modules can own critical data and behavior.
Core records do not reveal every dependency.
-
Infrastructure and deployment are part of the operating model.
Search, indexing, caching, queues, media, performance, security, and release management affect whether migrated data is usable.
Magento’s flexibility needs technical governance. Treat data structure, scope, modules, themes, integrations and infrastructure as one Target Store architecture, with an owner for how each layer continues to work.
Conclusion
Magento Open Source combines structured commerce data with control over code and infrastructure. Attributes, Product types, Categories, store scope, accounts, history and content work through modules, themes and integrations. The merchant retains responsibility for deployment, security, compatibility and ongoing maintenance.
Keep supported record transfer distinct from configuration, code, presentation and infrastructure. Use the Magento fit profiles to judge whether this operating model serves the business before detailed mapping, risk, preparation and validation decisions.
Common Questions
Is Magento Open Source the same as Adobe Commerce?
No. They share a platform lineage and many core concepts, but Adobe Commerce includes proprietary capabilities and commercial services that are not automatically part of Magento Open Source.
Why are attributes so important in Magento Open Source?
Attributes define structured Product information and can support administration, storefront display, search, filtering, comparison, and integrations. Poor attribute governance can make a migrated catalog difficult to maintain even when all Products are present.
Does every source category become a Magento Category?
No. Source classifications may represent browsing, filters, brands, campaigns, or internal organization. Magento Categories should be used where they provide a meaningful browse or content structure.
What is the difference among websites, stores, and store views?
They are levels in Magento's scope hierarchy. Websites can define major commercial boundaries, stores can organize catalogs around root Categories, and store views can present localized or alternate storefront content.
Does migrated Order history configure future payment and shipping?
No. Historical Orders can preserve transaction context, while active gateways, shipping integrations, tax, checkout, and fulfillment behavior require target configuration and testing.
Are extension and custom-module records part of standard Magento data?
Not automatically. Extensions and custom modules can create attributes, tables, entities and workflows outside core structures. Identify their purpose, destination and continuing owner, then confirm support for the required data on the actual migration path.