What Is Magento? Real Costs and How to Choose a Platform in 2026

Magento is an open source e-commerce platform for stores that need to change the sales process deeply, or manage several websites or brands in one system. The commercial naming is confusing today: the community edition is still called Magento Open Source, while the enterprise product sold by Adobe is called Adobe Commerce. Open Source has no license fee, but a Magento project that runs well in Vietnam still needs a large budget for business analysis, development, servers, testing and maintenance.

If your shop has only a few hundred products, accepts COD and bank transfer, and does not sync with other software, Magento is usually too heavy. It starts to pay off when you have several warehouses, several price lists, several country websites, or need to connect ERP, PIM or CRM.

Article reviewed on 07/08/2026, checked against prices on the Adobe and Shopify pages at that time. The goal is clear: after about 15 minutes of reading, you can rule out an option that is too heavy before spending several hundred million VND. It saves a round of quotes. Re-read 2 rounds if your system already has an ERP.

What is Magento, and what is it called now?

Open a Magento admin page and you see more than products, orders and customers. One screen can manage several websites, each with several stores, and each store with its own theme, language, currency, price list and catalog. That is why Magento shows up in retail projects more complex than an ordinary sales website.

Technically, Magento is an e-commerce application written in PHP that uses a database, indexing, caching and a search engine to handle large catalogs. The public source code of Magento Open Source is still maintained by Adobe on GitHub. You can download it, install it on your own server, edit the code and choose who operates it.

How to read the names:

Three levels to remember are website, store and store view. A website is usually tied to one domain or market; a store organizes the catalog; a store view handles display by language or context. With those three levels, one admin can serve several storefronts while keeping shared data throughout 1 year operations. In an example with 3 website, 2 language versions and 6 storefronts, this structure lets you manage the shared parts from one place. The name changed, the core stayed the same.

Magento is not a website template you download and swap the logo on. The platform already has catalog, cart, promotions, customers, orders and multi-store structure; the hard work is in how those blocks fit your wholesale pricing, warehouses, accounting, shipping and legacy data.

We usually steer the conversation to one real order: which storefront it came from, which price applied, which warehouse was deducted, who approved it and which system the data went back to. Until those five questions are answered, there is no point discussing interface colors. Magento is strong in architecture. For the same reason, it punishes a sloppy specification heavily.

How do Magento Open Source and Adobe Commerce pricing differ in 2026?

The clearest price is the number 0. Magento Open Source has no license fee; you still pay for servers, design, code, integration, security and the people who look after the system. “Free” only applies to the right to use the source code.

Adobe Commerce price list checked on 07/08/2026 does not publish a fixed number. Adobe Commerce as a Cloud Service, Adobe Commerce on Cloud and Adobe Commerce Optimizer all send you to the Get pricing button to request a custom quote. So the figure of 22,000 USD/year that still appears in many older articles should not be used as the 2026 price; it is not a level Adobe currently publishes on its pricing page.

Adobe describes Commerce in 2026 as having three directions: a shared multi-tenant cloud service, a dedicated cloud for a single customer, and a storefront/catalog layer that can be combined with an existing transaction engine. It is no longer a comparison of “a free edition missing a few features versus a paid edition with everything unlocked”. The architecture, upgrade path, data and operating responsibility differ from the start. Those three directions correspond to 3 editions which are multi-tenant SaaS, single-tenant PaaS on dedicated infrastructure, and Commerce Optimizer. The official page uses a get-pricing button for all three, meaning your budget table must leave an undetermined license line until Adobe sends a proposal. Do not fill it with an old number from a blog. A price of 0 is not a cost of 0.

A purchase file for Adobe Commerce should ask five things in writing: what metric the license is based on, what the production and staging environments include, what the support level is, which add-ons are not in the price, and how cost rises as sales or traffic grow. Without those five answers, total cost of ownership is not settled.

Magento is genuinely strong in customization and multi-store management

Magento's strengths show when a product is no longer just “name, price, image”. For example, an equipment distributor has retail prices, tier-1 dealer prices and contract prices; each warehouse holds its own stock; the same product code has different content and tax in Vietnam, Singapore and Australia. A small website would need many layers bolted on. Magento already has a structure for organizing that problem at its core.

One admin, several websites and store views

The website, store and store view structure lets you separate brands, markets or languages without maintaining several separate codebases. Shared catalogs are shared. Prices, content, currency or interface that need to differ are configured by scope.

For example, a business has three brands, sells in two countries and uses two languages. If split into 12 independent websites, one change to the returns policy has to be made 12 times. A correct Magento architecture can keep shared content at the top level and put localization in the store views. Fewer repeated operations, but edit permissions must also be locked down more tightly.

In that example, 3 brands × 2 countries × 2 languages produce 12 storefronts. Magento gathers these 12 storefronts into one deliberate architecture, instead of letting 12 groups of plugins drift apart. If the returns policy is edited 2 times/month, the shared architecture saves dozens of manual updates in 1 year.

Large catalogs and layered sales rules

Magento supports simple products, configurable products, grouped and bundle products, digital products and detailed filter attributes. Price rules for customer groups, coupons, cart conditions and admin permissions are deep enough to support both B2C and B2B.

Wide customization does not mean “change anything instantly”. Each new rule has to go through input data, edge cases and regression tests. A program like “buy 5 cases, dealer price, free item from another warehouse” easily touches three areas: price, stock and refunds. We always write out all three branches before coding.

Connecting ERP, PIM, CRM and warehouses with a dedicated architecture

Magento has APIs, events and queues to exchange data with other systems. This is the base for flows such as the ERP pushing prices, the PIM pushing product information, the website receiving orders, the warehouse reporting stock and the CRM receiving customer records. You can read more about how ERP consolidates operational data and CRM manages customer relationships before drawing the integration diagram.

One easily overlooked detail of the trade is the “source of truth” for each data field. If the ERP holds the price, the website admin must not edit it by hand. If Magento holds SEO content, the PIM must not overwrite it every night. As soon as two systems both think they are the source of truth, the price you just fixed reverts to the old one the next morning.

Magento is worth choosing when this complexity is real. If it isn't, you are buying a large machine to solve a problem you don't have yet. It is powerful, but only when it fits the job.

Magento's weak points: heavy, hard, and needs someone to look after the system

The night before a promotion, an update to a payment extension makes the checkout page throw an error. With Shopify, the provider looks after the core infrastructure. With Magento Open Source, your team has to read the logs, roll back to the previous build, check the queues and confirm whether orders were created twice. Deep control comes with that responsibility.

The infrastructure doesn't fit on ordinary shared hosting

Magento needs PHP, a database, a search engine, cache, cron and related services, all running the right versions. The system requirements for Adobe Commerce change with each release, so the technical team has to check the compatibility matrix before upgrading. Buying a VPS and finishing the install is not the same as running the store.

A production setup usually also includes a CDN, Varnish or an equivalent cache layer, Redis, OpenSearch, queues, monitoring, backups and a staging environment. Without staging, every module upgrade is tested directly on the store that takes your money. Don't do that.

That list alone already adds up to 7 operating layers on top of the storefront code. Production and staging are 2 environments at a minimum; larger systems also separate development, integration testing and load testing. A quote that only says “high-spec VPS” tells you nothing. There are a lot of layers.

A realistic maintenance schedule also has to keep backups 30 days, check that alerts cover the full 24 hours and rehearse restoring at least 2 times a year. These three numbers won't make the website faster, but they decide whether your technical team can save orders when an error hits at midnight. Put them in the contract.

Good speed has to be designed and measured

The old article said Magento loads fast by itself. That is wrong. A large catalog, many filter attributes, heavy images and extensions that call outside services all slow pages down. A wrong indexing schedule also means new prices don't show even after the admin has saved them.

We split speed into three layers: the storefront customers see, the API that exchanges data, and background tasks such as price syncing or sending emails. A product page can open fast while the queue is clogged and orders still reach the warehouse late. Measure each point separately. All three need to be checked.

Magento developers are hard to replace midway

Magento has its own module conventions, dependency injection, layout, indexers, cache and build process. Someone who knows PHP can't necessarily start working on a project right away. Custom code without documentation makes handover costs climb very quickly.

Before signing, you need to settle your rights to the code repository, cloud account, API keys, deployment process, integration documentation and a copy of the data. Don't let the whole system sit in the contractor's account. The hard part when switching vendors is knowing how many systems the code talks to, with which keys, and who receives the alert when something fails.

We require every integration to have 1 data owner, 1 logging mechanism and 1 way to rerun. Miss any one of the three and a small incident turns into a long session of digging through logs 2 days or longer. If the same error repeats 3 times a month the root cause has to be fixed, not patched by hand again. This is the part that takes people.

Magento, WooCommerce or Shopify: choose by complexity

All three platforms can take orders. The differences are launch speed, depth of customization, who holds the infrastructure, and how complex the store really is. Don't use product count as the only criterion; 20,000 products on one price list can be easier than 2,000 products with contract pricing, three warehouses and six approval steps.

Select WooCommerce when the shop needs its own website, strong SEO content, a process that isn't too complex, and WordPress administrators that are easy to find. The WooCommerce core is open source; the budget goes to hosting, theme, plugins and labor.

Select Shopify when you need to test a market within days, accept a USD subscription and use the flow the platform has already designed. The infrastructure is lighter at the start. In return, apps, third-party transaction fees and checkout limits have to be counted in advance.

Choose Magento when multiple websites, multiple price lists, warehouses and internal software are already a current problem. If you haven't reached that point, wait. A small shop shouldn't take on Magento's weight. Keep it lean.

A practical filter: a shop with under 50 SKUs, only 1 kho, with 2 payment methods which are COD and bank transfer, and no integrations running yet, gets products out faster on Shopify or WooCommerce. In the other direction, 3 storefront, 4 kho and contract-based B2B pricing are reason enough to survey Magento. Complexity decides.

If the shop only receives about 50 orders a month, needs to open within 7-day and has no technical staff, Shopify wins on startup speed. When every order has to go through 3 approval steps and several systems, Magento finally has room to show its value. Choose based on the work that is actually running.

What does a Magento project cost in Vietnam?

A Magento quote of 80 million and a quote of 600 million aren't necessarily selling the same work. The 80 million version may only install a theme and tweak the interface. The 600 million version may include business analysis, data import, ERP integration, load testing, staging, monitoring and warranty. Comparing totals without comparing scope leads to the wrong choice.

The table below is a reference budgeting framework for Vietnam, for breaking down the work before you request quotes in August 2026. It is not Adobe's list price or a fixed MONA quote.

An Open Source shop with a custom theme, one warehouse, one payment gateway and no ERP link should usually prepare about 250–450 million VND for the first year. Projects with multiple websites, multiple warehouses, B2B pricing and many integrations usually run from 500 million to over 1.2 billion VND, not including an Adobe Commerce license. This range is for ruling out unrealistic options, not a promise of a fixed price.

Don't add it up once and forget it. If infrastructure is 6 million VND/month, maintenance 20 million VND/quarter and extensions 60 million VND/year, just keeping the system running is already 212 million VND/year. A three-year budget will show which option holds up.

Ask the vendor to separate four numbers: the first-time build cost, annual license or extension fees, monthly infrastructure cost, and maintenance plus incident on-call cost. A 350 million project without staging, monitoring or documentation isn't necessarily cheaper than a 450 million project that has all three.

A quick calculation by person-days

Suppose the scope needs 140 person-days covering analysis, design, backend, frontend, testing and project management. An average rate of 2.2 million VND/day puts labor at about 308 million VND. Add 72 million for first-year infrastructure and 40 million as an integration contingency, and the total is 420 million VND. This calculation helps you see which step a 90 million quote is leaving out.

If the scope is only installing the Open Source version, using an existing theme and entering a few dozen products, doing it yourself is fine. Build it on staging, create 20 test orders, cancel 5, refund 3, change prices in bulk and restore a backup before you open for sales. If you can run it yourself, do; you don't need to hire MONA. Add it all up before you sign.

12-question checklist before you decide on Magento

Don't start with the question “is Magento powerful?” Open your current process and answer the 12 questions below. Only with 7 or more “yes” answers is Magento worth a deeper survey.

Do this quickly, in 20 minutes. Then pick 3 questions that cost the most money and check them against the data from 30 days the recent period, because the feeling that “orders are complicated” often differs from the real numbers. Mark three areas first.

1. Do you have two or more websites or brands that need to share product data?
2. Does the same SKU have multiple price lists by customer group, contract or market?
3. Does inventory have to be split across multiple warehouses, stores or countries?
4. Does the website have to send and receive data with an ERP, PIM, CRM or accounting system?
5. Does the catalog have tens of thousands of SKUs and many filter attributes?
6. Do you have B2B processes such as account approval, quotes, credit limits or buying on credit?
7. Does each market need its own language, currency, tax and content?
8. Do you have a technical team or an ongoing maintenance budget after handover?
9. Do you have a separate staging environment and a testing schedule before each upgrade?
10. Is the cost of the website being down for two hours greater than the cost of on-call operations?
11. Does your product data already have SKU codes and a clear source of truth?
12. Will the project approver accept longer analysis and testing time than a subscription platform needs?

With fewer than 4 “yes” answers, compare WooCommerce or Shopify again. Between 4 and 6, build a proof of concept for the hardest flow first, not the whole system. At 7 or more, the next step is a data diagram and expected load, and only then choose Open Source or Adobe Commerce. Don't rush the choice.

The test has 12 questions, but don't use it as a mechanical score. One “yes” on “the ERP must sync both ways every 5 minutes” weighs more than three answers about interface or language combined; so also mark which questions create data, money and inventory. If those three areas go wrong, you lose real money.

FAQ when choosing Magento

The four questions below cover points you often ask in the 30 minutes first part of a survey session. Each answer needs to be checked against at least 1 dataset and 1 day of operations from real use before you decide. Don't answer based on the demo.

Is Magento Open Source really free?

The license is 0 USD free under the public source code, but a production website still pays for infrastructure, implementation work, extensions and maintenance. A first-year estimate needs at least 4 cost groups . If a quote only says “install Magento for free”, you are only seeing the step of downloading code, not the cost of selling. That is the real total.

Can Magento handle hundreds of thousands of products?

Magento's architecture is used for large catalogs, but SKU count doesn't guarantee speed. 100.000 SKU with few attributes is sometimes lighter than 20.000 SKU a catalog with hundreds of filters, group pricing and constant syncing. You have to test sample data, filter queries and concurrent load on the planned infrastructure.

Can I migrate from WooCommerce or Shopify to Magento?

Yes, if you can export products, variants, customers, orders, images and old URLs in a usable format. A safe migration needs reconciliation at three levels: record counts, totals and random samples; then set up redirects for the old URLs to keep the SEO you already have. Don't just count products.

How long until a Magento website can go on sale?

A scope using an existing theme with few integrations usually takes a few months, not a few days. Multi-store projects with ERP links go through survey, proof of concept, development, data migration, load testing and a trial run; a schedule is only reliable after the number of flows is fixed. Be precise about scope. A shorter schedule is just a guess.

How does MONA build custom Magento projects?

MONA was founded in 2016, has delivered 14,000+ projects and has kept a rate of 85% returning clients. With Magento, we don't take on a project just because a client names the platform. The first two weeks of survey have to prove that Magento solves a real complexity; if WooCommerce or Shopify is leaner, we say so plainly so you don't buy extra maintenance.

The three numbers to check are 2016, 14,000+ projects and 85% retention. The six checkpoints below apply to each project, but checkpoint 2, on data sources, often takes the most time because prices, stock and product descriptions tend to sit in three different places. We spend at least 2 days just reviewing data sources before fixing the architecture. We settle data ownership first.

MONA is one of the few companies in Vietnam that takes on custom Magento implementations, from multi-website architecture to integrating internal software. Our approach follows six checkpoints:

1. Map one order from the storefront through warehouse, payment, accounting and after-sales care.
2. Name the correct source for products, prices, stock, customers and order status.
3. Set up staging with the same build process, backup and rollback to a stable version.
4. Build the hardest flow first, usually B2B pricing, stock sync or order refunds.
5. Load test against the agreed traffic and concurrent orders, not by gut feeling.
6. Hand over source code, accounts, integration documentation, logs and the maintenance schedule.

We rarely advise building everything in the first round. A sensible roadmap splits the core platform, required integrations and growth features into phases; get the data running correctly first, and do the nice features later. For a small shop, the answer stays the same: don't take on Magento's weight. Keep the scope lean.

If your 12-question checklist has 7 or more “yes” answers, bring your warehouse diagram, price lists, a list of the software you use and three months of sample orders to an architecture session. MONA will show which parts Magento should carry, which should stay in the ERP, and the budget range before we write a quote. See also our custom e-commerce website design service or call 1900 636 648 to discuss the actual problem Magento in your live system.