Lotus Notes to SharePoint Blog

Blog about Dell's Notes Migrator to SharePoint tool and other things related to Lotus Notes migration projects

Cool stuff in SharePoint 2010 that Notes customers will love: InfoPath everywhere

One of the biggest barriers to moving large numbers of Notes applications to SharePoint is the cost of rebuilding the complex applications.  As covered previously this cost is often overstated and can be mitigated by a good understanding of how to leverage out-of-box SharePoint features and code reuse, but it is still a very real issue. 

SharePoint 2010 contains many advances that will dramatically reduce the cost of application development and (even better) will allow tools such as Notes Migrator for SharePoint to do a lot more of the work for you.  We will cover things such as improvements in declarative workflow, dynamic scalable views, ASPX pages and offline capabilities in other posts.  But first I want to talk about InfoPath.

InfoPath is, of course, Microsoft’s primary solution for building data entry forms for complex business documents.  Many Notes customers see InfoPath as the only real choice for rebuilding Notes forms that contained user-friendly field layouts, non-trivial data validation rules, interactive functionality such as hide-when formulas, etc.  (That isn’t completely true, but InfoPath was certainly where most people start looking.)  The Notes Migrator for SharePoint features for migrating Notes form designs to InfoPath templates and migrating Notes documents to InfoPath data documents have certainly been very popular.


Unfortunately, there were some significant practical barriers to using InfoPath 2007 for large scale application development.  Here are the top three problems that I observed and how SharePoint 2010 and InfoPath 2010 solves them. 

1. SharePoint/InfoPath 2007 forced you to store your data as XML data documents, usually in SharePoint Document Libraries, and did not really work with SharePoint Lists (the natural target for most Notes application content).  With 2010 you can use InfoPath forms for both Lists and Libraries.  You can even start with an auto-generated InfoPath form (based on your list schema) and start customizing it from there. 


2. Unless you were willing to deploy the InfoPath 2007 client to all your user’s desktops, you had to live with the limitations of InfoPath Form Services (try telling your Notes users that they can’t have embedded images anymore).  With 2010, there have been a number of dramatic improvements in InfoPath Form Services and the web experience really is at near-parity with the “rich client” experience.

3. The process of building, maintaining and publishing InfoPath 2007 forms was a cumbersome and sometimes fragile process that was pretty much outside of “normal” SharePoint customization and development activities.  With 2010, you now have a very integrated experience which will make designing your custom forms a much more mainstream activity that even beginning developers can perform.


There are plenty of other InfoPath improvements that will reduce the cost of rebuilding Notes applications: additional controls, more seamless workflow integration, and automatic offline support.  My prediction is that InfoPath forms will replace ASPX pages (whether built by SharePoint Designer or Visual Studio) as the tool of choice for many developers and certainly for people trying to rebuild lots of Notes applications.

5 responses to “Cool stuff in SharePoint 2010 that Notes customers will love: InfoPath everywhere

  1. Kanchan May 5, 2011 at 6:53 pm

    Hi Walch,
    if notes forms has master-child relationship, how quest will help in generating and migrating to Infopath 2010, will Quest 6.0 help ?


  2. swalch May 5, 2011 at 9:22 pm

    Sorry, I am not sure what you mean by master-child relationship.

    • Kanchan May 6, 2011 at 8:34 am

      I’m sorry, I mean parent child relationship, exactly like discussion board, will quest help in migrating response documents if parent child is implemented for infopath 2010 forms.

      • swalch May 6, 2011 at 11:10 am

        Well that depends on what you want to do exactly. InfoPath itself does not offer a lot of options for implementing response documents, but in general you first need to figure out what your new solution will look like. Worry about how the new app should look and behave first (and what InfoPath and SharePoint will allow), and then figure out how to migrate to that.

        Assuming for a minute that you are talking about InfoPath XML documents in a form library, one option might be to merge many notes docs into one infopath doc, taking advantage of the multi-level data structures that XML allows you. NMSP does not handle migrating many docs to one doc per se, but it does allow for migrating multi-valued items to complex XML structures. So a workaround would be to create a migration job that migrates the top level documents and use formulas in the job to lookup data from the child documents, yielding multi-level data items.

        If you feel like you need additional help with this, it might be a good idea to open a Quest support case or prehaps contact Quest presales.

  3. Kanchan May 6, 2011 at 2:07 pm

    Thank you swalch, i will try to open a quest support ticket, Thanks once again