Digital Asset Management

Technical considerations for exporting assets, metadata and CMS pages from a Digital Asset Management platform

The following is the advice we give to our new clients who’ve been using another digital asset management platform and need to migrate their assets over to Brandworkz as part of a dam system migration.

Exporting assets and metadata

Plan A: Export directly from web-interface

Your current software should have tools built in to its admin web-interface which allows you to export all files and metadata to a common export format (e.g. CSV for metadata and a folder structure for the assets).

If you aren’t sure if such tools exist, then please send us a temporary admin login so we can investigate.

Metadata fields

Plan B – Export by incumbent vendor

This requires your incumbent 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.

For the metadata this will typically be CSV or Excel format. Ideally we would also want a backup of the SQL database so we can understand what their metadata structures are, and if necessary get to any additional data 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 harddisk which mirrors the folder structure in the web-interface (if this 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.

If the tagging structure follows a standard called IPTC and the incumbent’s system writes the IPTC metadata inside all assets, then we can extract this metadata from the asset files themselves on import. However, only a narrow range of formats (mainly images) support this, so if you e.g. have Word and PowerPoint files in your repository as well, then this will not work.

  1. It is to be expected that the incumbent vendor will request an admin charge to do this
  2. 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.


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

If the incumbent vendor doesn’t want to play ball, then the only option is to have a person downloading each asset or batch of assets 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.

Technical options for exporting web-pages

Option 1: Migration from SQL database

If your existing system has a lot of web-pages that needs 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 fewer 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 co-ordination of the timing of this so the content of the two systems don’t get out of sync in the transition phase.

CMS pages

Process/housekeeping/timing considerations

Migration process

This will largely depend on the following:

  • If 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 cut-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, say one month.

The typical DAM system migration process is as follows:

  1. We agree on a spec for the export (which data fields, which sections, etc).
  2. We configure and build your system to spec (setting up tagging fields, main sections, etc)
  3. The other vendor does a full export and sends it to us – typically on a harddisk or DVD
  4. 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.
  5. Once we are finished importing your assets – and any other tasks we need to do to complete the config of your system – we will then make this available to you – typically on a staging site.
  6. As soon as you have signed off the site, we will give you upload access so you can upload new assets (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.
  7. Once the system is fully populated you switch the live domain over to our system and the new system is launched
  • If you have 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.
Housekeeping/culling your assets

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

Therefore together we need to take a view as to how  much housekeeping/culling needs to happen before you re-import your data.

Why reducing the volume of your assets is necessary

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 harddisk. It’s easy 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 what you don’t need into Brandworkz, but this may well 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. easily 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 of course).

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.
  • 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 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.

Timing for a DAM system migration

This will to a large degree depend on:

  • How many assets you have to migrate.

Migration of data is almost never perfect and will need some adjusting before successful import. The more data, the more odd-one-out data issues which needs fixing.

  • How good/bad a state they are in.

i.e. how much housekeeping/culling needs to be done and by who.

  • 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.

If you give us estimates for the above, we can prepare a quote and time plan for you.