What a Magento Open Source implementation involves
This page covers planning and budgeting a new, self-hosted Magento Open Source store. It covers the catalog, theme, extensions, ERP and payment integrations, hosting, PCI DSS scope and the internal team time that all of these consume. Migration, upgrades, customization, SSO, performance and cost of ownership each have their own page, so they are referenced here only where they change the budget.
Teams usually start this work for one of four reasons: a new store, a rebuild of an existing store, a move off a setup that no longer receives security patches, or entry into a new market or sales channel. Each trigger changes the scope. A new market adds currencies, tax rules, languages and payment methods. A move off an unsupported setup adds risk around extensions that may not run on the target release.
The magento/magento2 repository licenses the Magento Open Source source under the Open Software License 3.0 (OSL-3.0). The software itself carries no license fee, so the cost of the store is labor, hosting, third-party extensions and people. Confirm with your own counsel whether any extension you plan to buy carries a different license or a recurring subscription.
The short answer: most teams keep product data, merchandising and content ownership in-house, because those people know the catalog and the promotions calendar. They usually bring in a partner for architecture, custom build, integration and hardening, where specialist experience shortens the work and reduces rework. Ask any partner to split its quote along that line so you can see what your team must staff.
What the work includes and what you receive
Each component below ends in written deliverables you can review, and each one has a cost driver you can ask a partner to price. DeployOpen prepares systems and evidence for assessors but does not issue audit reports or attestations.
Discovery and fit
Before any build, confirm which business processes the store must support, which catalog, tax, shipping and B2B rules apply, and whether Magento Open Source fits your volume and team. The output is a scoped requirements list and a written decision on edition, which drives the rest of the estimate. Ask for the assumptions behind each estimate.
Solution architecture and environments
Define the component layout for web, database, search, cache, queue and admin tiers, and the environment chain from development through production. Confirm the PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ and nginx versions against Adobe's published system requirements for your chosen release. Deliverables are an architecture document and configured environments.
Catalog model design
Design product types, attribute sets, categories, custom options and import formats for your catalog size and structure. Large catalogs with many configurable products and frequent price or stock changes add indexing and import effort. Deliverables include the data model, import specifications and a sample data load used for performance testing.
Theme and checkout build
Build the storefront theme and checkout flow against agreed designs, including responsive layouts and accessibility checks. Checkout changes carry the most risk because they touch payment, tax and order creation, so scope them early. Deliverables include the theme source in version control, a component inventory and checkout test cases.
Custom modules
Build only the custom modules that the requirements cannot meet with configuration or a vetted extension. Each module follows Magento's PSR-4 module structure and is kept separate from core files so that patches and upgrades do not overwrite it. Ask for a list of custom modules with owners, purpose and an upgrade impact note.
Extension selection
Shortlist third-party extensions against each requirement and check their compatibility with your release line, their maintenance history and their overlap with other extensions. Every extension added is a recurring upgrade and security obligation, so the count matters. Deliverables are an extension register with version, purpose and the decision to keep or replace.
ERP and payment integration
Specify how products, stock, prices, orders and invoices move between the store and the ERP, including whether calls are synchronous or queued, and how sync failures are retried and reported. Payment integration choices determine PCI DSS scope, so document the hosted or redirect options before the build. Deliverables are integration specifications and interface test evidence.
Hosting build
Build the hosting platform in infrastructure you control, whether on-premises or in cloud virtual machines, and confirm how the full-page cache is served in your setup. Self-managed installations use Varnish, which needs its own sizing and configuration. Deliverables include provisioned infrastructure, deployment scripts and a capacity note for peak traffic.
Security configuration
Configure admin URL protection, two-factor authentication, file permissions, Content Security Policy and patch intake for the chosen release. Content Security Policy in restrict mode on payment pages is enabled by default from release 2.4.7, so check any custom scripts before launch. Deliverables include a configuration baseline and a record of each control's setting.
PCI DSS scoping support
Map every system, network segment and person that stores, processes or transmits cardholder data, and record the reasons each one is in or out of scope. Choosing a payment method that keeps card data off your servers reduces the scope and the controls you must evidence. DeployOpen prepares systems and evidence for assessors but does not issue audit reports or attestations.
Testing
Test functional flows, integrations, load against a representative catalog, and security controls, with defects tracked to closure. Keep results as evidence so that later upgrades and patches can be regression tested against the same cases. Deliverables are test plans, test evidence and a list of open defects with agreed owners.
Launch readiness and handover
Confirm the go-live checklist, rollback steps, monitoring, backups and the on-call contacts before cutover. Handover moves the system to your internal team through runbooks and recorded training sessions. Ask for the runbook list and training scope in writing so the internal team time you need to budget is clear.
What drives cost and duration
This table lists the factors that most often move the budget and timeline for a Magento Open Source build, why each one matters, and what to do to keep it contained.
| Driver | Why it moves cost | How to keep it down |
|---|---|---|
| Catalog size and structure | Every SKU, configurable option, bundle, attribute and category adds import, mapping and indexing work, and a large catalog raises the load on indexers, cron and search during builds and peaks. | Define the attribute set and category tree before build. Load a representative sample early and test indexing time against the full catalog before go-live. |
| Theme and checkout changes | A stock theme needs configuration and light overrides. Heavy design changes, custom checkout steps and new page layouts add front end and QA effort on every release. | Keep the stock Luma or a maintained child theme where possible. Limit checkout changes to the steps the business requires and approve design scope in writing. |
| Number of custom modules | Each custom module needs design, code review, tests and upgrade effort. Modules that override core classes or many plugins multiply work at each patch and minor release. | Prefer plugins, observers and preferences over rewrites. Keep a register of modules with owners and review the list before each upgrade. |
| Third-party extensions and overlap | Each extension has its own license, support terms and compatibility window. Two extensions doing the same job create conflicts that someone must find and resolve. | Shortlist extensions against stated requirements. Remove overlaps before build, and ask vendors for their supported Magento 2.4.x versions in writing. |
| ERP and payment system integrations | Each system adds field mapping, sync direction, error queues, reconciliation reports and test accounts. Failure handling for stock, price and order sync often takes the largest share of integration effort. | Agree the system of record for each data type and the sync direction in the scope. Define retry rules, alerts and manual correction steps before development starts. |
| Number of environments and availability tier | Each extra environment needs its own infrastructure, data refresh, configuration and deployment steps. Higher availability tiers add web nodes, database replicas, cache and queue redundancy and monitoring. | Limit environments to development, staging and production unless a specific need exists. Match the availability tier to the sales and uptime needs written in the requirements. |
| Payment flow choice and PCI DSS scope | Hosted payment fields keep card data out of your servers and shrink the assessment. Server-side card handling expands the systems an assessor reviews and the controls you must evidence each year. | Choose hosted payment pages or fields where the business allows. Ask the payment provider and your assessor to confirm the scope before the design is fixed. |
| Edition and distribution choice | Magento Open Source, Mage-OS and Adobe Commerce differ in included features, support terms, extension compatibility and who supplies patches. Changing the choice after build is costly. | Decide the distribution during planning and confirm extension and integration compatibility with the chosen one. Ask each vendor what support and patch timing they provide. |
| Content and product data quality | Incomplete, duplicated or inconsistent product data, images and copy add cleaning, mapping and manual review time before and after launch. | Assign data owners and a cleaning deadline before import. Agree a data template and run a sample import to find gaps early. |
| Internal team availability | Build work stalls when business owners cannot answer pricing, catalog, tax or workflow questions, or cannot test in time. Delays in decisions extend the timeline and the vendor effort billed. | Name decision makers and testers with time reserved in writing. Schedule sign-off dates for each phase and log open decisions in a shared list. |
Project phases and their outputs
The sequence moves from a fit decision through design and build to a supported launch, and each phase closes with a written output the buyer can accept or reject.
Assess discovery and fit
Your team and ours review catalog size and structure, required integrations, payment methods, traffic expectations and the internal team that will run the store. The phase ends with a written fit assessment and a scope that states whether Magento Open Source suits the requirements or another route is better. Confirm the timing of this phase against your own scope in the plan and quote.
Design architecture and environments
We design the target topology for web, database, search, cache, queue and environment layout, and select versions from the Adobe system requirements for the chosen release line. The output is an architecture document, an environment plan and a decision record for each hosting and version choice. Ask the quote to state which components are included.
Build theme and module sprints
Developers build the storefront theme, custom modules and admin workflows in agreed sprints, following the Magento module and theme structure so upgrades stay manageable. Each sprint closes with a demonstrable build on a non-production environment and a signed-off list of completed stories. Sprint count and length come from the approved scope.
Build integrations
The ERP, payment, shipping and other integrations are built and tested against sandbox endpoints, including error handling and retry behavior for sync failures. The phase closes with a mapping document for each data flow and a log of test transactions. Confirm which system owners must provide access and sandbox credentials before this phase starts.
Test functionally, for performance, security and payment flow
We run functional test cases, load tests against the agreed traffic profile, security checks on the admin and storefront, and end-to-end payment flow tests. The output is a test report with defects logged, their severity and their resolution status. Release does not proceed while open critical defects remain unresolved.
Prepare launch readiness and cutover
We agree the go-live checklist, data load steps, DNS and redirect changes, rollback plan and a cutover window with your team. The phase closes with a signed launch readiness record listing each check and its owner. Ask the quote how cutover support and rollback rehearsal are priced and scheduled.
Hand over with hypercare
After launch, we provide a support period to resolve post-launch issues, then hand over runbooks, architecture records, admin training and the patching procedure. The phase closes when your team accepts the handover pack and the ongoing support decision is recorded. Ask for the hypercare terms and what happens after that period in writing.
What to keep in-house and what to outsource
This table compares, for each part of a Magento Open Source build, what teams usually keep internal and what they commonly hand to a partner, with the skills each part needs; the right split depends on whether you already have PHP and Magento developers and an operations function.
| Area | Usually kept in-house | Usually outsourced | Skills each part needs |
|---|---|---|---|
| Product data and merchandising rules | Catalog ownership, category structure decisions, promotions calendar and day-to-day product entry | Bulk import templates, attribute model cleanup and import scripts for a large initial load | Merchandising knowledge, spreadsheet or PIM data handling, Magento catalog and attribute concepts |
| Content | Copy, imagery, brand voice and page approvals | Page layout templates and migration of legacy content blocks | Copywriting, brand governance, basic CMS block and page configuration |
| Business rules and pricing logic | Tax, price list, customer group and discount policy decisions written down by finance and sales | Implementing complex price rules, custom pricing calculations and related test cases | Finance and pricing knowledge, Magento cart and price rule behavior, PHP for custom logic |
| Solution architecture | Approval of the target design, hosting choice and integration boundaries | Detailed architecture document, component sizing and environment layout | Senior Magento architecture, PHP, caching and search tier design, infrastructure knowledge |
| Theme and front-end build | Brand decisions, design sign-off and content review | Theme build, responsive layout, checkout UI and asset pipeline | Magento theme structure, LESS or Knockout or current front-end tooling, accessibility and Core Web Vitals awareness |
| Custom module development | Functional requirements and acceptance decisions | Writing PSR-4 modules, extension replacements and upgrade-safe overrides | Senior PHP, Magento module and plugin patterns, Composer, automated tests |
| ERP and payment integration | Owner of ERP data, payment provider contract and reconciliation rules | Connector build, message queue setup, retry and sync failure handling | Integration design, REST and asynchronous APIs, payment gateway tokenization concepts |
| Hosting and operations | Environment ownership, on-call duties and change approval | Server build, deployment pipeline, monitoring setup and runbooks | Linux administration, PHP-FPM, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, nginx, Varnish |
| Security configuration and testing | Risk acceptance, admin user policy and vulnerability triage decisions | Hardening of admin URL, 2FA, file permissions, CSP settings and penetration testing | Application security, Magento security configuration, web application testing |
| PCI DSS evidence preparation | Scope decisions, data flow ownership and evidence collection from internal systems | Scope analysis, control configuration records and evidence packs for the assessor | PCI DSS requirement knowledge, network and payment page controls, documentation discipline. Certification comes from an independent assessor, not the implementation partner |
| Project management and QA | Sponsor, acceptance testing and go-live decisions | Project plan, written scope, test plan, regression testing and defect tracking | Delivery management, test automation, written change control |
What usually goes wrong and how to prevent it
These six risks appear most often in Magento Open Source builds, and each one is cheaper to prevent in the plan than to fix after launch.
Custom code tied to core internals
Modules that override core classes, rewrite templates or call protected methods often work until the next patch cycle changes a signature. Magento's developer documentation describes PSR-4 module structure, so ask for a list of every core override before the build starts. Run the Upgrade Compatibility Tool against the target patch to see which customizations break.
Extension overlap and unvetted add-ons
Stores often install one extension per feature, and two of them may override the same checkout or catalog behavior. Each unreviewed add-on also adds code that needs security review and upgrade testing. Build an inventory of every third-party extension with its vendor, version, known overlaps and open issues, then decide to keep, replace or remove each one before the plan is approved.
ERP sync without queues or retries
Order, stock and price sync that runs as direct synchronous calls fails whenever the ERP is slow or offline, and orders can be lost or duplicated. Design asynchronous messaging with message queues, idempotent consumers, retry limits, dead-letter handling and an operator view of failed messages. Confirm who owns the queue broker and who approves a replay.
Hosting sized without load tests
Teams often size servers from average storefront traffic, then find that indexers, cache warming, search queries and cron jobs compete for the same resources during catalog updates or sales. Ask for load tests that cover full indexer runs, full-page cache hit rates, OpenSearch query latency and checkout under peak traffic. Include the cost of a staging environment that matches production in the plan.
CSP restrict mode breaking payment scripts
From 2.4.7, Content Security Policy runs in restrict mode by default on storefront and admin payment pages, so payment provider scripts, iframes and fields that are missing from the policy can be blocked at checkout. Test each payment method end to end in staging with the policy enforced, document every allowed source, and keep policy changes under change control.
Release line near end of support
Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability. End of regular support falls on August 11, 2026 for 2.4.6, May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. Choose a line with enough runway for launch and the first year of patches, and confirm the PHP, OpenSearch and database versions it requires.
What you need to provide before work starts
The fastest way to keep a fixed-scope quote stable is to close the open decisions before the statement of work is signed. Unresolved decisions are the most common reason a Magento Open Source quote changes, because each one can alter the module list, the integration design, the hosting layout or the PCI DSS scope. Ask your team to settle the edition or distribution (Magento Open Source, Mage-OS or another path), the payment provider and payment flow, the hosting location, the extension shortlist, and a launch date with a named business owner who can sign off.
Access is usually the first bottleneck. Before work starts, confirm admin accounts for the current store or staging environment, cloud or data center accounts where the store will run, and sandbox credentials for the ERP and each payment provider. Also confirm who controls DNS and the mail domain, since sending transactional email and cutover both depend on them. Agree how credentials will be shared and stored, and who can revoke them at the end of the engagement.
Data quality determines how much cleanup lands on your team and how much lands on the build. Provide a product feed with consistent SKUs, attributes and category assignments, and say which fields are authoritative. For customer and order history, decide how much history must move and whether personal data needs minimization first. Provide the tax rules by jurisdiction, shipping methods, carrier rules and any price lists that differ by customer group.
Name one owner for each area: product, merchandising, finance, security and operations. The product owner decides scope trade-offs, merchandising owns catalog structure and content, finance confirms tax, pricing and reconciliation rules, security approves the access model and the payment design, and operations accepts the hosting runbook and on-call handover. Owners who can make decisions within a week keep the plan on schedule and make the cost discussion concrete.
How the build changes by starting point
A new store on Magento Open Source has the fewest inherited constraints, so the plan spends its time on design decisions made early. Catalog modeling, checkout flow and theme scope drive most of the work.
- Plan: agree catalog structure, product attributes, tax and shipping rules, and the list of payment and ERP integrations before any build starts.
- Build: install the release line you select, then create custom modules and themes following the PSR-4 structure in Adobe's developer documentation.
- Effort drivers: number of integrations, custom checkout steps and the depth of the theme design.
- Roles: store owner, solution architect, front-end developer, back-end developer and QA lead.
- Confirm: the Magento Open Source release line and its end of support date, and the PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey and RabbitMQ versions listed for that release.
Moving from a hosted store builder changes the plan's first phase, because the new platform must be designed around data that already exists. Data movement itself is covered on the migration page, so this tab only covers how the build changes.
- Plan: inventory the features your hosted builder provides, then map each one to a module, extension or custom build on Magento Open Source.
- Build: plan extra time for theme parity, since hosted builders often ship templates that must be recreated.
- Effort drivers: how many hosted-builder apps or plugins have no direct equivalent and how much custom logic they hold.
- Roles: the store owner must decide which features to drop, and the marketing team must review URL and content changes.
- Confirm: with your current provider, what data can be exported and in what format, and whether any app functions are missing from Magento Open Source.
Rebuilding an older Magento 2 store means the platform already exists, so the work shifts toward upgrading code and removing old customizations. Adobe's upgrade guide names customizations, extension count, third-party integrations and coding practices as the main drivers of effort.
- Plan: run the Upgrade Compatibility Tool and an extension audit to decide what is kept, replaced or removed.
- Build: move to a supported 2.4.x line, then update custom modules and themes to the PHP and service versions that line requires.
- Effort drivers: the number of custom modules, extensions that lack a current release and any core rewrites or overrides.
- Roles: the platform team owns the environment changes, while developers own module and theme updates.
- Confirm: the current end of support date for your release line, and whether a newer patch on that line is needed before the upgrade starts.
A store on Kubernetes or a private cloud keeps the application design the same but changes the infrastructure phases. Hosting choices, environment layout and tier separation become build tasks rather than vendor settings. Hosting details are covered on the hosting page.
- Plan: decide how web, database, search, cache and queue tiers map to nodes or pods, and where each one runs.
- Build: add container images, persistent storage for search and database tiers, and a plan for full-page cache placement.
- Effort drivers: cluster maintenance, storage design, network policy and the number of environments that must mirror production.
- Roles: the platform team owns clusters and storage, the security team reviews network and secrets handling, and developers own the images.
- Confirm: whether your cluster distribution supports the service versions required by your chosen release line, and who patches the base operating system.
In a restricted or air-gapped network, every package, extension and dependency must reach the build through an approved path. Installing from public repositories is not an option, so the plan adds a mirroring and verification phase before development starts.
- Plan: list every Composer package, extension, theme and container image the build needs, including transitive dependencies.
- Build: mirror those artifacts into an internal repository, then verify checksums and licenses before they enter the build pipeline.
- Effort drivers: the number of third-party extensions, the depth of their dependency trees and the frequency of security patch intake.
- Roles: the security team approves artifacts, the platform team runs the mirror, and developers must work only from approved sources.
- Confirm: with your security team, the process for importing patches within the restricted network, and whether the Open Source license terms, OSL-3.0 and AFL 3.0 as stated in the magento2 repository, are accepted by your legal team.
A multi-store or multi-country setup multiplies the configuration, data and compliance work across markets. Magento Open Source supports multiple store views and websites, but each country usually adds its own tax, currency, language, payment and legal content needs.
- Plan: decide which catalog, pricing and customer data are shared and which are separate per market before any configuration begins.
- Build: plan translation workflows, per-market payment methods, and tax and shipping rules for each country.
- Effort drivers: the number of markets, languages, payment providers and whether each market has its own ERP instance.
- Roles: merchandising owns catalog rules per market, finance owns tax and currency, and developers own the shared modules.
- Confirm: with each market's payment provider and tax advisor, the local requirements, and whether your ERP supports multiple legal entities or currencies.
Common questions about cost, time and effort
What does a Magento Open Source implementation cost?
The cost is set by the written scope, and DeployOpen gives a quote only after that scope is agreed. The main components are discovery and design, catalog and data setup, theme and front end work, custom modules, extension selection and configuration, ERP and payment integrations, hosting setup, testing, and cutover. Each component is paid for as labor or as infrastructure. One-time costs include the build itself. Recurring costs include hosting, extension licenses, patching, security testing and support. Ask any vendor for a quote that separates these two groups and lists the assumptions behind each line.
How long does it take to build a Magento Open Source store?
Duration depends on the effort drivers in your scope, not on a fixed template. The biggest drivers are catalog size and structure, the number of custom modules and theme changes, how many third-party extensions must be assessed or replaced, the number and complexity of ERP and payment integrations, and how many environments and approval steps your organization needs. Your timeline should come from the agreed plan. Ask for the phases, their dependencies, and the items on the critical path, such as ERP interface design or payment provider certification.
Can our own team build a Magento Open Source store without a partner?
Yes, if your team has the skills and the time for the work. A capable build usually needs PHP and Magento module development, front end theme work, DevOps for PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ and nginx, and security review for payment flows. Check whether your team can also run the project, keep the store patched on each release cycle, and staff it during peak trading periods. Many organizations compare the internal time required for these tasks against the scope of an outside partner.
Why is there no license fee for Magento Open Source, and what replaces it?
Magento Open Source source code is distributed under the Open Software License 3.0, with the Academic Free License 3.0 also included, so there is no license fee for the core software. The cost moves to the work around it: hosting, extensions that carry their own licenses, development, patching, testing, and the people who run the store. Adobe's upgrade guide ties upgrade effort to customizations, extension count, third-party integrations and coding practices, so those choices are where your budget is decided.
Should we choose Magento Open Source, Mage-OS or Adobe Commerce?
The choice depends on your support model, feature needs, extension dependencies and how much of the platform cost you want to budget in-house. Magento Open Source is maintained by Adobe under the open-source license. Mage-OS is a community distribution built on Magento Open Source, run by the Mage-OS Association, and its site describes compatibility with Magento 2 extensions. Adobe Commerce is Adobe's commercial edition. Compare them on total cost of ownership, not license price alone. See the cost of ownership and editions page for a side-by-side view.
Which Magento Open Source release line should we start on?
Start on the newest line your extensions and hosting support, and plan for its support window. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability. Adobe lists end of regular support as May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9, and the 2.4.9 release came out in May 2026. Starting on 2.4.9 gives the longest runway, but confirm that each critical extension, PHP version and service version in your stack is compatible before you lock in the choice.
How DeployOpen scopes and delivers this work
DeployOpen plans, builds, hardens and documents self-hosted Magento Open Source stores inside infrastructure you control, starting from a written scope that sets out catalog, theme, integration and hosting decisions before any build work begins. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts.
How we scope
- Confirm which Magento Open Source 2.4.x release and PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey and RabbitMQ versions the written scope targets, using Adobe's system requirements for that release.
- Map catalog size and structure, custom modules, theme work, extensions and ERP or payment integrations as separate line items in the written scope.
- Record which parts of the payment flow stay in PCI DSS scope, so the scope states who owns each control and each piece of evidence.
How we build
- Build custom modules and themes against Magento's PSR-4 module structure so later upgrades touch fewer custom files.
- Configure full-page caching, sessions, search and queues in the tiers defined in the scope, then test checkout under load before go-live.
- Vet each third-party extension for security, code quality and upgrade compatibility, and remove or replace those that do not meet the agreed bar.
How we hand over
- Deliver environment documentation covering versions, service layout, deployment steps, configuration and secrets locations as agreed in the scope.
- Provide the runbook for patch cycles, cache clearing, indexer and cron checks and rollback, written for your internal ecommerce team.
- Walk your team through the handover, with each deliverable listed in the written scope and confirmed as complete before closing.
How we support
- Offer ongoing support, upgrades and patch application as a retainer, scoped separately from the implementation project.
- Plan each patch cycle with extension compatibility checks and staging tests, so security releases do not block the store for long.
- Confirm with your auditor or assessor which evidence they expect, since DeployOpen prepares systems and records but does not issue certifications or attestations.
