Saturday, 25 February 2012

Migrating Lotus Notes to SharePoint

Problem:  A common scenario is for large organisations to need to migrate from Lotus Notes (LN) to SharePoint 2010.  This post looks at potential issues and provides guidance for planning your migration. 

Initial Hypothesis:  To migrate from Lotus Notes, you will generally have a lot of databases so a migration tool such as Quest Migration Manager is a necessity.  Also consider using a firm that has done migrations they know the tools and have taken a lot of the hard knocks which saves time and produces better results.  Migrations take a long time, most large enterprises want everything migrate in the 12-18 month timeframe until they hear the cost and understand the complexity.  Clients need to be pragmatic but they often simply want Lotus to disappear and SharePoint to replace it.  Yes, it is possible, but as with all IT projects plan and spend you money wisely.

Resolution: Each scenario is unique but it is important to get expertise in Migration and know the migration tools.  And most obviously plan, plan, plan. 

At the highest level I break this into 3 steps: 1) analyse, 2) plan and 3) implement. 

1.> Analysis
During analysis use a tool to provide technical analysis on the Lotus Notes databases.  This is very useful to group the LN applications into how complex the specific migration will be.  The easiest will be direct LN into SharePoint templates, followed by simple list migration.  At the other end of the scale will be customised forms, logic and workflow.  The tools won't migrate the logic or forms (well some claim to) but they can all move your master and historic data to SharePoint.  Also a manual look at the LN database application helps asses the database, speak to the custodian of the LN database.  At the end of the analysis phase, you should have removed duplicate database, unused databases, categorised the difficulty of migration (technical tool and manual inspection as well as discussed with the custodian).  You often find only a part of the database is still being used.  A good example I have seen was a highly customised category 4 LN app (my most complex app type), the technical tool detected the database was being used and had several customised components.  After speaking to the custodian, the LN app was simply being used to create new project codes.  If I had gone into a migration it would of cost a lot take considerable time and added little to no value.  Speak to the owner/custodian and get how important is it to them.   During the face to face review I use metrics to rate the database that can't be detected using technical tools.  For example how important is the tool?  Standard answer is critical.  How many users use the system?  After a few qu's you often find these category 4 applications are not fully used or few users use them or they are not that important so do they really need to be migrated.  As a rough guide after removing duplicates and weeding out unused databases about 30% of the original amount remain, this varies from client to client but as a general rule I mention this to the client.  Next figure out what needs to be migrated out of these remaining databases and which databases are providing the best returns to migration cost.  You will have to prioritise them unless you have a very large budget.

2.> Plan
You now know what databases need to be migrated, ensure that they all go to SharePoint, for instance a lot of companies use Documentum for document management, sure SharePoint can do it but is this the right place for your business/client.  Also a lot of these databases to be migrated are needed for regulatory or archival purposes.  SharePoint is not the cheapest or necessarily the best location.  It may be cheaper and easier to convert archive info into pdf documents and add it to the archive repositories.
Workout the source and the destination with the mapping.  As mention if the LN template is standard most tools can auto detect and add the appropriate target SharePoint template. 
Decide on how the data will be migrated (will you copy the entire live LN database), what about changes to data until LN is replaced.  I'd recommend freezing LN changes, copying some data and the nsf to a separate location.  Perform the mapping.  Try identify custom templates that are used repeatedly to ensure mapping time is reduced.  Define the destination.  Migrate the sample data and ensure the data is thoroughly tested.  Define your migration strategy, all at once?  I prefer piece at a  time.  Do you need training on the new system for the users?  Changes to migrated data after you copy.  Do you have enough time in migration windows to get all the data (terabytes potentially) perform the mapping and do a quick sanity check.  Do you have the SharePoint Infrastructure to handle the additional resource requirement?

3.> Implement
Ensure the new apps have been accepted by stakeholders and tested, users are ready to use the new apps, support is ready to handle requests, it's going to be change and people don't always like change so the servers can't go down, the apps need to be as easy to use as possible.  Implementations will take months and should be batched generally.  Also be ready if there is a disaster, can you get users back to LN, do you want them going back if something goes wrong.

There is more, a lot more but if you analyse and plan the implementation will be smother and succesful. 
For me the 2 most important points are: 1) plan, 2) people - get experiece people (business, project and technical).

Walch, Steve.  2011. 11 Ways to Migrate Lotus Notes Applications to SharePoint and Office 365 -


Post a Comment