Hello VTEX team,
We are migrating from the CMS version to IO and need to understand how we can sync the images linked to each SKU.
We use the Millenium ERP to feed VTEX. In Millenium, there are no photos. We always upload the photos manually after VTEX pulls the new products from Millenium.
It’s important to emphasize that we have over 3,000 SKUs, and the manual effort to re-upload these images during the migration would be enormous.
We concluded that uploading the images to an FTP server is not effective and is prone to constant errors, which is why we believe VTEX has already found a practical solution for its CMS - IO migration customers.
Bela, regarding the products already registered in VTEX, you don’t need to make any changes — their images will be displayed in both the VTEX IO and Legacy CMS versions, as long as they are included in your SKU registrations.
The same applies to registering new products: you won’t need to change the way SKU images are registered here in VTEX, and you can continue using images in the Files Manager.
Just adding to what @KarinaMota shared, some VTEX modules are agnostic with regard to the store edition. That is, the information saved within them is used equally whether in Legacy CMS or in VTEX IO.
Among the modules that are agnostic in this way are the Catalog, Logistics, Master Data, Pricing, and Promotions modules. Although there are some tools from one edition or another that interact in specific ways with these modules (for example, the Assembly Options tool available for VTEX IO requires some specific configurations within the catalog), the information saved within them will generally be available for both editions and does not need to be changed in any way at the time of migration to VTEX IO.
Eduardo,
I appreciate your explanation, however it is not clear to us what the mechanics are — what is the process and step-by-step for this “source-to-destination” mapping of SKU images, orders, customer registrations, etc. to take place, since we are talking about a Legacy CMS environment that is live and another new environment (for now a “test environment”) in VTEX IO, where our new site is built. An additional environment was contracted. Do you understand?
What is the proper way to transfer this data from one database to the other? We need a tutorial or more direct action from the VTEX team itself.
Alright, so… I only now managed to understand that your migration covers two different accounts — in that case you have two options:
Option one: Keep using the account you’re already using today
How this option would work:
You can create a development workspace in VTEX IO and open a ticket with our support team so that only the migration from Business Edition (legacy CMS) to Store Edition (VTEX IO) is carried out, and then install what was developed in IO for the new site. This won’t affect your store’s front-end or your sales, sound good?
Your store will keep running normally — its front-end will only be switched to the IO version at the end of the full step-by-step migration process, which you can find in this documentation right here in the community. It’s very thorough and can help you understand a lot about this: VTEX IO - What is it? | Benefits and Migration Step-by-Step
With this option, you won’t need to migrate your catalog, logistics, or any other information for it to be reflected on your store’s front-end — just follow the step-by-step outlined above.
Option two: Migrate to the new account
With this option, you’ll need to export your catalog and import it into the new account. This can be done via spreadsheet following the documentation below:
If you go with this option, it’s worth noting that you won’t be able to reuse images automatically. This is because your image URLs depend on the account name, so you’ll need to export a spreadsheet with the link to each image, download them, and re-upload them to the new account via API or whichever method you find most practical.
As for orders, with this option there’s no way to transfer them to a new account. Any existing orders in the old account will need to be completed there, and their data will be stored exclusively in that account.
As for customer records, it is possible to export them from one account and import them into another following the documentation below:
With all that in mind, given everything outlined here, our recommendation is that you go with option one, as it’s the most common IO migration process and the simplest to carry out, sound good?
Thank you for laying out both migration options.
Regarding the first one, which seems the simplest but which you recommend as the best, our concern is that it would keep our database DIRTY with various products and other data across several modules that have been inactive since 2017 but are cluttering the database.
We would like to start on IO with a clean database, containing only the configurations we actually care about. Is there any way for us to delete products and other items individually?
Manually? We have over a thousand completely inactive products. I need to clean them up!
Hi @belaiache, by choosing the first option there’s unfortunately no way to “delete” those products.
So what can be done to “clean up” that database? Reuse those products by taking advantage of the existing slots to register new products, updating all the information stored in those products, as well as their inventory and pricing.
We know that keeping this database “dirty” can cause some visual inconvenience, but in terms of data and migration, this is the best option.
It’s worth mentioning that I consulted a few teammates on the subject to get more than one opinion, and this does indeed seem to be the most suitable solution.