Top Considerations for Migrating Assets to AEM

Govinda Baweja is a Senior Developer at Rightpoint and is an integral part of our integration team. He specializes in Java, CSS, HTML, Javascript, and Python. With 5 years of experience, Govinda works closely with our customers to help them realize their vision for the unique digital experience they want to create for their customers. Outside of work, Govinda can be found taking flight - whether it is with drones, flying Cessnas, or programming drones for autonomous flight using python.  When he has his feet on the ground he can be found traveling and even dancing (occasionally).

At Rightpoint (formerly Hoodoo Digital), we specialize in Adobe Experience Manager (AEM) Assets implementations, and a key part of this is migrating assets. This article is intended to outline some of the considerations and best practices for asset migration, but it is not intended to be a complete set of steps for every situation. All migration projects are unique, but these steps should cover a broad range of considerations. 

Adobe’s Digital Asset Manager (DAM), AEM Assets, allows companies to manage all content and digital assets on a single platform where assets can be managed, edited, and delivered with AI (Artificial Intelligence) and data-driven insights to streamline creative workflows and automate experience delivery at scale.  

Migrating digital assets from some other asset repository to AEM can seem like an enormous undertaking, but there are several steps you can use to approach an asset migration that can make the task more surmountable. For the remainder of this article, will be using the word “source” to refer to the place where all the assets that will be migrated are currently stored - In other words, the original asset storage location.  

Below are the simple steps for asset migration: 

1. Analysis and Extraction of source data 
2. AEM instance preparation and readiness 
3. Create custom metadata schema based on source (if required) 
4. Source data processing 
5. Binary data migration 
6. Assets metadata migration 
7. Validation of the migrated assets 

Analysis and Extraction of source data 

Before starting assets migration, you should analyze the following at the source: 

1. Consider all external sources: 
2. What is the external source? Is it a digital asset management tool or an external hard drive? 
3. Does the external source involve multiple asset management tools, multiple external hard drives, or both?  
4. AEM supported assets? 
5. Experience Manager Assets supports a wide range of assets and has varied support for different MIME types. Ask the client if they need any add-on features. For example, the support for EPS (Encapsulated Postscript) files applies to raster images only, and thumbnail generation for EPS vector images is not supported by default. To support this feature the additional imageMagic configuration is required to work with Experience Manager Assets. A list of assets that are supported by AEM can be found here. 
6. Assets migration size: 
7. What is the total number of assets and the total asset migration size? This is important for migration estimation as the migration involves multiple file types and file sizes. The processing power of PROD AEM instance on AEM as a Cloud Service (AEMaaCS) runs faster and has better performance as compared to Stage and Develop instances. Asset migrations can vary substantially in size, ranging from single digit to double digit (maybe more) TB of total assets. Knowing migration size and the number of assets that can migrate in a day helps to estimate the migration timeline. 
8. The folder structure in the existing system:  
9. This allows us to correctly map the source folder structure to the AEM folder structure. 
10. There could be a possibility that the client’s existing DAM may not have any folder structure. For example, a folder structure in AEMaaCS can based on a business logic for their business so that their authors could find, edit, and deliver assets in an easier and faster way. 
11. Assets access: 
12. In the case of the source digital asset management tool, are there any APIs (Application Programming Interface) available to get the binary data and metadata of the assets?  
13. What about archived assets? Check with client if archived assets in their existing DAM need to be migrated or not. Check with the client who manages them to determine if any additional authorization is required. 
14. Duplicate Assets: 
15. There are two types of duplicate assets: when two or more assets have the same binary data, and when two or more assets have the same file name.  

AEM Instance Preparation and Readiness 

After analyzing the existing system and its related challenges, it is time for AEM implementation architecture: 

1. Will the migration be performed on a new AEM instance or an existing system? If the AEM instance is new, any downtime for a faster approach will not impact the business. If it is a running system, a correct migration approach must be decided so that it does not disrupt daily activities for users and authors using the running system. 
2. Existing folder structure at source:
   For better performance and folder structure access, the folder structure needs to be organized and optimized specifically for the needs of the business. Deciding on the folder structure beforehand helps reduce stress during and post-migration. For example, consider organizing asset categories based on locale (country, state, city, etc.). 
3. Other pre-requisites (if applicable): 
4. (Does not apply to AEM as a Cloud Service) Check the DAM Update asset workflow as it fits the project and check if it requires any customization or any custom processing. DAM update asset workflow is important because, by default, all uploaded assets are processed using the DAM Update Asset workflow. The workflow executes for each uploaded asset and accomplishes basic asset management tasks such as rendition generation, metadata writeback, page extraction, media extraction, and transcoding.
5. Rebuild indexes and modify existing damAssetLucene index if metadata properties need to be indexed are introduced. This will help in searching and filtering assets. Please refer to Adobe official documentation to learn more about oak queries and indexing. 

Create custom metadata schema based on source (if required) 

Sometimes, the source system has custom properties for the assets. When these assets get migrated to AEM, these properties need to be mapped to the migrated assets.  

So, the custom metadata schema needs to be designed accordingly.  

Source data processing 

Discussion with the business is required if they want any data (be it binaries or metadata) to be cleaned up or rearranged, as this is a rare opportunity for proper cleanup and setting up a consistent system to better process assets. In this step, all information of the existing system is extracted and formatted, which includes the binaries like asset name, asset size, binary, unique ID, folder location, and metadata (some systems have it as a separate file, some have in nodes like in AEM). Now, this extracted metadata is to be formatted as supported in AEM (e.g., date format).  

It is particularly important to make sure no assets with the same name reside in the same folder and prepare for ingestion because it is not a best practice to have duplicates in AEM.  

Binary migration 

There are many ways binaries could be migrated depending on the requirement and factors listed on analysis and extraction of source data, but this section will focus on Assets HTTP API.