Migrating Assets Approach

I'm working on a project that requires a significant asset migration from a legacy system. I've used this approach for a few different migrations from legacy systems, and it has not failed me yet. As much as I would like to use a connector or some other easy route out of a lot of code, I didn't have a choice because the legacy software was ancient or the customer didn't want to keep both systems up.

So, the approach was to:

1. If this is a mass asset migration, turn off the workflow, "DAM Update Asset" and any other custom workflows that might interfere and cause noise.
2. If you have a slave, turn it off to eliminate another variable. When you turn the slave on, it will sync.
3. Ensure your aem instance is patched.
4. Go into the legacy system, zip up each package of content with an associated metadata xml file
5. Curl it over from the legacy system to AEM to a place under /content/dam/migrate/
6. Excluded a directory from the DAM Update Asset workflow so it wouldn't create renditions of content I was about to migrate. (see my post about regular expressions)
7. Create a workflow launcher that listens for zip files being created in that directory
8. Execute a custom workflow model
1. Created a custom workflow step that saves the path. This was needed because the payload gets destroyed in the next step.
2. Executes the DAM unarchiver workflow to extract the contents, destroys the zip
3. Execute a custom workflow step to process the data
1. Use the path stored in step 1, use JAXB to read the data from the XML file
2. Create the asset/page/etc... and add the custom data fields as needed

I've used other variations in my workflow model to DRM documents using the LiveCycle connector, executing other processes, and sending emails.

If you migrated a ton of assets, you can put the assets back into the "DAM Update Asset" workflow by using the script here:
http://www.wemblog.com/2012/09/how-to-put-dam-asset-back-to-workflow.html