Asset migration strategy and process for Digital Asset Management systems

Asset migration can be a messy business as there will typically be assets lurking in the corners of your Digital Asset Management or Brand Management System from years ago which nobody remembered you had, untagged assets, images you may not have licence rights to any longer or are out of date in other ways, peppered with embedded EXIF or XMP metadata from the original photographer which may be completely irrelevant or misleading, and if that wasn’t enough there are now GDPR issues to contend with where you may have e.g. headshots of management or salespeople who do not work in your business any longer (aka personal data which you aren’t supposed to store any longer unless you have a good reason to).

Therefore, if you have a significant amount of assets that you are migrating into Brandworkz it is essential to the success of your future brand management system that:

1. You gain a good overview of what to keep, what to get rid of, how to tag, potentially how to re-tag, etc. – covered in more detail below in section 7.
2. You allocate appropriate resources at your end for these tasks as it will invariably be a bigger job than you perhaps expected. We can help you with the technical migration, but we won’t have intimate knowledge about your product range, internal language, whether something is still on-brand or not, etc.

We have been involved in hundreds of asset migrations over the years so if you give us an honest overview of your existing asset collection we can also help you estimate how many resources you need internally to “clean it up”.

Note that you can outsource/insource the task of managing and tagging your assets – both the one-off housekeeping during migration and ongoing admin/housekeeping. If you require this please let us know and we can recommend appropriate companies who specialise in this.

We understand that this can be a daunting task and nobody likes doing the “housekeeping”, but if you don’t put the processes and resources in place you will be setting yourself up for a failed project as Brandworkz can only be as good as the assets housed within it!

1. Technical options for exporting assets and metadata from a DAM system

Plan A: Export directly using the built-in export functionality

The preferred method by far is if the incumbent software has tools built in to its admin interface which allows you to export all files and metadata to a common export format (e.g. CSV or XMP sidecar files for metadata and a folder structure for the assets with filenames that can be matched up to the exported metadata). If you aren’t sure if such tools exist, then please send us a temporary admin login so we can investigate.

Plan B – Export by the incumbent vendor – Requires the vendor to co-operate

If there are no export tools built in, then the next best option is to get the incumbent vendor to export the data to a common export format, or indeed if you host the system yourself and have access to the underlying database and file system you may be able to do this yourself in partnership with us.

For the metadata, this will typically be CSV or Excel format or something called XMP sidecar files. Ideally we would also want a backup of the SQL database so we can understand what their metadata structure is, and if necessary get to any additional data or relationships if the CSV exports turns out to not have all the data we need –or if at some point in the future you would like to refer to some data which weren’t available in the CSV exports.

For the assets, these should be exported to a folder structure on a hard disk which mirrors the folder structure in the web-interface (if one exists). The filename and the folder name of assets must also be available in the CSV export so it’s possible to match up the assets to the metadata on re-import to our system.

If the tagging structure follows a standard called XMP and the incumbent’s system writes the XMP metadata inside all assets, then we can alternatively extract this metadata from the asset files themselves on import. However, only a narrow range of formats (mainly images and Adobe formats) support this, so if you e.g. have Word and PowerPoint files in your repository as well, then this will not work. If your system supports the embedding of metadata only in the older IPTC format then this is typically not a good option as there are serious limitations with this (a truncation of long text and fixed fields only).

Notes:

• It is to be expected that the incumbent vendor will request an admin charge to do this unless your contract with them states that this will be free of charge.
• We do not require any other permutations of files than the master – i.e. we do not need low-res previews and thumbnails because our system will auto-create these on import. In fact, if the incumbent vendor supplies multiple resolutions/formats of the assets we or you will have to spend extra time deleting the non-master permutations of assets so will slow down the migration.

Plan C – Export assets and metadata file-by-file through the web-interface.

If the incumbent vendor doesn’t want to play ball or the relationship has soured, then the only option is to have a person downloading each asset or batch of assets manually through the web-interface as a normal user. This is obviously very laborious and prone to human error so should be avoided if at all possible.

2. Technical options for exporting Users

If you have less than 50-100 users – or indeed if you are not sure exactly which users are active any longer, whether their details are up to date, or whether they should even have access at all – then you are probably better off just asking your users to register again by enabling the Brandworkz registration feature on the login page. This will also help you avoid any GDPR issues where you may then unnecessarily be storing personal details of users who aren’t active users of the system any longer.

Also, if you predominantly have SSO (Single Sign-On) users via SAML and the permissions around those are fairly simple, then it typically also doesn’t make sense to migrate user details as Brandworkz can do “just in time provisioning” of SSO users – i.e. if a pre-authenticated request comes in from your SSO system (e.g. Active Directory Federation Services) for a user that hasn’t been set up in Brandworkz, we will auto-create that user account in real time using the details in the request, assign them permissions based on pre-defined rules, and log them in.

However, if you have a large amount of non-SSO users, and we can get access to an export of their details then we can, in turn, bulk-import them into Brandworkz.

The feasibility – and cost – of doing this will typically depend on these factors:

1. It would be highly unusual – and extremely unsafe – if the incumbent system could export the users’ passwords in clear text. Therefore, we need to decide how a new password is handled/generated and communicated back out to each user.
2. If there are different user groups with different access permissions in the incumbent system, then we will have to understand how the permission system works, get access to an export of these permissions, transform them to our own permission structure and then import these with the user accounts.
3. Does the users’ activity history from the previous system need to be migrated, e.g. historic downloads of assets, metadata changes, etc. This will typically be a complex and expensive job to do so there will typically need to be a very strong legal or regulatory reason for embarking on migrating each user’s activity history.

Note that for cases like this a complete export of the incumbent vendor’s complete SQL database for your data can be a very good “insurance policy” because if the need arises in the future for this sort of thing, then this can be implemented at a later date.

3. Technical options for exporting CMS web-pages

Option 1: Migration from SQL database

If your existing system has a lot of web-pages, possibly hosting Brand Guidelines, that need migrating unchanged – e.g. over 100, then it may make sense for us to receive the raw SQL database from the incumbent vendor, for us to understand the database schema and see if it’s possible to do a bulk-migration by writing a script which takes the structured database content from their database to ours. It’s impossible to say if this will be possible until we see how the other vendor saves their content as there is a wide variety of ways this can be done.

Option 2: Re-creation of pages

If you have less than 100 web-pages then its highly likely that the best route is having a person re-creating the web-pages in our CMS system by copying and pasting page elements from the other system.

For this to happen we just need a login to your existing system and we can do this at a fixed price per page. If the system is actively used, then there will have to be some coordination of the timing of this so the content of the two systems doesn’t get out of sync in the transition phase.

4. Technical options for exporting workflows

If you have lots of Approval Workflows in your existing system which you would like to migrate to ours for historical/reference purposes, then this may be possible by investigating their SQL database, understanding the schema and writing a migration script.

However, the database storage of workflows with all its constituent parts is usually highly complex, and migrating these are likely to have a high cost so should typically only be considered if you have thousands of workflows and they for legal or compliance reasons must be preserved in an active system.

5. Technical options for exporting dynamic templates

If you use a system for dynamic templates – also known as Web-to-Publish or Web-to-Banner templates – which are based on Adobe InDesign or Illustrator files then we can highly likely use these master files as the basis for creating dynamic templates in Brandworkz as well, although they will probably need some modification and the various rules around editable/non-editable areas will have to be redone. We would need to see a couple of sample files to determine how much modification work would need to be done.

If the dynamic templates are based on a vendor-proprietary format, then they would most likely have to be re-created.

6. Process/housekeeping/timing considerations

Migration process

This will largely depend on the following:

• Is your current system is active in the sense that you are uploading to it on an ongoing basis and will need to do this ideally up to the point of a hand-over to your new Brandworkz system?
  If so then the time window between export from old and import to new need to be minimised. However, because we can’t verify if all the data is correct until we have re-imported (there could be mistakes in the export, strange characters, etc) a reasonable amount of time need to be allowed – This could be anywhere from a week to a month depending on the amount and complexity of the exported data. The process is in this case typically as follows:
  • We agree on a spec for the export (which data fields, which sections, etc)
  • We configure and build your system to spec (setting up tagging fields, main sections, etc).
  • The other vendor does a full export and sends it to us – typically on an encrypted hard disk.
  • You ideally don’t upload any new assets to your current system until we have finished importing the assets into Brandworkz. If this isn’t possible then you need to make a note of what you upload.
    If it’s too laborious a task to make note of the assets you upload in the migration period, you can alternatively also go back at a later date to incumbent vendor and ask for a second export of asset uploaded in that period, but this will likely cost you extra, may not be easy/possible for the vendor, or they may decide they don’t like you so much anymore and drag their feet doing it at all.
  • Once we are finished importing your assets/metadata – and any other tasks we need to do to complete the config of your system – we will then make this available to you on your pre-live system.
  • As soon as you have signed off the site, we will give you upload access so you can upload new assets (potentially in parallel to uploading them to your old system) – and optionally upload the backlog of assets which you made a note of while we were doing the import.
  • Once the system is fully populated you switch the live domain over to our system and the new system is launched!!

• If you have already stopped uploading new assets to your current system, then the process is pretty much as above but is easier because you can give us the export at your earliest convenience, and you won’t have to upload to two systems in parallel.

7. Housekeeping/culling your assets

If you have been using a system for years, it can be almost guaranteed that there will be assets in the old system which shouldn’t be migrated because they are out-of-date, other assets in there which haven’t been properly tagged, are not on-brand any longer, etc.

Therefore together we need to take a view as to how much housekeeping/culling needs to happen before you re-import your data for you to end up with a successful Brandworkz system.

Commonly:

• In terms of when to do this then these are the common options:
  • Do it in the current system before export. Possibly the best option if the tagging/reporting facilities of your current system is strong – e.g. it’s easy to get a report over which assets haven’t been properly tagged, which assets are x years old, etc.
  • Do it after the export once you have the files on a hard disk. It’s easy to visually review and delete (image and video) files in a standard folder structure so this could be an option. However, you need to keep your files and CSV file in sync – i.e. delete rows when you delete files – so this is probably only the best option for deleting big tranches of files that are grouped together.
  • Do it after import to Brandworkz. On one hand, it’s somewhat wasteful to import the “rubbish” into Brandworkz, but this could in some cases be the best option because once it’s in there the metadata and assets are synched back up. Also, there is reporting functionality so you can e.g. see where your “holes” are in the tagging, or which files are too low-res. The one thing you can’t see is how old the asset is because by default all imported assets will have the creation date as per the import date – i.e. a five-year-old asset will have a recent date. It is possible for us to import the original creation dates, but this will require custom-scripting. Therefore, if you are culling some of your assets based on original upload date, then this may be easier to do in the current system before you export (if it has the facility to search by date).

• In terms of who does this then:
  • You as the brand owner obviously has the greatest knowledge about your assets, so if somebody knowledgeable in your company has the time then this will be a good option. It’s typically not a good option to hire a “random” temporary person such as an intern for this job as they will not have the necessary knowledge about your brand/marketing/products/etc to assess what should be deleted and what should be kept.
  • We can recommend companies who can cull and tag your library to bring it up to scratch, but they will need a certain amount of initial training /guidance from you to do it.
  • We can also advise on what needs to be done as part of our consultancy. However, we are not a branding agency, so if you need help with defining e.g. the visual styling for images – and then a culling exercise for images that don’t follow the agreed styling – then we can recommend branding agencies which will help you with this.

8. Timing

This will to a large degree depend on:

• How many assets you have to migrate. Migration data is almost never perfect and will need some adjusting before successful import. The more data, the more odd-one-out data issues which need fixing.
• How good/bad a state they are in, i.e. what housekeeping needs to be done and by who. See above.
• If you are migrating to a new system as part of a re-brand. If this is the case then there will be certain difficulties in getting the new assets ready because they typically need to be purchased/created from scratch. However, this is usually also the time to heavily cull all of your old assets, so there will be much less to migrate from an old system.

The more visibility you give us of the good, the bad and the ugly, the better we can help you estimate the timings!

9. Outline migration plan

Here are the typical steps you and we need to go through for a successful migration. The timeline of this is hard to set in stone as the received data can be unpredictable and virtually no migration is completely trouble-free – but the below assumes a “normal” migration from a vendor which plays ball, and has around  2,500 – 5,000 assets.

Also note that the more assets you have the quicker it typically gets, i.e. 50,000 assets may only take twice as long as 5,000 assets if they all follow the same format.