What a customized Magento build involves
Magento Open Source is the free edition of the Magento 2 commerce platform, maintained by Adobe and released under the Open Software License 3.0. Adobe Commerce is the paid edition on the same core, adding B2B accounts, content staging and customer segments, plus Adobe support and hosting. A production store runs PHP with MySQL or MariaDB, OpenSearch, a cache service, Varnish and RabbitMQ.
A store is mostly catalog and integration work: product data from a PIM or ERP, prices and stock, payments and fraud screening, tax, shipping, order export and a fast mobile storefront. Each becomes a module or extension that the team carries through every upgrade.
Discovery covers catalog size and structure, store views and languages, pricing rules, payment methods, fulfillment, the system of record for products, stock, customers and orders, and traffic peaks. It produces an integration map and a decision per requirement: configuration, a third-party extension or a custom module.
Design the catalog and store structure
Catalog decisions are hard to reverse once orders, URLs and integrations depend on them.
Websites and store views
Websites separate customers, prices and payment methods; store views handle languages. Each scope multiplies configuration and testing, so keep the structure small.
Attribute sets
Decide which attributes are searchable, filterable in layered navigation or used in promotions, and which system owns each value.
Product types
Configurable products with many options create many child SKUs. Model them on how customers choose, and check indexing and import time.
Pricing and inventory
Customer groups, tier prices and price rules cover most cases; contract pricing usually comes from the ERP. Decide whether Magento or the ERP is the source of truth for stock.
Content pages
Page Builder has been bundled with Magento Open Source since 2.4.3 for CMS pages, blocks and product descriptions.
Configuration, extensions or custom modules
Customizations are modules wired through dependency injection. How a change hooks in decides how it behaves on upgrade.
| Mechanism | Use it for | Upgrade cost |
|---|---|---|
| Admin configuration | Store settings, payment and shipping methods, tax rules. | Low. Export shared settings with app:config:dump so they deploy with the code. |
| Third-party extensions | Payment gateways, ERP connectors, tax and marketing tools. | Moderate to high. Check support for your target 2.4 line and the vendor's security fix record before buying. |
| Plugins (interceptors) | Changing public methods with before, after and around methods. | Moderate. They cannot target final, non-public or static methods. Prefer before and after over around. |
| Observers | Reacting to events such as order placement. | Low. Keep them short and send slow ERP calls to message queues. |
| Preferences | Replacing a class in di.xml when nothing else fits. | High. Only one preference per class takes effect, so extensions conflict. |
Choose a storefront approach
Luma, the default theme, uses LESS, RequireJS and Knockout.js. Most extensions ship Luma templates, but front-end performance needs deliberate work on bundling and third-party scripts.
Hyvä uses Tailwind CSS and Alpine.js. In November 2025 the theme became open source under OSL 3.0 and AFL 3.0; Hyvä Checkout remains commercial. Extensions need Hyvä compatibility modules.
GraphQL and REST APIs let a separate front end run the storefront. That adds a second application to build and secure, and some extensions lack GraphQL coverage.
Integrations with ERP, payments, search and identity
ERP and PIM
Use the asynchronous bulk APIs with RabbitMQ consumers for large volumes, keep integrations idempotent, and agree which system wins when values conflict.
Payments
Provider-hosted fields or payment pages keep card data off your servers. Test authorization, capture, refunds and 3-D Secure for every method.
Search
Catalog search runs on OpenSearch; Adobe lists only OpenSearch for 2.4.9. Tune synonyms and layered navigation with merchandisers.
Identity
Admin two-factor authentication is built in. Single sign-on usually comes from a third-party extension, which then needs its own security review.
Migrate from Magento 1 or another platform
Adobe ended support for Magento 1 on June 30, 2020, and there is no in-place upgrade. Adobe's Data Migration Tool moves settings, data and incremental changes to Magento 2; themes, extensions and custom code are rebuilt.
From WooCommerce, Shopify or a custom system, map categories, attributes and variants first, then import products, customers and orders. Password hashes are usually incompatible, so plan a reset or a module that verifies the old hash at first sign-in. Load URL rewrites before launch and rehearse the cutover with a delta import.
Hosting, performance and patching
Dates are from Adobe's release pages as of October 2026.
| Area | Practice | Check |
|---|---|---|
| Stack and deploys | Component versions Adobe lists for your 2.4 line, production mode, and code compiled during the build. | No one runs Composer on production. |
| Indexers and cron | Update by Schedule indexers, cron every minute and supervised queue consumers. | Backlogs alert before stale prices reach the storefront. |
| Caching | Varnish full-page cache and a CDN for static assets. | No block makes a whole category or product page uncacheable. |
| Hardening | Custom admin path, network-restricted admin, 2FA for every admin user. | The admin login is unreachable from the public internet. |
| Payment page scripts | From 2.4.7, payment pages default to CSP restrict mode and Subresource Integrity for local JavaScript. | A new or changed checkout script raises an alert. |
| Security patches | Adobe publishes security bulletins, -p patch releases and isolated patches for urgent issues. | The store runs the latest patch of a supported 2.4 line. |
| Upgrades | 2.4.9 shipped in May 2026. Adobe's lifecycle policy lists May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9 as end of standard support. | An upgrade plan names PHP, database and extension changes. |
Magento operating ownership
The platform, the code, the catalog and the payment flow each need a named owner.
Platform team
- Patches Magento, PHP and supporting services.
- Watches cron, queues, indexers and cache hit rates.
Developers
- Maintain custom modules, theme and integrations.
- Keep the extension inventory current.
Commerce team
- Owns catalog structure and promotions.
- Tests checkout after each release.
Security and compliance
- Reviews Adobe security bulletins.
- Keeps the checkout script inventory and PCI DSS evidence.
Magento Open Source questions
What is Mage-OS?
A community distribution of Magento Open Source maintained by the Mage-OS Association, currently based on Magento 2.4.9 and aiming for extension compatibility. Test extensions and payment modules on it before switching.
Which payment integration keeps PCI DSS scope smallest?
Redirects and provider-hosted fields or iframes keep card data out of Magento; direct integrations bring your servers into scope. Confirm the SAQ type and scope with your acquirer or QSA.
Do checkout scripts matter if card data never touches our servers?
Yes. PCI DSS v4.0.1 covers payment page scripts and change detection (6.4.3 and 11.6.1), and the January 2025 SAQ A revision added an eligibility condition about script attacks. Magento's CSP and SRI help, and third-party tags still need review.
Can we keep extensions we bought years ago?
Only if the vendor supports your target 2.4 line and PHP version. Replace abandoned extensions during the upgrade.
Scope and handover
DeployOpen runs discovery, designs the catalog, builds custom modules, the theme and ERP, PIM, payment and search integrations, migrates data, and deploys the stack in your infrastructure. Security work covers testing of custom modules and checkout and admin hardening. For PCI DSS, DeployOpen helps with scoping, the script inventory and evidence; the assessment and attestation come from your QSA or acquirer's self-assessment process.
Handover includes the Composer project, extension inventory, integration map, deployment and rollback runbooks, patching schedule, restore test results and the plan for the next 2.4 line.
