The battle for the collaborative application space has been long fought. Two key players, Lotus with their Notes/Domino platform and, more recently, Microsoft with SharePoint, have established their own collaborative platforms having different feature sets but a common goal – to allow individuals, teams, departments and organisations to work more effectively together.

An organisation’s investment in a collaborative platform can mean significant financial and staff investment. Moving an organisation from one platform to another produces a number of challenges. This article, aimed at a SharePoint 2010 developer who also understands Lotus Notes development, introduces some of the considerations when migrating applications from Lotus Notes to SharePoint. Although you won’t be a migration ninja after reading it, you will at least be more aware of the obstacles that you will face and be more equipped for the road ahead!

A couple of caveats first: my Notes development experience ended with version 7. If the current version, 8.5.2, has a nifty new feature called “Migrate Complete Application to SharePoint in 1 Click”, then that’s great, but I shall only address my knowledge up to version 7. Also, views are my own and not those of my employer.

In 2005 IBM portrayed Microsoft as being utter failures at collaboration by listing thirteen “failed” products in their “Collaborative Graveyard” image.

(Facsimile of copyrighted presentation slide, IBM, 2005)

Six years on, Microsoft would like to depict their collaborative offering as somewhat brighter.

I’m not sure it’s quitelike this but, for various reasons, many organisations are moving from Lotus Notes to SharePoint. I would like to share some ideas and approaches to simplify your own migration.

Successfully migrating from Notes to SharePoint can involve much work but I believe it boils down to three key phases: application/owner audit, cleansing, and migration. 

Application/Owner Audit

Deliverables: known applications, known owners, known migration decisions

To know what to migrate ideally requires an up-to-date application and owner inventory. The main approach should be to establish a list of all of the Notes applications in your organisation. From this list, discard those that you know you definitely don’t need (such as system databases). This core list then allows you to focus on which can stay and which can go. At each stage, your number of applications is reduced, as illustrated below.

If you don’t have an application inventory, or cannot consider third-party analysis products like those from Quest or Binary Tree, start by grabbing a copy of your Notes Domain Catalogue (catalog.nsf).

This catalog copy can become your actual migration monitoring application. After discarding the known unwanted applications, amend the main form to capture:

• application metadata (path, size, number of documents)
• security – ACL, use of readers/authors fields, field-level encryption
• potential owners (retrieved from document authors, the ACL and the user history)
• screenshots and descriptions
• questionnaires – a list of who has already been consulted
• migration checklist

Next, consult your users to find your applications’ owners and whether the applications are required. A questionnaire could be implemented into your Notes migration application to ask simple questions such as:

• do you use this application?
• are you the owner of this application?
• do you still require this application?

This questionnaire could be implemented using a simple form, using a workflow as illustrated below (click the image to enlarge).

Your questionnaire responses may fall into six broad categories:

Migration to SharePoint not required

• remove the application now
• application has a limited shelf life – retain the application until end of life and then retire
• don’t migrate but export the data to CSV, Excel, XML, etc.

Migration to SharePoint required

• migrate functionality only
• migrate the functionality/data but not the security (use SharePoint security)
• migrate everything

As can be seen, there are two types of migration – design and data. But before that, the big clean up.

Cleansing

Deliverables: functional specifications and clean data sets

Cleansing is the process whereby the application is made good to go (literally)! I see two necessary types – design cleansing and data cleansing.

Design cleansing refers to the production of a functional specification by a business analyst in consultation with the users. This should focus on what the application does, not how it does it. Technology should not be considered; I’d recommend not even looking at the old Notes code!

Data cleansing, ideally performed by the business, refers to the removal of any data no longer required (it’s useful to enforce a cut-off date for this). If you think they might not be sure what they need to keep, consider offering to migrate the last six months’ data or implement a per-GB data migration charging model. That’ll get them thinking!

Migration

Deliverables: migrated applications/data

Now it’s time to consider the actual migration, which I see as having one or two components depending on your owner’s requirements – design migration and data migration.

The Design Migration

The design migration is the job of your developers. Look for common functionality across all of your applications before any development. Identifying reusable functionality or the need for site definitions will save time and effort in the long run.

Consider which applications:

• use a standard Lotus template
• use an in-house template
• contain design elements that use an in-house template
• reference shared LotusScript/Java script libraries
• connect to other Notes databases (dependant databases might need to migrate as one group)
• connect to non-Notes sources
• map to standard SharePoint sites and lists
• are true one-offs
• rely on real-time updates
• contain “large” numbers of documents
• contain “large” security models (document-level permissions)

Your approach to how you develop certain functionality can be influenced by:

• the complexity of your Notes application’s security model
• the SharePoint feature set (2007? 2010? Foundation? Enterprise?)
• your organisation’s willingness to use third-party products or SharePoint migration tools (vs. in-house development)
• your organisation’s acceptance of “against-live” tools, such as SharePoint Designer or Nintex Workflow
• your organisation’s definition of “like for like”
• your ability to influence your management!

Despite these factors, your main focus should always be on reproducing the functionality, not adding unnecessary bells and whistles. Visual Studio should only be considered after the simpler development in the web interface (UI) has been ruled out. Start with the UI and take that as far as you can. Development and deployment become increasingly complex the more you move away from the UI and into custom code, as illustrated below.

Establish a set of Notes/SharePoint “functional equivalents”. For example:

Two essential developer tools for migration work are InfoPath and SharePoint Designer.

InfoPath is the closest match for a RAD Lotus Notes developer and is excellent for:

• “hide-whens”, using formatting rules
• complex validation rules
• complex data structures – with promoted InfoPath fields, you get the additional goodness of document libraries

As well as superb UI design capabilities, SharePoint Designer (2010) workflows should be able to reproduce a significant number of your Notes workflows – whether it’s changing the status of a document, sending an email or locking a document.

You may also need to consider:

• if a third-party product would suffice
• migrating your application to Exchange
• developing inside an Excel spreadsheet, Word template or Access database

Beyond “core” SharePoint development, you may also wish to:

• host a SQL server backend with a SharePoint front end
• retain the Lotus Notes backend but host it in SharePoint, using an iframe. (I would discourage this as you may need to change Domino to use IIS as an alternative HTTP stack, authenticate using Active Directory, and possibly web-enable the Notes application. Notes is going anyway after all!)

The Data Migration

Standard Notes fields (text, choice, dates, etc.) can map easily to SharePoint list columns. However, it’s not all so simple, as Notes documents contain rich text fields and these can store pretty much anything. It’s not uncommon for a single Notes document to have multiple rich text fields, each containing mixtures of formatted text, attachments, and Object Linking and Embedding (OLE) objects.

You may need different migration targets for different types of data contained within a rich text field. Consider, for example, fifty pdf files inside one Notes field. How should these be migrated? Here are just three possibilities – one SharePoint document library storing one document which itself contains fifty attachments, fifty SharePoint document libraries each storing one document having one attachment, or any number of alternative combinations.

As you can see, Notes data migration might not just be about “lift, move and dump”. You may have to consider information architecture as well.

A couple of final data tips:

• before the data migration, ensure any existing Notes workflows are completed. Then block all users. That way, you can ensure the data to move is accurate and complete.
• links inside Notes documents can point to other Notes documents which will break once the data has migrated to SharePoint. Tools like Quest’s can monitor and replace document links.
• after your migration, redirect Notes users to the new SharePoint site (this should work whether the Notes application was for the client or the web). Eventually remove the Notes application completely (and ring a bell).

Final Recommendations

Knowing in advance what to have in place and what to avoid can make your migrations that little bit smoother. Here are three recommendations.

Avoid Co-existence

Geographical separation of your users might mean that one set of users uses the Notes application and another is using the SharePoint conversion. You may then need to use a real-time link re-direction and data synchronisation service (for example, Avepoint’s) to ensure that both applications can co-exist. But try to avoid it!

Consider A Directory Name-Mapping Service

To preserve name-based document security, develop a Domino Directory to Active Directory name mapping. This could, for example, consume an AD web service.

Develop A Core Code Library

Hardly unique to a SharePoint development environment, but the more you can reuse, the quicker the migration.

Conclusion

Lotus Notes and SharePoint both provide compelling enterprise collaboration platforms, each having unique feature sets and limitations. Migrating from Notes to SharePoint adds an extra challenge on top but, with an appreciation of both platforms and thorough thought, planning, and a simplistic functional focus, your migration can be less painful, less time-consuming, and more efficient. I hope this article has provided ideas and inspiration.

Please note: This article is a finalist entry for the Aspiring Authors Competition 2011. To vote for this article as the winner, please use the Like button below, or read the contest details on http://sharepointmagazine.net/aspiring-authors-competition-2011.

[wpfblike]