Khi chuyển sang Adobe Commerce, doanh nghiệp nên lập kế hoạch cho một môi trường vận hành thương mại ở cấp doanh nghiệp, thay vì chỉ xem đây là một storefront Magento có quy mô lớn hơn. Quá trình chuyển đổi vẫn có thể bao gồm những dữ liệu thương mại quen thuộc như Products, Categories, Customers, Orders, Reviews, Coupons, CMS Pages và Blog Posts, nhưng Adobe Commerce thường bổ sung nhiều quan hệ quản trị kinh doanh hơn: company accounts, vai trò người mua, shared catalogs, quy trình báo giá, quy tắc Purchase Orders, storefront theo từng phạm vi, nội dung theo lịch, custom modules và các mối phụ thuộc vào hệ thống bên ngoài.
Lớp vận hành doanh nghiệp này làm thay đổi điểm xuất phát của kế hoạch chuyển đổi. Câu hỏi không chỉ là dữ liệu nguồn có thể được di chuyển hay không. Điều cần xác định là sau khi được đưa sang Adobe Commerce, các bản ghi có tiếp tục hỗ trợ đúng quy tắc thương mại, quan hệ giữa người mua, phạm vi storefront, cách tính giá, quy trình nội dung và trách nhiệm của các tích hợp mà doanh nghiệp cần sau khi chính thức vận hành hay không.
Adobe Commerce dùng chung nền tảng kiến trúc Magento với Magento Open Source, vì vậy các loại Products, attributes, attribute sets, phạm vi website/store/store view, Categories, URLs và các phần tùy chỉnh qua extensions vẫn rất quan trọng. Khác biệt nằm ở việc Adobe Commerce thường đặt thêm yêu cầu vận hành doanh nghiệp lên những cấu trúc đó. Kế hoạch chuyển đổi cần giữ đúng cách dữ liệu Magento được tổ chức, đồng thời dành thêm sự chú ý cho B2B, quản trị, Content Staging, quy mô vận hành và trách nhiệm giữa các đội ngũ.
Adobe Commerce như một Nền tảng đích cho vận hành doanh nghiệp
Adobe Commerce thường được chọn khi Cửa hàng đích cần mức kiểm soát vận hành cao hơn một storefront với catalog đơn giản. Doanh nghiệp có thể cần cấu trúc tài khoản B2B, khả năng giới hạn catalog theo thỏa thuận thương mại, quy tắc mua hàng riêng theo company, nhiều storefronts, nội dung bản địa hóa, quy trình merchandising có kiểm soát, các bước phê duyệt rõ ràng hơn và các tích hợp với ERP, PIM, CRM, hệ thống thuế, kho vận, marketplace, analytics hoặc marketing.
Những yêu cầu này biến chuyển đổi thành bài toán về cấu trúc kinh doanh. Dữ liệu Products, Customers, lịch sử đơn hàng và nội dung vẫn quan trọng, nhưng phải được đánh giá trong chính môi trường Adobe Commerce sẽ sử dụng chúng.
| Hạng mục trong Adobe Commerce | Ý nghĩa đối với chuyển đổi | Quyết định cần xác định sớm |
|---|---|---|
| Phạm vi website, store và store view | Storefronts có thể đại diện cho khu vực, thương hiệu, ngôn ngữ, mô hình kinh doanh hoặc ngữ cảnh catalog khác nhau. | Xác định giá trị nào dùng chung toàn hệ thống và giá trị nào thuộc website, store hoặc store view cụ thể. |
| Các loại Products và attributes | Cấu trúc Products có thể ảnh hưởng đến cách biến thể hoạt động, filtering, search, merchandising và các tích hợp. | Phân loại các loại Products, attributes và attribute sets trước khi chuyển đổi. |
| B2B company accounts | Khách hàng doanh nghiệp có thể có company admins, users, permissions, credit, quotes và quy trình Purchase Orders. | Xác định dữ liệu khách hàng ở nguồn là dữ liệu tài khoản cá nhân, dữ liệu company hay quan hệ tùy chỉnh. |
| Shared catalogs và pricing | Khả năng nhìn thấy Products và mức giá có thể thay đổi theo ngữ cảnh người mua. | Xác định price lists, nhóm Customers hoặc contract pricing ở nguồn cần mapping được hỗ trợ, cấu hình hay rà soát phạm vi ngoài chuẩn. |
| Content Staging | Thay đổi về merchandising và nội dung có thể được lên lịch. | Tách nội dung cần di chuyển khỏi việc lập lịch campaign và quản trị nội dung ở Cửa hàng đích. |
| Extensions và các tích hợp | Cửa hàng doanh nghiệp thường phụ thuộc vào modules và các hệ thống bên ngoài. | Xác định sớm các bản ghi extension không được hỗ trợ, external IDs và quy trình tùy chỉnh. |
Adobe Commerce có thể hỗ trợ mô hình thương mại phức tạp, nhưng chất lượng chuyển đổi phụ thuộc vào việc các cấu trúc ở đích đã được xác định trước khi chạy di chuyển dữ liệu trên quy mô đầy đủ hay chưa. Nếu chưa có những quyết định này, dữ liệu vẫn có thể xuất hiện trong Adobe Commerce nhưng không phục vụ đúng mô hình thương mại của doanh nghiệp.
Nền tảng kiến trúc Magento vẫn là phần cốt lõi
Adobe Commerce thuộc cùng nền tảng kiến trúc Magento. Vì vậy, nhiều vấn đề khi chuyển đổi từ hoặc sang Magento Open Source vẫn còn nguyên giá trị: các loại Products, attributes, attribute sets, Categories, hệ thống phân cấp storefront, URL rewrites, nhóm Customers, lịch sử đơn hàng, giả định về inventory, modules và các trường tùy chỉnh.
Sai lầm nằm ở việc dùng mối quan hệ này như lý do để sao chép nguyên kế hoạch Magento Open Source. Adobe Commerce bổ sung các yêu cầu ở cấp doanh nghiệp. Một bản ghi Products ở nguồn vẫn cần được đưa về đúng loại Products của kiến trúc Magento, nhưng đồng thời có thể cần giới hạn khả năng hiển thị theo người mua hoặc giá trong shared catalog. Một bản ghi Customers vẫn cần thông tin hồ sơ chính xác, nhưng cũng có thể phải gắn đúng company, vai trò tài khoản, quyền mua hàng hoặc ngữ cảnh sales representative. Một CMS Page có thể cần được di chuyển, trong khi thời điểm nội dung được đưa lên còn phụ thuộc vào Content Staging hoặc quy trình quản trị campaign.
Vì vậy, mối quan hệ Magento cần được dùng như ranh giới để kiểm soát phạm vi:
| Điểm chung trong kiến trúc Magento | Phần mở rộng ở cấp doanh nghiệp của Adobe Commerce |
|---|---|
| Configurable Products và các Simple Products liên kết | Khả năng hiển thị theo người mua, giá B2B, đặt hàng theo tài khoản và bộ mẫu xác thực cho bối cảnh doanh nghiệp. |
| Attributes và attribute sets | Quản trị catalog giữa nhiều bộ phận, các tích hợp và quyền sở hữu dữ liệu của PIM hoặc ERP. |
| Phạm vi website/store/store view | Tách storefront theo thương hiệu, khu vực, ngôn ngữ và mô hình B2B/B2C. |
| Nhóm Customers | Gán shared catalog, hành vi company account, pricing, tax và các quy tắc thương mại. |
| URL rewrites và nội dung CMS | Duy trì SEO và khả năng truy cập từ tìm kiếm, đồng thời kiểm soát thời điểm campaign, nội dung theo lịch và phê duyệt nội dung ở cấp doanh nghiệp. |
| Extensions và dữ liệu tùy chỉnh | Rà soát phạm vi xử lý riêng khi modules hoặc hệ thống bên ngoài sở hữu dữ liệu quan trọng đối với hoạt động kinh doanh. |
Cách phân biệt này giúp nội dung về Adobe Commerce giữ đúng trọng tâm. Adobe Commerce không chỉ là “Magento có nhiều tính năng hơn”. Đây là Nền tảng đích mà mô hình dữ liệu Magento thường phải phục vụ thêm các yêu cầu quản trị doanh nghiệp.
Phạm vi storefront và cấu trúc kinh doanh
Các quyết định về phạm vi trong Adobe Commerce cần được đưa ra sớm vì chúng có thể thay đổi cách dữ liệu sau chuyển đổi hoạt động. Doanh nghiệp có thể dùng các websites riêng cho từng thương hiệu, quốc gia, đơn vị kinh doanh, kênh B2B và B2C, base currency, ngữ cảnh thuế hoặc phạm vi tài khoản Customers. Stores có thể kiểm soát cách catalog được điều hướng qua root Categories. Store views thường được dùng cho ngôn ngữ và phần hiển thị bản địa hóa.
Cửa hàng nguồn không phải lúc nào cũng tách các khái niệm này theo cùng cách. Một Nền tảng nguồn có thể lưu giá trị theo ngôn ngữ trong translation plugin, thương hiệu trong Categories, giá theo khu vực trong các trường tùy chỉnh, quyền nhìn thấy catalog của Customers trong app và quyền B2B trong một hệ thống riêng. Nếu các giá trị đó được di chuyển mà chưa xác định cách phân phạm vi trong Adobe Commerce, kết quả có thể trông đầy đủ nhưng vẫn sai về cách kinh doanh vận hành.
Khi xác định phạm vi, cần trả lời những câu hỏi thực tế:
| Câu hỏi về phạm vi | Vì sao quan trọng |
|---|---|
| Những websites nào sẽ được dùng khi chính thức vận hành? | Cấu trúc website có thể ảnh hưởng đến cách tách tài khoản, ngữ cảnh thương mại, currency và cấu hình. |
| Stores và root Categories nào phục vụ từng storefront? | Cách điều hướng và tổ chức catalog có thể khác nhau theo dòng kinh doanh hoặc khu vực. |
| Store views nào cần giá trị bản địa hóa? | Tên và mô tả Products, URLs, metadata, CMS Pages và Blog Posts có thể cần xử lý riêng theo ngôn ngữ. |
| Giá trị nào dùng chung và giá trị nào có phạm vi riêng? | Cơ chế kế thừa sai có thể ghi đè nội dung bản địa hóa hoặc dữ liệu riêng cho từng mô hình kinh doanh. |
| Cấu trúc nào ở Nền tảng nguồn không thực sự tương ứng với phạm vi Adobe Commerce? | Categories, tags, nhóm Customers hoặc các trường tùy chỉnh có thể bị hiểu nhầm thành websites hoặc store views. |
Không nên để toàn bộ bản ghi rơi vào phạm vi mặc định chỉ vì chưa có quyết định, trừ khi doanh nghiệp đã chủ động chọn cấu trúc đó.
Quản trị catalog bắt đầu từ ý nghĩa của Products
Quản trị catalog trong Adobe Commerce bắt đầu từ việc xác định đúng ý nghĩa của từng bản ghi Products. Simple, Configurable, Grouped, Bundle, Virtual, Downloadable và Gift Card Products có thể kéo theo các yêu cầu chuyển đổi khác nhau. Configurable Products đặc biệt quan trọng vì bản ghi Products cha hiển thị cho khách hàng và các Simple Products liên kết phải giữ đúng ý nghĩa về SKU, option, price, image và inventory để cả người mua lẫn đội ngũ quản trị có thể sử dụng.
Attributes và attribute sets cũng cần được quản trị rõ ràng. Attributes có thể phục vụ trang chi tiết Products, search, layered navigation, so sánh Products, promotions, báo cáo hoặc hoạt động của các tích hợp. Trong môi trường doanh nghiệp, một attribute được di chuyển sai không chỉ tạo ra dữ liệu thừa trên giao diện. Điều này có thể làm giảm khả năng tìm Products của người mua, gây lệch dữ liệu với PIM, mất liên kết tham chiếu với ERP, làm sai báo giá, ảnh hưởng dữ liệu xuất sang marketplace hoặc tăng khó khăn cho công việc bảo trì nội bộ.
Kế hoạch catalog cần phân biệt dữ liệu phục vụ hiển thị với dữ liệu phục vụ vận hành:
| Loại trường ở nguồn | Câu hỏi cần giải quyết trong Adobe Commerce |
|---|---|
| Thông số kỹ thuật của Products | Giá trị này cần hiển thị cho khách hàng, tham gia search, filtering, so sánh hay chỉ dùng nội bộ? |
| Options tạo biến thể | Giá trị này nên tạo Configurable Products hay một cấu trúc Products khác? |
| Cờ giá hoặc availability dành cho B2B | Chúng thuộc shared catalogs, nhóm Customers, quy tắc tùy chỉnh hay hệ thống bên ngoài? |
| IDs từ ERP/PIM/marketplace | Nên đưa vào trường được hỗ trợ, giữ lại bằng mapping hoặc điều chỉnh cấu hình được hỗ trợ, hay cần xử lý ngoài chuẩn? |
| Attributes cũ hoặc trùng lặp | Nên làm sạch, hợp nhất, loại bỏ hay giữ lại để tra cứu lịch sử? |
Mục tiêu của chuyển đổi sang Adobe Commerce không phải đưa sang càng nhiều các trường càng tốt. Mục tiêu là giữ những các trường thực sự hỗ trợ mô hình quản trị catalog của Cửa hàng đích.
B2B company accounts và quan hệ người mua
B2B thường là điểm phân biệt rõ nhất giữa Adobe Commerce và Magento Open Source. Company accounts có thể bao gồm company administrators, users, roles, permissions, company credit, hành vi Purchase Orders, quyền sử dụng quotes, giới hạn phương thức thanh toán và vận chuyển, cùng quan hệ với shared catalogs. Những cấu trúc này làm thay đổi ý nghĩa của Di chuyển Customers.
Một bản ghi Customers ở nguồn không mặc nhiên tương đương với một company account. Một nhóm Customers wholesale không mặc nhiên tương đương với hệ thống phân cấp buyers. Một dealer price list không mặc nhiên là shared catalog. Một trường sales representative cũng không mặc nhiên tương ứng với cách gán company của Adobe Commerce. Các khác biệt này cần được làm rõ trước khi chấp nhận phạm vi chuyển đổi.
Khi lập kế hoạch B2B cho Adobe Commerce, nên chuẩn bị các trường hợp đại diện:
| Ví dụ B2B | Giá trị đối với quá trình chuyển đổi |
|---|---|
| Company có một administrator và nhiều buyers | Kiểm tra kỳ vọng về hệ thống phân cấp tài khoản và quan hệ giữa users. |
| Company được gán pricing hoặc khả năng xem Products riêng | Kiểm tra tác động của shared catalog hoặc nhóm Customers. |
| Bản ghi Customers tham gia quy trình quote hoặc Purchase Orders | Làm rõ phần nào cần cấu hình ở Cửa hàng đích và những gì phải xác thực. |
| Company có credit hoặc bị giới hạn phương thức thanh toán/vận chuyển | Tách dữ liệu lịch sử khỏi thiết lập thương mại đang hoạt động. |
| Bản ghi B2B ở nguồn do các trường tùy chỉnh hoặc CRM/ERP bên ngoài quản lý | Xác định nhu cầu rà soát phạm vi riêng hoặc các tích hợp. |
Chất lượng chuyển đổi B2B không được chứng minh bằng số lượng bản ghi Customers. Kết quả chỉ đạt yêu cầu khi người mua có thể đăng nhập, thấy đúng catalog và giá, sử dụng đúng permissions và tiếp tục quy trình mua hàng mà doanh nghiệp yêu cầu sau khi chính thức vận hành.
Content Staging, merchandising và thời điểm triển khai
Content Staging của Adobe Commerce có thể làm thay đổi cách đội ngũ lập kế hoạch cho thời điểm chính thức vận hành. Products, Categories, cart price rules, catalog price rules, CMS Pages, CMS Blocks và widgets có thể nằm trong các thay đổi merchandising hoặc campaign được lên lịch. Quá trình chuyển đổi không nên giả định rằng việc đưa nội dung sang Cửa hàng đích sẽ tự động tái tạo cách campaign được lập lịch và quản trị.
Cửa hàng nguồn có thể có promotions theo lịch, landing pages theo mùa, Products dự kiến ra mắt trong tương lai, campaign banners hoặc các phiên bản nội dung được quản lý bằng apps hay quy trình biên tập. Kế hoạch chuyển đổi cần phân loại những kỳ vọng đó. Có nội dung nên được di chuyển dưới dạng bản ghi. Có nội dung cần được xây dựng lại hoặc lập lịch trong Adobe Commerce. Một số trường hợp cần rà soát thủ công vì quy trình ở nguồn không có cấu trúc tương đương trực tiếp trên Cửa hàng đích.
Vì vậy, kế hoạch triển khai cần tách rõ:
| Nội dung hoặc hạng mục merchandising | Cách xử lý khi lập kế hoạch |
|---|---|
| CMS Pages và Blog Posts thông thường | Di chuyển khi được hỗ trợ và xác thực nội dung, URLs cùng metadata. |
| Promotions theo lịch | Xác định quy tắc có được di chuyển hay cần thiết lập ở Cửa hàng đích hoặc xây dựng lại campaign thủ công. |
| Landing pages theo mùa | Xác thực khả năng truy cập URL, content blocks, media và thời điểm đưa lên. |
| Nội dung do Page Builder hoặc app quản lý | Rà soát xem thuộc phạm vi được hỗ trợ, cần xây dựng lại thủ công hay cần xử lý ngoài chuẩn. |
| Quản trị campaign | Xem đây là phần lập kế hoạch quy trình ở Cửa hàng đích, không chỉ là chuyển dữ liệu. |
Content Staging chỉ mang lại giá trị khi doanh nghiệp chủ động sử dụng đúng mục đích. Điều này trở thành rủi ro nếu đội ngũ mặc định rằng cách lập lịch ở nguồn cũng đã được chuyển chỉ vì các bản ghi nội dung xuất hiện ở Cửa hàng đích.
Tích hợp và quyền sở hữu dữ liệu ở cấp doanh nghiệp
Các dự án chuyển đổi sang Adobe Commerce thường phụ thuộc vào những hệ thống nằm ngoài storefront. ERP có thể sở hữu Products IDs, tài khoản Customers, invoices hoặc inventory. PIM có thể sở hữu attributes và nội dung Products. CRM có thể sở hữu quan hệ giữa companies hoặc cách gán sales representative. Hệ thống thuế và vận chuyển có thể quyết định hành vi ở checkout. Marketplace, analytics, loyalty, subscription hoặc công cụ marketing cũng có thể sở hữu những bản ghi nhìn giống dữ liệu thương mại nhưng không thực sự thuộc dữ liệu gốc của nền tảng.
Kế hoạch chuyển đổi cần xác định hệ thống sở hữu dữ liệu trước khi quyết định cách xử lý. Nếu Nền tảng nguồn chỉ hiển thị một giá trị do hệ thống khác sở hữu, việc di chuyển trường hiển thị đó chưa chắc giữ được quy trình kinh doanh. Nếu dữ liệu được tạo bởi module, bản export chuẩn có thể không chứa dữ liệu đó. Nếu các tích hợp tùy chỉnh ghi dữ liệu vào các trường riêng, những giá trị này có thể cần rà soát phạm vi ngoài chuẩn hoặc công việc triển khai riêng.
Có thể phân loại yêu cầu theo cách sau:
| Yêu cầu | Cách phân loại phù hợp hơn |
|---|---|
| Bản ghi được hỗ trợ cần thay đổi cách filtering hoặc mapping | Lập kế hoạch rõ cho filtering hoặc mapping cần dùng. |
| Bản ghi được hỗ trợ phụ thuộc vào cách cấu hình ở đích | Tách cách xử lý trong di chuyển dữ liệu khỏi phần cấu hình Cửa hàng đích. |
| Cần giữ dữ liệu do extension hoặc app sở hữu | Cần rà soát phạm vi ngoài chuẩn. |
| External identifiers phải tiếp tục hoạt động | Cần rà soát phạm vi xử lý riêng hoặc các tích hợp. |
| Các tích hợp đang hoạt động cần được kết nối lại sau chuyển đổi | Đây là công việc triển khai ở Cửa hàng đích, không thể hoàn thành chỉ bằng việc di chuyển dữ liệu. |
Adobe Commerce cho phép doanh nghiệp xây dựng mô hình vận hành phức tạp, nhưng mức linh hoạt đó chỉ có ích khi quyền sở hữu dữ liệu và trách nhiệm với các tích hợp được xác định rõ.
Kết luận
Kế hoạch chuyển đổi sang Adobe Commerce cần bắt đầu từ mô hình vận hành doanh nghiệp mà Cửa hàng đích phải hỗ trợ. Products, hồ sơ Customers, Orders, Categories, CMS Pages, Blog Posts và URLs vẫn quan trọng, nhưng chỉ là một phần của toàn bộ bài toán. Kế hoạch còn phải tính đến B2B company accounts, shared catalogs, phạm vi storefront, quan hệ Configurable Products, attributes và attribute sets, Content Staging, các tích hợp, custom modules và trách nhiệm xác thực.
Một dự án chuyển đổi sang Adobe Commerce được chuẩn bị tốt không phải là dự án chuyển được nhiều dữ liệu nhất. Đó là một quá trình có kiểm soát, trong đó dữ liệu đã di chuyển, cấu hình ở Cửa hàng đích, phạm vi di chuyển dữ liệu đã được chấp nhận và hoạt động xác thực của doanh nghiệp cùng hỗ trợ đúng mô hình thương mại sau khi chính thức vận hành.
Câu hỏi thường gặp
Kế hoạch chuyển đổi sang Adobe Commerce khác Magento Open Source ở điểm nào?
Adobe Commerce dùng chung nền tảng kiến trúc Magento, nhưng kế hoạch thường cần chú ý nhiều hơn đến các cấu trúc doanh nghiệp như B2B company accounts, shared catalogs, quy trình quote và Purchase Orders, Content Staging, quản trị và các tích hợp.
Mọi dự án chuyển đổi sang Adobe Commerce đều cần lập kế hoạch B2B không?
Không phải mọi dự án đều cần. Một số cửa hàng Adobe Commerce chủ yếu phục vụ B2C hoặc hoạt động dựa nhiều vào nội dung. Lập kế hoạch B2B trở nên quan trọng khi doanh nghiệp có company accounts, wholesale buyers, dealer pricing, quy trình mua hàng có hỗ trợ từ sales, quotes hoặc quyền truy cập catalog riêng theo tài khoản.
Vì sao phạm vi storefront quan trọng khi chuyển sang Adobe Commerce?
Phạm vi website, store và store view có thể ảnh hưởng đến cách Products được gán vào catalog, nội dung bản địa hóa, URLs, currency, cấu hình và ngữ cảnh người mua. Dữ liệu được đưa vào sai phạm vi có thể khiến Cửa hàng đích trông đầy đủ nhưng hoạt động không đúng.
Nên xử lý dữ liệu tùy chỉnh của Adobe Commerce như thế nào?
Các điều chỉnh mapping hoặc configuration được hỗ trợ có thể xử lý nhu cầu filtering, mapping hoặc cấu hình trong phạm vi giới hạn. Dữ liệu extension không được hỗ trợ, các trường tùy chỉnh, identifiers từ hệ thống bên ngoài, transformations riêng và quy tắc B2B hoặc các tích hợp phức tạp cần được rà soát phạm vi ngoài chuẩn.
Sau representative test của Adobe Commerce, nên xác thực gì trước?
Nên bắt đầu với các mẫu đại diện cho catalog, phạm vi storefront, Customers, companies, shared catalogs, URLs và những trường hợp phụ thuộc vào các tích hợp. Mục tiêu là chứng minh các bản ghi sau chuyển đổi hỗ trợ đúng hành vi của Adobe Commerce, không chỉ đối chiếu số lượng.