Các hạng mục cần ưu tiên xác thực sau khi chuyển đổi sang osCommerce

Xác thực sau khi chuyển đổi sang osCommerce phải chứng minh nhiều hơn việc bản ghi đã được đưa sang Cửa hàng đích. Cửa hàng có thể có đúng số lượng Products, Customers, Orders, Categories và CMS Pages nhưng vẫn không đáp ứng yêu cầu kinh doanh nếu khách hàng không thể duyệt danh mục, nhóm Customers mất ý nghĩa thương mại, tổng tiền trong Orders khó hiểu hoặc chức năng do module sở hữu bị bỏ khỏi kế hoạch đưa cửa hàng vào vận hành.

osCommerce cần được xác thực cẩn thận vì nhiều dự án phải xử lý đồng thời hai lớp lịch sử: mô hình dữ liệu của Nền tảng nguồn và cách doanh nghiệp muốn osCommerce tiếp quản hoạt động sau chuyển đổi. osCommerce v4 hiện đại có thể bao gồm nhiều kênh bán hàng, quản lý danh mục Products, nhóm Customers, Coupons, SEO, Design and CMS, module, thiết lập, ứng dụng từ App Shop, lựa chọn cài đặt và trách nhiệm vận hành máy chủ. Nguồn osCommerce cũ hoặc hệ thống có nguồn gốc từ osCommerce còn có thể chứa add-ons cũ, bảng tùy chỉnh và những cách xử lý được duy trì qua nhiều năm. Vì vậy, quá trình xác thực phải tách dữ liệu đã di chuyển khỏi cấu hình trên Nền tảng đích, rồi chứng minh cả hai đều sẵn sàng để sử dụng.

Xác thực osCommerce cần chứng minh những gì

Mục tiêu của xác thực là chứng minh Cửa hàng đích osCommerce đủ đáng tin cậy cho các đội ngũ sẽ vận hành cửa hàng sau khi chính thức đi vào hoạt động. Quản trị viên cần đọc và hiểu được Products, Categories, Customers, Orders, Coupons, CMS Pages, trường SEO và các giả định liên quan đến module. Bộ phận chăm sóc khách hàng cần lịch sử đơn hàng giải thích được những gì đã xảy ra trước di chuyển dữ liệu. Đội phụ trách merchandising cần các đường dẫn khám phá danh mục phù hợp với cách khách hàng tìm kiếm và duyệt sản phẩm. Đội kỹ thuật cần thông tin xác nhận rõ dữ liệu nào đã được di chuyển, hạng mục nào được cấu hình trong osCommerce, hạng mục nào cần điều chỉnh di chuyển dữ liệu đã được phê duyệt và hạng mục nào phải đưa sang rà soát xử lý ngoài phạm vi tiêu chuẩn.

Vì vậy, quá trình xác thực cần kiểm tra đồng thời ba nhóm. Nhóm thứ nhất là dữ liệu đã di chuyển: Products, Customers, Orders, Coupons, Reviews, CMS Pages, Blog Posts khi áp dụng và các bản ghi liên quan. Nhóm thứ hai là cấu hình osCommerce: kênh bán hàng, tiền tệ, ngôn ngữ, nhóm Customers, module thanh toán và vận chuyển, vùng Tax, trạng thái Orders, menu, theme và thiết lập SEO. Nhóm thứ ba là phạm vi không tiêu chuẩn: ứng dụng App Shop, extension của bên thứ ba, bảng tùy chỉnh ở nguồn, mã định danh của hệ thống ngoài và cách xử lý riêng không thể xác nhận chỉ bằng số lượng bản ghi.

Một lần xác thực đạt yêu cầu không có nghĩa phải tái tạo Cửa hàng nguồn giống hệt. Mục tiêu là xác định điều kiện sẵn sàng trước khi chính thức vận hành: Cửa hàng đích osCommerce có đúng dữ liệu, dữ liệu hoạt động theo mô hình vận hành đã chọn và không còn giả định ẩn có thể khiến đội ngũ bất ngờ khi mở rộng di chuyển dữ liệu hay đưa cửa hàng vào hoạt động.

Xác thực khả năng khám phá danh mục và kênh bán hàng

Danh mục cần được kiểm tra từ storefront, không chỉ từ khu vực quản trị. Khả năng khách hàng tìm thấy Products trong osCommerce có thể phụ thuộc vào Categories, brands, properties, bộ lọc, việc gán vào kênh bán hàng, menu, chức năng tìm kiếm, trang khuyến mại, Products nổi bật, danh sách Products mới và chế độ hiển thị danh sách. Một bản ghi Products có thể hiển thị đúng trong khu vực quản trị nhưng vẫn không đạt nếu khách hàng không thể đi tới Products đó theo các đường duyệt dự kiến.

Nên bắt đầu bằng các Categories đại diện thay vì chỉ chọn những Products bán chạy nhất. Bộ mẫu cần có Categories ở cấp nông và sâu, Categories dùng bộ lọc, Categories chứa nhiều Products, Categories được liên kết từ menu và Categories từng có giá trị SEO hoặc giá trị như trang đích. Sau đó, kiểm tra Products được gán vào các Categories này có hiển thị đúng tên, hình ảnh, giá, trạng thái tồn kho, attributes và mô tả ngắn hay không. Quan hệ một bản ghi Products với nhiều Categories cần được chú ý riêng vì Products sau di chuyển dữ liệu có thể cần tiếp tục xuất hiện trong nhiều bối cảnh khách hàng khác nhau.

Nếu cấu hình osCommerce đích sử dụng nhiều storefront hoặc kênh bán hàng, việc xác thực theo từng kênh cũng rất quan trọng. Bản ghi Products có thể phù hợp với một kênh nhưng không phù hợp với kênh khác do khác biệt về ngôn ngữ, tiền tệ, giá, tồn kho, nội dung hoặc theme. Kết quả xác thực phải cho biết Products, Categories, Pages và menu chỉ xuất hiện ở đúng nơi cần thiết. Nếu Cửa hàng nguồn chỉ có một storefront nhưng osCommerce đích sử dụng nhiều kênh bán hàng, quyết định về khả năng hiển thị là quyết định cấu hình trên đích, không phải kết quả tự động của việc di chuyển dữ liệu.

Khả năng khám phá danh mục nên được xác thực trước khi chấp nhận kết quả di chuyển dữ liệu ở phạm vi rộng hơn, vì lỗi tại đây thường trông nhỏ khi kiểm tra trong khu vực quản trị nhưng sẽ hiển thị ngay với khách hàng sau khi cửa hàng vận hành.

Xác thực chi tiết Products, attributes, tồn kho và giá

Xác thực Products phải tập trung vào ý nghĩa thương mại. osCommerce có thể biểu diễn nhiều khái niệm liên quan đến Products, bao gồm danh tính Products, Categories, tồn kho, attributes, properties, nhóm Products, nhà cung cấp, kho hàng, Reviews, hình ảnh và trường SEO. Mẫu kiểm tra chỉ đạt khi Products vẫn hoạt động như một mặt hàng có thể bán, không chỉ là một bản ghi có tiêu đề và giá.

Bộ mẫu mạnh cần có cả trường hợp thông thường và trường hợp biên. Hãy kiểm tra một bản ghi Products đơn giản; một bản ghi Products có attributes cho khách hàng lựa chọn; một bản ghi Products có properties dùng cho bộ lọc; một bản ghi Products nằm trong nhiều Categories; một bản ghi Products gắn với brand; một bản ghi Products có cách xử lý nhạy với tồn kho; một bản ghi Products có Reviews; một bản ghi Products có giá đặc biệt hoặc khuyến mại; và bất kỳ bản ghi Products nào mà chức năng ở nguồn phụ thuộc vào extension hoặc trường tùy chỉnh. Nếu dự án có Products tải xuống, bundle, giới hạn mua, trường nhà cung cấp, quy tắc kho hoặc loại bản ghi Products khác, cũng cần đưa các trường hợp đó vào mẫu.

Khi xác thực attributes, phải tách dữ liệu Products đã di chuyển khỏi cách hoạt động trực tiếp trên Nền tảng đích. Một option ở nguồn có thể trở thành attribute, property, trường tùy chỉnh hoặc một chức năng không được hỗ trợ trong osCommerce, tùy vào cách option đó được dùng. Nếu attribute ảnh hưởng đến giá, lựa chọn của khách hàng, hiển thị, bộ lọc hoặc kỳ vọng tồn kho, kết quả xác thực phải chứng minh ý nghĩa ở đích là có chủ đích. Nếu cấu trúc tiêu chuẩn trên đích không thể tái hiện ý nghĩa cần thiết, vấn đề phải được chuyển sang hướng xử lý phù hợp thay vì bị che bởi một lần kiểm tra số lượng Products.

Tồn kho và giá cần được kiểm tra bằng các tình huống vận hành. Hãy rà soát Products có tồn kho bình thường, hết hàng, tồn kho thấp, bối cảnh kho hoặc nhà cung cấp, giá khuyến mại, Coupons hoặc giảm giá, cách xử lý riêng theo nhóm Customers và giá nhạy với Tax. Một bản ghi Products chỉ đạt khi quản trị viên có thể hiểu rõ mặt hàng nào sẽ được bán, giá nào sẽ hiển thị và thông tin về tình trạng còn hàng nào khách hàng sẽ nhìn thấy.

Xác thực Customers, nhóm Customers và ý nghĩa tài khoản

Xác thực Customers phải chứng minh lịch sử tài khoản và cách phân nhóm vẫn sử dụng được. osCommerce có thể lưu Customers, nhóm Customers, các quy tắc liên quan đến quyền truy cập, bối cảnh ngôn ngữ và tiền tệ, địa chỉ, Reviews, đăng ký hoặc trường do module sở hữu, cùng các giả định về giá hay khả năng hiển thị. Nếu Cửa hàng nguồn dùng nhóm Customers cho giá bán buôn, truy cập B2B, cách xử lý Tax, phê duyệt, phương thức thanh toán hoặc khả năng nhìn thấy Products, các nhóm này phải được xác thực như quy tắc thương mại chứ không chỉ như nhãn.

Bộ mẫu các bản ghi Customers nên có nhiều kiểu tài khoản: một khách hàng đăng ký thông thường; một khách mua với tư cách guest nhưng có lịch sử đơn hàng; một tài khoản Customers có nhiều địa chỉ; một tài khoản Customers thuộc nhóm đặc biệt; một tài khoản Customers có Reviews; một tài khoản Customers có Orders ở nhiều trạng thái; và một tài khoản Customers chứa mã vùng, ngôn ngữ, tiền tệ hoặc mã định danh dùng cho tích hợp. Nếu Nền tảng nguồn lưu sự đồng ý tiếp thị, dữ liệu loyalty, thông tin giao dịch B2B hoặc trường do extension sở hữu, cần quyết định rõ dữ liệu đó thuộc phạm vi di chuyển dữ liệu tiêu chuẩn, phạm vi điều chỉnh di chuyển dữ liệu đã được phê duyệt hay phạm vi xử lý không tiêu chuẩn.

Mật khẩu phải được thảo luận riêng với dữ liệu Customers. Tùy giới hạn của Nền tảng nguồn và Nền tảng đích, mật khẩu có thể không thể tiếp tục sử dụng trực tiếp hoặc có thể cần kế hoạch truyền thông cho khách hàng. Không nên đánh dấu Di chuyển Customers là thất bại chỉ vì cơ chế mật khẩu cần một kế hoạch triển khai trên đích. Câu hỏi đúng là liệu bản ghi Customers, địa chỉ, nhóm và lịch sử có đủ hữu ích cho hoạt động sau khi cửa hàng đi vào vận hành hay không.

Kết quả xác thực Customers phải cho phép bộ phận chăm sóc khách hàng và quản trị viên trả lời được các câu hỏi thực tế: đây là khách hàng nào, thuộc nhóm nào, Orders nào liên kết với tài khoản, địa chỉ nào đang có, chính sách thương mại nào áp dụng và cần kế hoạch truyền thông hoặc đặt lại mật khẩu nào trước khi vận hành.

Xác thực Orders, tổng tiền, Coupons và bối cảnh giao dịch trước đây

Orders cần được xác thực theo khả năng đọc hiểu trong vận hành. Đơn hàng trước đây không cần trở thành quy tắc checkout mới, nhưng phải tiếp tục hữu ích cho chăm sóc khách hàng, đối chiếu kế toán, rà soát xử lý đơn hàng, báo cáo quản lý và giải quyết tranh chấp. Bộ mẫu cần có các bản ghi Orders đã thanh toán, đang chờ, đã hủy, đã hoàn tiền, hoàn tất một phần, điều chỉnh thủ công, dùng Coupons, nhạy với Tax và nhiều tiền tệ khi các trường hợp này có trong nguồn.

Ý nghĩa Orders trong osCommerce có thể bao gồm trạng thái, nhóm trạng thái, ghi chú, nhãn thanh toán, nhãn vận chuyển, tổng tiền, Tax, giảm giá, tham chiếu Coupons, thông tin gift card, tracking, số hóa đơn, transaction ID, bối cảnh Customers và Products đã mua. Kết quả xác thực phải chứng minh mỗi đơn hàng kể lại được một câu chuyện giao dịch mạch lạc sau di chuyển dữ liệu: khách hàng đã mua gì, đã trả bao nhiêu, Tax hoặc giảm giá nào được áp dụng, đơn hàng đã đi đến trạng thái nào và ghi chú hay mã định danh nào còn quan trọng cho vận hành.

Coupons, gift cards và lịch sử khuyến mại cần được diễn giải thận trọng. Coupons đã dùng và hiển thị trong đơn hàng là dữ liệu lịch sử. Cấu hình Coupons có thể dùng trực tiếp trong osCommerce là chức năng của Nền tảng đích. Không được suy ra rằng việc di chuyển lịch sử giảm giá tự động tạo ra chương trình khuyến mại mới có thể sử dụng. Nếu doanh nghiệp cần tiếp tục các chương trình sau khi vận hành, chúng phải được cấu hình và kiểm thử riêng.

Nên có những người thực sự dùng dữ liệu tham gia xác thực Orders. Nếu kế toán, chăm sóc khách hàng và đội xử lý đơn hàng không thể đọc các bản ghi Orders trong mẫu một cách tự tin, số lượng bản ghi đúng vẫn chưa đủ.

Xác thực Design and CMS, SEO và khả năng khách hàng tiếp tục tìm thấy nội dung

Design and CMS trong osCommerce có thể ảnh hưởng trực tiếp đến trải nghiệm của khách hàng sau di chuyển dữ liệu. Pages, menu, theme, bản dịch, email template, trang danh mục, banner và điều hướng storefront cần được rà soát khi nằm trong phạm vi đưa cửa hàng vào vận hành. CMS Pages và bản ghi nội dung có thể được di chuyển dưới dạng nội dung, nhưng vị trí trong theme, quy tắc menu, form, bố cục và cách trình bày storefront là quyết định triển khai trên Nền tảng đích.

SEO cần ưu tiên các đường truy cập có giá trị cao. Trang Products, Categories, brand, CMS Pages, redirect, metadata, kỳ vọng về XML sitemap, thiết lập analytics và chức năng tìm kiếm nên được đối chiếu với danh sách URL và truy vấn quan trọng. Mục tiêu không phải kiểm tra thủ công mọi URL, mà là chứng minh những đường truy cập quan trọng từ công cụ tìm kiếm và nguồn giới thiệu đã được liên kết, chuyển hướng, xây lại hoặc chủ động ngừng sử dụng theo kế hoạch.

Kiểm thử tìm kiếm nên dùng ngôn ngữ khách hàng thực sự sử dụng, không chỉ SKU. Hãy kiểm tra tên brand, tên Categories, một phần tên Products, lỗi chính tả phổ biến và các từ khóa từng cho kết quả hữu ích ở Cửa hàng nguồn. Nếu cách tìm kiếm trong osCommerce khác Nền tảng nguồn, cần ghi rõ khác biệt đó có thể chấp nhận, cần cấu hình thêm hay cần extension tìm kiếm riêng.

Một lần xác thực nội dung và SEO đạt yêu cầu phải cho thấy khách hàng vẫn có thể đến được những nội dung thương mại quan trọng, metadata và redirect có kế hoạch rõ ràng, đồng thời CMS Pages không bị nhầm với việc tái tạo toàn bộ theme hoặc điều hướng.

Xác thực module, phụ thuộc App Shop và dữ liệu tùy chỉnh

Đây là phần osCommerce thường làm lộ ra nhiều giả định ẩn nhất. Cửa hàng nguồn có thể chứa add-ons tùy chỉnh, bảng cơ sở dữ liệu đã sửa, cách xử lý checkout được viết trực tiếp trong code, tham chiếu ERP, ID báo cáo bên ngoài, extension vận chuyển hoặc thanh toán, cải tiến tìm kiếm, kết nối Marketplace hoặc code cũ chưa từng tồn tại dưới dạng bản ghi nền tảng rõ ràng. osCommerce hiện đại có thể hỗ trợ ứng dụng App Shop và module, nhưng điều đó không có nghĩa mọi extension ở nguồn tự động trở thành chức năng đã được di chuyển ở đích.

Trước khi mở rộng di chuyển dữ liệu, cần lập bảng theo dõi các thành phần phụ thuộc. Mỗi thành phần phải được phân vào một trong bốn kết quả: di chuyển như dữ liệu tiêu chuẩn; cấu hình trong osCommerce; xử lý bằng điều chỉnh di chuyển dữ liệu đã được phê duyệt khi yêu cầu có phạm vi rõ; hoặc đưa sang rà soát xử lý ngoài tiêu chuẩn khi có bản ghi không tiêu chuẩn hoặc phép biến đổi riêng. Việc phân loại này tránh tình trạng đội vận hành chỉ phát hiện muộn rằng một quy trình quan trọng chưa từng nằm trong phạm vi công việc của di chuyển dữ liệu.

Các mã định danh tùy chỉnh cần được chú ý riêng. ERP ID, mã nhà cung cấp, tham chiếu kho, dấu phê duyệt Customers, cờ Products từ hệ thống cũ, trường Orders tùy chỉnh và tham chiếu hệ thống ngoài có thể nhỏ về hình thức nhưng ảnh hưởng đến đối chiếu dữ liệu, xử lý đơn hàng, chăm sóc khách hàng và báo cáo. Nếu các trường này phải tiếp tục tồn tại, hãy xác thực trực tiếp. Nếu không cần giữ, phải ghi lại quyết định để sự vắng mặt sau vận hành không trở thành bất ngờ.

Kết quả xác thực module và dữ liệu tùy chỉnh phải cho thấy mọi chức năng không tiêu chuẩn đều có chủ sở hữu và cách xử lý rõ. Đội ngũ cần biết chức năng nào được di chuyển, chức năng nào sẽ được cấu hình trong osCommerce, chức năng nào cần extension và chức năng nào được chủ động loại khỏi kết quả đích.

Xác thực dữ liệu đại diện, phạm vi rộng hơn và các kết quả osCommerce về sau

Kiểm thử trên mẫu đại diện và di chuyển dữ liệu ở phạm vi rộng hơn chứng minh hai loại điều khác nhau. Mẫu đại diện phải chủ động đưa vào những bản ghi khó để kiểm tra các giả định cấu trúc: một bản ghi Products thuộc nhiều Categories hoặc front end; một bản ghi Products bị giới hạn theo nhóm Customers; chức năng phụ thuộc attribute hoặc property; một tài khoản Customers có nhiều địa chỉ hoặc bối cảnh nhóm; một đơn hàng có giảm giá, Tax, hoàn tiền hoặc dấu vết xử lý đơn hàng chia nhỏ; một CMS Page hoặc URL quan trọng; và ít nhất một trường hợp liên quan đến App Shop, extension cũ, bảng tùy chỉnh hoặc mã định danh hệ thống ngoài.

di chuyển dữ liệu ở phạm vi rộng hơn phải chứng minh cách diễn giải đã phê duyệt vẫn đầy đủ trên toàn phạm vi sản xuất. Cần rà soát Products hiếm gặp, bản ghi không hoạt động, Customers cũ, Orders của guest, lịch sử trạng thái ngoại lệ, mọi front end quan trọng, nội dung đa ngôn ngữ hoặc theo kênh, URL giá trị cao và quyết định cuối cùng đối với module hoặc dữ liệu tùy chỉnh. Orders trước đây phải tiếp tục dễ hiểu nhưng không được dùng làm bằng chứng rằng module thanh toán, vận chuyển, Tax, checkout, email hoặc front end trực tiếp đã được cấu hình.

Các hành động di chuyển dữ liệu về sau đối với osCommerce cần được xác thực lại tương ứng với front end, Products, nhóm Customers, Orders, URL, module và quan hệ tùy chỉnh bị tác động:

Quyết định sẵn sàng vận hành osCommerce theo Pass, Watch hoặc Block

Phê duyệt đưa osCommerce vào vận hành nên phân loại kết quả xác thực theo Pass, Watch hoặc Block. Trạng thái phải áp dụng cho một bản ghi Products, nhóm Customers, tình huống Orders, front end, URL, module hoặc bản ghi tùy chỉnh cụ thể, không phải gán chung cho toàn bộ cửa hàng.

Các kết quả di chuyển dữ liệu đã mua và được phê duyệt phải được đối chiếu với bộ lọc, cách liên kết hoặc kết quả cấu hình đã xác định. Các hạng mục di chuyển dữ liệu không tiêu chuẩn đã thống nhất phải được đối chiếu với cách xử lý bảng tùy chỉnh, bản ghi extension cũ, mã định danh hệ thống ngoài, phép biến đổi riêng hoặc quan hệ front end đã được chấp nhận. Xác thực chỉ chứng minh kết quả đã thống nhất; không mở rộng phạm vi di chuyển dữ liệu đã được chấp nhận.

Hồ sơ xác thực cần ghi kết quả dự kiến, kết quả quan sát được, trạng thái quyết định, người phụ trách, hướng xử lý và kết quả kiểm thử lại. Cách ghi này giúp phân biệt cấu hình trên Nền tảng đích với lỗi di chuyển dữ liệu, đồng thời ngăn vấn đề dữ liệu chưa giải quyết bị xem nhẹ như công việc vận hành thông thường.

Kết luận

Xác thực osCommerce phải chứng minh mức độ sẵn sàng vận hành trên khả năng khám phá danh mục, ý nghĩa Products, Customers, nhóm Customers, Orders, Design and CMS, SEO, module và dữ liệu tùy chỉnh. Cửa hàng sau di chuyển dữ liệu chỉ đạt khi các bản ghi sử dụng được trong mô hình vận hành đích và đội ngũ có thể giải thích rõ phần nào còn là cấu hình, công việc extension, phạm vi di chuyển dữ liệu không tiêu chuẩn hoặc hạng mục chuẩn bị trước vận hành.

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

Số lượng bản ghi khớp có đủ để xác thực Di chuyển sang osCommerce không?

Số lượng bản ghi khớp vẫn chưa đủ để xác thực Di chuyển sang osCommerce. Số lượng hỗ trợ kiểm tra tính đầy đủ nhưng không chứng minh được ý nghĩa Products, khả năng hiển thị theo front end hoặc nhóm Customers, khả năng đọc lịch sử đơn hàng, quyền sở hữu CMS, dữ liệu module hay sự tiếp nối của URL.

Kiểm thử trên mẫu đại diện cần chứng minh điều gì với osCommerce?

Mẫu phải chứng minh cách diễn giải Products khó, quan hệ Categories và front end, nhóm Customers, Orders ngoại lệ, CMS Pages, URL ưu tiên và bản ghi extension hoặc bảng tùy chỉnh trước khi mô hình đó được áp dụng ở phạm vi di chuyển dữ liệu rộng hơn.

Có nên xác thực module thanh toán và vận chuyển như dữ liệu đã di chuyển không?

Nhãn thanh toán và vận chuyển trước đây là thông tin xác nhận từ Orders. Cách hoạt động trực tiếp của module thanh toán, vận chuyển, Tax, checkout, email và front end thuộc cấu hình Cửa hàng đích và cần kết quả kiểm thử vận hành riêng.

Nhiều front end của osCommerce cần được xác thực như thế nào?

Hãy rà soát từng front end quan trọng riêng biệt, bao gồm phân bổ Products và Categories, giới hạn nhóm Customers, ngôn ngữ, tiền tệ, nội dung, menu, giá trị SEO và cấu hình module riêng cho kênh đó.

Khi nào một vấn đề osCommerce phải được xếp Block?

Dùng Block khi vấn đề ngăn bán hàng, làm sai khả năng hiển thị theo kênh hoặc nhóm, khiến Orders trước đây gây hiểu nhầm, làm hỏng URL ưu tiên hoặc khiến một điều chỉnh di chuyển dữ liệu đã được phê duyệt hay kết quả di chuyển dữ liệu không tiêu chuẩn không sử dụng được.

Cần xác thực lại những gì sau một hành động Di chuyển osCommerce về sau?

Hãy xác thực lại mọi Products, Customers, Orders, Blog Posts, phân bổ front end, quan hệ nhóm, URL, trường module và bản ghi tùy chỉnh bị ảnh hưởng. Cấu hình thay đổi hoặc kết quả riêng biệt đòi hỏi phạm vi kiểm chứng rộng hơn so với tiếp tục bằng cấu hình đã được phê duyệt và không đổi.