{"id":1590,"date":"2023-01-09T11:16:45","date_gmt":"2023-01-09T09:16:45","guid":{"rendered":"https:\/\/dam-evangelist.blog\/?p=1590"},"modified":"2023-01-09T11:16:45","modified_gmt":"2023-01-09T09:16:45","slug":"how-to-replace-my-dam-system-a-mini-roadmap","status":"publish","type":"post","link":"https:\/\/dam-evangelist.blog\/en\/2023\/01\/09\/how-to-replace-my-dam-system-a-mini-roadmap\/","title":{"rendered":"How to replace my DAM system? – A mini roadmap!"},"content":{"rendered":"

In the new year, many people make the resolution to part with old, unpleasant habits or things that have gotten old.
\nMany a DAM system has also aged over the years and if you have finally reached the point where all anti-aging cures have been unsuccessful, then it is probably time to say goodbye (see also:Is it time to get rid of your legacy system? 5 signs that speak for this!<\/a>).
\nChanges and goodbyes don’t always come easy, so you should have a little roadmap ready for this!<\/p>\n

\"\"<\/a><\/p>\n

Notice:
\nThis article is not about evaluating a new DAM system. I am assuming here that this has already been done!(Select Software the agile way! Here is why you will be successful!<\/a>)<\/p>\n

I would like to share some ideas for such a roadmap with you here.<\/h5>\n

Ultimately, the environment variables of a DAM system could be roughly divided into three cornerstones:<\/p>\n

    \n
  1. The DAM system itself, i.e. the core of the application.<\/li>\n
  2. The people who work with the system<\/li>\n
  3. The other systems that interact with the DAM system.<\/li>\n<\/ol>\n

    1. Let’s look first at the DAM system itself.<\/h4>\n

    (Of course, it has to be decided individually which data or if any data should be migrated at all!)<\/p>\n

    Ultimately, a DAM consists of three components, to put it simply:<\/h5>\n
      \n
    1. The physical data such as images, documents, movies, audios, etc.<\/li>\n
    2. The abstracted data, i.e. the different types of metadata.<\/li>\n
    3. \nThe user and group administration including the rights system<\/li>\n<\/ol>\n

      The physical data are usually present in such a way that they cannot simply be “grabbed”. This means that I usually cannot simply copy them via the file system. Export functions are usually needed for this.
      \nThe same applies to metadata that must be extracted from a database.
      \nWith users and groups, the first question is whether they were actually created in the DAM system or whether the DAM system was connected to a central user administration (e.g. Active Directory).
      \nIf the latter is the case, then the new DAM system must simply be connected to this central administration (standard nowadays! See also:      Bind your DAM to AD (german written only)<\/a>)).
      \nIf the users are local in the old DAM system, it depends on whether it is possible to export them (attention: stumbling block passwords!) with the help of standard and custom functions. In the worst case, all users and groups have to be created again. In the case of permissions, this will have to be done anyway, as they can hardly be migrated.\n<\/p>\n

      2. The people who work with the DAM system:<\/h4>\n

      The user and group information is an important information base. With the help of this information, it is very easy to track who is working in the DAM system. (Let’s leave temporary guest accesses aside for a moment).
      \nIt is also important to ask from where these users access the DAM – a DAM system should not always be freely accessible from the Internet. If there are users outside the organisation, they must be provided with VPN or similar.<\/p>\n

      3. The other systems that interact with the DAM system:<\/h4>\n

      This is where it usually gets a little “tricky”. Of course, the wish would be that a central API or a central data hub already exists in the company into which the DAM feeds its “information”.
      \nCurrently, this is hardly ever the case (but this architecture should be a target for the new DAM system)!
      \nAt this point, some detective work is usually required.
      \nIf you have to start from scratch here, then it is worthwhile to start “simply”.
      \nBasically, there can be two different types of interactions:<\/p>\n

    4. Ad hoc interactions, i.e. triggered actions, for example, an image is called up in a third-party system, this call goes directly to the DAM system. <\/li>\n
    5. Cyclical interactions: At time x, action y is carried out. For example, images are made available for the web shop once a night.<\/li>\n

      With this knowledge, you can work your way forward. Ultimately, one will first look to see if there are log files, or configurations in the system, if this is not the case, one can move on to monitoring the traffic.
      \nThese are certainly not things that a product owner\/project manager can do, but they should have them on their radar and get the appropriate people on board.
      \nI have developed a variety of mechanisms that can be used to deal with this complex issue, and I would be happy to support you in this!
      \nSee also:      DAM Evangelist – Services<\/a><\/p>\n

      Then I can start now?!<\/h4>\n

      Get started yes, but migrating a DAM system requires good planning.
      \nThis mini roadmap is only intended to highlight the main areas that are always affected by a migration.
      \nThese areas must be individually filled with life. For this, one will have to get one or the other expert on board. Especially the point “communication with other systems” can quickly become highly complex.<\/p>\n

      I will be happy to answer your questions or support you in one or all points!<\/p>\n

       <\/p>\n