Welcome to part two of our article on digital asset management (DAM) system migration by John George. Part one, which you can read here, focused on the tasks that lead up to migration - assessing your team’s DAM needs, conducting research, and interacting with vendors. Part two is all about the implementation.
Implementation, as described here, is about getting our assets into a new system. We’ve broken it into three parts.
- What to expect during pre-implementation: It’s time to double check that the system will meet your needs. Also, revisit your metadata schema, assets, user roles and asset groups. Be prepared to re-conceptualize and re-categorize.
- Implementing and testing: Move all your assets and metadata, then make sure the new system works as you would expect. Use your resources to correct problems.
- Keeping it clean during post-implementation: Keep track of what needs to be addressed post-implementation and can be added to a roadmap.
Enjoy the second half of the story to George’s corporate digital asset migration.
Internal approval, contracts, and planning
Pre-implementation begins where we left off in part one: vendor evaluations. The directive was to create request for proposals and create a list of questions or use cases specific to your needs and present them to vendors for use in demos. The objective was for you and your team to attend demos that address your needs – not a generic list of functions.
Once we found our best-fit system, the Widen Media Collective, it was time for the tasks of pre-implementation.
Contracts and administration
Getting the software upgrade pushed through upper administration was the most time-consuming part of our migration process. Each level of decision makers had to be convinced that the change was a benefit.
A primary concern centered around the Media Collective’s ability to replace libraries that served external partners like media and business collaborators. The current DAM served marketing and its vendors, but other departments had their own libraries and needs. Smaller needs assessment meetings were held with those stakeholders to make sure that the new software would comply. In short, we had to prove a financial benefit.
We spent a fair amount of time double-checking functionality in this phase. We talked directly with the managers of the secondary libraries to make sure the Media Collective would work for them. We took their questions back to our Widen advisor to make sure that features – such as collection share pages or the InDesign plugin – performed as we understood and met the requirements of our team. We were happy to find that they did.
Once we got approval to migrate to the Media Collective, we continued working with our Widen advisor to create a Statement of Work (SOW) and a Master Service Agreement (MSA). These documents are critical for implementation.
The SOW covers items such as:
- Pricing and structures for charges
- Number of users
- The implementation process, including a sample schedule
- A description of the web hosting service and security related to the hosting services
- The Service Level Agreement (SLA), which outlines expectations for access to and reliability of the software and response times to queries and outages
- Optional/additional features, including both those that will and will not be implemented
While the items covered in the SOW can be altered, having a document of expectations and understandings made the process go smoother and helped avoid hangups during implementation.
For example, the Media Collective offers single sign-on (SSO), meaning the DAM system connects to your company’s active directory, which allows employees to quickly log in to the DAM system with an existing account. Using an SSO can affect how you design your permissions structure and assign users to user groups, so you want to know up front if you are going to use that feature or not. Changing midway through implementation can result in a messy situation.
The SOW became part of the MSA – the binding contract that both parties sign. You’ll want to have your legal team review the MSA. Once that is signed, implementation can begin.
Parsing migration tasks is essential. Putting the responsibility for a task with the appropriate department or person makes work lighter and gives the work to an expert who will do it right.
The company had two main players involved in the system migration: marketing and IT. In this phase, we were also introduced to our Widen implementation specialist who gave essential guidance and support.
The marketing department had the bulk of the workload including:
- Project management. The major responsibility here was keeping the project on track and sharing changes across teams. A major part of this function was maintaining a calendar of tasks and who is responsible for them. Widen provided a calendar for their specific tasks, but we had additional tasks and wanted to break down some of Widen’s steps into more digestible tasks. We kept own calendar using Widen’s as a template, but you could create your own using Microsoft Project, a spreadsheet, or some other tool you like. Our internal calendar was developed and maintained by the librarian and the senior marketing manager.
- Image audit and weeding. Migration is a great time to go through your library and remove duplicate, expired, and under-used images and other files. We did most of this work after our files were loaded into the Media Collective. If you are close to your storage limit, you may want to audit and weed before migration. Our librarian handled that with input from stakeholders.
- Metadata audit and clean-up. Review your metadata schema and remove unnecessary fields. Move data to new fields. This work was done in both the legacy system and in the Media Collective. Another librarian task. Do you see a trend here?
- Defining asset groups and user roles. There are two sides of the permissions coin – figuring out which buckets to place assets into and what groups of users to give access to for each of the buckets. This is arguably the most challenging part of implementation process, as new types of assets are added and new groups of users need access to them. Responsibility was with the librarian with consultation from stakeholders.
- Communicating with users. This involved letting users know that the system would be updated, scheduling training, and setting up registration systems. The senior marketing manager and librarian handled this step.
IT, which managed the infrastructure for the old system, was responsible for one primary task: copying the assets and the metadata from the old library and delivering them to Amazon Web Services (AWS) and Widen. This turned out to be a more difficult task than expected because of some eccentricities in the old system. IT saved all the assets to a hard drive, copying them folder by folder from the old structure. They did the same for the metadata.
The Widen implementation specialist both consulted on best practices for the migration and was the obvious subject matter expert on the software, advising on specific tasks and helping to put the tasks in the right time order of tasks.
Implement and test
The big move
Widen provided a host of resources to help prepare our DAM administrator for the migration. The most important resource was the implementation specialist. Widen assigned us an expert who will work with you throughout the process by offering options, sound reasoning, and knowledge to help you with each step of the implementation.
Look for valuable resources like these to guide your system implementation when migrating:
- The Admin Playbook, all about activities and processes necessary to run a DAM system. It’s a big-picture document that shows the basics of maintaining a DAM system.
- The Site Setup document, including how your login and interior pages will look, how you’ll be transferring the assets and metadata, password specifications, the end-user license agreement, and the system URL. With the Media Collective, you can get a personalized vanity URL or use a subdomain of widencollective.com (e.g., yourcompany.widencollective.com).
- The Implementation Worksheet, which takes you through the steps needed to get the system rolling. It helps you set up your administrators, outline permissions structure and metadata schema, define categories, identify beta testers, and more. When you’ve completed the Implementation Worksheet, you’ve done a lion’s share of the conceptual work and you’ll be ready to launch.
Delivering assets and metadata
Widen sent us a hard drive, which we used to save our assets. It was then sent to AWS and, following that, uploaded into our Media Collective site. If you have the wherewithal to organize your assets into folders in advance, the upload will also result in a category structure that will better help users navigate your system.
Delivering the metadata took a little more thought. Widen offers the ability to upload metadata from a spreadsheet if you can extract it from your current solution. That wasn’t an option with our files, so Widen worked with us on alternate solutions to help migrate our metadata.
During implementation, we mapped out a high-level taxonomy for the DAM site. Widen helped me align our metadata migration with those implementation decisions. Once that was done, our assets were uploaded, metadata was added to the associated images, and the basics of the site were up and running!
Setting up the assets groups and corresponding roles is critical to controlling access to your assets. In our old system, we assigned one role to each user. This created some confusion, as we had many different asset groups and users needed access to more than one group.
With the Media Collective, we implemented a modular system, meaning that the assets were broken down to fine-grained asset groups and subsequent user roles. We also created roles for some of the functionality -- like sharing -- separately. Users get access to any number of those roles, so they’re often assigned to six or eight roles. While this sounds complicated, it makes it really easy to see which assets a user can see and download.
The selection committee was a tremendous help with beta testing. I created scripts that guided through various tasks: searching, filtering, finding metadata, downloading, creating and sharing collections, and, for more advanced users, uploading and editing metadata. We also tested different user roles to make sure that governance was correct, and we tested on Mac and PC platforms using various browsers.
The scripts were created in Excel with screenshots to help testers find their way in a new program. Testing lasted about two weeks, and the results were good. We addressed some specific changes in permissions and updated the filters that were available and the order they appeared. We launched to our larger user base about ten weeks after the implementation process began. Widen helped us create a short training video for our users, and we took advantage of additional training offered so users could easily register and login for the first time.
Keeping up your system up to date
The launch was a great day if perhaps a little anti-climactic. There wasn’t any tickertape. No doves were released. We thanked everyone who helped along the way and congratulated the core team. Then it was time to get back to work.
Throughout the migration, we identified features that we wanted to use, but knew we wouldn’t be ready for with the initial launch. Chief among those was connecting the Media Collective to a CMS platform our IT department created. We also had clean-up tasks, like closing down the other libraries.
Working with the senior marketing manager, I devised a schedule to address these migration items and prioritized them based on cost, value added and readiness. For example, closing a specific secondary library would save almost $10,000 per year, so that was a top priority. But the CMS was a year from launch, so it didn’t rank as high. It’s important to note that system migration is an organic, ever-changing thing. We felt one clear sign of a good DAM solution was being able to grow and morph with our needs over time.
A couple of days ago, my boss was looking for reference material from of our migration process. She found a file dated October 2013 and was reminded that it took 15 months to identify, select and launch the Media Collective. Since then, I’ve heard nothing but good comments about our new DAM system — and NO ONE says they wish we had the old system back. That says a lot about the success of the system migration.
The time we took to check in with users and research other systems paid off. We improved the structure of our data and permissions and worked on the future road map. We are also working with IT on a CMS platform that will integrate with the Media Collective.
As the librarian/administrator, I couldn’t be happier. Users like the product and usage is up. And I can get back to my day-to-day work of cataloging images and helping users.
John George is a digital asset archivist and seasoned DAM professional. He has a strong background in information management theory, and is experienced in metadata development, taxonomy construction, and managing digital archives projects. John has worked with digital asset management systems such as Widen, MediaBin, and ContentDM.