Khi BigCommerce đã được chọn làm Nền tảng đích, phương án thực hiện chuyển đổi phù hợp phụ thuộc vào tỷ lệ dữ liệu ở Cửa hàng nguồn có thể được đưa vào các cấu trúc BigCommerce được hỗ trợ mà vẫn giữ đúng ý nghĩa kinh doanh. Catalog đơn giản có thể phù hợp với phương án tương đối trực tiếp. Ngược lại, catalog có nhiều variants, pricing được phân theo nhiều nhóm, mô hình multi-channel, các trường tùy chỉnh có yêu cầu xử lý vượt quá phạm vi mapping được hỗ trợ, bản ghi do app sở hữu, external identifiers hoặc kế hoạch redirects nhạy cảm với SEO có thể cần khâu chuẩn bị kỹ hơn, Add-ons, Managed Service hoặc xem xét Custom Service.
Không nên chọn Dịch vụ chuyển đổi dữ liệu chỉ dựa trên quy mô cửa hàng. Độ phức tạp của BigCommerce thường đến từ cách Products được cấu hình, pricing rules, channel assignments, yêu cầu vận hành theo storefront, cách phân nhóm Customers, các tích hợp và phần thiết lập ở hệ thống đích. Một cửa hàng lớn vẫn có thể theo phương án dễ quản lý nếu dữ liệu nằm trong phạm vi được hỗ trợ và có thể xác thực rõ ràng. Ngược lại, cửa hàng nhỏ vẫn có thể cần Custom Service nếu dữ liệu do app hoặc cấu trúc tùy chỉnh giữ vai trò quan trọng trong vận hành.
Khi lựa chọn Dịch vụ chuyển đổi dữ liệu của Next-Cart cho BigCommerce, kết quả rà soát dữ liệu thực tế cần cho biết phạm vi được hỗ trợ đã đủ hay chưa, dự án có cần đội ngũ chuyên môn thực hiện phần di chuyển dữ liệu hay không, và cấu trúc riêng của nền tảng có đòi hỏi Add-ons hoặc Custom Service hay không.
Phương án thực hiện chuyển đổi BigCommerce cần xác định những gì
Phương án cho BigCommerce là quyết định về phạm vi, trách nhiệm, mức hỗ trợ và mức độ xác thực cần thiết. Phương án phải xác định những bản ghi nào sẽ được di chuyển vào BigCommerce, cấu hình nào phải được thiết lập trực tiếp trên BigCommerce, yêu cầu điều chỉnh nào cần Add-ons, trường hợp nào cần Custom Service và những mẫu nào trong Demo Migration phải đạt yêu cầu trước Di chuyển toàn bộ.
| Loại công việc | Trường hợp trên BigCommerce | Ảnh hưởng đến lựa chọn dịch vụ |
|---|---|---|
| Bản ghi nằm trong phạm vi được hỗ trợ | Products, Categories, Customers, Orders, images, content pages, redirects và các trường liên quan được hỗ trợ. | Có thể phù hợp với Standard Service hoặc Managed Service tùy trách nhiệm thực hiện và nhu cầu xác thực. |
| Điều chỉnh trong phạm vi được hỗ trợ | Dữ liệu Products, Customers, Orders, content hoặc redirects cần điều kiện theo từng loại dữ liệu, biểu thức biến đổi giá trị hoặc trường đích khác. | Có thể cần Data Filter, Advanced Data Mapping hoặc Data Transformation. |
| Yêu cầu tùy chỉnh hoặc chưa được hỗ trợ | Dữ liệu do app sở hữu, trường tùy chỉnh chưa được hỗ trợ và cần diễn giải ngoài tiêu chuẩn, mã định danh bên ngoài, quy tắc định giá thiết kế riêng, dữ liệu feed hoặc phép biến đổi đặc thù. | Cần xem xét Custom Service. |
| Thiết lập ở hệ thống đích | Storefront theme, checkout settings, payment setup, tax rules, shipping settings, apps, channels và các tích hợp đang hoạt động. | Cần được cấu hình và kiểm thử trên BigCommerce, không nên được xem như bản ghi sẽ tự di chuyển. |
Phương án phù hợp phải tránh hai sai lầm đối lập: chọn mức hỗ trợ quá thấp cho dữ liệu kinh doanh phức tạp, hoặc đẩy mọi chi tiết riêng của nền tảng sang Custom Service dù Add-on được hỗ trợ hay một đầu việc cấu hình ở hệ thống đích đã đủ giải quyết.
Khi Standard Service có thể đáp ứng dự án
Standard Service có thể phù hợp khi phạm vi BigCommerce nằm trong phần được hỗ trợ, dữ liệu nguồn sạch và doanh nghiệp có thể chuẩn bị đầu vào cũng như tự xác thực kết quả. Trường hợp này thường có Products, Categories, Customers, Orders, images, pages, redirects và các trường liên quan có thể được di chuyển mà không cần transformation thiết kế riêng hoặc xử lý dữ liệu app chưa được hỗ trợ.
Standard Service phù hợp nhất khi lựa chọn Products đơn giản hoặc đã được phân loại rõ, pricing không phân tầng quá phức tạp, kỳ vọng về channels hạn chế, dữ liệu Customers chủ yếu theo cấu trúc thông thường và doanh nghiệp có thể rà soát các mẫu Demo Migration mà không cần phối hợp chuyên sâu.
| Dấu hiệu phù hợp với Standard Service | Vì sao phù hợp với BigCommerce |
|---|---|
| Products có SKUs, options, variants, images và Categories rõ ràng. | Việc rà soát catalog có thể tập trung vào các cấu trúc Products được BigCommerce hỗ trợ. |
| Modifiers hoặc các hình thức tùy chỉnh của người mua hạn chế hoặc dễ nhận diện. | Catalog ít cần diễn giải riêng hơn. |
| Pricing chủ yếu là base price, sale price hoặc discount context đơn giản được hỗ trợ. | Độ phức tạp từ bảng giá hoặc B2B pricing còn hạn chế. |
| Channels đơn giản hoặc không tạo thêm độ phức tạp cho thời điểm vận hành. | mức độ hiển thị của Products và phạm vi storefront dễ xác thực hơn. |
| Customers và Orders chủ yếu là các bản ghi lịch sử thông thường. | Có thể kiểm tra tra cứu người mua và lịch sử đơn hàng qua các mẫu đại diện. |
| Phạm vi redirects và content đã rõ. | Có thể rà soát SEO continuity mà không cần transformation content tùy chỉnh. |
Standard Service trở nên rủi ro nếu doanh nghiệp chưa thể giải thích cách options của Products, pricing, channels hoặc app data ở nguồn cần được thể hiện trên BigCommerce. Một loại bản ghi được hỗ trợ không có nghĩa mọi cách hệ thống nguồn hoạt động gắn với bản ghi đó đều nằm trong phạm vi được hỗ trợ.
Khi Managed Service có thể an toàn hơn
Managed Service phù hợp hơn khi phần lớn dữ liệu vẫn nằm trong phạm vi được hỗ trợ nhưng quá trình thực hiện cần phối hợp, xác định trình tự và được đội ngũ chuyên môn xử lý. Điều này có thể xảy ra khi doanh nghiệp có catalog lớn, nhiều lựa chọn Products, redirects quan trọng, lịch sử đơn hàng có giá trị cao, SEO nhạy cảm với thời điểm vận hành, mức độ hiển thị của Products khác nhau theo nhiều channels hoặc đội ngũ nội bộ có ít nguồn lực để trực tiếp thực hiện di chuyển dữ liệu.
Managed Service có thể giảm khối lượng công việc vận hành cho doanh nghiệp, nhưng không biến bản ghi app chưa được hỗ trợ thành dữ liệu di chuyển dữ liệu tiêu chuẩn. Dịch vụ này phù hợp khi dữ liệu được hỗ trợ hoặc đã có phạm vi rõ nhưng cần cách thực hiện và phối hợp chặt chẽ hơn. Nếu dự án có các bản ghi chưa được hỗ trợ hoặc các phép biến đổi được thiết kế riêng, vẫn có thể cần Custom Service.
| Trường hợp phù hợp với Managed Service | Tình huống BigCommerce |
|---|---|
| Phạm vi được hỗ trợ nhưng có nhiều điểm cần rà soát | Products, variants, Categories, images, Customers, Orders, pages và redirects cần được kiểm tra phối hợp. |
| SEO có giá trị cao cần duy trì | Redirects, URLs của Products, URLs của Categories, pages và metadata cần được sắp xếp trình tự cẩn thận trước khi vận hành. |
| Catalog có nhiều variants | Lựa chọn Products nằm trong phần được hỗ trợ nhưng cần kiểm thử có hệ thống trên bộ mẫu. |
| Nhạy cảm với multi-channel hoặc pricing | Channel assignments, bảng giá hoặc pricing theo nhóm Customers cần kế hoạch xác thực rõ. |
| Đội ngũ doanh nghiệp có ít nguồn lực trực tiếp | Doanh nghiệp cần phần thực hiện Việc di chuyển do Next-Cart đảm nhận nhưng vẫn tự xác nhận kết quả cuối cùng. |
Managed Service nên được chọn vì nhu cầu hỗ trợ thực hiện và phối hợp rà soát, không phải để thay thế việc xác định phạm vi. Doanh nghiệp vẫn cần acceptance criteria và bộ mẫu đại diện.
Khi Add-ons có thể giải quyết yêu cầu
Add-ons phù hợp khi yêu cầu vẫn nằm trong phạm vi được hỗ trợ, có ranh giới rõ và có thể mô tả cụ thể. Data Filter có thể chọn các bản ghi Products, Customers hoặc Orders theo điều kiện dựa trên trường cho từng loại dữ liệu. Advanced Data Mapping có thể chuyển một trường nguồn tiêu chuẩn được hỗ trợ sang một trường đích BigCommerce tương thích được hỗ trợ mà không thay đổi giá trị, còn Data Transformation áp dụng biểu thức để thay đổi các giá trị đích được hỗ trợ. Các Add-ons này không thay thế Custom Service cho các bản ghi chưa được hỗ trợ, hệ thống bên ngoài, quy tắc thiết kế riêng hoặc dữ liệu do app sở hữu mà BigCommerce không nhận như dữ liệu di chuyển dữ liệu thông thường.
| Nhu cầu Add-on | Trường hợp BigCommerce | Ranh giới cần kiểm tra |
|---|---|---|
| Data Filter | Di chuyển Products, Customers, Orders, CMS Pages hoặc Blog Posts được hỗ trợ khi đáp ứng điều kiện dựa trên trường cho từng loại dữ liệu. | Trường, điều kiện và quy tắc đưa vào hoặc loại ra phải được xác định rõ. |
| Data Transformation | Áp dụng expressions để biến đổi các giá trị được hỗ trợ trước khi đưa vào BigCommerce. | Input values, expected outputs và các trường hợp ngoại lệ phải có thể kiểm thử. |
| Advanced Data Mapping | Chuyển các trường nguồn tiêu chuẩn được hỗ trợ sang các trường đích BigCommerce khác được hỗ trợ mà không thay đổi giá trị. | Việc mapping không thể tự tạo hành vi hoặc cấu trúc BigCommerce chưa được hỗ trợ. |
| Xử lý nhu cầu đặc thù nhưng có phạm vi giới hạn | Áp dụng một điều chỉnh cụ thể được hỗ trợ cho Products, Categories, URLs, Customers hoặc Orders. | Nếu cần quy tắc tùy chỉnh hoặc các bản ghi chưa được hỗ trợ, nên xem xét Custom Service. |
Yêu cầu Add-on tốt phải được viết thành acceptance criteria cụ thể. Những yêu cầu chung chung như “làm cho giống Cửa hàng nguồn” nhưng không xác định các trường hoặc kết quả cần đạt sẽ không đủ để lựa chọn cách xử lý.
Khi nên xem xét Custom Service
Custom Service nên được xem xét khi yêu cầu Di chuyển sang BigCommerce vượt khỏi cách xử lý tiêu chuẩn được hỗ trợ. Quy mô doanh nghiệp không quyết định việc có cần Custom Service hay không. Các dấu hiệu thực sự nằm ở custom data, cấu trúc nguồn chưa được hỗ trợ, transformation thiết kế riêng, bản ghi của app, external identifiers, trường hợp sử dụng Custom Platform hoặc yêu cầu điều chỉnh cách xử lý di chuyển dữ liệu riêng.
Trên BigCommerce, nhu cầu tùy chỉnh thường xuất hiện ở options của Products, các trường tùy chỉnh, metafields, pricing, dữ liệu ERP, dữ liệu đăng ký định kỳ, Reviews, marketplace feeds, cấu trúc tương tự B2B, cách phân nhóm Customers, loyalty records và storefront Headless hoặc kết nối app.
| Dấu hiệu cần Custom Service | Vì sao làm thay đổi phương án |
|---|---|
| options của Products ở nguồn không phù hợp rõ ràng với variants, variant options hoặc modifiers. | Catalog có thể cần phân tích và thiết kế cách xử lý riêng trước khi BigCommerce sử dụng được dữ liệu. |
| Dự án cần dữ liệu đăng ký định kỳ, loyalty, bundles, Reviews, feeds hoặc các bản ghi marketplace do app quản lý. | Dữ liệu có thể không thuộc các bản ghi tiêu chuẩn của nền tảng. |
| các trường tùy chỉnh hoặc external identifiers phải tiếp tục phục vụ ERP, CRM, accounting hoặc dịch vụ khách hàng. | Mapping được hỗ trợ có thể không đủ để duy trì đúng ý nghĩa kinh doanh. |
| Pricing rules nâng cao phụ thuộc vào quy tắc riêng hoặc hệ thống bên ngoài. | Bảng giá hoặc bulk pricing có thể không thể hiện đầy đủ cách pricing hoạt động ở nguồn. |
| Source content phụ thuộc vào page builders, scripts hoặc cách storefront tùy chỉnh vận hành. | BigCommerce content và redirects có thể cần cách xử lý riêng hoặc xây dựng lại thủ công. |
| Custom Platform nằm ở phía nguồn hoặc đích của dự án. | Cấu trúc nguồn có thể cần được phân tích trực tiếp trước khi có thể tin cậy mapping. |
Custom Service cần được xác định phạm vi từ các trường hợp cụ thể. Doanh nghiệp nên cung cấp Products, Customers, Orders, các bản ghi nội dung, các trường tùy chỉnh có yêu cầu xử lý vượt quá phạm vi mapping được hỗ trợ, app exports, external identifiers và kết quả mong đợi đủ đại diện. Nếu thiếu các trường hợp thực tế, việc thảo luận nhu cầu tùy chỉnh sẽ quá trừu tượng để xây dựng một phương án dịch vụ đáng tin cậy.
Demo Migration cần giúp quyết định điều gì
Demo Migration cần cho biết phương án BigCommerce đã chọn có đủ đáp ứng dự án hay chưa. Không nên xem Demo Migration như bản xem trước đơn giản về số lượng bản ghi. Bộ mẫu phải chứng minh rằng ý nghĩa dữ liệu đặc thù của BigCommerce vẫn được giữ đúng sau di chuyển dữ liệu.
| Mẫu Demo Migration | Quyết định cần hỗ trợ |
|---|---|
| Products đơn giản | Xác nhận mô hình Products, Categories, images, pricing và inventory cơ bản. |
| Products có nhiều variants | Xác nhận options và variants hoạt động đúng. |
| Products có cấu trúc giống modifier | Xác định phần tùy chỉnh của người mua có cần hướng xử lý khác hay không. |
| Products có các trường tùy chỉnh có yêu cầu xử lý vượt quá phạm vi mapping được hỗ trợ hoặc metafields | Xác định mapping được hỗ trợ đã đủ hay cần Custom Service. |
| Trường hợp bảng giá hoặc bulk pricing | Xác định kỳ vọng pricing nằm trong phần được hỗ trợ, cần cấu hình ở đích hay cần xử lý tùy chỉnh. |
| Products riêng theo channel | Xác định channel assignment và visibility có cần rà soát thêm hay không. |
| Customers có group hoặc trường tùy chỉnh | Xác nhận danh tính Customers và segmentation được duy trì đúng. |
| Orders có discount hoặc refund | Xác nhận lịch sử đơn hàng vẫn có thể đọc và sử dụng đúng mục đích. |
| URL ưu tiên hoặc content page | Xác định kỳ vọng SEO và redirects có cần điều chỉnh hay không. |
Phương án đang chọn là quá nhẹ nếu Demo Migration không thể làm rõ lựa chọn Products, pricing, phạm vi channel, cách phân nhóm Customers, redirects hoặc app-owned data. Khi đó, cần điều chỉnh phạm vi trước Di chuyển toàn bộ thay vì kỳ vọng lần chạy đầy đủ sẽ tự giải quyết sự không phù hợp.
Entity Points trong quá trình xác định phạm vi BigCommerce
Entity Points giúp lập kế hoạch khối lượng bản ghi thuộc các loại dữ liệu đủ điều kiện, nhưng không chứng minh dữ liệu nguồn phù hợp với BigCommerce. Với BigCommerce, các bản ghi Products, Customers, Orders và Blog Posts đủ điều kiện có thể sử dụng Entity Points khi được di chuyển lần đầu. Những bản ghi đã được tính trong cùng Dịch vụ chuyển đổi dữ liệu và lộ trình chuyển đổi cố định không bị tính lại chỉ vì có thêm một hoạt động di chuyển dữ liệu; độ phức tạp từ channels, bảng giá, modifiers và apps được đánh giá riêng. Các bản ghi mới đủ điều kiện có thể sử dụng Entity Points khi được di chuyển lần đầu.
Với BigCommerce, cần xem Entity Points cùng với cấu trúc và độ phức tạp. Cửa hàng nhỏ có thể cần Custom Service nếu phụ thuộc vào các trường do app quản lý, external IDs, custom pricing hoặc storefront quy tắc. Cửa hàng lớn hơn vẫn có thể phù hợp với Standard Service hoặc Managed Service nếu các bản ghi nằm trong phạm vi được hỗ trợ và doanh nghiệp có thể xác thực chúng.
| Yếu tố về phạm vi | Hỗ trợ ước tính điều gì | Không chứng minh điều gì |
|---|---|---|
| Số lượng Products | Khối lượng catalog và mức sử dụng Entity Points có thể phát sinh. | Variants, modifiers, các trường tùy chỉnh, images, Categories và channels có được mapping đúng hay không. |
| Số lượng Customers | Khối lượng bản ghi người mua. | Groups, các trường tùy chỉnh, duplicates, external IDs và quan hệ Customers có tiếp tục hữu ích hay không. |
| Số lượng Orders | Khối lượng lịch sử đơn hàng. | Refunds, discounts, bối cảnh thanh toán, xử lý đơn hàng và custom statuses có còn đọc đúng hay không. |
| Số lượng Blog Posts | Khối lượng content khi có liên quan. | URLs, redirects, metadata và cách trình bày content đã sẵn sàng cho thời điểm vận hành hay chưa. |
Entity Points hỗ trợ lập kế hoạch, không thay thế việc đánh giá phương án dịch vụ.
Các lựa chọn cho lần di chuyển dữ liệu tiếp theo ảnh hưởng thế nào đến kế hoạch vận hành BigCommerce
Phương án cho lần di chuyển dữ liệu tiếp theo cần được xem xét khi Cửa hàng nguồn tiếp tục thay đổi sau Demo Migration hoặc Di chuyển toàn bộ, hoặc khi doanh nghiệp cần thay đổi cách xử lý dữ liệu ở những lần tiếp theo. Lựa chọn phải phù hợp với thay đổi thực tế, không nên được chọn chỉ vì một hoạt động khác vẫn còn khả dụng trong Dịch vụ chuyển đổi dữ liệu đã mua và đang còn thời hạn.
| Hoạt động hiện tại | Khi nào phù hợp với BigCommerce | Nội dung cần xác thực lại |
|---|---|---|
| Continue the di chuyển dữ liệu with the Last Used Configuration | Khi Cửa hàng nguồn có Products, Customers, Orders hoặc Blog Posts mới đủ điều kiện và filters, mappings, giả định về channels, cách xử lý redirects cùng cấu trúc catalog đã được chấp nhận vẫn còn phù hợp. | Rà soát các bản ghi mới, variants hoặc modifiers bị ảnh hưởng, channel visibility, lịch sử đơn hàng và URLs ưu tiên. |
| Continue the di chuyển dữ liệu with a New Configuration | Khi filters, mappings, cách hiểu options của Products, cách phân nhóm Customers, xử lý redirects, giả định về bảng giá hoặc phạm vi channel/storefront cần thay đổi. | Xác thực cả rules đã thay đổi và các bản ghi đại diện từng được chấp nhận theo cấu hình cũ. |
| Perform a Di chuyển New | Khi kết quả trước đó không còn là cơ sở của dự án, môi trường BigCommerce ở đích được thiết lập lại hoặc thay đổi đáng kể, hoặc dự án cần một kết quả di chuyển dữ liệu mới theo phạm vi vừa được phê duyệt trong khi lộ trình cố định từ Nền tảng nguồn đến Nền tảng đích vẫn không đổi. | Lặp lại đầy đủ acceptance set cho catalog, Customers, Orders, content, redirects, channels và custom requirements. |
Phân biệt này đặc biệt quan trọng trong giai đoạn BigCommerce chuẩn bị vận hành, khi Cửa hàng nguồn vẫn liên tục phát sinh Orders và Customers mới nhưng catalog chính không thay đổi.
Phương án cho lần di chuyển dữ liệu tiếp theo không tái tạo BigCommerce apps, theme code, checkout configuration, channel các tích hợp, payment settings hoặc workflows của hệ thống bên ngoài. Nếu thay đổi ở nguồn ảnh hưởng đến những hạng mục này, doanh nghiệp cần phối hợp phần triển khai tại hệ thống đích và xác thực lại riêng với hoạt động di chuyển dữ liệu.
Trách nhiệm thực hiện vẫn tuân theo Dịch vụ chuyển đổi dữ liệu đã chọn. Với Standard Service hoặc Custom Service không kèm Expert Handle, khách hàng tự thực hiện các hoạt động khả dụng. Với Managed Service hoặc Custom Service có Expert Handle, phần thực hiện hoạt động đã thống nhất được bao gồm trong phạm vi; khách hàng vẫn chịu trách nhiệm xác nhận kết quả cuối cùng của di chuyển dữ liệu.
Dấu hiệu cho thấy phương án hiện tại chưa đủ
Phương án BigCommerce chưa đủ khi dự án xem những khác biệt riêng của nền tảng như việc chuyển các bản ghi thông thường. Các dấu hiệu thường xuất hiện ở ý nghĩa catalog, pricing, phạm vi channel, redirects, cách phân nhóm Customers hoặc app data.
| Dấu hiệu cảnh báo | Hướng xử lý có thể cần |
|---|---|
| Không thể phân loại lựa chọn Products thành variants, variant options, modifiers, phần thiết lập hoặc phạm vi tùy chỉnh. | Rà soát lại phạm vi catalog trước khi chốt phương án. |
| Bảng giá, pricing theo nhóm Customers hoặc bulk pricing quan trọng với hoạt động kinh doanh nhưng chưa có mẫu kiểm thử. | Bổ sung mẫu pricing và đánh giá nhu cầu Add-ons hoặc Custom Service. |
| Channel assignments hoặc mức độ hiển thị của Products khác nhau giữa các storefronts. | Tăng mức độ chuẩn bị và xác thực theo channel. |
| Redirects, CMS Pages hoặc Blog Posts có giá trị cao nhưng phạm vi còn mơ hồ. | Xem continuity của content và SEO là điều kiện quan trọng trước khi vận hành. |
| Trường tùy chỉnh, metafields, dữ liệu app hoặc mã định danh bên ngoài giữ vai trò quan trọng trong vận hành. | Trước hết xác nhận liệu việc chuyển trường được hỗ trợ có giữ đúng yêu cầu hay không; chỉ xem xét Custom Service khi phạm vi mapping được hỗ trợ không đủ. |
| Demo Migration chỉ dùng Products đơn giản và Orders không có tình huống phức tạp. | Mở rộng bộ mẫu trước Di chuyển toàn bộ. |
| Dữ liệu nguồn tiếp tục thay đổi sát thời điểm vận hành nhưng chưa có kế hoạch cho hoạt động tiếp theo. | Xác định thời điểm, di chuyển dữ liệu action, người chịu trách nhiệm và nội dung cần xác thực lại. |
Những dấu hiệu này cần được xử lý trước Di chuyển toàn bộ. Nếu để đến thời điểm vận hành mới giải quyết, dự án sẽ khó phân biệt lỗi di chuyển dữ liệu với phần thiết lập BigCommerce còn thiếu ở hệ thống đích.
Đối chiếu điều kiện dự án để chọn phương án thực tế
Phương án phù hợp cho BigCommerce là lựa chọn ít phức tạp nhất nhưng vẫn duy trì được kết quả kinh doanh cần thiết. Standard Service có thể đủ khi các bản ghi nằm trong phạm vi được hỗ trợ và doanh nghiệp thực tế có thể tự xác thực. Managed Service an toàn hơn khi phạm vi được hỗ trợ cần phối hợp chặt chẽ hơn. Add-ons phù hợp khi các bản ghi được hỗ trợ cần filtering, biến đổi giá trị trường hoặc chuyển trường nguồn sang trường đích khác. Custom Service cần thiết khi dự án có dữ liệu chưa được hỗ trợ, dữ liệu tùy chỉnh hoặc do app và hệ thống bên ngoài sở hữu, hoặc transformation thiết kế riêng cần được đánh giá.
Một phương án rõ ràng cần trả lời bốn câu hỏi:
- những bản ghi nào sẽ được di chuyển vào BigCommerce;
- BigCommerce settings, apps, channels hoặc storefront behaviors nào phải được cấu hình riêng;
- Add-ons hoặc yêu cầu Custom Service nào nằm trong phạm vi;
- những mẫu nào trong Demo Migration phải đạt yêu cầu trước Di chuyển toàn bộ.
Khi bốn nội dung này đã rõ, phương án thường có đủ cơ sở để tiếp tục. Nếu vẫn còn mơ hồ, doanh nghiệp nên hoàn thiện phạm vi trước khi xem quyết định lựa chọn Dịch vụ chuyển đổi dữ liệu là xong.
Kết luận
Lựa chọn phương án di chuyển dữ liệu cho BigCommerce cần dựa trên cách doanh nghiệp muốn BigCommerce vận hành sau khi cửa hàng đi vào hoạt động. Standard Service, Managed Service, Add-ons và Custom Service đều có vai trò riêng, nhưng không nên lựa chọn dịch vụ chỉ từ số lượng bản ghi. Phương án phải tính đến cấu trúc catalog, variants, modifiers, bảng giá, channels, Customers, Orders, redirects, content, apps, Entity Points, các hoạt động di chuyển dữ liệu về sau và kết quả Demo Migration.
Một phương án dịch vụ phù hợp phải làm rõ cả cách thực hiện di chuyển dữ liệu lẫn cách doanh nghiệp xác thực kết quả. Cần xác định dữ liệu nào sẽ được di chuyển, phần nào phải cấu hình trên BigCommerce, yêu cầu nào cần Add-ons, trường hợp nào cần Custom Service và những gì phải được kiểm chứng trước khi cửa hàng chính thức vận hành.
Câu hỏi thường gặp
Khi nào Standard Service có thể đủ cho Di chuyển sang BigCommerce?
Standard Service có thể phù hợp khi phạm vi BigCommerce nằm trong phần được hỗ trợ, cấu trúc Products rõ ràng, pricing và channels dễ quản lý, Customers và Orders tương đối thông thường, redirects và content đã có phạm vi cụ thể, đồng thời doanh nghiệp có thể tự xác thực kết quả với đủ dữ liệu để đối chiếu.
Khi nào nên xem xét Managed Service cho Di chuyển sang BigCommerce?
Managed Service hữu ích khi di chuyển dữ liệu vẫn nằm trong phạm vi được hỗ trợ nhưng cần mức hỗ trợ cao hơn cho việc thực hiện, phối hợp, rà soát mẫu, sắp xếp trình tự trước thời điểm vận hành hoặc quản lý áp lực xác thực catalog, redirects, pricing và channels.
Add-ons khác Custom Service như thế nào khi chuyển sang BigCommerce?
Add-ons điều chỉnh cách lọc các bản ghi được hỗ trợ, biến đổi giá trị trường hoặc liên kết trường nguồn với trường đích. Với BigCommerce, cần xem xét Custom Service khi multi-storefront assignments, các bản ghi B2B, app-owned data, external identifiers hoặc transformations riêng cho catalog và Customers không thể được xử lý bằng mapping được hỗ trợ hay Add-ons có phạm vi giới hạn.
Demo Migration cần chứng minh điều gì cho BigCommerce trước Di chuyển toàn bộ?
Demo Migration cần cho thấy các trường hợp đại diện hoạt động đúng trên BigCommerce: Products, variants, modifiers, các trường hợp pricing, Customers, Orders, redirects, content, channel assignments và những mẫu tùy chỉnh hoặc do các tích hợp sở hữu khi có liên quan.
Lựa chọn cho lần di chuyển dữ liệu tiếp theo nào phù hợp khi BigCommerce cần cập nhật dữ liệu trước khi vận hành?
Dùng 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 phù hợp với các bản ghi mới đủ điều kiện. Dùng Continue the di chuyển dữ liệu with a New Configuration khi filters, mappings, phạm vi channel, redirects hoặc cách xử lý Products cần thay đổi. Dùng Perform a Di chuyển New khi dự án cần một kết quả mới do phạm vi hoặc cách thiết lập BigCommerce ở đích thay đổi đáng kể nhưng lộ trình chuyển đổi đã mua vẫn giữ nguyên. Nếu cần một lộ trình khác từ Nền tảng nguồn đến Nền tảng đích, khách hàng phải mua một Dịch vụ chuyển đổi dữ liệu riêng.