Three Steps to Successful PST Migrations
In this article I will discuss three crucial steps to a successful PST Migration into Enterprise or for that matter into Exchange. If you approach a migration project with these three key-areas in mind your chances to deliver a project on-time, with a good level of user acceptance and with very few surprises are definitely going to be increased.
Step 1 - Planning
Hopefully to all the readers of this article it is pretty clear that any kind of PST Migration project for hundreds or thousands of users needs to planned out before it can be started. You might need additional hardware for the migration, or at least to check on the capacity of the existing hardware. Additional resources might be needed during the project to assist with issues directly coming from the PSTs that you're trying to migrate - and not just the PST files themselves, but also the end-user gripe of having 'lost data', and helping the user find it again. There are many things to work through, but, in the end the aim here is not to plan things in such detail that things become amazingly complicated. In fact just the opposite is what is needed to help with a successful migration. You want the planning to be good, and the eventual plan to be as simple as possible.
Migrations to Enterprise Vault or to Microsoft Exchange, even for thousands of users can be quite daunting as you may spend a lot of time figuring out every single what-if combination and permutation. But it's not a good path to go down. It's far better to keep things simple and to keep in mind this simplicity as the project proceeds through to completion.
One of the key aspects in all this planning points towards ....
Step 2 - User Involvement
Simply telling end-users that PST files are going to go away will probably fill them with dread and hatred. Dread in that they will believe that they are going to lose data. Hatred in that they are thinking that the 'evil' IT department is interfering again.
Both of these are needless worries if you involve users and spend more time telling them about the benefits of the PST Migration. You don't even have to mention that you are eliminated or removing PST files. Focus instead on the fact that you are migrating PST files, and that you're going to give them a better experience. Whether your target environment is Microsoft Exchange Personal Archives or Enterprise Vault users are going to have infinitely better access to the data in their PST files, and it's going to be at their finger-tips rather than buried away in files and folders on their hard drives, pen-drives or even more uncomfortably on CD or DVD's.
Of course there are advantages to going to Exchange versus Enterprise Vault, and there are advantages of going to Enterprise Vault versus Exchange - that's not a focal point in this article, and to end-users it probably doesn't matter either. What matters more is that they feel part of the migration, and that they are getting something out of it.
Why not send end-users weekly or bi-weekly reports on the overall progress of the project? Tell them of the thousands of files totalling hundreds of Gigabytes that have been made more accessible in the PST-target-environment.
All of this leads to the third step ...
Step 3 - Execution
Choosing the software to do the PST migration itself is tricky. If you're going to Enterprise Vault or to Exchange there are a variety of products that can be used, and of course there are even built in mechanisms in each product. To get the best out of your migration though, I think you need to invest some money in expertise, and get a great product. The built-in migration tools are lacking in quite a few different areas:
- no user involvement
- poor user communication
- no progress reporting
- difficult to identify errors
- hard to process all PST files with one tool
Those are just some of the areas that both the Exchange PST capture tool and the built-in Enterprise Vault PST migrations tool lack. Remember as well that Enterprise Vault has several mechanisms that can be used to ingest PST data. But each of those shortcomings can be a deal breaker, and importantly to organisations in this economic climate, they can be costly to work around.
Products like PST FlightDeck and PST FlightDeck SME from QUADROtech address these concerns head-on and aim to rectify them all as well as provide a powerful interface for administrators to manage the PST migration with. Take a look at the main PST FlightDeck SME Dashboard below:
It contains a wealth of important information and gives you, at a glance, the overall status of the migration. Of course there is also a lot that goes on underneath the covers with password removal, backup, user-level deduplication, filtering based on age or message class and conversion of old ANSI PSTs to Unicode being just some of the activities that can take place on a PST file before it's migrated into the target environment. That's not all though - the target environment can then be Enterprise Vault, or even Exchange 2010 (or higher) Personal Archives, or Office 365.
In just a short time it's easy to get up to speed with the terminology used in the product and it can even help with the planning and user involvement steps of the project. A powerful client-side Migration Agent can be deployed to really report on the PST files that end-users have stashed away on local disks, as well as portable devices and network shares. It also has powerful user messaging built-in which will really let the user explore what is happening with their data.
Of course whether you choose PST FlightDeck or one of the other third party products like PST Accelerator is down to the way your organisation works, but the gain for a PST migration project is clear - in using these third party products you get the knowledge and skill that has been focused into a product by dedicated, passionate experts in their field.
In conclusion you can see that really these three elements for success are simple, straight forward, and dare I say it, common sense. Without adequate planning, but with an eye to simplicity many projects, never mind IT projects, will fail. Involving the people impacted by the project means that they accept the change more easily, and of course excellent execution on the plan is essential.
You would be surprised when talking to different system engineers and project members how often these key steps are forgotten in the rush to perform an ill-planned PST migration with little-to-gain for end-users. If you are a system engineer or consultant I'm sure you'll be all too familiar with issues that have come up in projects when these key steps have been missed or de-emphasised. Taking them on-board, and approaching the project with a good level of agility to adapt to changes along the way will really help deliver more successful projects.
Have you been involved in PST migrations where these elements have been forgotten about? How did it work out?
