Subscribe:

Labels

Wednesday, June 22, 2011

Migrating Lotus Notes applications to SharePoint 2007 – Part 3


Part 3: Migration Process

Any Lotus Notes application has 3 parts to it:
  1. User Interfaces Pages or Forms – Lotus Notes Forms, Pages, Navigators, etc..
  2. Application Logic – Lotus Notes Scripts/Formulas in Action buttons, Agents etc..
  3. Data – Lotus Notes Documents
Given the architecture of Lotus Notes and APIs it provides, you can only migrate #3 i.e. the data out of its databases. That's the ground reality. So,
  • If the application can be mapped to a List Template in SharePoint, you get all the user interface elements and features out of the box from SharePoint. Even if some list/library customization is required in SharePoint, the effort is small and manageable
  • If application needs custom InfoPath form, ASP.NET form, Web Part(s) or complex workflows then those elements need to be custom developed and effort might be substantial
So, migration process and effort depends on whether a Lotus Notes application can be mapped to some out of the box or custom template in SharePoint or not.
Classifying Appplications
Classifying applications based on their complexity, features and integration requirements helps in:
  • mapping each application to target solution
  • evaluate and select migration tool (s)
  • estimate effort required and prepare a project plan
As the Application Analysis Envisioning Process for Lotus Domino Applications guide mentions, dissecting the domino application and determining the baseline pattens will help you be successful in seeing the end-state solution that will replace the Domino Application. Some patterns mentioned in it are:
  • Pattern 1 Document Management
  • Pattern 2 Workflow
  • Pattern 3 Connection to external data source
  • Pattern 4 Connection to other notes application
  • Pattern 5 Discussion databases
  • Pattern 6 Team rooms
Based on your environment, you can identify more patterns and then use them to classify applications. One of the ways to classify them might be:
  1. Simple applications - can be mapped to standard SharePoint list/site templates
  2. Medium applications - applications without workflow - need custom list/site templates in SharePoint
  3. Complex applications - custom applications with workflow - need custom list/site templates and workflow development
  4. High Complexity applications - need extensive SharePoint application development
  5. Non-SharePoint apps - where SharePoint is not the right fit technically/strategically. They will get replaced by some existing .NET application, a LoB app or some standard package

1 comment:

  1. this is a good resource for sharepoint
    Congrats and thanks

    ReplyDelete