Chuyển sang Magento cần được lập kế hoạch như một quá trình diễn giải dữ liệu, không chỉ là chuyển bản ghi từ hệ thống này sang hệ thống khác. Magento có thể tiếp nhận những nhóm dữ liệu commerce quen thuộc như Products, Categories, Customers, Orders, images, Coupons, CMS Pages, Blog Posts và Reviews, nhưng ý nghĩa của các bản ghi này phụ thuộc vào cấu trúc catalog, cách quản lý thuộc tính, hệ phân cấp website/store/store view, mô hình inventory, cách xử lý URL và hệ sinh thái extensions của Magento.
Một option của Products ở Nền tảng nguồn có thể cần được thể hiện thành quan hệ configurable, custom option, lựa chọn trong bundle, quan hệ grouped, cấu hình downloadable hoặc một giá trị nằm ngoài mô hình catalog có sẵn. Một trường nguồn chỉ nên trở thành thuộc tính Magento khi có mục đích rõ trên Cửa hàng đích. Giá trị riêng theo ngôn ngữ có thể cần gán theo store view thay vì ghi đè giá trị toàn cục. Tag của Customers có thể cần được xem xét như nhóm Customers hoặc dữ liệu tùy chỉnh. URL cũ có thể cần URL rewrite hoặc kế hoạch redirect thay vì chỉ sao chép trang.
Câu hỏi quan trọng không phải Magento có chỗ để lưu dữ liệu hay không. Cần xác định Magento có thể sử dụng dữ liệu sau khi di chuyển theo đúng cách doanh nghiệp cần để bán hàng, tổ chức catalog, filtering, địa phương hóa content, áp dụng pricing, xử lý đơn hàng, hỗ trợ khách hàng và duy trì cửa hàng sau khi chính thức vận hành hay không.
Ý nghĩa dữ liệu trên Magento phụ thuộc vào cấu trúc
Magento có mức độ cấu hình cao, nhưng điều đó đồng nghĩa cấu trúc đích phải được xác định rõ. Loại Products, thuộc tính, attribute sets, website, store, store view, thiết lập inventory, đường dẫn Categories, URL keys, nhóm Customers, bản ghi Orders và extensions đều cần được thể hiện rõ trong phạm vi công việc của dự án.
Một Cửa hàng nguồn có file export đơn giản vẫn có thể ẩn nhiều ý nghĩa phức tạp. Lựa chọn trên Products có thể trông như nhãn văn bản nhưng thực tế quyết định SKU, giá, tồn kho, images hoặc cách xử lý đơn hàng. Tag Customers có thể trông như thông tin tham khảo nhưng lại điều khiển pricing, tax class hoặc segmentation. Tên Categories có thể trông như trường phân nhóm nhưng đồng thời mang giá trị navigation và SEO. trường do custom module tạo có thể tồn tại trong cơ sở dữ liệu nhưng không có đích tiêu chuẩn trong Magento.
| Mô hình dữ liệu ở nguồn | Câu hỏi cần trả lời trên Magento | Hàm ý khi chuyển đổi |
|---|---|---|
| Variants hoặc options của Products | Lựa chọn nên trở thành các bản ghi Products loại simple, quan hệ configurable, bundle options, grouped Products, custom options hay dữ liệu cần xử lý riêng? | Cách Products hoạt động, chi tiết mặt hàng trong Orders, inventory và công việc bảo trì phụ thuộc vào cấu trúc đã chọn. |
| trường của Products tùy chỉnh | Giá trị nên trở thành trường có sẵn, thuộc tính Products, content theo store view, tham chiếu cho các tích hợp hay dữ liệu theo scope cần xử lý riêng? | Cách quản lý thuộc tính ảnh hưởng đến filtering, search, merchandising, trải nghiệm quản trị và các lần import sau. |
| Giá trị theo ngôn ngữ hoặc thị trường | Giá trị nên áp dụng toàn cục, theo website, theo store hay theo store view? | Scope ảnh hưởng đến tên, mô tả, việc gán Categories, metadata, URL keys và khả năng hiển thị theo từng storefront. |
| Tags, roles hoặc nhóm Customers | Giá trị nên trở thành nhóm Customers, metadata, ghi chú segmentation hay dữ liệu tùy chỉnh? | Pricing, tax class, giảm giá, cách phục vụ và reporting có thể phụ thuộc vào cách diễn giải đúng. |
| Giá trị inventory | Một con số quantity đã đủ hay còn phải xét sources, stock status, reservations, backorders và cách xử lý đơn hàng? | Inventory có thể trông đầy đủ nhưng số lượng thực sự có thể bán vẫn sai. |
| URLs cũ và routes content | Đường dẫn nên trở thành URL key, URL rewrite, redirect, CMS Page, Blog Posts hay custom route? | Duy trì giá trị SEO và khả năng khách hàng tiếp tục truy cập đúng nội dung phụ thuộc vào kế hoạch ở cấp route, không chỉ việc content có tồn tại. |
| Bản ghi do extensions quản lý | Magento có cấu trúc có sẵn cho dữ liệu đó hay cần xử lý riêng? | Dữ liệu extension không được hỗ trợ không nên bị làm phẳng thành trường thông thường. |
Cách tiếp cận ưu tiên cấu trúc giúp tránh cảm giác hoàn tất không có cơ sở. Tổng số bản ghi cho biết dữ liệu đã được đưa sang đến đâu, nhưng không chứng minh Magento đang hiểu và sử dụng dữ liệu đúng.
Loại Products thay đổi cách catalog hoạt động
Kế hoạch Products trên Magento phải bắt đầu từ ý nghĩa của từng loại Products. Tùy cách doanh nghiệp bán hàng và cách Nền tảng nguồn biểu diễn catalog, một bản ghi Products có thể cần trở thành loại simple, configurable, grouped, bundle, virtual hoặc downloadable. Những cấu trúc chỉ có trong Adobe Commerce hoặc do extension cài thêm cung cấp không nên được mặc định là có sẵn trong Magento.
Products loại simple thường dễ xác định hơn khi mỗi mặt hàng có SKU, giá và cách quản lý inventory riêng. Products loại configurable khác ở chỗ một bản ghi Products hiển thị trên storefront có thể đại diện cho nhiều bản ghi Products loại simple được liên kết, mỗi bản ghi có SKU và ý nghĩa inventory riêng. Products loại bundle lại cho phép khách hàng chọn thành phần hoặc cấu hình. Grouped Products trình bày nhiều Products loại simple có liên quan nhưng vẫn được mua như những mặt hàng riêng. Products loại virtual và downloadable thay đổi yêu cầu về shipping, xử lý đơn hàng và cách đọc lịch sử mua hàng.
| Quyết định về Products | Cách thể hiện trên Magento | Hệ quả khi chuyển đổi |
|---|---|---|
| Một mặt hàng, một SKU | Products loại simple có thể là đủ. | SKU mang ý nghĩa riêng về giá, khả năng hiển thị, Taxes, media, Categories và inventory. |
| Một bản ghi Products có options kích thước/màu sắc và tồn kho độc lập | Có thể cần Products loại configurable cùng các bản ghi Products loại simple được liên kết. | SKU con, thuộc tính tạo lựa chọn, inventory, images và danh tính mặt hàng trong Orders phải tiếp tục liên kết đúng. |
| Kit hoặc package có thể cấu hình | Có thể cần cấu trúc bundle hoặc một mô hình đích khác. | Lựa chọn thành phần, cách tính giá, quyền quản lý inventory và ý nghĩa xử lý đơn hàng phải được xác định rõ trong cấu trúc đích. |
| Nhiều Products liên quan được bán cùng nhau nhưng vẫn độc lập | Cấu trúc grouped có thể phù hợp. | Cửa hàng đích phải phân biệt quan hệ merchandising với một package hoặc bundle bắt buộc. |
| Dịch vụ không cần shipping | Cách xử lý Products loại virtual có thể phù hợp. | Bản ghi không nên mang ý nghĩa shipping vật lý mà mặt hàng nguồn chưa từng có. |
| Products kỹ thuật số | Có thể cần Products loại downloadable. | Files, links, quyền truy cập sau mua và cách đọc Orders trước đây cần đích dữ liệu rõ ràng. |
Loại Products không chỉ quyết định storefront. Cấu trúc này còn ảnh hưởng đến import, inventory, cách trang Products hoạt động, filters, checkout, chi tiết mặt hàng trong Orders, reporting và công việc hỗ trợ. Products có thể trông đúng với khách hàng nhưng vẫn khó quản lý trong giao diện quản trị nếu loại Products trên Magento được chọn sai.
Thuộc tính và attribute sets cần được quản lý theo mục đích sử dụng
Thuộc tính là một trong những khác biệt quan trọng nhất của mô hình dữ liệu Magento. Thuộc tính mô tả Products, cung cấp thông tin cho trang Products, xác định kiểu input, hỗ trợ search và layered navigation, phục vụ so sánh Products và có thể tham gia vào promotions. Attribute sets đóng vai trò như bộ khung cho từng dòng sản phẩm, xác định những thuộc tính nào xuất hiện khi tạo hoặc quản lý Products.
Mô hình này rất linh hoạt nhưng dễ trở nên lộn xộn sau chuyển đổi. Nhiều Nền tảng nguồn cho phép các trường dạng tự do, tags, meta values, các trường của plugin hoặc custom columns. Nếu đưa tất cả vào Magento dưới dạng thuộc tính, giao diện quản lý Products có thể chứa quá nhiều trường, giá trị trùng, filters thiếu nhất quán và kết quả search kém hữu ích. Nếu chuyển quá ít, doanh nghiệp lại có thể mất thông số quan trọng, dữ liệu merchandising hoặc định danh các tích hợp.
| Mục đích của trường | Câu hỏi cần trả lời trên Magento |
|---|---|
| Hiển thị trên trang Products | Khách hàng có cần thấy giá trị này không và dữ liệu đã đủ sạch để công khai chưa? |
| Search và layered navigation | Giá trị có đủ nhất quán để dùng cho filtering, search weighting hoặc giúp khách hàng tìm Products không? |
| So sánh Products | Giá trị có giúp người mua so sánh Products theo cách có ý nghĩa không? |
| Promotions hoặc merchandising | Giá trị có đủ ổn định để tham gia vào rules hoặc xác định đối tượng campaign không? |
| Quản lý trong giao diện quản trị | trường có giúp đội ngũ quản lý Products hay chỉ làm tăng lượng thông tin không cần thiết? |
| Duy trì các tích hợp | Giá trị nên là thuộc tính Magento, trường do extension quản lý, định danh dùng giữa nhiều hệ thống hay dữ liệu nên tiếp tục nằm ở hệ thống bên ngoài? |
Attribute sets cũng cần được thiết kế theo nhu cầu thực tế. Catalog có thời trang, phụ tùng thay thế, files tải xuống, thiết bị, phụ kiện và dịch vụ không nhất thiết nên ép tất cả Products vào một attribute set quá rộng. Ngược lại, tạo quá nhiều attribute sets sẽ làm việc bảo trì lâu dài phức tạp hơn. Mục tiêu là duy trì đúng ý nghĩa thuộc tính mà không biến giao diện quản trị Magento thành kho lưu trữ mọi trường từng tồn tại ở nguồn.
Scope website/store/store view thay đổi nơi dữ liệu cần được đặt
Hệ phân cấp website, store và store view của Magento có thể thay đổi cấp mà một giá trị sau khi di chuyển cần được áp dụng. Nền tảng nguồn có thể dùng storefront riêng, thư mục ngôn ngữ, markets, domains, nhóm Customers hoặc nhánh catalog. Magento có thể biểu diễn một phần những khác biệt đó bằng scope website/store/store view, nhưng không có quan hệ tương ứng tự động.
Store view thường được dùng cho các locale khác nhau, nên đặc biệt quan trọng với tên Products, mô tả, metadata, URL keys, CMS Pages và nhãn Categories theo ngôn ngữ. Website và store có thể ảnh hưởng đến cấu trúc catalog, root Categories, cách tài khoản Customers hoạt động, cấu hình và cách storefront được tổ chức. Một installation Magento có thể chứa nhiều website, store và store view, vì vậy mỗi giá trị theo scope phải được gán đúng cấp thay vì kế thừa nguyên cấu trúc Cửa hàng nguồn.
| Mô hình ở nguồn | Câu hỏi về scope trên Magento | Hệ quả về cấu trúc |
|---|---|---|
| Nhiều ngôn ngữ | trường nào nên thay đổi theo store view? | Giá trị đã địa phương hóa có thể ghi đè dữ liệu toàn cục hoặc xuất hiện sai storefront. |
| Nhiều brands hoặc domains | Nên trở thành website, store, store view, Categories hay dự án riêng? | Giả định về catalog, URLs, Customers và cấu hình có thể bị trộn lẫn. |
| Pricing hoặc khả năng hiển thị riêng theo thị trường | Scope đích nào có thể tạo đúng chức năng dự kiến? | Products có thể xuất hiện sai ngữ cảnh bán hàng hoặc áp dụng sai kỳ vọng về giá/hiển thị. |
| Nhiều root Categories | Root Categories nào thuộc từng store? | Navigation có thể được chuyển nhưng không còn phù hợp với storefront dự kiến. |
| CMS Pages hoặc Blog Posts đã địa phương hóa | Content nào cần được gán theo store view hoặc có kế hoạch route riêng? | Content có thể tồn tại nhưng không hiển thị, bị trùng hoặc được gán sai. |
Đây là một trong những lý do kết quả Magento không thể được đánh giá chỉ qua một giao diện quản trị. Cùng một bản ghi Products hoặc một page có thể cần được kiểm tra trong nhiều bối cảnh storefront khác nhau.
Categories, URLs, CMS Pages và Blog Posts có quan hệ trực tiếp với nhau
Di chuyển Categories trên Magento không nên được xem như chuyển nhãn phân loại. Categories có thể định hình navigation, cách khách hàng tìm Products, URL paths, merchandising và cấu trúc store. Tùy kế hoạch đích, cây Categories ở nguồn có thể cần được giữ lại, đơn giản hóa, tách theo root Categories, địa phương hóa, redirect hoặc tổ chức lại.
URLs cũng cần được xử lý với mức độ cẩn trọng tương tự. URLs của Products, URLs của Categories, routes của CMS Pages, Blog Posts, redirects cũ và custom routes đều có thể mang giá trị SEO hoặc giúp khách hàng tiếp tục đến đúng nội dung. Trang Products đã có trên Cửa hàng đích không có nghĩa URL cũ đã được xử lý. CMS Page đã tồn tại cũng không chứng minh internal links, metadata, menus và khả năng hiển thị theo store view đều đúng.
| Hạng mục | Câu hỏi cần trả lời khi chuyển sang Magento |
|---|---|
| Hệ phân cấp Categories | Categories nào phục vụ navigation cho khách hàng, tổ chức trong giao diện quản trị hoặc cả hai? |
| URL keys | Giá trị URL của Products, Categories, CMS Pages hoặc Blog Posts nào cần được duy trì? |
| URL rewrites và redirects | Đường dẫn cũ nào cần tiếp tục truy cập được hoặc được chuyển hướng đến trang đích phù hợp? |
| CMS Pages | Trang chính sách, landing pages, content pages và brand pages nào cần có trong Magento? |
| Blog Posts | Blog Posts thuộc phạm vi được hỗ trợ, thuộc hệ thống blog bên ngoài hay cần cách xử lý riêng theo scope? |
| Internal links | Các links trong content có trỏ đúng đến đường dẫn Magento sau khi chính thức vận hành không? |
| Routes theo store view | Đường dẫn theo locale hoặc thị trường có được liên kết đúng không? |
Nhóm vấn đề này thường nằm ở giao điểm giữa di chuyển dữ liệu, duy trì SEO và cấu hình trên Nền tảng đích. Không cần lặp lại toàn bộ nguyên tắc SEO chung, nhưng kế hoạch chuyển đổi phải duy trì đúng mục đích của những routes quan trọng khi URL cũ còn giá trị.
Inventory và xử lý đơn hàng phụ thuộc vào nhiều yếu tố hơn quantity
Ý nghĩa inventory trên Magento có thể liên quan đến quantity, stock status, loại Products, source assignment, cấu hình stock, backorders, reservations, salable quantity và hệ thống bên ngoài đang quản lý inventory. Trong Inventory Management, sources đại diện cho các địa điểm giữ hàng vật lý, còn stocks tổng hợp khả năng bán từ các sources theo sales channel. Vì vậy, một file export ở nguồn chỉ có một cột quantity có thể không đủ để xác định Magento phải tính lượng hàng có thể bán như thế nào.
Điều này đặc biệt quan trọng với Products loại configurable vì inventory thường thuộc các bản ghi Products loại simple được liên kết, không chỉ Products cha hiển thị trên storefront. Bundle và grouped Products có thể tạo thêm quan hệ cần xử lý. Cửa hàng multi-source hoặc vận hành theo warehouse có thể cần diễn giải source/stock, còn inventory do ERP quản lý có thể cần kế hoạch các tích hợp vượt ra ngoài dữ liệu di chuyển dữ liệu.
| Mô hình inventory | Vấn đề cần xác nhận trên Magento | Quan hệ đích cần đạt |
|---|---|---|
| SKU simple có quantity | Liên kết stock cơ bản có thể là đủ. | Xác nhận SKU, quantity, stock status và khả năng bán trên storefront. |
| Products loại configurable | Stock phụ thuộc vào các bản ghi Products loại simple được liên kết. | Tồn kho của SKU con, options có thể bán, cách Products cha hiển thị và chi tiết mặt hàng trong Orders tiếp tục liên kết đúng. |
| Bundle hoặc kit | Khả năng có hàng của component có thể ảnh hưởng đến việc Products có thể bán. | Quan hệ giữa component, giá, inventory và xử lý đơn hàng có cấu trúc đích rõ. |
| Warehouse hoặc multi-source inventory | Source và stock assignment có thể quyết định kết quả. | Xác nhận nguồn quản lý, salable quantity và cách xử lý đơn hàng dự kiến. |
| Hệ thống inventory bên ngoài | di chuyển dữ liệu có thể chỉ chuyển một snapshot tại thời điểm cụ thể. | Xác định Magento hay hệ thống inventory bên ngoài chịu trách nhiệm duy trì quantity và khả năng bán sau đó. |
Inventory phải được thể hiện theo ý nghĩa vận hành. Quantity có thể được chuyển chính xác nhưng salable quantity vẫn sai nếu quan hệ Products, stock status, source assignment, reservations hoặc quyền quản lý inventory bên ngoài không được thiết lập đúng.
Customers và Orders cần giữ đúng ý nghĩa lịch sử lẫn vận hành
Bản ghi Customers trên Magento có thể gồm danh tính tài khoản, địa chỉ, nhóm Customers, trạng thái newsletter, lịch sử đơn hàng, thông tin liên quan đến Taxes và các trường tùy chỉnh. Một trường của Customers ở nguồn có thể chỉ mang tính tham khảo trên nền tảng này nhưng lại quyết định vận hành trên nền tảng khác. Nhóm Customers cần được chú ý riêng vì có thể ảnh hưởng đến giảm giá, tax class, segmentation, cách phục vụ và một số yêu cầu tương tự B2B.
Orders cần duy trì đủ thông tin lịch sử để phục vụ hỗ trợ khách hàng, đối chiếu kế toán, rà soát tài khoản, xử lý returns và công việc vận hành. Nhãn payment và shipping trong lịch sử cần tiếp tục đọc được, nhưng không nên bị nhầm với cấu hình payment gateway hoặc shipping method đang hoạt động trên Cửa hàng đích.
| Nhóm dữ liệu | Câu hỏi cần trả lời trên Magento |
|---|---|
| Nhóm Customers | Nhóm chỉ mang tính tham khảo, quyết định pricing, Taxes, segmentation hay thuộc cách xử lý riêng? |
| Địa chỉ | Địa chỉ billing/shipping có đủ để hỗ trợ dịch vụ và tra cứu lịch sử Taxes không? |
| Trạng thái Orders | Trạng thái ở nguồn cần giữ lại để đọc lịch sử hay thực sự phải tái tạo workflow tương ứng? |
| Lựa chọn Products trong Orders | Chi tiết mặt hàng sau khi di chuyển có giữ đúng thuộc tính, options và tùy chỉnh đã được chọn không? |
| Nhãn payment và shipping | Đây là thông tin lịch sử hay thiết lập cần hoạt động trên Nền tảng đích? |
| Tham chiếu hệ thống bên ngoài | Có cần giữ ERP IDs, PIM keys, marketplace references, CRM IDs, định danh đăng ký định kỳ hoặc mã kế toán không? |
Lịch sử đơn hàng trên Magento cần tiếp tục hữu ích, nhưng không thay thế cấu hình cho checkout, payment, Taxes, shipping hoặc workflows xử lý đơn hàng đang hoạt động.
Extensions, custom modules và dữ liệu tùy chỉnh cần có ranh giới rõ
Cửa hàng Magento thường phụ thuộc vào extensions, custom modules, themes, các tích hợp và thay đổi riêng trong cơ sở dữ liệu. Đây là một trong những khác biệt lớn nhất so với các nền tảng SaaS được tiêu chuẩn hóa hơn. Giá trị ở nguồn có thể hoàn toàn không thuộc mô hình dữ liệu Magento core, hoặc thuộc một extension tạo tables và chức năng riêng.
Dữ liệu extensions và modules cần có quyết định đích rõ ràng. Một số giá trị có thể trở thành thuộc tính Magento hoặc trường của Customers có sẵn. Những giá trị khác thuộc extension đã cài, bảng của custom module, hệ thống bên ngoài hoặc cấu trúc cũ không nên tiếp tục được mang sang. Chỉ liên kết trường ở nguồn với trường ở đích không thể tái tạo chức năng phụ thuộc vào code của module, events, observers, scheduled jobs hoặc quan hệ cơ sở dữ liệu tùy chỉnh.
| Yêu cầu | Hướng xử lý phù hợp hơn |
|---|---|
| Lọc các bản ghi Magento được hỗ trợ | Xác định các đối tượng dữ liệu và quan hệ có sẵn nào thuộc phạm vi dữ liệu đích. |
| Đưa trường được hỗ trợ sang đích khác | Chỉ dùng thuộc tính hoặc trường có sẵn khi mục đích trên Cửa hàng đích đã rõ. |
| Điều chỉnh cách dữ liệu được thể hiện trong phạm vi hỗ trợ | Giữ kết quả phù hợp với ý nghĩa của Products, Customers, Orders và scope trên Magento. |
| Giữ dữ liệu trong bảng custom module | Xác định module đang quản lý dữ liệu và liệu có cấu trúc đích được hỗ trợ hay không. |
| Duy trì ERP, PIM, CRM, marketplace hoặc warehouse IDs | Chỉ lưu như định danh giữa các hệ thống khi các tích hợp sau khi vận hành thực sự cần chúng. |
| Diễn giải dữ liệu nguồn tùy chỉnh | Xác định ý nghĩa nghiệp vụ trước khi chọn trường có sẵn, trường của extension, hệ thống bên ngoài hoặc chủ động loại khỏi phạm vi. |
| Tái tạo chức năng từ extension không được hỗ trợ | Xem đây là công việc triển khai trên Nền tảng đích, không phải di chuyển bản ghi thông thường. |
Ranh giới này cần được làm rõ trước khi phê duyệt phạm vi công việc. Magento linh hoạt không đồng nghĩa mọi chức năng tùy chỉnh ở Nền tảng nguồn đều có một đích tiêu chuẩn trên Magento.
Các quan hệ trên Magento cần dẫn đến kết quả đích rõ ràng
Mô hình đích nhất quán cần hỗ trợ việc quản lý catalog, hiển thị storefront, search và navigation, layered filtering, diễn giải inventory, đọc lịch sử đơn hàng, hỗ trợ Customers, duy trì URLs và tiếp tục các tích hợp. Kết quả cần hướng đến cấu trúc rõ ràng, không phải giữ lại số lượng trường lớn nhất có thể.
| Nhóm quan hệ | Kết quả cần đạt trên Cửa hàng đích |
|---|---|
| Loại Products | Mỗi dòng sản phẩm dùng cấu trúc duy trì đúng SKU có thể mua, options, inventory và ý nghĩa của mặt hàng trong Orders. |
| Thuộc tính và attribute sets | trường quan trọng được quản lý nhất quán, tái sử dụng đúng và chỉ gán cho những dòng sản phẩm thực sự cần chúng. |
| Scope | Việc gán website, store và store view giữ đúng bối cảnh brand, language, domain, content và catalog. |
| Categories và URLs | Root Categories, URL keys, rewrites và content routes tiếp tục hỗ trợ đúng navigation và mục đích của đường dẫn. |
| Inventory | Sources, stocks, quantities, reservations và salable quantity phù hợp với quan hệ Products cùng hệ thống chịu trách nhiệm xử lý đơn hàng. |
| Customers và Orders | Hồ sơ Customers, groups, addresses, chi tiết mặt hàng, statuses và các tham chiếu lịch sử vẫn dễ hiểu và hữu ích. |
| Extensions và dữ liệu tùy chỉnh | trường có sẵn, dữ liệu do extensions quản lý, định danh các tích hợp và cấu trúc cũ được loại bỏ có ranh giới trách nhiệm riêng. |
Dự án Magento tốt nhất không nhất thiết là dự án chuyển được nhiều trường nhất. Kết quả tốt là Magento nhận đủ dữ liệu đã được tổ chức đúng để vận hành ổn định mà không phải mang theo toàn bộ dữ liệu dư thừa và cấu trúc cũ không còn mục đích sử dụng.
Kết luận
Khác biệt trong mô hình dữ liệu Magento quan trọng vì Magento gắn ý nghĩa cấu trúc cho các bản ghi commerce. Loại Products, thuộc tính, attribute sets, website, store, store view, Categories, URLs, inventory, nhóm Customers, Orders, extensions và dữ liệu tùy chỉnh đều ảnh hưởng đến cách dữ liệu sau khi di chuyển hoạt động trên Cửa hàng đích.
Kế hoạch chuyển đổi tốt cần đưa dữ liệu nguồn vào cấu trúc Magento theo mục đích sử dụng đã xác định. Mục tiêu là duy trì ý nghĩa kinh doanh có giá trị, tránh tạo attribute clutter không cần thiết và tách rõ quan hệ có sẵn của Magento khỏi chức năng do extensions hoặc hệ thống bên ngoài quản lý.
Câu hỏi thường gặp
Vì sao loại Products quan trọng khi chuyển sang Magento?
Loại Products quyết định cách Magento hiểu catalog. Simple, configurable, grouped, bundle, virtual và downloadable có thể ảnh hưởng đến SKU, inventory, cách hiển thị giá, chi tiết mặt hàng trong Orders, xử lý đơn hàng và công việc bảo trì. Products có thể trông đúng trên storefront nhưng vẫn sai về cấu trúc nếu loại Products không phù hợp với mô hình kinh doanh.
Mọi trường tùy chỉnh ở nguồn có cần trở thành thuộc tính Magento không?
Không cần chuyển mọi trường tùy chỉnh thành thuộc tính. Chỉ nên tạo hoặc di chuyển thuộc tính khi trường đó phục vụ trang Products, search, filtering, comparison, merchandising, quản trị, reporting hoặc các tích hợp. Biến mọi trường nguồn thành thuộc tính có thể làm giao diện quản trị rối và tạo filters thiếu nhất quán cho khách hàng.
Vì sao scope store view quan trọng khi chuyển sang Magento?
Store view có thể quản lý các giá trị đã địa phương hóa như tên Products, mô tả, metadata, nhãn Categories, CMS Pages và URL keys. Nếu scope không được lập kế hoạch, giá trị theo locale có thể ghi đè content toàn cục hoặc xuất hiện trong sai storefront.
Magento có xử lý dữ liệu riêng của Adobe Commerce theo cùng cách không?
Magento và Adobe Commerce có liên quan về kiến trúc nhưng không phải cùng một Nền tảng đích về mặt lập kế hoạch. Cấu trúc riêng của Adobe Commerce không nên được mặc định có trong Magento, trừ khi môi trường đích thể hiện cùng ý nghĩa kinh doanh bằng cấu hình có sẵn, extension đã cài, hệ thống bên ngoài hoặc phần triển khai riêng.
Khi nào dữ liệu Magento cần cách xử lý riêng trên Cửa hàng đích?
Dự án cần cách xử lý riêng hoặc phần triển khai trên Nền tảng đích khi nguồn phụ thuộc vào bảng extensions không được hỗ trợ, trường của custom modules, quan hệ cơ sở dữ liệu không theo chuẩn, định danh hệ thống bên ngoài hoặc chức năng không có đích tương ứng trong Magento.
Nên xử lý trường của extensions và external IDs như thế nào trên Magento?
Trước khi xác định đích, cần biết hệ thống nào quản lý giá trị và giá trị đó tiếp tục phục vụ công việc gì. Thuộc tính có sẵn có thể phù hợp với dữ liệu catalog cần tái sử dụng; module tables, ERP keys, marketplace references hoặc workflow metadata có thể cần đích do extension quản lý, định danh các tích hợp hoặc chủ động loại khỏi phạm vi. Việc giá trị đã tồn tại trên Magento không tự chứng minh đích đó đúng.