Khi cân nhắc Bagisto làm Nền tảng đích, việc lập kế hoạch nên bắt đầu từ cách Bagisto tổ chức hoạt động thương mại thay vì xem đây như một hệ thống trống để nhập các bản ghi từ Cửa hàng nguồn. Nền tảng Laravel, mô hình các loại Products, hệ thống attributes, channels, inventory sources, các nhóm Customers, CMS, các quy tắc marketing, APIs và kiến trúc mở rộng đều có thể thay đổi cách dữ liệu nguồn cần được diễn giải trước khi trở thành dữ liệu có thể sử dụng trong cửa hàng mới.
Với doanh nghiệp chuyển từ một nền tảng Hosted đơn giản hơn, Bagisto có thể tạo cảm giác linh hoạt và cần nhiều quyết định cấu hình hơn dự kiến. Với doanh nghiệp đến từ một nền tảng Open Source hoặc hệ thống xây dựng riêng, cấu trúc code và khả năng tùy biến có thể quen thuộc hơn, nhưng dự án vẫn cần kiểm soát phạm vi chặt chẽ. Products, quan hệ Categories, lịch sử Customers, lịch sử đơn hàng, nội dung, promotions và các tích hợp phải được chuyển thành cấu trúc phù hợp với Bagisto, không chỉ sao chép từng giá trị trong cơ sở dữ liệu.
Bagisto cần được nhìn nhận thế nào khi lập kế hoạch chuyển đổi
Bagisto là một nền tảng thương mại Open Source dựa trên Laravel với kiến trúc mô-đun. Điều này quan trọng đối với dự án chuyển đổi vì Nền tảng đích không chỉ là storefront. Bagisto đồng thời là môi trường quản trị, hệ thống mô hình hóa catalog, nơi cấu hình channels và inventory, cũng như nền tảng để mở rộng chức năng bằng packages và code tùy chỉnh.
Câu hỏi thực tế không chỉ là liệu Products, Customers và Orders có thể được di chuyển hay không. Câu hỏi quan trọng hơn là mô hình thương mại của Cửa hàng nguồn có thể được thể hiện rõ ràng qua các loại Products, attributes, attribute families, Categories, channels, inventory sources, các nhóm Customers, trạng thái Orders, cấu trúc CMS và chức năng mở rộng của Bagisto hay không.
| Hạng mục cần lập kế hoạch | Ý nghĩa trong Bagisto | Nội dung cần quyết định trước khi chuyển đổi |
|---|---|---|
| Mô hình catalog | Products phụ thuộc vào loại Products, attributes, attribute families, Categories, giá, hình ảnh và cách quản lý tồn kho. | Mô hình catalog nào của Cửa hàng nguồn nên được chuyển thành cấu trúc Bagisto có sẵn thay vì tạo phương án tùy chỉnh. |
| Cấu trúc storefront | Channels, theme, CMS, URL rewrites, search terms và thiết lập hiển thị ảnh hưởng đến cách khách hàng tìm thấy Products và nội dung. | Những yếu tố nào phải được duy trì để bảo đảm tính liên tục của SEO, điều hướng và khả năng chuyển đổi khách hàng. |
| Hoạt động vận hành | Orders, invoices, shipments, refunds, transactions, các nhóm Customers, Taxes và inventory sources ảnh hưởng đến công việc back-office. | Những dữ liệu lịch sử nào phải tiếp tục có ý nghĩa đối với vận hành sau khi chuyển đổi. |
| Khả năng mở rộng | Packages, APIs, cửa hàng Headless, các loại Products tùy chỉnh, phương thức payment và phương thức shipping có thể mở rộng chức năng nền tảng. | Yêu cầu tùy chỉnh nào thuộc cấu hình Bagisto, khả năng mapping được hỗ trợ, điều chỉnh cấu hình hoặc phạm vi cần xử lý riêng. |
Bagisto vì thế phù hợp với doanh nghiệp muốn có nhiều quyền kiểm soát hơn so với một môi trường SaaS khép kín. Tuy nhiên, nếu giai đoạn lập kế hoạch chỉ xem Bagisto là nơi nhận Products, Customers và Orders, phạm vi công việc rất dễ bị đánh giá thiếu. Giá trị của Bagisto nằm ở khả năng linh hoạt có cấu trúc, và cấu trúc đó chỉ phát huy hiệu quả khi các quyết định về Nền tảng đích được xác định rõ trước Di chuyển toàn bộ.
Một dự án chuyển đổi sang Bagisto có nền tảng tốt nên bắt đầu bằng việc thống nhất mô hình vận hành. Doanh nghiệp cần xác định cửa hàng tương lai sẽ quản lý catalog phức tạp, bán hàng đa kênh, tồn kho, phân khúc Customers, promotions, nội dung, checkout, các tích hợp và nhu cầu tùy biến sau này như thế nào. Những quyết định này tạo ranh giới cho nội dung nào nên di chuyển trực tiếp, nội dung nào cần cấu hình lại, nội dung nào phải xây dựng lại và nội dung nào nên loại khỏi phạm vi công việc.
Bagisto tổ chức hoạt động thương mại như thế nào
Bagisto tổ chức hoạt động thương mại thông qua nhiều cấu trúc liên kết thay vì một catalog phẳng. Products được phân loại theo các loại Products và gắn với attribute families. Categories tạo cấu trúc điều hướng và khám phá Products. Channels xác định ngữ cảnh storefront, locale, currency, inventory và cách hiển thị. Inventory sources ảnh hưởng đến lượng hàng có thể bán. Các nhóm Customers có thể tác động đến phân khúc và các điều kiện thương mại. Orders lưu lại lịch sử giao dịch cùng invoices, shipments, refunds, transactions, phương thức payment, phương thức shipping, Taxes và trạng thái xử lý.
Mô hình này tạo ra một khung lập kế hoạch hữu ích:
| Cấu trúc Bagisto | Ý nghĩa đối với chuyển đổi | Câu hỏi cần giải quyết |
|---|---|---|
| Các loại Products | Một bản ghi Products không chỉ được xác định bởi SKU; cấu trúc có thể là simple, configurable, virtual, bundle, grouped, downloadable hoặc booking-related. | Xác định cách Products vận hành trước khi xử lý từng trường dữ liệu. |
| Attributes và attribute families | Dữ liệu catalog cần được gắn vào cấu trúc Bagisto có ý nghĩa. | Tách attributes có cấu trúc rõ khỏi dữ liệu cũ dạng text, các trường tùy chỉnh và ghi chú merchandising riêng lẻ. |
| Channels | Ngữ cảnh storefront có thể ảnh hưởng đến currency, locale, inventory và phần hiển thị. | Xác định dự án cần một channel hay nhiều channels. |
| Inventory sources | Tồn kho không chỉ là một con số nếu doanh nghiệp vận hành nhiều địa điểm hoặc nhiều nguồn cấp hàng. | Quyết định tồn kho nguồn nên được gộp hay tách thành các inventory sources trong Bagisto. |
| Các nhóm Customers | Phân nhóm Customers có thể ảnh hưởng đến giá, quyền truy cập và cách phục vụ thương mại. | Duy trì ý nghĩa của từng nhóm, không chỉ tên nhóm. |
| CMS và marketing | Nội dung, URL rewrites, catalog rules, cart rules, campaigns, search terms và sitemaps ảnh hưởng đến khả năng thu hút và chuyển đổi khách hàng. | Xem nội dung và quy tắc promotions như một phần của phạm vi cần duy trì để cửa hàng có thể vận hành ổn định khi ra mắt. |
Các cấu trúc này cần được lập kế hoạch cùng nhau. Một bản ghi Products dạng configurable không thể được xác thực đầy đủ nếu attribute family sai. Nhóm Customers không còn nhiều giá trị nếu các điều kiện giá liên quan không được rà soát. Lịch sử đơn hàng có thể xuất hiện đầy đủ nhưng vẫn không hữu ích cho vận hành nếu invoices, shipments, refunds, Taxes hoặc ý nghĩa trạng thái không còn dễ hiểu với đội ngũ sau chuyển đổi.
Bagisto cũng tạo ra ranh giới rõ giữa dữ liệu được di chuyển và cấu hình cần thiết lập trên Nền tảng đích. Tên Products, SKU, mô tả, hình ảnh và giá có thể là dữ liệu cần chuyển. Trong khi đó, việc gán loại Products, thiết kế attribute families, khả năng hiển thị theo channel, cấu hình Tax, theme, checkout và chức năng extension có thể cần được cấu hình hoặc triển khai trực tiếp trên Bagisto. Kế hoạch tốt phải giữ hai nhóm này tách biệt.
Những nhóm dữ liệu cốt lõi quyết định phạm vi chuyển đổi
Các loại dữ liệu chính thường gồm Products, Categories, Customers, Orders, Reviews, Coupons, CMS Pages, Blog Posts khi có và các bản ghi thương mại hỗ trợ khác. Trong Bagisto, giá trị của những bản ghi này phụ thuộc vào cấu hình và quan hệ xung quanh.
Products cần được xem xét kỹ nhất. Cửa hàng nguồn có thể sử dụng variants, options, bundles, downloads, booking hoặc các trường option tùy chỉnh theo cách không thể chuyển thẳng nếu mô hình Products chưa được quyết định. Hệ thống phân loại Products của Bagisto tạo cơ hội chuẩn hóa một catalog thiếu nhất quán, nhưng đồng thời cũng làm lộ những lối tắt từng hoạt động trên nền tảng cũ chỉ vì nền tảng đó cho phép cấu trúc lỏng hơn.
Categories cần được rà soát theo hierarchy, tên gọi, giá trị URL, mục đích merchandising và mức độ liên quan với từng channel. Một cây Categories từng phù hợp với catalog nhỏ có thể không đáp ứng cách search và điều hướng dự kiến trên Bagisto. Ngược lại, một cây Categories cũ quá lớn có thể chứa node trùng lặp, lỗi thời hoặc chỉ phục vụ campaign trước đây và không nên được chuyển nguyên trạng.
Customers và Orders cần được xem như bộ nhớ thương mại của doanh nghiệp. Customers có thể gắn với các nhóm Customers, addresses, đăng ký nhận thông tin, Reviews, trạng thái tài khoản và các điều kiện giá. Orders có thể chứa statuses, invoices, shipments, refunds, transactions, Taxes, discounts, phương thức payment, phương thức shipping và ghi chú nội bộ. Phạm vi chuyển đổi phải giữ đủ ngữ cảnh để đội chăm sóc khách hàng và đội vận hành hiểu được lịch sử, không chỉ hiển thị được mã Orders.
Cấu trúc CMS và marketing cũng có vai trò đáng kể. CMS pages, URL rewrites, search terms, search synonyms, catalog rules, cart rules, campaigns, email templates, newsletters, sitemaps và rich snippets có thể ảnh hưởng đến khả năng khách hàng tìm thấy nội dung và hoàn tất mua hàng. Một số thành phần có thể được chuyển như dữ liệu hoặc quy tắc. Thành phần khác cần tạo lại, cấu hình lại hoặc thiết kế lại vì phụ thuộc vào cách Bagisto vận hành trên Nền tảng đích.
Có thể phân loại phạm vi trước khi chuyển đổi như sau:
| Nhóm xử lý | Ví dụ | Cách tiếp cận |
|---|---|---|
| Di chuyển dữ liệu trực tiếp | Products có cấu trúc rõ, tên Categories, tài khoản Customers, lịch sử đơn hàng, Reviews, Coupons, CMS Pages. | Di chuyển trong phạm vi được hỗ trợ khi ý nghĩa trường dữ liệu đã rõ ràng. |
| Căn chỉnh cấu hình | Channels, locales, currencies, inventory sources, Taxes, phương thức payment, phương thức shipping, thiết lập checkout. | Cấu hình trong Bagisto rồi xác thực với dữ liệu sau khi di chuyển. |
| Mapping và chuyển đổi dữ liệu | Attribute families, gán loại Products, các nhóm Customers, trạng thái Orders, URLs, các trường tùy chỉnh cũ. | Xác định quan hệ nguồn-đích hoặc phép biến đổi; đưa yêu cầu không được hỗ trợ vào phạm vi cần xử lý riêng. |
| Triển khai tùy chỉnh | Chức năng Products tùy chỉnh, dữ liệu do package quản lý, bản ghi extension, dependency của cửa hàng Headless, tích hợp riêng. | Lập kế hoạch như công việc không tiêu chuẩn hoặc phần phát triển trên Nền tảng đích. |
Cách phân loại này ngăn một sai lầm phổ biến: cho rằng mọi cách vận hành của cửa hàng cũ đều phải được chuyển dưới dạng dữ liệu. Trong Bagisto, nhiều chức năng phù hợp hơn khi được thể hiện bằng cấu hình, chức năng do extension quản lý hoặc cấu trúc được thiết kế lại.
Tùy biến, extensions và kiến trúc Headless
Nền tảng Laravel và hệ sinh thái phát triển là một phần quan trọng trong bản sắc của Bagisto. Với dự án chuyển đổi, đây vừa là lợi thế vừa là trách nhiệm.
Doanh nghiệp có thể chọn Bagisto vì cần custom packages, API access, cửa hàng Headless, các loại Products tùy chỉnh, phương thức payment hoặc shipping riêng, theme tùy chỉnh, tối ưu hiệu năng hay khả năng kiểm soát tích hợp sâu hơn. Đây đều là lý do hợp lý để chọn Bagisto, nhưng chúng cũng làm thay đổi phạm vi vì di chuyển dữ liệu có thể phụ thuộc vào code tùy chỉnh, dữ liệu của extension hoặc phần phát triển trên Nền tảng đích không tồn tại trong một cửa hàng Bagisto mặc định.
Nếu kiến trúc đích sử dụng custom packages, marketplace modules, B2B modules, cửa hàng Headless hoặc các tích hợp chuyên biệt, kế hoạch cần xác định phần nào phải sẵn sàng trước kiểm thử đại diện và phần nào chỉ có thể xác thực sau khi quá trình phát triển đạt trạng thái có thể sử dụng.
| Dấu hiệu tùy biến | Hệ quả đối với chuyển đổi | Hướng xử lý cần đánh giá |
|---|---|---|
| Cửa hàng nguồn có các trường tùy chỉnh tương ứng rõ với attributes của Bagisto. | Cần xác định mapping, nhưng mô hình đích vẫn có thể dùng cấu trúc Bagisto có sẵn. | Có thể xử lý bằng quan hệ nguồn-đích có phạm vi rõ nếu nằm trong giới hạn được hỗ trợ. |
| Cửa hàng nguồn có cách vận hành Products không được các loại Products có sẵn thể hiện. | Dữ liệu có thể cần biến đổi kết hợp với chức năng đích tùy chỉnh. | Cần đánh giá phạm vi xử lý không tiêu chuẩn hoặc phần phát triển trên Nền tảng đích. |
| Bagisto đích sử dụng custom packages. | di chuyển dữ liệu có thể phải chờ schema hoặc APIs của package sẵn sàng. | Dữ liệu do package quản lý có thể cần xử lý ngoài phạm vi tiêu chuẩn. |
| Storefront đích dùng kiến trúc Headless. | Việc xác thực storefront phụ thuộc vào APIs, URLs, nội dung và cách frontend hiển thị. | Cần kế hoạch xác thực kỹ thuật và vận hành phù hợp với phạm vi đã thống nhất. |
| Cửa hàng nguồn có mô hình B2B hoặc Marketplace phức tạp. | Account hierarchy, dữ liệu vendor, giá, phê duyệt hoặc commission có thể không thuộc cấu trúc tiêu chuẩn. | Nên xác định sớm phần cần xử lý riêng hoặc triển khai bổ sung. |
Điểm cần giữ rõ là: yêu cầu mapping hoặc điều chỉnh cấu hình có phạm vi giới hạn khác với yêu cầu xử lý không tiêu chuẩn. Di chuyển Khi phải xử lý bản ghi không được hỗ trợ, dữ liệu package, phép biến đổi riêng hoặc cách xử lý chuyển đổi tùy chỉnh, phạm vi cần được đánh giá riêng từ đầu để tránh đánh giá thiếu thời gian và trách nhiệm triển khai.
Bagisto làm thay đổi cách xác định phạm vi công việc
Bagisto khiến các quyết định thiết kế nền tảng trở nên rõ hơn. Với một số Nền tảng đích đơn giản, doanh nghiệp có thể nhập dữ liệu trước rồi tổ chức lại cửa hàng sau. Bagisto phù hợp hơn với hướng ngược lại: xác định cấu trúc vận hành đích trước, sau đó di chuyển dữ liệu vào cấu trúc đã được quyết định.
Những câu hỏi phạm vi quan trọng nhất gồm:
| Câu hỏi cần quyết định | Vì sao quan trọng |
|---|---|
| Những loại Products nào sẽ được sử dụng khi cửa hàng chính thức vận hành? | Cách Products vận hành ảnh hưởng đến attributes, giá, options, tồn kho, cart và tiêu chí xác thực. |
| Những attribute families nào cần thiết? | Thiết kế attribute families quyết định dữ liệu catalog có trở thành cấu trúc dễ quản lý hay bị phân tán. |
| Cần những channels, locales, currencies và inventory sources nào? | Ngữ cảnh storefront ảnh hưởng đến khả năng bán, phần hiển thị, giá và cách đội vận hành sử dụng dữ liệu. |
| Những rules và promotions nào phải tiếp tục hoạt động? | Catalog rules và cart rules có thể ảnh hưởng đến doanh thu, kỳ vọng của khách hàng và kết quả đối chiếu trước khi ra mắt. |
| Những nội dung và tín hiệu SEO nào phải được duy trì? | CMS Pages, URL rewrites, sitemaps, search terms và rich snippets ảnh hưởng trực tiếp đến khả năng thu hút traffic sau chuyển đổi. |
| Extensions hoặc custom packages nào là thiết yếu với hoạt động kinh doanh? | Chức năng do package quản lý có thể cần xử lý riêng hoặc phải được phát triển theo đúng trình tự. |
Bagisto cũng thay đổi cách đánh giá chất lượng chuyển đổi. Đối chiếu số lượng bản ghi là chưa đủ. Kiểm thử đại diện cần chứng minh rằng catalog vận hành đúng, Customers có thể tiếp tục sử dụng, lịch sử đơn hàng dễ hiểu, nội dung hiển thị đúng, channels và inventory sources được căn chỉnh, đồng thời đội vận hành có thể làm việc với môi trường đích.
Một bản ghi Products có thể đã tồn tại trong Bagisto nhưng vẫn chưa đạt điều kiện chính thức vận hành nếu bị gán sai loại Products, nằm trong attribute family không phù hợp, không xuất hiện ở đúng channel, thiếu quan hệ inventory cần thiết hoặc được hiển thị qua storefront không đáp ứng cách merchandising dự kiến. di chuyển dữ liệu chỉ thực sự đạt yêu cầu khi các bản ghi sau chuyển đổi hỗ trợ được quy trình kinh doanh mà chúng đại diện.
Lập kế hoạch để duy trì hoạt động kinh doanh
Duy trì hoạt động kinh doanh khi chuyển sang Bagisto nghĩa là cửa hàng có thể tiếp tục bán hàng, phục vụ khách, xử lý Orders và theo dõi kết quả sau khi chính thức vận hành. Mục tiêu này đòi hỏi sự phù hợp giữa dữ liệu sau di chuyển dữ liệu và mô hình vận hành của Bagisto, chứ không chỉ việc các bản ghi đã có trên Cửa hàng đích.
| Nhóm cần duy trì | Nội dung cần xác nhận |
|---|---|
| Hoạt động thương mại | Products, giá, discounts, các nhóm Customers, lịch sử đơn hàng, invoices, shipments, refunds và Taxes vẫn dễ hiểu và sử dụng được. |
| Storefront | Categories, CMS Pages, URLs, search, sitemaps, rich snippets, media và phần hiển thị theme tiếp tục hỗ trợ khách hàng tìm thấy và mua Products. |
| Vận hành nội bộ | Inventory sources, phương thức payment, phương thức shipping, checkout, trạng thái Orders và reporting hỗ trợ công việc hằng ngày. |
| Kỹ thuật | APIs, extensions, packages, cửa hàng Headless, scripts tùy chỉnh và các điểm tích hợp đã sẵn sàng cho bước xác thực trước khi chính thức vận hành. |
Bagisto phù hợp khi doanh nghiệp sẵn sàng đưa ra các quyết định này một cách chủ động. Nền tảng sẽ kém phù hợp hơn nếu doanh nghiệp kỳ vọng cửa hàng mới tự động tái hiện mọi thói quen hình thành trên Nền tảng nguồn trong khi đồng thời thay đổi kiến trúc, tăng khả năng tùy biến và giảm technical debt.
Cách tiếp cận phù hợp là duy trì có chọn lọc. Giữ lại ý nghĩa thương mại mà khách hàng và nhân sự nội bộ cần. Xây dựng lại những cấu trúc không còn phù hợp khi Bagisto cung cấp mô hình tốt hơn. Xác định sớm yêu cầu tùy chỉnh hoặc không được hỗ trợ. Kiểm chứng các tình huống đại diện trước Di chuyển toàn bộ. Cách làm này giúp khả năng linh hoạt của Bagisto cải thiện môi trường vận hành thay vì biến thành phạm vi không kiểm soát.
Cuối cùng, doanh nghiệp cần xác định Bagisto được chọn chủ yếu như một điểm đến dữ liệu có cấu trúc hơn, một nền tảng vận hành linh hoạt hơn, hay một nền tảng thương mại sẵn sàng cho phát triển tùy chỉnh. Ba hướng này tạo ra ba tư thế chuyển đổi khác nhau. Hướng thứ nhất nhấn mạnh bản ghi được hỗ trợ và mapping. Hướng thứ hai nhấn mạnh channels, inventory sources, attributes, các nhóm Customers, CMS và marketing rules. Hướng thứ ba còn đòi hỏi quyết định về packages, APIs, Headless và chức năng Products hoặc checkout tùy chỉnh. Gọi đúng mục tiêu từ đầu giúp phạm vi thực tế hơn và tránh việc dự án hứa hẹn hiện đại hóa kiến trúc trong khi chỉ dự toán cho một lần chuyển bản ghi cơ bản.
Kết luận
Chuyển sang Bagisto nên được lập kế hoạch như một thay đổi có cấu trúc về kiến trúc thương mại. Nền tảng có thể hỗ trợ nhiều loại Products, catalog dựa trên attributes, channels, inventory sources, CMS, marketing rules, APIs, Headless, extensions, mô hình Marketplace, mô hình B2B và phát triển tùy chỉnh. Sự linh hoạt đó chỉ tạo giá trị khi phạm vi di chuyển dữ liệu được thiết kế theo đúng cách Bagisto tổ chức hoạt động thương mại.
Những dự án chuyển đổi sang Bagisto có chất lượng thường tách dữ liệu cần di chuyển khỏi cấu hình đích, phân biệt rõ khả năng mapping hoặc điều chỉnh cấu hình được hỗ trợ với phần cần xử lý riêng, xác thực cách Products vận hành trước khi ra mắt, đồng thời xem nội dung, SEO, vận hành và các tích hợp là một phần của điều kiện sẵn sàng. Khi các quyết định này được đưa ra sớm, Bagisto có thể trở thành nền tảng vận hành rõ ràng và linh hoạt hơn. Nếu bị trì hoãn, dự án có thể chỉ mang sự phức tạp cũ sang một nền tảng mạnh hơn mà không làm cửa hàng dễ quản lý hơn.
Câu hỏi thường gặp
Bagisto có chỉ phù hợp với doanh nghiệp có đội kỹ thuật chuyên sâu không?
Bagisto không chỉ phù hợp với doanh nghiệp có đội kỹ thuật chuyên sâu. Nền tảng này cũng có thể phù hợp với doanh nghiệp muốn kiểm soát catalog, channels, inventory, nội dung và các tích hợp một cách có cấu trúc. Tuy nhiên, đội dự án cần sẵn sàng đưa ra quyết định về cấu hình và kiến trúc thay vì kỳ vọng một quy trình chuyển đổi hoàn toàn plug-and-play.
Dữ liệu Products có cần được tái cấu trúc trước khi chuyển sang Bagisto không?
Tùy độ phức tạp của catalog. Products đơn giản có thể tương ứng khá trực tiếp, nhưng cấu trúc configurable, bundle, grouped, downloadable, booking hoặc các mô hình Products tùy chỉnh cần được rà soát trước để xác định cách thể hiện phù hợp trong Bagisto.
Bagisto có thể duy trì lịch sử Customers và Orders không?
Customers và lịch sử đơn hàng có thể nằm trong phạm vi di chuyển dữ liệu, nhưng giá trị sử dụng phụ thuộc vào việc duy trì đúng các nhóm Customers, addresses, trạng thái Orders, invoices, shipments, refunds, Taxes, discounts và tham chiếu payment hoặc shipping cần thiết.
Extensions của Bagisto có được di chuyển tự động không?
Không nên giả định chức năng của extensions sẽ tự động được di chuyển. Dữ liệu do extension quản lý, schema của package, các trường tùy chỉnh và chức năng được xây dựng riêng có thể cần xử lý ngoài phạm vi tiêu chuẩn hoặc phải được triển khai trực tiếp trên Nền tảng đích.
Điều gì khiến việc chuyển sang Bagisto khác với một lần đổi nền tảng đơn giản?
Khác biệt nằm ở việc các cấu trúc của Nền tảng đích như các loại Products, attributes, channels, inventory sources, CMS, marketing rules, APIs và custom packages quyết định dữ liệu sau di chuyển dữ liệu có thực sự sử dụng được khi cửa hàng chính thức vận hành hay không.