When you are involved in a PST Migration or an Archive migration one of the most tricky things to produce is a plan of which users to migrate and when to perform the migration for those user-groups. There are many different variables that should be considered. In this article we'll look through some of these challenges and ways in which you might resolve things.
First things first, if you have less than say 1,000 users then this sort of problem is likely to not impact you or your environment at all. To some administrators 1000 users might seem like quite a lot, especially if the IT department is very small. However, in the grand scheme of things it's not very many users at all. If at all possible in migrations of less than 1000 users just keep things simple and try to migrate everyone at once (after you have done a test user or two, or three!). Of course it might not always be possible to do things that way. If that's the case you may benefit from looking through some of the options presented here, and adapting them, or 'lightening' them a little, and perhaps that will help with your migration.
Geographies
Usually when there are lots of archives to migrate for lots of users the user population is split over multiple geographies. This could be as simple as different buildings in the same town or city, or more complicated and split across different countries all around the world. So with many archives to migrate one way to slice up the community is to split the migration up based on location. It is worth considering geography though as something other than just 'location'. Consider also cultures. Even in a 'small' place like Europe there are many different cultures to consider, and an approach which suits some countries might not go down too well with people from other countries (even neighbouring countries are different). If you enter into a migration plan of just simply migrating data, there are many cultures who will be resistant to that sort of approach, because they haven't been 'involved' in the decision making. With geographies spreading across the world you also have to take into account timezones and time differences. When you perform an operation on a server environment in the 'middle of the night' it might actually be at the beginning of the working day for some people - and might cause unnecessary interruption.
Hierarchies
In any large organisation hierarchies develop whether IT likes it or not. So when you begin thinking about ways to migrate user archives or PST data you might want to follow this hierarchical approach with your migration. The choice then becomes whether you migrate the senior folks first, so that they seem more important, or the less senior folks first, to give you and your team experience in doing the migration, and ironing out issues, before tackling the people at the top of the company. In companies that have hierarchies like this, often times the people at the head of the company want to be migrated first, so that they can be on the leading edge - they don't want to wait 6 months for you to 'get around' to doing their new-shiney-thing. One possible disadvantage of doing a migration based on hierarchy is that if problems are encountered then all the senior people in the organisation may come knocking at your door, at the same time!
Source data distribution
Something that should also be considered is how data is currently held on the source system - the system you're migrating away from. For example if you have a handful or more Vault Stores, you may want to consider migrating the data from that environment Vault Store by Vault Store. One thing to note when going down this route is that it is sometimes similar to the hierarchical approach. Part of the reason for having multiple vault stores in Enterprise Vault might be because you have senior people grouped together in a particular Vault Store. Sometimes though the Vault Store split of data might scatter across employees across the whole organisation. This is sometimes a good approach because you're not going to impact everyone in a particular team at the same time. So, before considering splitting the data migration based on Vault Store consider which archives are actually in that Vault Store. That being said the idea of impacting 1-2 people from lots of different teams can be a good approach when it comes to migrating data, and processing a whole Vault Store at a time gives an overall impression of movement and builds momentum for the migration. It might also mean that certain parts of the hardware or infrastructure can be freed up more quickly as the migration progresses.
Conclusion
In conclusion you can see that there are a number of variables that can be considered when selecting users to migrate. The job of this article is not necessarily to list all the permutations and combinations of these variables and give you the 'right' answer. I do hope though that the ideas presented here are useful to you, and more than anything it should get you thinking about how to slice and dice up the archives that you have got to migrate, and come up with your own suitable plan.
Have you used any of these approaches when migrating data? Let me know in the comments below.
