Notes to SharePoint migration - Phase One Discovery

More and more of the migration projects I am involved with are Lotus Notes to SharePoint.

These projects often start out with thousands of Notes, Domino.Doc, or Quickplace applications (or databases as they have been known in the Notes vernacular). It can be very
overwhelming.

Remember the old question: "How do you eat an elephant?" Answer: "One bite at a time." Well, aside from being disgusted at the thought of chewing on elephant flesh, this is really the approach I take with each project.

This post covers the first phase of any successful Notes to SharePoint migration project.

Bold
Start by documenting the current Notes/Domino environment. Find all the NSF files on the Domino servers. Immediately subtract any databases that are Notes specific or mail specific. These can be Help files, address books, user mailboxes, Notes default databases Tips and Tricks, etc. They are easy to spot.

Microsoft makes a tool that will analyze Notes applications. This will help give a list of all the easy stuff. It will show you applications you can easily discard, for example. It classifies things into quadrants. Basically, just about everything falls into quadrant four. All that really means is that the tool couldn't identify an exact template match for SharePoint or which template the design of the Notes application used. Don't worry too much about the quadrants issued by this tool. It can't take the place of human analysis.

The tool does generate a list which you can work from. I open every quadrant three and four applications in Notes or Domino Designer, document the permissions and check the logs for activity. Notes shows who connected and how much data they transferred. If only other Domino servers are connecting, this is an indication that the database can be retired. You can get other clues from this.

Once you get a list of everything, you can do deeper analysis into the design of the more complex applications which may include workflow, connections to other datasources, custom views, forms and email integration. It's important to be thorough with the more complex applications. You need to understand the level of effort involved in recreating these applications on another platform.

If the applications are very complex, access legacy data, or integrate with LOB applications SharePoint is not always the answer. In one case, a client of mine was using Notes to transform raw data dumps from their CRM solution. Moving that functionality in SharePoint just didn't make sense. They were upgrading the CRM solution soon so it made sense that a key requirement of that project would be the data mining and reporting be robust enough that an external application not be required.

One more analysis step I always take is to talk to the people who use the database. Sometimes all they use is a small portion of the functionality. It is always the part of the discovery phase that teaches me the most about the applications. Seeing them use it for ten minutes and asking them a few questions will save days in the end. It also increases user satisfaction. Sometimes you find that no legacy data need be retained in these interviews, or that if it is, they don't mind opening Notes once a year. This can really save time in the design and deployment phases.

Assign a realistic level of effort for each of the more complex applications. This really helps the PMO and management understand the project scope. Add in extra time as there are always unknowns or technical issues that pop up in any IT project.

Stay tuned for the next post where I will take you through the creation of the target environment (SharePoint design) and coexistence strategy.

Comments

Popular posts from this blog

ADMT fails to migrate SID History

Exchange 2010 event errors 2601, 2604, 2501

Robocopy Error 31 A device attached to the system is not functioning