During the Akeneo SaaS migration, product data will be cloned from Akeneo v6 Production to Akeneo SaaS Production. However, Akeneo v6 will continue to be used for daily business operations during the migration period, which means any updates made in v6 after the Phase 1 data clone starts must be carefully tracked and re-applied to SaaS later.

This guide provides tips for updating and managing delta data during the migration. Delta data refers to any product updates, new SKU/SKN combinations, or content changes made in Akeneo v6 after 24 August 2026, when Phase 1 begins. These changes need to be logged and reapplied in Akeneo SaaS during Phase 3: Delta Re-entry, from 7–11 September 2026, so that SaaS contains the latest business data before the SFCC sync and go-live.

As agreed, due to the complexity of the data, Carol has agreed to support the update of the delta product data in phase 2 and phase 3. The MSC eCommerce Commercial Team and other users only need to log the changes they have made in v6 and validate the data in SaaS.

Phase 1: The Akeneo Project Team starts cloning data from Akeneo v6 Production to Akeneo SaaS Production.

Phase 2: Carol receives access to Akeneo SaaS Production and begins data transformation, import profile setup, and other required preparation activities.

Phase 3: Carol continues entering the delta information into Akeneo SaaS Production.

Once the MSC eCommerce Commercial Team receives access to Akeneo SaaS Production, they will validate the data entered by Carol and observe the system behavior.

Phase 4: Data is synchronized from Akeneo SaaS Production to SFCC.

Phase 5: Hypercare support begins.

During Phrase 1 and Phrase 2, each member of the MSC eCommerce Commercial Team can maintain a personal log sheet to record the SKUs they have updated. For example:

Each person should copy and paste their personal log into the shared log.

The purpose of maintaining a personal log is to allow each individual to cross-check whether their entries still exist in the shared log, in case any records are accidentally deleted from the shared log.

Having a shared log with unique sku so that someone can export from Akeneo v6 and import to Akeneo SaaS, for example:

For example, each SKU should appear only once in the log. If duplicate records exist, they will be highlighted in red, as shown below. Please remove the duplicate row so that only one record remains for each SKU.

Click here to access the sheet, there are two tabs, one is [phase1_2] for recording all the changes made within phrase 1 and 2. And [phase3] for recording the changes made within phase 3.

Reference Entity

Reference entity data changes should be recorded and maintained in both systems during the migration period.

Some attributes, such as images, cannot be directly exported from V6 and imported into SaaS. These should be maintained manually.

For the Barcode reference entity, updates in SaaS are not required, as it is no longer being used.

This part will be maintained by MSC eCommerce Commercial Team

There are three types of data to be re-entered:

There are approximately 689 attributes (for all ROA locales) that should be exported, highlighted in green below.

The remaining attributes either are not used or are system attributes updated by the daily AS400 import — for example, upc — and therefore do not need to be exported from Akeneo v6.

Carol will export the data from Akeneo v6 on the last day of Phase 2 and last day of Phase 3, then re-import it into Akeneo SaaS Production.

During Phase 4, since it takes place on Friday afternoon, each individual will need to maintain their updates in both Akeneo v6 Production and Akeneo SaaS Production by themselves.

Click here for the full list.

The date and time attributes will be removed from Akeneo SaaS by the Akeneo Project Team during the cloning process, as they are custom attributes.

During Phase 2, Carol will first recreate the date/time attributes in Akeneo SaaS. By the end of Phase 2, she will import all the date and date time value.

On the last day of Phase 3, Carol will export the data from Akeneo v6, then re-import it into Akeneo SaaS Production.

During Phase 4, since it takes place on Friday afternoon, each individual will need to maintain their updates in both Akeneo v6 Production and Akeneo SaaS Production by themselves.

This information can be directly exported from v6

Note: Carol will create last_price_change as a date attribute in Akeneo SaaS (it is date and time in v6), as this field will be imported through the AS400 product import.

However, last_price_change and last_cost_change will no longer be used for margin calculation. The margin will now be recalculated by the triggered rule whenever the cost or final price is updated.

You cannot use the standard product_import profile. Instead, you should use the tailored date and time import profile, as it can accept the date/time format listed above.

Click here to access the sample file

3. Drag and drop the file in xlsx

4. Select Update

5. Click Launch Import

6. Once it is completed you can see the message like this

For the product images, since the naming convention and the way how it stores the data is different (v6 in product attributes where SaaS in Asset), you cannot export from v6 for direct import.

With this in mind, you can consider the following options.

Option A: Everyone save in Sharepoint

Option B: Export from Akeneo v6 and Import into Akeneo SaaS

Decision: After discussing with Carol, MSC eCommerce Commercial Team agreed to proceed with Option B. Carol will update the delta images based on the log provided by the team.

Option A: Everyone save in the sharepoint

Reference Only — Not the Agreed Method

This option is included for reference only to explain an alternative approach that was previously considered.

Each individual should save a copy to the shared SharePoint folder.

Within ROA_SaaS_delta_images, the users should handle the image preparation and upload as follows:

Note: Please pay close attention to the quality of work during the image preparation process. There may be cases where different people overwrite the same images with each other.

Option B: Export from Akeneo v6 and Import into Akeneo SaaS — Most Reliable, but Technical

Agreed Method

It is considered the most reliable approach because the images are exported directly from Akeneo v6 and then prepared for import into Akeneo SaaS. However, it is also technical because the exported image files are not immediately ready for SaaS import.

After export, the images are organized in a nested folder structure by SKU and image position, and each file must be extracted, renamed according to the SaaS asset naming convention, consolidated into the correct folder, and validated before import. If the image volume is large, this process requires careful batch handling and file verification to avoid incorrect file names, missing images, duplicate files, or accidental overwriting. Therefore, this option may require technical support or someone familiar with bulk file processing and image preparation.

4. Select this and click Export to continue.

5. Once it is ready you can download the archived files which contains the images

6. Each folder will store the images using the following structure:

sku/image_*/file.jpg

for example

For example, if a SKU #1035332 has 10 images, they will be listed as follows:

1035332/image_1/110162_i1.jpg

1035332/image_2/110162_i2.jpg

1035332/image_3/110162_i3.jpg

1035332/image_4/110162_i4.jpg

1035332/image_5/110162_i5.jpg

7. Carol will rename all images according to the SKU_i().jpg naming convention and place them into the same folder.

8. Import the renamed images into the SaaS asset family.