This is the second post in a series looking at Implementing an Enterprise Social Network. In this post we are going to look at the importance of Migration activities. We have also looked at the Analysis phase and how to drive Adoption.
For traditional Intranet projects content migration can be a significant consideration, often taking up a large part of project time or budget. Migrating content from other systems, moving documents from file shares and updating users’ details can all take considerable time and effort.
When it comes to Enterprise Social Networks (ESNs), the same considerations need to be taken into account. Content, data, and user migration need to be fully considered to help in the launch and maintenance of a successful system.
In this blog post we are going to look at a number of migration areas that you should be aware of when implementing an Enterprise Social Network.
The very first step in any migration exercise is to understand the systems in question. For an ESN this means:
The first point is simply a case of looking at a past system, or systems, and making a decision on whether to migrate data from it or not.
The second point is a bit more nuanced. Many companies have business systems, like Intranets, that include elements of social functionality. When implementing a new Enterprise Social Network it is important to carefully consider these elements. Will they be turned off? Will the data be moved, or integrated, to the new system?
Finally all good Enterprise Social Networks, including our own, integrate with sources of user data like Active Directory. A migration project, to a new system, is a good time to look at this data and clean or tidy it up.
When considering migration of data from an existing social system we need to think carefully about the types of data. In a typical Enterprise Social Network we have:
User profiles are arguably the most important data we might want to migrate. People tend to spend time carefully building and curating their own profile information. A good migration plan needs to carefully consider how this data is to be moved. Whilst it is important not to corrupt existing profiles, old or seldom updated information could be archived. This is also a good time to consider ‘dead’ profiles of people who have left or moved on.
More generally it can be a good idea not to migrate some data, but leave it in the old system and set access to ‘read only’. When using SharePoint for example, user profiles can be shared between farms, and it is possible to link from the old environment to the new system. By configuring SharePoint search correctly, it is even possible to search the old tool through the new system.
Any migration exercise needs to be carefully considered in terms of cost/benefit, and this is true for Enterprise Social Networks as well. The effort and time involved needs to be considered against the full range of benefits. As we have discussed, profile data is really important so there the benefits are clear. But conversations and activity data in an old social system? Arguably it is less important to have these in the new tool, especially if it is expensive or complex to move them.
The most important thing is that the new system contains high quality content that is relevant and useful to users. If this content is partially migrated from an existing or old system, then great. But here at Beezy we know the importance of continually updating and adding fresh new content to social systems. That is what keeps users coming back, keeps them engaged, and keeps the system useful. So next time you are implementing an enterprise social network, think carefully about migration, but only as part of a wider balanced plan.
This is the second post in a series about Implementing an Enterprise Social Network. You can view Part 1 here, where we take a look at the importance of thorough 'analysis'.