Khi PrestaShop được chọn làm Nền tảng đích, quá trình di chuyển dữ liệu thực chất là chuyển ý nghĩa của Cửa hàng nguồn sang một mô hình catalog tách rõ biến thể có thể mua, đặc điểm dùng để mô tả Products, dữ liệu cá nhân hóa do khách hàng nhập, phạm vi từng shop và hành vi do module sở hữu. Những bản ghi quen thuộc như Products, Categories, Customers, Orders, Coupons, CMS Pages, hình ảnh và URL có thể mang ý nghĩa khác khi đi vào các quan hệ về biến thể, thuộc tính, nhóm khách hàng, multistore, ngôn ngữ và module của PrestaShop.
Điểm khác biệt cốt lõi là Nền tảng nguồn có thể dùng một lớp “option” hoặc trường tùy chỉnh chung để thực hiện nhiều chức năng khác nhau. Trên PrestaShop, một giá trị có thể cần trở thành thuộc tính dùng để tạo biến thể, thuộc tính mô tả của toàn bộ Products, trường cá nhân hóa do khách hàng điền, quan hệ giữa Products, phân bổ vào Categories, quan hệ nhóm khách hàng, giá trị riêng theo từng shop hoặc bản ghi do module sở hữu. Nếu chỉ đối chiếu theo tên trường mà không hiểu chức năng kinh doanh, catalog có thể đầy đủ về mặt kỹ thuật nhưng lại thiếu nhất quán trong cách bán hàng.
Mô hình catalog PrestaShop bắt đầu từ cấu trúc Products
Products trên PrestaShop có thể là Products tiêu chuẩn, Products có biến thể, pack hoặc Products ảo. Bản ghi Products còn liên kết với Categories, brand và supplier, hình ảnh, attachments, Products liên quan, thuộc tính mô tả, trường cá nhân hóa, giá, tồn kho, ngôn ngữ và phạm vi shop. Chính các quan hệ này quyết định Products được lựa chọn, hiển thị, quản lý và bán như thế nào.
| Ý nghĩa ở Cửa hàng nguồn | Câu hỏi cần trả lời ở PrestaShop | Hệ quả đối với quan hệ dữ liệu |
|---|---|---|
| Một mặt hàng có thể bán, không có phiên bản để khách lựa chọn | Có tiếp tục là Products tiêu chuẩn không? | Danh tính Products, reference, giá, tồn kho, hình ảnh, thuế, Categories và URL tiếp tục nằm ở cấp Products. |
| Kích thước, màu sắc, dung lượng, bề mặt hoặc phiên bản có thể mua khác | Các giá trị thuộc tính có nên tạo thành biến thể không? | Biến thể có thể sở hữu reference, chênh lệch giá, số lượng, hình ảnh và tập giá trị đã chọn. |
| Thông số ổn định như chất liệu hoặc xuất xứ | Có nên trở thành thuộc tính mô tả không? | Giá trị mô tả toàn bộ Products thay vì tạo ra một phiên bản Products khác để mua. |
| Văn bản hoặc tệp cá nhân hóa do khách hàng nhập | Có nên trở thành trường cá nhân hóa hoặc một cấu trúc đích khác không? | Thông tin khách hàng nhập được giữ tách biệt với thuộc tính tạo biến thể và đặc điểm mô tả. |
| Nhóm Products hiện có được bán cùng nhau | Đây là pack, quan hệ Products, Categories hay quan hệ merchandising khác? | Cấu trúc đích phải giữ danh tính từng Products và mục đích nhóm mà không tạo bản sao không cần thiết. |
| Lựa chọn hoặc bản ghi do module tạo | Module hoặc quy trình đích nào sẽ tiếp tục sở hữu dữ liệu này? | Không nên vô tình đẩy hành vi đang do extension quản lý vào các trường Products cốt lõi. |
Cách biểu diễn đúng phải dựa trên giá trị đó làm gì, không phải chỉ dựa trên nhãn. Ví dụ, “Color” có thể tạo biến thể, mô tả đặc điểm Products, phục vụ lọc/khám phá hoặc chỉ là đầu ra do module tạo. Chỉ nhìn vào tên “Color” là chưa đủ để quyết định cấu trúc đích.
Biến thể, thuộc tính, đặc điểm mô tả và trường cá nhân hóa không thể thay thế lẫn nhau
Biến thể trên PrestaShop đại diện cho các phiên bản Products có thể mua. Chúng được tạo từ các giá trị thuộc tính và có thể mang reference, chênh lệch giá, số lượng, hình ảnh, chênh lệch trọng lượng, trạng thái khả dụng và dữ liệu riêng ở cấp biến thể. Thuộc tính mô tả lại dùng để diễn giải đặc điểm chung của Products, không quyết định khách hàng đang mua phiên bản nào. Trường cá nhân hóa thu thập văn bản hoặc tệp do khách hàng cung cấp.
Sự tách biệt này phải được giữ rõ sau chuyển đổi:
| Cấu trúc trên PrestaShop | Ý nghĩa thương mại | Sai lầm nguồn-đích thường gặp |
|---|---|---|
| Nhóm thuộc tính và giá trị | Chiều lựa chọn như kích thước hoặc màu sắc | Biến thông số mô tả thành lựa chọn bắt buộc khách hàng phải chọn. |
| Biến thể | Một tổ hợp thuộc tính hợp lệ có thể mua | Làm phẳng biến thể thật vào một bản ghi Products và làm mất SKU con, giá, hình ảnh hoặc tồn kho. |
| Thuộc tính mô tả và giá trị | Đặc điểm ổn định của Products | Biến thông số cần phục vụ lọc hoặc so sánh thành văn bản tự do. |
| Trường cá nhân hóa | Văn bản hoặc tệp do khách hàng nhập | Biến dữ liệu cá nhân hóa thành giá trị thuộc tính cố định hoặc ghi chú Orders. |
| Pack | Quan hệ nhóm giữa Products hiện có | Nhân bản dữ liệu thành phần hoặc nhầm bundle với một biến thể. |
| Products ảo | Products phi vật lý với yêu cầu giao nội dung riêng | Giữ tham chiếu tệp nhưng làm mất quan hệ với Products và quyền truy cập. |
Nền tảng nguồn có thể lưu biến thể con dưới dạng những bản ghi Products riêng. Nếu chúng thực sự chỉ là các phiên bản của cùng một mặt hàng, PrestaShop có thể biểu diễn chúng dưới một bản ghi Products đóng vai trò cha với nhiều biến thể. Ngược lại, những Products có nội dung, cách merchandising, vòng đời hoặc danh tính báo cáo riêng không nên bị gộp thành biến thể.
Việc tạo biến thể cũng phụ thuộc vào bộ giá trị thuộc tính. Những giá trị nguồn không nhất quán như “Large”, “L” và “large” cần được rà soát trước khi trở thành các giá trị thuộc tính đích riêng biệt. Tuy nhiên, không được chuẩn hóa gộp các giá trị nếu chúng đang gắn với SKU, giá, tồn kho hoặc ý nghĩa hiển thị khác nhau.
Categories, brand, supplier và các quan hệ Products ảnh hưởng đến cách khách hàng khám phá catalog
Categories trên PrestaShop tạo các đường dẫn phân cấp trong catalog và có thể mang mô tả, hình ảnh, metadata, friendly URL, quan hệ Products và phạm vi shop. Một bản ghi Products có thể thuộc nhiều Categories nhưng vẫn cần xác định Categories chính làm ngữ cảnh ưu tiên. Brand, supplier, Products liên quan, accessories và pack tạo thêm các quan hệ phục vụ khám phá hoặc vận hành.
Nền tảng nguồn thường trộn nhiều vai trò này. Một collection có thể là nhóm Products ổn định, chiến dịch mùa vụ, trang tập hợp theo brand, kết quả lọc, lối tắt điều hướng hoặc landing page SEO. Nếu mọi nhóm nguồn đều được tạo thành Categories trên PrestaShop, cửa hàng mới có thể giữ lại cả sự lộn xộn và các mục đích trùng nhau.
| Cấu trúc nguồn | Ý nghĩa có thể có trên PrestaShop | Tín hiệu để quyết định |
|---|---|---|
| Nhóm phân cấp ổn định | Cây Categories | Khách hàng và nhân viên thực sự dùng phân cấp này như đường dẫn catalog ổn định. |
| Nhóm theo brand hoặc manufacturer | Quan hệ brand, Categories, thuộc tính mô tả hoặc trang nội dung | Cấu trúc đích phải phục vụ nhu cầu duyệt catalog, độ tin cậy, báo cáo và quản lý Products. |
| Tham chiếu supplier | Quan hệ supplier hoặc mã procurement ngoài hệ thống | Giá trị phục vụ sourcing hoặc quản trị, không phải nhất thiết phục vụ branding storefront. |
| Collection theo mùa hoặc chiến dịch | Categories tạm thời, quy tắc merchandising hoặc landing page nội dung | Không phải cấu trúc tạm thời nào cũng xứng đáng trở thành phân cấp catalog lâu dài. |
| Products liên quan hoặc phụ kiện | Quan hệ Products | Quan hệ phục vụ cross-sell mà không thay đổi danh tính Products. |
| Bundle gồm Products hiện có | Pack hoặc cấu trúc bundle đã xác định | Thành phần vẫn phải có danh tính riêng và bundle không bị biến thành biến thể giả. |
Quan hệ giữa Categories chính và friendly URL cần được chú ý đặc biệt vì ngữ cảnh Categories có thể ảnh hưởng đến cách đường dẫn Products được tạo và được hiểu. Products có thể vẫn thuộc đúng tập Categories nhưng lại nhận đường dẫn chính không mong muốn nếu quan hệ ưu tiên chưa được xác định.
Danh tính Customers phải tách khỏi cách nhóm khách hàng điều khiển thương mại
Bản ghi Customers trên PrestaShop mang danh tính, thông tin liên hệ, địa chỉ, trạng thái tài khoản, bối cảnh ngôn ngữ và quan hệ Orders. Nhóm khách hàng có thể ảnh hưởng đến cách cửa hàng phục vụ người mua thông qua giảm giá, hiển thị giá, quyền hiển thị hoặc các hành vi đã cấu hình khác. Vì vậy, nhóm không chỉ là một nhãn.
| Mô hình Customers ở nguồn | Câu hỏi cho mô hình đích | Kết quả cần giữ |
|---|---|---|
| Tài khoản bán lẻ thông thường | Danh tính, địa chỉ, ngôn ngữ và liên kết Orders nào là thông tin chính thức? | Lịch sử Customers tiếp tục gắn với đúng tài khoản. |
| Người mua wholesale hoặc trade | Nhóm, giá, thuế, quyền hiển thị hay quan hệ tài khoản ngoài hệ thống nào quyết định cách phục vụ? | Danh tính người mua được tách khỏi các quy tắc thương mại áp dụng cho người mua đó. |
| Phân khúc khách hàng thân thiết hoặc tư cách thành viên | Giá trị này nên là nhóm cốt lõi, bản ghi module, phân khúc CRM hay chỉ là nhãn lịch sử? | Chỉ giữ quan hệ còn tiếp tục được sử dụng trong cửa hàng mới. |
| Guest buyer | Orders có nên giữ danh tính giao dịch mà không tạo tài khoản Customers thông thường không? | Có thể diễn giải lịch sử đơn hàng mà không tạo cảm giác sai rằng tài khoản vẫn liên tục như cũ. |
| Customers trùng lặp | Bản ghi nào sẽ sở hữu email, địa chỉ, Orders và ID bên ngoài? | Quyết định hợp nhất không được làm đứt liên kết với Orders. |
Ở Cửa hàng nguồn, nhóm khách hàng có thể từng ảnh hưởng đến giá, thuế, quyền truy cập catalog, quy trình phê duyệt hoặc giao tiếp nằm ngoài chức năng cốt lõi. Chỉ chuyển tên nhóm không thể giữ được các kết quả đó. Mô hình đích phải chỉ ra chức năng nào thuộc cấu hình PrestaShop, hành vi nào thuộc module và hành vi nào tiếp tục thuộc CRM hoặc ERP bên ngoài.
Multistore bổ sung quyền sở hữu theo shop cho các bản ghi dùng chung
Multistore của PrestaShop cho phép một back office quản lý nhiều shop hoặc nhóm shop. Vì vậy, Products, Categories, Customers, nội dung, ngôn ngữ, tiền tệ, URL và cách module hoạt động có thể được dùng chung, kế thừa hoặc tách riêng theo shop. Số lượng bản ghi không thể chứng minh quyền sở hữu này đã được giữ đúng.
| Khu vực multistore | Quyết định về quyền sở hữu |
|---|---|
| Products và biến thể | Shop nào nhận Products, biến thể, quyền hiển thị, giá và bối cảnh số lượng? |
| Categories | Cây gốc nào và quan hệ shop nào quyết định vị trí trong catalog? |
| Customers và nhóm khách hàng | Danh tính nào và cách phục vụ thương mại nào dùng chung hoặc tách riêng theo shop? |
| Ngôn ngữ và trường nội dung được bản địa hóa | Tên, mô tả, slug và metadata nào thuộc từng ngôn ngữ và shop? |
| CMS Pages và nội dung | Storefront, ngôn ngữ, đường dẫn điều hướng hoặc domain nào sở hữu nội dung? |
| URL và domain | Shop nào thay thế mỗi route nguồn quan trọng? |
| Module | Bản ghi hoặc cấu hình module áp dụng toàn cục, theo nhóm shop hay theo từng shop? |
Nếu làm phẳng mọi quan hệ shop về shop mặc định, dữ liệu có thể trông đầy đủ nhưng ranh giới thương hiệu, khu vực, ngôn ngữ hoặc B2B/B2C sẽ biến mất. Ngược lại, nhân bản toàn bộ bản ghi dùng chung cho từng shop tạo ra khác biệt không cần thiết và khiến quản lý catalog sau này khó hơn.
Orders giữ thông tin giao dịch, không phải cấu hình vận hành tương lai
Orders trên PrestaShop liên kết Customers hoặc guest buyer với snapshot Products, biến thể, số lượng, giá, giảm giá, thuế, vận chuyển, nhãn thanh toán, địa chỉ, tin nhắn, lịch sử trạng thái và tham chiếu module. Lịch sử đơn hàng cần tiếp tục dễ hiểu ngay cả khi quy trình nguồn không có cấu trúc tương ứng hoàn toàn trên PrestaShop.
| Quan hệ trong Orders | Ý nghĩa cần giữ trong bản ghi đích |
|---|---|
| Chi tiết mặt hàng và biến thể | Tên Products đã mua, reference, thuộc tính đã chọn, số lượng và giá tại thời điểm giao dịch. |
| Danh tính Customers hoặc guest buyer | Bối cảnh người mua và quan hệ với dữ liệu tài khoản lịch sử. |
| Địa chỉ | Snapshot thanh toán và giao hàng đã dùng cho giao dịch. |
| Giảm giá và voucher | Ảnh hưởng lịch sử lên Orders, không phải tự động tái tạo quy tắc khuyến mãi cho tương lai. |
| Nhãn thanh toán và carrier | Thông tin về giao dịch cũ, không chứng minh module tương ứng đã hoạt động ở cửa hàng mới. |
| Trạng thái và tin nhắn | Lịch sử quy trình và bối cảnh hỗ trợ có thể cần chuyển nghĩa trạng thái. |
| Tham chiếu module hoặc hệ thống ngoài | Khóa liên hệ giữa các hệ thống hoặc ngữ cảnh do extension sở hữu với mục đích đích đã xác định. |
Module thanh toán, carrier, quy tắc thuế, mẫu email hoặc tùy biến checkout là vấn đề cấu hình đang hoạt động ở Nền tảng đích. Có thể giữ nhãn lịch sử mà không làm cho người đọc hiểu nhầm rằng quy trình tương lai đã được triển khai. Ranh giới này giúp Orders tiếp tục hữu ích cho hỗ trợ khách hàng và tài chính nhưng không biến lịch sử giao dịch thành bằng chứng về mức độ sẵn sàng vận hành.
Module, override, theme và dữ liệu tùy chỉnh cần có chủ sở hữu rõ ràng
Hệ sinh thái module và override của PrestaShop có thể mở rộng Products, biến thể, Customers, Orders, checkout, khuyến mãi, Reviews, loyalty, feed marketplace, SEO, vận chuyển, thanh toán, analytics và quản trị. Một giá trị hiển thị trong back office hoặc storefront vì vậy có thể đến từ bảng dữ liệu cốt lõi, bảng module, override, quy tắc theme hoặc hệ thống bên ngoài.
| Loại yếu tố phụ thuộc | Cách hiểu trong mô hình dữ liệu |
|---|---|
| Bản ghi do module sở hữu | Xác định Products, Customers, Orders, nội dung hoặc bản ghi ngoài hệ thống nào là bản ghi cha và module đích nào sẽ tiếp tục sử dụng dữ liệu. |
| Trường tùy chỉnh trên bản ghi cốt lõi | Chỉ dùng trường gốc hoặc trường extension được quản lý khi đã xác định được chủ sở hữu đích. |
| Override hoặc code riêng | Xác định code đang thay đổi cách lưu, tính toán, validation hay hiển thị thay vì mặc định xem đây là dữ liệu có thể chuyển nguyên trạng. |
| Trường thuộc theme | Tách nội dung bền vững khỏi layout hoặc markup chỉ có ý nghĩa với theme nguồn. |
| ID bên ngoài | Giữ khóa ERP, CRM, PIM, kế toán, marketplace hoặc xử lý đơn hàng trong một quan hệ tích hợp được quản lý rõ. |
| Đầu ra cache hoặc dữ liệu suy ra | Tái tạo từ dữ liệu đích chính thức thay vì sao chép phần dư kỹ thuật đã cũ. |
Không nên sao chép phần dư của module chỉ vì dữ liệu đó đang tồn tại. Ngược lại, trường do module sở hữu nhưng đang quyết định danh tính Products, quyền lợi Customers, cách hiểu Orders hoặc khả năng liên kết tích hợp không thể bị xem là metadata tùy chọn. Mô hình đích phải xác định hệ thống hoặc module nào sẽ tiếp tục dùng dữ liệu đó.
Nội dung, ngôn ngữ và URL đều mang theo bối cảnh shop
Các trường nội dung của Products, Categories, CMS Pages và những đối tượng khác trên PrestaShop có thể được bản địa hóa. Tên, mô tả, slug, metadata và chú thích hình ảnh có thể khác theo ngôn ngữ và shop. Trong khi đó, Nền tảng nguồn có thể dùng các Store tách biệt, bản ghi nhân bản, plugin dịch hoặc URL riêng theo ngôn ngữ.
Mô hình đích cần tách danh tính dùng chung khỏi cách biểu đạt theo ngôn ngữ. Một bản ghi Products có thể giữ chung reference và cấu trúc quan hệ, trong khi tên, mô tả, slug và metadata thay đổi theo ngôn ngữ. Bản ghi nguồn chỉ khác ngôn ngữ không nên trở thành Products trùng lặp nếu về bản chất vẫn là cùng một mặt hàng thương mại.
URL cũng phải gắn với đối tượng sở hữu rõ ràng. Route nguồn có thể đại diện cho Products, Categories, trang brand, CMS Pages, đường dẫn ngôn ngữ hoặc domain của một shop. Route đích phải đi đến đúng đối tượng PrestaShop và đúng bối cảnh shop thay thế cho mục đích đó. Chỉ giữ chuỗi friendly URL mà thiếu bản ghi, ngôn ngữ và quan hệ shop tương ứng là chưa đủ.
Phải xác định chủ sở hữu đích trước khi chuyển từng trường dữ liệu
Một mô hình PrestaShop hoàn chỉnh cần đưa mỗi giá trị nguồn quan trọng vào một trong những kết quả sau:
- một quan hệ gốc của Products, biến thể, thuộc tính, đặc điểm mô tả, trường cá nhân hóa, Categories, Customers, Orders, nội dung hoặc shop;
- một trường module hoặc trường tùy chỉnh được quản lý và có chủ sở hữu đích tiếp tục sử dụng;
- một quan hệ với hệ thống ngoài có mã định danh ổn định cần tiếp tục truy vết được;
- cấu hình hoặc phần trình bày phải được xây lại trên Nền tảng đích thay vì chuyển như dữ liệu;
- phần dữ liệu cũ không còn mục đích sử dụng và nên được lưu trữ hoặc loại khỏi phạm vi.
| Khu vực quyết định | Câu hỏi về chủ sở hữu đích |
|---|---|
| Biến thể Products | Products và tổ hợp thuộc tính nào sở hữu SKU, giá, số lượng, hình ảnh và danh tính có thể mua? |
| Thông tin Products | Giá trị nào là thuộc tính mô tả, nội dung, attachment hoặc nội dung theo ngôn ngữ thay vì biến thể? |
| Khả năng khám phá catalog | Categories, brand, supplier, quan hệ Products và URL nào giữ đúng mục đích tìm kiếm của khách hàng? |
| Cách phục vụ Customers | Nhóm khách hàng hoặc quan hệ ngoài hệ thống nào quyết định giá, quyền hiển thị, thuế hoặc quyền lợi? |
| Multistore | Shop hoặc nhóm shop nào sở hữu từng phân bổ và giá trị theo ngôn ngữ? |
| Dữ liệu module/tùy chỉnh | Module, đội ngũ hoặc hệ thống bên ngoài nào sẽ tiếp tục sử dụng bản ghi? |
Cách nhìn theo chủ sở hữu này giúp PrestaShop không trở thành nơi chứa các nhãn được sao chép từ Cửa hàng nguồn. Catalog sau chuyển đổi có thể vận hành như một hệ thống Products, Customers, Orders, nội dung, shop và module có quan hệ rõ ràng.
Kết luận
Khác biệt quan trọng trong mô hình dữ liệu PrestaShop nằm ở việc tách Products khỏi biến thể, thuộc tính tạo lựa chọn khỏi đặc điểm mô tả, nội dung cố định khỏi dữ liệu cá nhân hóa do khách hàng nhập, danh tính Customers khỏi cách nhóm khách hàng điều khiển thương mại, bản ghi dùng chung khỏi quyền sở hữu theo multistore, lịch sử đơn hàng khỏi cấu hình tương lai và dữ liệu cốt lõi khỏi extension do module sở hữu.
Một dự án chuyển đổi đáng tin cậy phải giữ được các ranh giới này trước khi quyết định cách chuyển từng trường dữ liệu. Kết quả không chỉ là cơ sở dữ liệu đã có bản ghi; mô hình đích phải là một mô hình catalog và tài khoản đích nơi dữ liệu vẫn giữ ý nghĩa thương mại rõ ràng qua từng shop, ngôn ngữ, module và hệ thống được kết nối.
Câu hỏi thường gặp
Vì sao biến thể trên PrestaShop khác với tùy chọn Products nói chung?
Biến thể là phiên bản Products có thể mua được tạo từ các giá trị thuộc tính. Biến thể có thể sở hữu reference, chênh lệch giá, số lượng, hình ảnh, trọng lượng và trạng thái khả dụng riêng. Thuộc tính mô tả hoặc dữ liệu cá nhân hóa do khách hàng nhập có vai trò khác.
Thuộc tính mô tả trên PrestaShop có giống thuộc tính tạo biến thể không?
Hai cấu trúc này không giống nhau. Thuộc tính tạo lựa chọn giúp hình thành biến thể có thể mua, còn thuộc tính mô tả diễn giải đặc điểm ổn định của Products. Nhầm hai loại có thể biến thông số thành lựa chọn thừa hoặc làm phẳng biến thể thật thành văn bản mô tả.
Nên xử lý biến thể nguồn đang được lưu như những bản ghi Products riêng như thế nào?
Trước tiên cần xác định chúng là các phiên bản của cùng một mặt hàng hay là các mặt hàng thương mại độc lập. Danh tính dùng chung, nội dung chung, khác biệt để khách chọn, quyền sở hữu SKU, tồn kho, giá và vòng đời sẽ giúp quyết định có nên dùng biến thể hay không.
Vì sao nhóm khách hàng không thể chỉ được đối chiếu theo tên?
Nhóm khách hàng có thể liên quan đến giảm giá, hiển thị giá, quyền hiển thị, thuế hoặc cách module hoạt động. Chỉ nên giữ quan hệ Customers-nhóm cùng với định nghĩa rõ về cách phục vụ thương mại nào sẽ tiếp tục hoạt động trên cửa hàng đích.
Multistore làm thay đổi mapping dữ liệu như thế nào?
Multistore bổ sung quyền sở hữu theo shop và nhóm shop cho Products, Categories, Customers, nội dung, ngôn ngữ, URL và module. Bản ghi dùng chung nên tiếp tục dùng chung khi phù hợp, còn phân bổ riêng theo shop không được làm phẳng về shop mặc định.
Dữ liệu do module sở hữu nên được xử lý như thế nào?
Cần truy vết từng bản ghi module về đối tượng cha, ý nghĩa kinh doanh và hệ thống đích sẽ tiếp tục sử dụng. Bản ghi còn giá trị sử dụng và khóa tích hợp cần được giữ khi còn mục đích; hành vi đang hoạt động phải được xây lại ở môi trường đích; dữ liệu cache, dữ liệu suy ra hoặc phần dư đã lỗi thời không có chủ sở hữu tiếp tục nên được loại khỏi phạm vi.