Magento là gì? Chi phí thật và cách chọn nền tảng năm 2026

Magento là nền tảng thương mại điện tử mã nguồn mở dành cho cửa hàng cần sửa sâu quy trình bán, quản lý nhiều website hoặc nhiều thương hiệu trên cùng một hệ thống. Tên thương mại hiện nay dễ gây nhầm: bản cộng đồng vẫn gọi là Magento Open Source, còn sản phẩm doanh nghiệp do Adobe bán mang tên Adobe Commerce. Bản Open Source không thu phí bản quyền, nhưng một dự án Magento chạy ổn ở Việt Nam vẫn cần ngân sách lớn cho phân tích nghiệp vụ, lập trình, máy chủ, kiểm thử và bảo trì.

Nếu shop chỉ có vài trăm sản phẩm, nhận COD, chuyển khoản và chưa đồng bộ với phần mềm khác, Magento thường quá nặng. Khi anh chị có nhiều kho, nhiều bảng giá, nhiều website theo quốc gia hoặc phải nối ERP, PIM, CRM, nền tảng này mới bắt đầu đáng tiền.

Bài được rà lại ngày 07/08/2026, đối chiếu giá trên trang Adobe và Shopify tại đúng thời điểm đó. Mục tiêu rất rõ: sau khoảng 15 phút đọc, anh chị tự loại được phương án quá nặng trước khi bỏ ra vài trăm triệu đồng. Đỡ mất một vòng báo giá. Cứ đọc lại 2 lần nếu hệ thống đang có ERP.

Magento là gì và đang được gọi bằng tên nào?

Mở một trang quản trị Magento, anh chị không chỉ thấy sản phẩm, đơn hàng và khách mua. Một màn hình còn quản được nhiều website, mỗi website có nhiều cửa hàng, mỗi cửa hàng lại có giao diện, ngôn ngữ, tiền tệ, bảng giá và danh mục riêng. Đây là lý do Magento xuất hiện trong các dự án bán lẻ phức tạp hơn một website bán hàng thông thường.

Về kỹ thuật, Magento là ứng dụng thương mại điện tử viết bằng PHP, dùng cơ sở dữ liệu, hệ thống lập chỉ mục, bộ nhớ đệm và công cụ tìm kiếm để xử lý danh mục lớn. Mã nguồn công khai của Magento Open Source vẫn được Adobe duy trì trên GitHub. Anh chị được tải, cài trên máy chủ riêng, sửa code và tự chọn đơn vị vận hành.

Tên gọi nên hiểu như sau:

Ba tầng cần nhớ là website, store và store view. Một website thường gắn với một miền hoặc thị trường; store tổ chức catalog; store view lo cách hiển thị theo ngôn ngữ hay bối cảnh. Có ba tầng đó, một bộ quản trị mới phục vụ nhiều mặt tiền mà vẫn giữ được phần dữ liệu dùng chung suốt 1 năm vận hành. Trong một ví dụ có 3 website, 2 bản ngôn ngữ và 6 trang hiển thị, cấu trúc này giúp quản lý phần dùng chung từ một nơi. Tên đã đổi, lõi vẫn vậy.

Magento không phải một mẫu website tải về rồi thay logo. Phần nền tảng đã có catalog, giỏ hàng, khuyến mãi, khách mua, đơn hàng và cấu trúc đa cửa hàng; phần tốn công nằm ở cách những khối đó ăn với giá sỉ, kho, kế toán, vận chuyển và dữ liệu cũ của anh chị.

Tụi em thường kéo cuộc nói chuyện về một đơn thật: đơn đến từ storefront nào, lấy giá nào, trừ kho nào, ai duyệt và dữ liệu trả về hệ thống nào. Trả lời chưa xong năm câu đó thì chưa cần bàn màu giao diện. Magento mạnh ở kiến trúc. Cũng vì vậy, nó phạt rất nặng một bản đặc tả làm qua loa.

Magento Open Source và Adobe Commerce khác giá ra sao năm 2026?

Giá rõ nhất lại là con số 0. Magento Open Source không thu phí license; anh chị vẫn trả tiền cho máy chủ, thiết kế, code, tích hợp, bảo mật và người chăm hệ thống. “Miễn phí” chỉ áp cho quyền dùng mã nguồn.

Bảng giá Adobe Commerce được kiểm ngày 07/08/2026 không niêm yết một con số cố định. Cả Adobe Commerce as a Cloud Service, Adobe Commerce on Cloud và Adobe Commerce Optimizer đều dẫn sang nút Get pricing để nhận báo giá riêng. Vì vậy, con số 22.000 USD/năm còn xuất hiện trong nhiều bài cũ không nên dùng làm giá 2026; đó không phải mức Adobe đang công bố trên trang giá hiện tại.

Adobe mô tả Commerce năm 2026 có ba hướng: dịch vụ cloud nhiều khách dùng chung, cloud chuyên biệt cho một khách, và lớp storefront/catalog có thể ghép với bộ máy giao dịch đang có. Đây không còn là phép so “bản miễn phí thiếu vài tính năng, bản trả tiền mở hết”. Kiến trúc, cách nâng cấp, dữ liệu và trách nhiệm vận hành khác nhau ngay từ đầu. Ba hướng đó ứng với 3 bản gồm SaaS nhiều khách dùng chung, PaaS một khách trên hạ tầng riêng và Commerce Optimizer. Trang chính thức dùng nút nhận giá cho cả ba, nghĩa là bảng ngân sách phải chừa một dòng license chưa xác định cho tới khi Adobe gửi đề xuất. Đừng điền bằng con số cũ trên blog. Giá 0 chưa phải chi phí 0.

Một hồ sơ mua Adobe Commerce cần hỏi bằng văn bản năm mục: license tính theo chỉ số nào, môi trường production và staging gồm gì, mức hỗ trợ ra sao, add-on nào chưa nằm trong giá, chi phí tăng khi doanh số hoặc lưu lượng tăng thế nào. Chưa có năm câu trả lời, chưa chốt tổng chi phí sở hữu.

Magento mạnh thật ở tùy biến và quản lý đa cửa hàng

Điểm mạnh của Magento lộ rõ khi một sản phẩm không còn chỉ có “tên, giá, ảnh”. Chẳng hạn, một nhà phân phối thiết bị có giá lẻ, giá đại lý cấp 1, giá theo hợp đồng; mỗi kho giữ lượng hàng riêng; cùng mã sản phẩm nhưng nội dung và thuế khác giữa Việt Nam, Singapore và Úc. Một website nhỏ sẽ phải chắp thêm nhiều lớp. Magento đã có cấu trúc để tổ chức bài toán đó ngay từ lõi.

Một bộ quản trị, nhiều website và nhiều store view

Cấu trúc website, store và store view cho phép anh chị tách thương hiệu, thị trường hoặc ngôn ngữ mà không phải nuôi nhiều bộ code rời. Danh mục nào dùng chung thì chia sẻ. Giá, nội dung, tiền tệ hoặc giao diện cần tách thì cấu hình theo phạm vi.

Ví dụ một doanh nghiệp có ba nhãn hàng, bán ở hai quốc gia và dùng hai ngôn ngữ. Nếu tách thành 12 website độc lập, một lần sửa chính sách đổi trả phải làm 12 lượt. Kiến trúc Magento đúng có thể giữ nội dung dùng chung ở tầng trên, phần địa phương hóa nằm ở store view. Ít thao tác lặp hơn, nhưng quyền sửa cũng phải khóa kỹ hơn.

Trong ví dụ đó, 3 nhãn hàng × 2 quốc gia × 2 ngôn ngữ tạo ra 12 trang hiển thị. Magento gom 12 trang này vào một kiến trúc có chủ đích, thay vì để 12 nhóm plugin phát triển lệch nhau. Nếu chính sách đổi trả sửa 2 lần/tháng, kiến trúc dùng chung bớt được hàng chục lượt cập nhật thủ công trong 1 năm.

Catalog lớn và quy tắc bán hàng nhiều tầng

Magento hỗ trợ sản phẩm đơn, sản phẩm có biến thể, nhóm, bundle, sản phẩm số và các thuộc tính lọc chi tiết. Quy tắc giá cho nhóm khách, coupon, điều kiện giỏ hàng và phân quyền quản trị đủ sâu để làm nền cho cả B2C lẫn B2B.

Tùy biến rộng không đồng nghĩa “muốn sửa gì cũng sửa ngay”. Mỗi quy tắc mới phải đi qua dữ liệu đầu vào, trường hợp biên và bài kiểm hồi quy. Một chương trình “mua 5 thùng, giá theo đại lý, tặng hàng khác kho” dễ đụng ba vùng: giá, tồn và hoàn trả. Tụi em luôn viết đủ ba nhánh trước khi code.

Nối ERP, PIM, CRM và kho theo kiến trúc riêng

Magento có API, sự kiện và hàng đợi để trao đổi dữ liệu với hệ thống khác. Đây là nền cho những luồng như ERP đẩy giá, PIM đẩy thông tin sản phẩm, website nhận đơn, kho phản hồi tồn, CRM nhận hồ sơ khách. Anh chị có thể đọc thêm cách ERP gom dữ liệu vận hành và CRM quản lý quan hệ khách hàng trước khi vẽ sơ đồ tích hợp.

Một chi tiết nghề dễ bị bỏ qua là “nguồn đúng” của từng trường dữ liệu. Giá do ERP giữ thì người quản trị website không được sửa tay. Nội dung SEO do Magento giữ thì PIM không được ghi đè mỗi đêm. Chỉ cần hai hệ thống cùng nghĩ mình là nguồn đúng, sáng hôm sau giá vừa sửa sẽ quay về bản cũ.

Magento đáng chọn khi sự phức tạp này có thật. Nếu chưa có, anh chị đang mua một bộ máy lớn để xử lý bài toán chưa xuất hiện. Mạnh, nhưng phải đúng việc.

Điểm yếu của Magento: nặng, khó và cần người giữ hệ thống

Đêm trước ngày chạy khuyến mãi, bản cập nhật extension thanh toán làm trang checkout báo lỗi. Với Shopify, phần lõi hạ tầng do nhà cung cấp giữ. Với Magento Open Source, đội của anh chị phải đọc log, quay lại bản build cũ, kiểm hàng đợi và xác nhận đơn có bị tạo lặp hay không. Quyền sửa sâu đi cùng trách nhiệm đó.

Hạ tầng không gói gọn trong một hosting phổ thông

Magento cần PHP, cơ sở dữ liệu, công cụ tìm kiếm, cache, cron và các dịch vụ liên quan chạy đúng phiên bản. Tài liệu yêu cầu hệ thống của Adobe Commerce thay đổi theo từng bản phát hành, nên đội kỹ thuật phải kiểm ma trận tương thích trước khi nâng cấp. Mua một VPS rồi cài xong chưa phải là vận hành.

Một cấu hình production thường còn có CDN, Varnish hoặc lớp cache tương đương, Redis, OpenSearch, hàng đợi, giám sát, backup và môi trường staging. Thiếu staging, mỗi lần nâng module là thử thẳng trên nơi đang nhận tiền. Cấm làm vậy.

Chỉ riêng danh sách vừa nêu đã có 7 lớp vận hành ngoài phần code storefront. Production và staging là 2 môi trường tối thiểu; hệ thống lớn còn tách thêm môi trường phát triển, kiểm thử tích hợp và kiểm tải. Một báo giá chỉ ghi “VPS cấu hình cao” chưa nói được gì. Rất nhiều lớp.

Một lịch bảo trì thực tế còn phải giữ bản backup 30 ngày, kiểm cảnh báo đủ 24 giờ và diễn tập khôi phục ít nhất 2 lần/năm. Ba con số này không làm website nhanh hơn, nhưng quyết định đội kỹ thuật có cứu được đơn khi lỗi xuất hiện lúc nửa đêm hay không. Phải ghi vào hợp đồng.

Tốc độ tốt phải được thiết kế và đo

Bài cũ nói Magento tự tải nhanh là sai. Catalog lớn, nhiều thuộc tính lọc, ảnh nặng và extension gọi dịch vụ ngoài đều kéo trang chậm. Lập chỉ mục sai lịch còn khiến giá mới chưa hiện dù quản trị đã lưu.

Tụi em chia tốc độ thành ba lớp: storefront khách nhìn thấy, API trao đổi dữ liệu và tác vụ nền như đồng bộ giá hay gửi email. Trang sản phẩm mở nhanh mà hàng đợi bị nghẽn, đơn vẫn chậm sang kho. Đo mỗi điểm riêng. Phải xem cả ba.

Lập trình viên Magento khó thay thế giữa chừng

Magento có quy ước module, dependency injection, layout, indexer, cache và quy trình build riêng. Một người biết PHP chưa chắc vào dự án xử lý được ngay. Code tùy chỉnh thiếu tài liệu làm chi phí bàn giao tăng rất nhanh.

Trước khi ký, anh chị cần chốt quyền với kho mã nguồn, tài khoản cloud, khóa API, quy trình triển khai, tài liệu tích hợp và bản sao dữ liệu. Đừng để toàn bộ hệ thống nằm trong tài khoản của nhà thầu. Điểm khó lúc đổi đơn vị là biết code đang nói chuyện với bao nhiêu hệ thống, theo khóa nào và lỗi thì ai nhận cảnh báo.

Tụi em yêu cầu mỗi tích hợp có 1 chủ dữ liệu, 1 cơ chế ghi log và 1 cách chạy lại. Thiếu một trong ba, sự cố nhỏ sẽ thành buổi dò log kéo dài 2 ngày hoặc lâu hơn. Cùng một lỗi lặp 3 lần/tháng thì phải sửa gốc, không tiếp tục chữa tay. Đây là phần tốn người.

Magento, WooCommerce hay Shopify: chọn theo độ phức tạp

Ba nền tảng đều nhận đơn được. Sự khác biệt nằm ở tốc độ mở bán, độ sâu tùy biến, ai giữ hạ tầng và mức phức tạp mà shop thật sự đang có. Đừng dùng số sản phẩm làm tiêu chí duy nhất; 20.000 sản phẩm cùng một bảng giá đôi khi dễ hơn 2.000 sản phẩm có giá hợp đồng, ba kho và sáu bước duyệt.

Chọn WooCommerce khi shop cần website riêng, nội dung SEO mạnh, quy trình chưa quá phức tạp và muốn dễ tìm người quản trị WordPress. Phần lõi WooCommerce là mã nguồn mở; ngân sách dồn vào hosting, theme, plugin và công làm.

Chọn Shopify khi cần thử thị trường trong vài ngày, chấp nhận thuê bao USD và dùng luồng nền tảng đã thiết kế. Hạ tầng nhẹ đầu hơn. Đổi lại, app, phí giao dịch bên thứ ba và giới hạn checkout phải được tính trước.

Chọn Magento khi nhiều website, nhiều bảng giá, kho và phần mềm nội bộ đã trở thành vấn đề hiện tại. Chưa tới mức đó thì khoan. Shop nhỏ thì đừng dùng Magento cho nặng. Chọn gọn.

Một mốc lọc thực dụng: shop dưới 50 mã hàng, chỉ 1 kho, có 2 cách nhận tiền là COD và chuyển khoản, chưa chạy tích hợp thì Shopify hoặc WooCommerce giúp ra hàng nhanh hơn. Ở chiều ngược lại, 3 storefront, 4 kho và giá B2B theo hợp đồng đã đủ lý do khảo sát Magento. Độ phức tạp quyết định.

Nếu shop mới nhận khoảng 50 đơn/tháng, cần mở trong 7 ngày và chưa có người kỹ thuật, Shopify thắng về tốc độ khởi động. Khi mỗi đơn phải đi qua 3 lần duyệt cùng nhiều hệ thống, Magento mới có đất thể hiện. Chọn theo việc đang chạy.

Chi phí triển khai Magento ở Việt Nam gồm những khoản nào?

Một báo giá Magento 80 triệu và một báo giá 600 triệu chưa chắc đang bán cùng một việc. Bản 80 triệu có thể chỉ cài theme và sửa giao diện. Bản 600 triệu có thể gồm phân tích nghiệp vụ, nhập dữ liệu, tích hợp ERP, kiểm tải, staging, giám sát và bảo hành. So tổng tiền mà không so phạm vi sẽ chọn sai.

Bảng dưới là khung lập ngân sách tham khảo tại Việt Nam, dùng để bóc việc trước khi lấy báo giá trong tháng 08/2026. Đây không phải bảng giá niêm yết của Adobe hay báo giá cố định của MONA.

Một shop Open Source dùng theme tùy chỉnh, một kho, một cổng thanh toán và chưa nối ERP thường nên chuẩn bị khoảng 250–450 triệu VNĐ cho năm đầu. Dự án đa website, đa kho, giá B2B và nhiều tích hợp thường đi từ 500 triệu đến trên 1,2 tỷ VNĐ, chưa gồm license Adobe Commerce. Đây là dải để anh chị loại phương án thiếu thực tế, không phải lời hứa chốt giá.

Đừng cộng một lần rồi quên. Nếu hạ tầng là 6 triệu VNĐ/tháng, bảo trì 20 triệu VNĐ/quý và extension 60 triệu VNĐ/năm, riêng phần giữ hệ thống đã là 212 triệu VNĐ/năm. Tính ngân sách ba năm sẽ lộ rõ phương án nào chịu được.

Hãy yêu cầu nhà cung cấp tách bốn con số: tiền làm lần đầu, tiền bản quyền hoặc extension mỗi năm, tiền hạ tầng mỗi tháng, tiền bảo trì và trực sự cố. Một dự án 350 triệu nhưng không có staging, monitoring và tài liệu chưa chắc rẻ hơn dự án 450 triệu có đủ ba thứ đó.

Tự tính nhanh bằng ngày công

Giả sử phạm vi cần 140 ngày công gồm phân tích, thiết kế, backend, frontend, kiểm thử và quản lý dự án. Đơn giá bình quân 2,2 triệu VNĐ/ngày đưa phần nhân công về khoảng 308 triệu VNĐ. Cộng 72 triệu hạ tầng năm đầu và 40 triệu dự phòng tích hợp, tổng là 420 triệu VNĐ. Phép tính này giúp anh chị nhìn ra báo giá 90 triệu đang bỏ mất khâu nào.

Nếu phạm vi chỉ là cài bản Open Source, dùng theme có sẵn và nhập vài chục sản phẩm, tự triển khai vẫn được. Hãy dựng trên staging, tạo 20 đơn thử, hủy 5 đơn, hoàn 3 đơn, đổi giá hàng loạt và khôi phục một bản backup trước khi mở bán. Tự dùng được thì cứ dùng, chưa cần thuê MONA. Tính đủ rồi mới ký.

Checklist 12 câu trước khi quyết định dùng Magento

Đừng bắt đầu bằng câu “Magento có mạnh không”. Hãy mở quy trình hiện tại và trả lời 12 câu dưới đây. Có từ 7 câu “có” trở lên, Magento mới đáng đưa vào vòng khảo sát sâu.

Làm nhanh trong 20 phút. Sau đó chọn 3 câu tốn nhiều tiền nhất và kiểm lại bằng dữ liệu của 30 ngày gần đây, vì cảm giác “đơn đang phức tạp” dễ khác số thật. Khoanh ba vùng trước.

1. Anh chị có từ hai website hoặc hai thương hiệu cần dùng chung dữ liệu sản phẩm?
2. Cùng một mã hàng có nhiều bảng giá theo nhóm khách, hợp đồng hoặc thị trường?
3. Tồn kho phải tách theo nhiều kho, cửa hàng hoặc quốc gia?
4. Website phải nhận và trả dữ liệu với ERP, PIM, CRM hay hệ thống kế toán?
5. Danh mục có hàng chục nghìn SKU và nhiều thuộc tính lọc?
6. Có quy trình B2B như duyệt tài khoản, báo giá, hạn mức hoặc mua công nợ?
7. Mỗi thị trường cần ngôn ngữ, tiền tệ, thuế và nội dung riêng?
8. Có đội kỹ thuật hoặc ngân sách bảo trì liên tục sau ngày bàn giao?
9. Có staging riêng và lịch kiểm thử trước mỗi lần nâng cấp?
10. Chi phí website ngừng nhận đơn hai giờ lớn hơn chi phí trực vận hành?
11. Dữ liệu sản phẩm đã có mã SKU và nguồn quản lý rõ?
12. Người duyệt dự án chấp nhận thời gian phân tích, kiểm thử dài hơn nền tảng thuê bao?

Có dưới 4 câu “có”, hãy so lại WooCommerce hoặc Shopify. Nằm giữa 4 và 6, làm bản chứng minh kỹ thuật cho đúng luồng khó trước, chưa xây cả hệ thống. Từ 7 trở lên, bước kế là lập sơ đồ dữ liệu và tải dự kiến, rồi mới chọn Open Source hay Adobe Commerce. Đừng chọn vội.

Bài kiểm có 12 câu, nhưng không dùng nó như thang điểm máy móc. Một câu “có ERP phải đồng bộ hai chiều mỗi 5 phút” nặng hơn ba câu về giao diện hay ngôn ngữ cộng lại; vì vậy anh chị phải khoanh luôn câu nào làm phát sinh dữ liệu, tiền và tồn kho. Ba vùng đó sai là mất tiền thật.

Câu hỏi thường gặp khi chọn Magento

Bốn câu dưới đây xử lý các điểm anh chị hay hỏi trong 30 phút đầu của một buổi khảo sát. Mỗi câu cần đối chiếu tối thiểu 1 bản dữ liệu và 1 ngày vận hành thật trước khi chốt. Đừng trả lời theo demo.

Magento Open Source có thật sự miễn phí không?

License là 0 USD theo mã nguồn công khai, còn website production vẫn trả hạ tầng, công triển khai, extension và bảo trì. Một dự toán năm đầu phải có tối thiểu 4 nhóm tiền đó. Nếu bảng chào giá chỉ ghi “cài Magento miễn phí”, anh chị mới nhìn thấy bước tải code, chưa thấy chi phí bán hàng. Đó mới là tổng tiền.

Magento có chịu được hàng trăm nghìn sản phẩm không?

Kiến trúc Magento được dùng cho catalog lớn, nhưng số SKU không tự bảo đảm tốc độ. 100.000 SKU có ít thuộc tính đôi khi nhẹ hơn 20.000 SKU với hàng trăm bộ lọc, giá theo nhóm và đồng bộ liên tục. Phải kiểm dữ liệu mẫu, truy vấn bộ lọc và tải đồng thời trên hạ tầng dự kiến.

Có chuyển từ WooCommerce hoặc Shopify sang Magento được không?

Được, nếu xuất được sản phẩm, biến thể, khách, đơn, ảnh và URL cũ ở định dạng dùng được. Một lần chuyển an toàn cần đối soát theo ba lớp: số bản ghi, tổng tiền và mẫu ngẫu nhiên; sau đó lập chuyển hướng cho URL cũ để giữ phần SEO đang có. Đừng chỉ đếm sản phẩm.

Bao lâu thì một website Magento mở bán được?

Phạm vi dùng theme sẵn, ít tích hợp thường cần vài tháng thay vì vài ngày. Dự án đa store và nối ERP phải đi qua khảo sát, bản chứng minh kỹ thuật, phát triển, chuyển dữ liệu, kiểm tải và chạy thử; lịch chỉ đáng tin sau khi chốt số luồng. Nói chính xác bằng phạm vi. Lịch ngắn hơn chỉ là đoán.

MONA triển khai Magento theo yêu cầu như thế nào?

MONA thành lập năm 2016, đã thực hiện 14.000+ dự án và duy trì tỷ lệ 85% khách quay lại. Với Magento, tụi em không nhận dự án chỉ vì khách gọi đúng tên nền tảng. Hai tuần khảo sát đầu phải chứng minh được Magento giải quyết một độ phức tạp có thật; nếu WooCommerce hoặc Shopify gọn hơn, tụi em nói thẳng để anh chị không mua thêm việc bảo trì.

Ba số để đối chiếu là 2016, 14.000+ dự án và 85% retention. Sáu chốt bên dưới dùng cho từng dự án, nhưng chốt số 2 về nguồn dữ liệu thường ngốn nhiều thời gian vì giá, tồn và mô tả sản phẩm hay nằm ở ba nơi khác nhau. Tụi em dành tối thiểu 2 ngày chỉ để rà nguồn dữ liệu trước khi chốt kiến trúc. Tụi em giải quyết quyền sở hữu dữ liệu trước.

MONA là một trong số ít đơn vị tại Việt Nam nhận triển khai Magento theo yêu cầu, từ kiến trúc đa website đến tích hợp phần mềm nội bộ. Cách tụi em làm đi theo sáu chốt kiểm:

1. Vẽ một đơn hàng từ storefront tới kho, thanh toán, kế toán và chăm sóc sau bán.
2. Chỉ định nguồn đúng cho sản phẩm, giá, tồn, khách và trạng thái đơn.
3. Dựng staging cùng quy trình build, backup và quay lại bản ổn định.
4. Làm luồng khó trước, thường là giá B2B, đồng bộ tồn hoặc hoàn đơn.
5. Kiểm tải theo lượng truy cập và số đơn đồng thời đã chốt, không kiểm bằng cảm giác.
6. Bàn giao mã nguồn, tài khoản, tài liệu tích hợp, log và lịch bảo trì.

Tụi em hiếm khi khuyên xây toàn bộ ngay lượt đầu. Một roadmap hợp lý chia nền tảng lõi, tích hợp bắt buộc và phần tăng trưởng thành các giai đoạn; dữ liệu chạy đúng trước, tính năng đẹp làm sau. Với shop nhỏ, câu trả lời vẫn giữ nguyên: đừng dùng Magento cho nặng. Giữ phạm vi cho gọn.

Nếu checklist 12 câu của anh chị có từ 7 câu “có”, hãy mang sơ đồ kho, bảng giá, danh sách phần mềm đang dùng và ba tháng đơn mẫu tới buổi bóc kiến trúc. MONA sẽ chỉ ra phần Magento nên gánh, phần nên giữ ở ERP và khoảng ngân sách trước khi viết báo giá. Xem thêm dịch vụ thiết kế website bán hàng theo yêu cầu hoặc gọi 1900 636 648 để trao đổi đúng bài toán Magento của hệ thống đang vận hành.