Magento is a self-hosted, extensible e-commerce platform designed for merchants and implementation teams that want direct control over the application, database, infrastructure, codebase, extensions, themes, integrations, and deployment process. Its defining strength is structural flexibility: the catalog can use multiple Product types, reusable attributes, attribute sets, category trees, websites, stores, and store views, while the codebase can be extended through modules and service integrations.
That flexibility makes Magento materially different from a hosted platform with a narrow prescribed operating model. The Target Store is not produced by migrated data alone. It is assembled from catalog records, configuration scope, themes, modules, search, integrations, infrastructure, deployment practices, and ongoing technical governance.
A clear overview must also keep Magento separate from Adobe Commerce. They share a platform lineage and many core concepts, but they are not interchangeable product editions. Features that depend on Adobe Commerce should not be assumed to exist in Magento merely because the underlying terminology looks familiar.
Magento as a Self-Hosted Commerce Platform
Magento gives the merchant or implementation team ownership of the application environment. That includes hosting, database services, search services, caching, media storage, certificates, backups, monitoring, deployment, patching, extension compatibility, and security maintenance. The platform supplies the commerce application; it does not remove the need for an operating team.
This responsibility model affects migration orientation from the beginning. A Target Store can contain Products, Customers, and Orders while still being operationally incomplete because search is not ready, indexing is delayed, extensions are incompatible, theme templates do not expose migrated fields, or infrastructure is undersized.
| Architecture layer | Typical ownership | Migration significance |
|---|---|---|
| Commerce data | Products, Categories, Customers, Orders, reviews, CMS Pages, and related records | Supported 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 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 navigated through the chosen storefront implementation. |
| 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. |
Magento rewards disciplined implementation. Its breadth should be treated as an architecture to govern, not as permission to reproduce every legacy customization.
Magento also relies on background processing and derived storefront data. Catalog changes may need indexing before they appear correctly in search, navigation, pricing, or inventory views. Caches and deployment artifacts can affect what administrators and customers see after records are loaded. These mechanisms are part of the operating environment rather than part of the migrated record itself. They must be healthy for the Target Store to represent migrated data accurately.
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 Architecture: Products, Attributes, and Attribute Sets
The Magento catalog is built around structured Products and reusable attributes. Product information such as name, SKU, price, status, visibility, weight, descriptions, tax class, media, and custom business fields can be represented through attributes. Attribute sets group the fields needed for particular Product families.
This model supports a catalog that is more governed than a collection of isolated Product records. A clothing Product may need size, material, care instructions, and season. An industrial Product may need voltage, certification, dimensions, and compatibility. Those fields can be organized in the administration experience and exposed selectively in storefronts, integrations, search, or reporting.
The migration significance is not simply that attributes can be imported. The Target Store needs a coherent attribute architecture:
- 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.
Magento also supports several Product structures for different selling patterns. Source simple Products, variants, bundles, grouped relationships, virtual items, downloadable items, or custom option logic should be interpreted according to how the Target Store will sell them. A source platform’s parent-child relationship may resemble a Magento configurable structure, but resemblance is not enough; SKU ownership, pricing, stock, images, and shopper selection behavior must align.
| Catalog concern | Magento meaning | Early orientation |
|---|---|---|
| Product identity | SKU-centered commerce record with attribute-driven information | Preserve stable identifiers 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. |
The attribute system is one of Magento’s strongest capabilities and one of the main reasons poor source classification becomes expensive. A loosely governed source catalog can enter Magento and become technically structured but commercially inconsistent unless values, field ownership, and Product families are normalized.
Categories, Navigation, and Catalog Discovery
Magento Categories form a hierarchy that can shape storefront navigation. 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 often mix several meanings: customer navigation, brands, filters, campaigns, internal departments, landing pages, or SEO paths. Magento provides Categories, attributes, search, layered navigation, CMS content, menus, and theme components that can divide those responsibilities more deliberately.
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 navigation?
- 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?
This overview does not replace the later data-model or preparation articles. It establishes that Magento’s 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.
Websites, Stores, and Store Views
Magento 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.
Configuration and attribute values can have different scopes. A Product name might vary by store view while a SKU remains global. A price may be governed at a broader scope than a translated description. Categories and navigation can differ according to the selected store structure.
This hierarchy matters because a source multi-store implementation may not map one-to-one. Separate source domains could become Magento websites, stores, or store views depending on catalog, Customer, currency, tax, checkout, and operational requirements. Conversely, several source storefronts may be consolidated when their distinctions are no longer useful.
The platform overview should make one point clear: Magento’s scope architecture influences the meaning and visibility of migrated records. It is not merely a target-side display preference.
Customers, Orders, and Transaction History
Magento 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.
A migrated Customer should remain recognizable and useful, but account continuity is broader than name and email. Address structures, Customer groups, tax treatment, newsletter state, custom attributes, and external-system identifiers may affect operations. Password compatibility depends on the supported migration method and should not be assumed.
A migrated Order should preserve enough context for staff to understand the transaction. Line items, SKUs, Product names, quantities, selected options, prices, discounts, tax, shipping, totals, status, addresses, payment references, invoices, shipments, and refunds may all contribute to that meaning where supported.
Historical data does not configure future operation. A prior shipping method name does not deploy a carrier integration. A payment reference does not configure a gateway. Historical tax amounts do not establish current tax rules. Magento’s future checkout and fulfillment behavior depends on target configuration, modules, credentials, and integrations.
Content, Themes, and Storefront Presentation
Magento includes CMS Pages, content blocks, widgets, media, Product and Category content, and theme-driven storefront rendering. These elements allow commerce data to be combined with editorial, promotional, and navigational content.
The presentation layer can use layouts, templates, blocks, theme configuration, and extensions. A migrated attribute may exist in the database but remain invisible because the theme does not render it. A CMS Page may be present but disconnected from navigation. A Product image may transfer while responsive image behavior or gallery presentation differs.
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, navigation, filtering, and URL behavior.
Magento URLs, rewrites, Category paths, Product keys, and content destinations can differ from the Source Platform. SEO continuity should be based on valid Magento destinations and high-value source paths rather than the assumption that every legacy URL can be recreated exactly.
Modules, Customizations, and Integrations
Magento has a large module and integration ecosystem. Extensions can add payment methods, shipping methods, search, merchandising, subscriptions, marketplaces, Product builders, Customer fields, Order attributes, reporting, fulfillment, or administrative workflows. Custom modules can also change core behavior or create entirely new data structures.
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 records;
- standard target configuration;
- extension-owned data;
- custom module data and logic;
- theme-specific presentation;
- external-system ownership.
The distinction is especially important for identifiers. Product, Customer, and Order records may carry ERP IDs, PIM keys, marketplace references, or fulfillment codes. Those identifiers are valuable only when the corresponding integration will use and maintain them after launch.
Magento and Adobe Commerce
Magento and Adobe Commerce share a common heritage, but their product boundaries must remain explicit. Magento 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.
This boundary affects migration expectations. A source store may use B2B, merchandising, content, segmentation, operational, or cloud capabilities associated with Adobe Commerce or third-party extensions. The Target Platform must be evaluated according to the actual Magento implementation and selected modules, not a blended feature list from the broader Adobe Commerce family.
The same naming discipline applies to source data. A field originating from an Adobe Commerce feature may require a different destination, an extension, or tailored handling in Magento. Shared database concepts do not guarantee equivalent business behavior.
What Makes Migration Into Magento Distinct
Magento 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 can support sophisticated stores, but its flexibility depends on technical governance. The platform performs best when data structure, configuration scope, modules, themes, integrations, and infrastructure are designed as one Target Store architecture.
Conclusion
Magento is a self-hosted, open-source commerce platform built around structured Products, attributes, attribute sets, Categories, store scope, Customers, Orders, content, modules, themes, and integrations. Its operating model gives merchants direct control while assigning them responsibility for infrastructure, deployment, security, extension compatibility, and ongoing maintenance.
A migration into Magento should preserve supported business data without confusing that data with store configuration, code, presentation, or infrastructure. This platform overview establishes the architecture needed for the later hub pages on fit, data-model translation, risks, preparation, service selection, validation, and recurring pitfalls.
Common Questions
Is Magento 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.
Why are attributes so important in Magento?
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 navigation, 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. Their data must be identified by purpose, destination, and long-term owner.