Lựa chọn phương án thực hiện chuyển đổi phù hợp cho Adobe Commerce

Lựa chọn phương án thực hiện chuyển đổi phù hợp cho Adobe Commerce là quyết định về mô hình vận hành, không chỉ là bài toán đếm bản ghi. Adobe Commerce có thể kết hợp Configurable Products, nhiều websites, stores và store views, B2B company accounts, shared catalogs, pricing riêng theo company, nhóm Customers, content theo lịch, custom attributes, các tích hợp và dữ liệu do extensions sở hữu. Phương án dịch vụ phải phân biệt rõ cấu trúc nào thuộc dữ liệu được hỗ trợ theo cách thông thường, phần nào cần cấu hình riêng trên Nền tảng đích, yêu cầu nào có thể xử lý bằng Add-ons trong phạm vi hỗ trợ và yêu cầu nào cần được đánh giá riêng theo Custom Service.

Một dự án chuyển đổi sang Adobe Commerce lớn không mặc nhiên cần Dịch vụ chuyển đổi dữ liệu phức tạp nhất. Standard Service vẫn có thể phù hợp khi lộ trình chuyển đổi được hỗ trợ, dữ liệu nguồn dùng các cấu trúc có thể nhận diện rõ và khách hàng có thể tự vận hành cũng như xác thực dịch vụ. Managed Service phù hợp hơn khi khối lượng điều phối và xác thực lớn. Add-ons xử lý các nhu cầu cụ thể về lọc bản ghi được hỗ trợ, biến đổi giá trị trường hoặc chuyển trường nguồn sang trường đích khác. Custom Service là hướng cần xem xét khi kết quả yêu cầu phụ thuộc vào dữ liệu chưa được hỗ trợ, custom modules, cách biến đổi riêng, cấu trúc B2B không tiêu chuẩn, identifiers của hệ thống bên ngoài hoặc quy tắc di chuyển dữ liệu tùy chỉnh.

Khi lựa chọn Dịch vụ chuyển đổi dữ liệu của Next-Cart, các thông tin này giúp phân biệt phạm vi được hỗ trợ, trách nhiệm thực hiện, nhu cầu Add-ons có giới hạn rõ và những yêu cầu Adobe Commerce cần xử lý theo phạm vi tùy chỉnh.

Bắt đầu từ mô hình vận hành Adobe Commerce

Dự án chuyển đổi sang Adobe Commerce nên được phân loại theo mô hình vận hành mà Nền tảng đích cần hỗ trợ. Một cửa hàng B2C đơn thương hiệu với một website và Products có cấu trúc thông thường tạo ra quyết định chuyển đổi rất khác với một hệ thống doanh nghiệp có nhiều websites, store views theo khu vực, company accounts, shared catalogs, pricing riêng theo người mua và kết nối chặt với ERP hoặc PIM.

Adobe Commerce sử dụng hệ thống phân cấp website, store và store view. Websites có thể có domain và phạm vi checkout riêng. Stores có thể dùng root Categories và catalog riêng. Store views thường phục vụ khác biệt về ngôn ngữ hoặc cách trình bày. B2B shared catalogs có thể kiểm soát Products và mức giá mà từng company được phép xem. Đây là kiến trúc của Nền tảng đích, không chỉ là các nhãn gắn vào bản ghi được di chuyển.

Phương án chuyển đổi chỉ nên được chọn sau khi mô hình này đã được ghi nhận rõ. Nếu không, một dự án có thể bị xác định như việc chuyển catalog tiêu chuẩn trong khi doanh nghiệp thực tế kỳ vọng các hoạt động B2B và mô hình nhiều storefront tự động vận hành sau khi dữ liệu được chuyển.

Khi Standard Service là lựa chọn phù hợp

Standard Service phù hợp khi lộ trình chuyển đổi từ Nền tảng nguồn sang Adobe Commerce được hỗ trợ, dữ liệu có thể truy cập qua phương thức kết nối được hỗ trợ và đầu ra cần thiết nằm trong phạm vi xử lý tiêu chuẩn. Với Dịch vụ chuyển đổi dữ liệu này của Next-Cart, khách hàng chịu trách nhiệm chuẩn bị, cung cấp thông tin kết nối, lựa chọn cấu hình, quyết định thực hiện và xác thực kết quả.

Một dự án phù hợp với Standard Service thường có:

• phạm vi Products, Customers, Orders và content rõ ràng;
• các loại Products và quan hệ biến thể có thể nhận diện;
• SKUs và identifiers của Products nhất quán;
• Categories, attributes và giá trị attributes dễ hiểu;
• bản ghi Customers và địa chỉ theo cấu trúc thông thường;
• lịch sử đơn hàng không phụ thuộc vào ngữ cảnh ẩn trong hệ thống bên ngoài;
• website, store và store view đích đã được xác định;
• không kỳ vọng extensions, B2B modules hoặc các tích hợp được xây dựng lại chỉ thông qua việc di chuyển bản ghi tiêu chuẩn;
• đội ngũ có thể rà soát chi tiết kết quả Demo Migration và Di chuyển toàn bộ.

Không nên loại Standard Service chỉ vì catalog lớn. Khối lượng bản ghi được xác định qua Entity Points Plan đã chọn. Câu hỏi quan trọng hơn là dữ liệu có còn nằm trong cấu trúc được hỗ trợ hay không và khách hàng có thể tự xác thực kết quả hay không.

Standard Service trở nên kém phù hợp khi Products phụ thuộc vào custom types, company pricing nằm ngoài cấu trúc B2B có thể nhận diện, external identifiers quyết định việc xử lý đơn hàng hoặc doanh nghiệp kỳ vọng cấu hình Nền tảng đích và triển khai modules tự động đi theo dữ liệu được chuyển.

Khi Managed Service an toàn hơn

Managed Service phù hợp khi phần lớn yêu cầu vẫn nằm trong phạm vi được hỗ trợ nhưng khách hàng cần chuyên gia Next-Cart thực hiện các lần chạy di chuyển dữ liệu và điều phối công việc theo kế hoạch. Cách này có thể giảm áp lực vận hành cho dự án có catalog lớn, nhiều nhóm nghiệp vụ, khung thời gian go-live chặt hoặc khối lượng xác thực đáng kể.

Managed Service thường an toàn hơn khi:

• khối lượng catalog, Customers và Orders tạo ra nhiều công việc rà soát;
• nhiều websites, stores hoặc store views cần được các chủ sở hữu khác nhau xác thực;
• các nhóm nghiệp vụ cần một lịch di chuyển dữ liệu được điều phối;
• các bên phụ trách B2B, khu vực hoặc kênh bán phải duyệt dữ liệu đại diện;
• dữ liệu nguồn có thể hiểu được nhưng thiếu nhất quán và cần rà soát vận hành cẩn thận;
• doanh nghiệp không đủ tự tin để tự quản lý cấu hình và thực hiện di chuyển dữ liệu;
• khung thời gian go-live cần theo dõi vấn đề và chuyển cấp xử lý có kiểm soát.

Managed Service không tự động mở rộng những gì nền tảng hỗ trợ theo tiêu chuẩn. Dịch vụ này thay đổi trách nhiệm thực hiện và điều phối di chuyển dữ liệu. Nếu kết quả cần cấu trúc company chưa được hỗ trợ, dữ liệu custom modules, cách biến đổi riêng hoặc quan hệ ngoài hệ thống không tiêu chuẩn, các yêu cầu đó vẫn có thể cần Custom Service.

Nguyên tắc hữu ích là tách khối lượng công việc thực hiện khỏi khối lượng tùy chỉnh. Managed Service giải quyết phần thứ nhất. Custom Service giải quyết phần thứ hai. Một số dự án doanh nghiệp có thể cần cả việc thực hiện theo Managed Service và phạm vi tùy chỉnh được thống nhất riêng.

Add-ons phù hợp ở đâu

Add-ons phù hợp khi phần chính của di chuyển dữ liệu vẫn theo cách tiêu chuẩn nhưng một nhu cầu có giới hạn rõ trong phạm vi hỗ trợ cần thay đổi đầu ra. Với Adobe Commerce, các kiểm soát liên quan gồm lọc bản ghi theo điều kiện dựa trên trường cho từng loại dữ liệu, dùng biểu thức để biến đổi giá trị trường và chuyển trường nguồn sang trường đích khác.

Ví dụ với Adobe Commerce có thể gồm:

• dùng điều kiện trên các trường của Products để loại Products ngừng hoạt động hoặc không còn cần thiết;
• dùng điều kiện trên các trường của Customers hoặc Orders để loại Customers thử nghiệm hoặc Orders cũ không còn cần trong phạm vi;
• dùng biểu thức để biến đổi giá trị trường được hỗ trợ trong quá trình di chuyển dữ liệu;
• chuyển các trường nguồn tiêu chuẩn được hỗ trợ của Products, Categories, Customers hoặc Orders sang các trường đích tương thích được hỗ trợ mà không thay đổi giá trị;
• giữ lại content hoặc thông tin liên quan đến SEO khi lộ trình chuyển đổi hỗ trợ;
• sử dụng Data Filter, Advanced Data Mapping hoặc Data Transformation cho một nhu cầu được hỗ trợ và xác định rõ.

Không nên dùng Add-ons như một nhãn chung cho mọi yêu cầu phức tạp trên Adobe Commerce. Chuyển một trường được hỗ trợ sang vị trí khác hoàn toàn khác với trích xuất dữ liệu từ custom B2B module. Lọc Orders cũ bằng điều kiện trên trường của Orders cũng khác với xây dựng lại quy trình phê duyệt cho company. Trường hợp đầu có thể phù hợp với Add-on; trường hợp sau cần Custom Service đánh giá hoặc cần triển khai riêng trên Nền tảng đích.

Ranh giới nằm ở việc yêu cầu có còn thuộc cách xử lý di chuyển dữ liệu được hỗ trợ hay không. Nếu có, Add-on có thể đủ. Nếu cần trích xuất, biến đổi, quy tắc xử lý hoặc xác định quyền sở hữu theo cách không tiêu chuẩn, yêu cầu đó thuộc phạm vi Custom Service cần đánh giá.

Khi nào nên cân nhắc Custom Service

Custom Service nên được cân nhắc khi kết quả cần thiết không thể đạt được chỉ bằng dữ liệu tiêu chuẩn được hỗ trợ và Add-ons có phạm vi giới hạn. Với Adobe Commerce, nhu cầu này thường xuất hiện từ hệ sinh thái extensions, cấu trúc B2B, nhiều storefront và sự phụ thuộc vào hệ thống bên ngoài.

Các dấu hiệu thường cần chuyển sang đánh giá Custom Service gồm:

• custom types của Products hoặc quan hệ do modules tạo;
• custom attributes cần biến đổi riêng cho Nền tảng đích;
• company accounts, company users, shared catalogs hoặc negotiated pricing được lưu trong cấu trúc không tiêu chuẩn;
• các trường tùy chỉnh trong checkout hoặc dữ liệu Orders nằm trong extension tables;
• identifiers từ ERP, PIM, OMS, WMS, CRM, tax hoặc hệ thống xử lý đơn hàng cần được giữ ở một trường đích cụ thể;
• quy tắc phân bổ website/store/store view riêng;
• dữ liệu chưa được hỗ trợ từ modules về marketplace, subscription, loyalty, quoting, approval hoặc returns;
• custom database columns, APIs hoặc tables của các tích hợp;
• Custom Platform ở một trong hai đầu lộ trình chuyển đổi;
• yêu cầu làm thay đổi quy tắc xử lý di chuyển dữ liệu tiêu chuẩn.

Custom Service không tự động bao gồm phát triển Adobe Commerce modules, cài đặt extensions, cấu hình B2B, thiết lập shared catalogs, tạo websites hoặc store views, triển khai theme, cấu hình payment hoặc shipping, triển khai các tích hợp hay xây dựng lại toàn bộ Cửa hàng đích. Những trách nhiệm này chỉ được bao gồm khi được thống nhất rõ trong phạm vi dịch vụ.

Entity Points và xác định phạm vi doanh nghiệp

Entity Points tạo khung dung lượng cho các bản ghi đủ điều kiện được di chuyển. Với những lần xử lý Adobe Commerce sau đó, các bản ghi đủ điều kiện đã được tính vẫn chỉ được tính một lần trên cùng lộ trình chuyển đổi; độ phức tạp của websites, store views, B2B và extensions được đánh giá riêng. Categories, attributes, companies, shared catalogs, websites, store views, các trường tùy chỉnh, modules và external identifiers có thể làm tăng độ phức tạp nhưng không trở thành các loại bản ghi Entity Points riêng.

Sự khác biệt này đặc biệt quan trọng với Adobe Commerce. Hai dự án có thể dùng cùng Entity Points Plan nhưng cần phương án dịch vụ rất khác nhau. Một catalog lớn với Products thông thường có thể phù hợp với Standard Service. Một catalog nhỏ hơn có thể cần Custom Service nếu mọi Products đều phụ thuộc vào custom attributes, company-specific pricing hoặc identifiers do các tích hợp kiểm soát.

Trong các hoạt động Adobe Commerce sau đó, các bản ghi đủ điều kiện đã được tính trên cùng lộ trình chuyển đổi không tiêu thụ Entity Points thêm chỉ vì có một hành động di chuyển dữ liệu khác. Products, Customers, Orders hoặc Blog Posts mới đủ điều kiện có thể tiêu thụ Entity Points khi được di chuyển lần đầu.

Việc lập kế hoạch Entity Points cần trả lời:

Entity Points giúp xác định quy mô di chuyển dữ liệu. Chúng không chứng minh các yêu cầu B2B, nhiều storefront, extensions hoặc các tích hợp nằm trong phạm vi được hỗ trợ.

Demo Migration cần chứng minh điều gì

Demo Migration nên kiểm tra quyết định về phương án dịch vụ bằng cả bản ghi đại diện và trường hợp phức tạp. Chỉ chọn Products đơn giản có thể tạo cảm giác an toàn sai lệch trong một dự án chuyển đổi sang Adobe Commerce.

Bộ dữ liệu nên bao gồm, khi có liên quan:

• Simple, Configurable, Bundle, Grouped, Virtual hoặc Downloadable Products;
• Products có attributes phức tạp và giá trị riêng theo store view;
• Categories được dùng bởi các stores hoặc root catalogs khác nhau;
• Customers thuộc nhóm quan trọng hoặc ngữ cảnh company;
• Orders có discounts, taxes, refunds, statuses bất thường hoặc external identifiers;
• CMS Pages, Blog Posts và dữ liệu nhạy với URL cần ưu tiên;
• dữ liệu chịu ảnh hưởng của extensions hoặc các tích hợp;
• trường hợp từ từng website, store hoặc store view quan trọng với go-live.

Demo Migration cần trả lời bốn câu hỏi:

1. Dữ liệu tiêu chuẩn có được thể hiện đúng không?
2. Quan hệ theo phạm vi storefront và B2B có còn đúng ý nghĩa không?
3. Khoảng trống nào có thể xử lý bằng cấu hình được hỗ trợ hoặc Add-ons?
4. Khoảng trống nào cần Custom Service hoặc triển khai riêng trên Nền tảng đích?

Demo Migration đạt yêu cầu không chỉ là đối chiếu số lượng bản ghi. Kết quả phải tạo cơ sở để xác nhận phương án dịch vụ đã chọn đủ phù hợp trước Di chuyển toàn bộ. Nếu dữ liệu đại diện cho thấy cấu trúc chưa được hỗ trợ hoặc quyền sở hữu bị ẩn, phương án cần được điều chỉnh trước khi thực hiện toàn bộ phạm vi.

Chọn phương án cho lần di chuyển dữ liệu tiếp theo với Adobe Commerce

Phương án cho lần di chuyển dữ liệu tiếp theo hỗ trợ các hoạt động di chuyển dữ liệu về sau khi nguồn vẫn tiếp tục hoạt động, cấu hình đích thay đổi hoặc doanh nghiệp cần một kết quả di chuyển dữ liệu khác. Hành động được chọn phải dựa trên việc cấu hình đã được chấp nhận trước đó còn phù hợp hay không.

Các hành động này không tự động triển khai Adobe Commerce modules, shared catalogs, company permissions, các tích hợp bên ngoài, themes hoặc cấu hình Nền tảng đích. Chúng hoạt động trong phạm vi Dịch vụ chuyển đổi dữ liệu đã được thống nhất và giữ nguyên lộ trình chuyển đổi từ Nền tảng nguồn sang Nền tảng đích đã mua. Nếu cần thay đổi Nền tảng nguồn hoặc Nền tảng đích, doanh nghiệp phải mua một Dịch vụ chuyển đổi dữ liệu riêng cho lộ trình khác.

Chốt phương án dịch vụ

Phương án Adobe Commerce tốt nhất là lựa chọn nhẹ nhất nhưng vẫn có thể giữ đúng ý nghĩa nghiệp vụ cần thiết và tạo ra kết quả mà doanh nghiệp có thể xác thực một cách rõ ràng.

Quyết định nên được ghi lại trước Di chuyển toàn bộ và xác nhận bằng kết quả Demo Migration. Dự án không nên nâng cấp dịch vụ chỉ vì Adobe Commerce là nền tảng doanh nghiệp, nhưng cũng không nên giữ phương án nhẹ khi kết quả đích đã được chấp nhận phụ thuộc vào cấu trúc doanh nghiệp chưa được hỗ trợ.

Kết luận

Lựa chọn phương án chuyển đổi cho Adobe Commerce phụ thuộc vào quan hệ giữa phạm vi dữ liệu, mô hình vận hành doanh nghiệp, trách nhiệm thực hiện và mức độ tùy chỉnh. Standard Service có thể xử lý lộ trình chuyển đổi sạch và nằm trong phạm vi hỗ trợ. Managed Service phù hợp khi khối lượng điều phối và xác thực lớn. Add-ons xử lý nhu cầu có giới hạn trong phạm vi hỗ trợ. Custom Service dành cho yêu cầu tùy chỉnh và không tiêu chuẩn.

Quyết định cuối cùng cần tính đến hệ thống website, store và store view; các loại Products; B2B companies và shared catalogs; hệ thống bên ngoài; Entity Points; và kết quả từ Demo Migration. Sau đó, các lựa chọn cho lần di chuyển dữ liệu tiếp theo nên được chọn dựa trên việc cấu hình đã được chấp nhận còn phù hợp, cần điều chỉnh hay cần tạo một kết quả di chuyển dữ liệu mới.

Câu hỏi thường gặp

Catalog Adobe Commerce lớn có thể dùng Standard Service không?

Catalog lớn vẫn có thể dùng Standard Service nếu lộ trình chuyển đổi được hỗ trợ, cấu trúc Products có thể nhận diện rõ và khách hàng có thể tự thực hiện cũng như xác thực dịch vụ. Entity Points xác định dung lượng bản ghi đủ điều kiện, còn độ phức tạp cấu trúc được đánh giá riêng.

Khi nào Managed Service phù hợp hơn với Adobe Commerce?

Managed Service phù hợp khi di chuyển dữ liệu vẫn nằm trong cách xử lý được hỗ trợ nhưng khối lượng thực hiện, điều phối hoặc xác thực lớn. Điều này đặc biệt hữu ích với dự án có nhiều nhóm tham gia, nhiều phạm vi storefront, khối lượng rà soát lớn hoặc lịch go-live chặt.

Add-ons có xử lý custom Adobe Commerce modules không?

Add-ons không phải giải pháp chung cho custom modules. Add-ons phục vụ nhu cầu có giới hạn trong cách xử lý di chuyển dữ liệu được hỗ trợ. Dữ liệu nằm trong custom modules, extension tables, cấu trúc B2B riêng hoặc hệ thống bên ngoài thường cần Custom Service đánh giá.

Demo Migration cần chứng minh gì với Adobe Commerce?

Demo Migration cần chứng minh Products, Customers, Orders, content, phạm vi store, quan hệ B2B, URLs và các trường liên kết với các tích hợp vẫn giữ đúng ý nghĩa trong các trường hợp đại diện. Kết quả cũng cần cho thấy khoảng trống nào thuộc cấu hình, Add-ons, Custom Service hoặc triển khai riêng trên Nền tảng đích.

Nên chọn phương án nào cho lần di chuyển dữ liệu tiếp theo?

Chọn Continue the di chuyển dữ liệu with the Last Used Configuration khi cấu hình đã được chấp nhận vẫn còn phù hợp; chọn Continue the di chuyển dữ liệu with a New Configuration khi các thiết lập được hỗ trợ cần thay đổi; và chọn Perform a Di chuyển New khi doanh nghiệp cần một kết quả di chuyển dữ liệu riêng cùng vòng xác thực đầy đủ.