Lotus Notes to SharePoint Blog

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

Category Archives: SharePoint 2010

Allowing PDF files to open in the browser

Does your SharePoint server force you to save PDF files to disk first, instead of opening them directly from your list or library?  If you are lucky enough to have access to SharePoint Central Administration, there is a simple way to fix this in your web application’s General Settings.


The details are discussed in this blog post by Bram Nuyts: http://bramnuyts.be/2011/11/03/allowing-pdf-files-to-open-in-the-browser/

Now if only Microsoft would change this setting on Office 365!  Without it, archiving your old Notes applications as PDF documents is a lot less satisfying.

New Webcast: Migrating Lotus Notes Applications to SharePoint Online in Office 365

How should I connect? How do I link? Which solutions do I need to install?

[Note: I am updating this old post to reflect the latest migration options in Notes Migrator for SharePoint 6.0.1.  Specifically, the “Lightweight Migration Service” is no longer needed.]

Connection options

Notes Migrator for SharePoint 6.0 now supports two very different ways to connect to SharePoint sites in order to migrate content to them. 

1. Quest Import Service.  The “classic” way is to install the Notes Migrator for SharePoint Import Service.  This is a stand-alone IIS web application that you run on one or more of your SharePoint front-end server boxes.  You have to directly access (or remote into) a SharePoint front-end server, run the NotesMigratorForSharePoint-Services-64bit-6.0.0.x.msi setup program, and select the “Import Service” option.  You need to be a farm administrator to install it and think about service accounts, permissions, etc. 

You also have to configure every new SharePoint site collection you create to use a particular Import Service instance.  To make this possible you also need to install the “Front End Services” solution included in the same NotesMigratorForSharePoint-Services-64bit-6.0.0.x.msi setup program.  Unless you are putting these components on different physical machines, you would simply install both components at once, which is the default. 

The Quest Import Service is definitely not trivial to install, but it is by far the most powerful and best performing option.  It should be noted, however, that there are three cases where the Quest Import Service cannot be used at all:

  • You are migrating to Office 365 (SharePoint Online Standard or Dedicated)
  • Your SharePoint site is using Claims Based Authentication
  • Your administrator refuses to install third-party code on your SharePoint environment


2. SharePoint 2010 Web Services.  The new option, for 2010 customers only, is to migrate via Microsoft’s new out-of-the-box web service.  This is much simpler to deploy – in fact there is often no need to deploy anything on your servers at all (see below).  There are really only two disadvantages to using this approach.  First, it can be significantly slower than running migrations via the Import Service.  Second, there is a slight limitation to how our Link Tracking Service works.  As you will see below, everything works in the end, but the user experience suffers a little until you finalize your links.

Linking options

Related your choice of connection options is the choice of Link Tracking Service options.  The Quest Link Tracking Service is an optional feature that keeps track of all the Notes documents you have migrated and dynamically redirects users to the current location.  I won’t go into all the details of the service here, but I want to focus on how the Link Redirector page works. 

If you enable the Link Tracking Service, every Notes DocLink (or HTTP link to a web enabled Notes document) in every migrated document gets converted to an HTTP link to a Link Redirector page (QuestLinkTracking.aspx).  This redirector page typically performs a lookup in a centralized Link Tracking database and then dynamically redirects the user to another migrated document in SharePoint (if it has been migrated) or to the original Notes version (if it has not yet been migrated).  So the natural question here is: Where does this Link Redirector page live and how does it get installed?

There are actually now two different versions of the Link Redirector page that you can choose from.  First is the “classic” one that you get when you install the Front End Services solution described above.  This one is configured on a per site collection basis, alongside the Quest Import Service.

An alternative version is the Sandbox Link Redirector page.  This version is intended for cases where you do not have the ability to install custom solutions and/or you cannot establish SQL connections from your server to the a shared Link Tracking database.  The main case we were thinking of when we designed this solution is Microsoft’s Office 365 environment and other highly secured hosting environments, but there will be plenty of people who prefer this option even for on-premises environments.  This page is packaged as a simple SharePoint solution (Quest.SandboxLinkRedirector.wsp).  Because it is a sandbox safe solution, it can actually be installed by any site collection administrator, even on locked down environments such as Office 365, without involving your farm administrators at all.


Note that because Sandbox Safe Link Redirector page does not connect to an external Link Tracking database, it always offers to redirect user to Notes, even if the document had been migrated to SharePoint.  In this scenario, users will not actually get redirected to their new SharePoint documents until their links are Finalized.  The saving grace here is that you can Finalize your links as often as you want to.  In productions migrations, customers often choose to Finalize links on a daily basis.


Putting it all together

Wow that is a lot of options and choices here!  Let me try to simplify things with a nice table.

Migration mode Quest Import Service SharePoint 2010 Web Services
SharePoint versions 2007, 2010 2010
Office 365 (BPOS) Dedicated only Dedicated and Standard
Server installation Administrator must run MSI, etc. None
Server configuration Per site collection None
Performance Fastest Slowest
Functional limitations None None
Link Tracking Service Full Dynamic Link Redirection (via Front End Services solution) Limited Redirection (via Sandbox Link Redirector solution) *

* NOTE: Strictly speaking, it is possible to install the Front End Services solution (with full dynamic link redirection using a Link Tracking database) even if you are not installing the Quest Import Service.  We believe, however, that most people will either want to install the full solution or keep things as light as possible and will not often mix and match.

Getting Started with Migration to InfoPath List Forms

One of the most important aspects of migrating a Notes application to SharePoint is form design.  InfoPath is, of course, Microsoft’s primary solution for building data entry forms for complex business documents.  Many Notes customers see InfoPath as the best choice for migrating Notes forms that contain user-friendly field layouts, non-trivial data validation rules, and interactive functionality such as hide-when formulas. 

With SharePoint 2007, the decision to use InfoPath meant that you were forced to store your data as XML data documents, usually in SharePoint form libraries.  Notes Migrator for SharePoint 5.x helped you migrate your Notes form designs to InfoPath form templates and also made it possible to migrate your Notes documents to whatever XML data schema you came up with.  Unfortunately this was a rather heavyweight solution suitable only for complex apps that should justify the development effort.

SharePoint 2010 introduces a great new way to use InfoPath: InfoPath List Forms. This feature allows you to use InfoPath forms as your editor for list items. Now you get the best of both worlds: a lightweight way to store documents with custom schema and a great way to design custom forms for entering and displaying them.  The experience for developers is now greatly simplified and even junior developers can design custom forms using an integrated set of tools.


The best part of all this is that you already know how to migrate data to this type of solution.  The data is still living in a list, and Notes Migrator for SharePoint has been migrating data to lists since 2005.  In fact you can take any list you have ever migrated to and (assuming you have upgraded to SharePoint 2010) you can press the above button and add an InfoPath List Form to it.

The new part that Notes Migrator for SharePoint 6.0 is adding to the equation is the ability to migrate your Notes forms to InfoPath List Forms.  When generating InfoPath List Forms, you need to create your migration job and provision your new List with the correct schema first.  (This is different than migrating to InfoPath Form Libraries, where you would typically generate a form template first and then generate your library from that.)

You can access the InfoPath form generation capability from the Designer Client using the new Designer menus or from the Migration Console using actions on a selected Database record.   


For the new functionality, select the List option.


The form migration wizard takes you through the remaining steps for migrating your form.  We will detail this in subsequent articles, but the wizard is actually self-explanatory if you read it slowly and follow the steps carefully. 

At the end of the process, you get an InfoPath List Form that looks just like your old Notes form.  Here is an example of a customer’s document in Notes and the same document in SharePoint.


As with our older “form library” form migration feature, the tool does an excellent job with the user interface but does not attempt to migrate formulas and other form events, so be prepared to roll up your sleeves and rebuild that functionality using your new SharePoint development skills.  SharePoint 2010 makes this part easier than ever, so make sure you learn the new development capabilities well.

Getting started with Multiple SharePoint Environments

Notes Migrator for SharePoint 6.0 now allows you to manage connection information to multiple SharePoint environments. Previously, if your staging and production environments required (for example) different passwords you would have to change the password configured in the tool when you wanted switch between them. Now you can save a set of connections for every SharePoint environment in your world and the tool will automatically pick the appropriate one.

To accommodate this, the Advanced Configuration Options dialog has been redesigned somewhat. Now the SharePoint tab has a checkbox at the bottom:


When you check this box, the user interface changes info multi-environment mode and you can define multiple environments. Now each environment maintains its own connection type, credentials for authenticating, settings appropriate for that type of connection, and list of available site collections:



When selecting a target site or running migration jobs, all site collections in all environments will be available.


Getting Started with Migration via Native SharePoint 2010 Web Services

Notes Migrator for SharePoint 6.0 now allows you to migrate directly to SharePoint 2010 environments without needing to install the Notes Migrator for SharePoint Import Service (or any other Quest code) on your SharePoint front end servers.  This of course is a huge win for anyone who operates a highly secured SharePoint environment where asking to install a third product raises eyebrows.  It is also essential for migrating to SharePoint Online / Office 365 (option 3 in this blog post).

Enabling this migration mode in Notes Migrator for SharePoint is simple.  Go to the SharePoint tab in Advanced Configuration Options and set the connection type for your environment to “SharePoint 2010 Web Services”.  You will notices that there are actually two choices here, one that uses “Classic Mode Authentication” and another that uses “Claims Based Authentication”. 


For SharePoint Online (Office 365 or BPOS-Dedicated) use “Claims Based Authentication”.  For most other sites, use “Classic Mode Authentication” unless you know your SharePoint environment is using CBA.  We will cover more about how authentication works with CBA sites in a separate article.

For environments configured to use “SharePoint 2010 Web Services”, the Settings dialog is slightly different than for environments that use the Import Service.


The main option here indicates whether to you want to use the Quest Link Tracking Service for documents migrated to this site.  For most people, the answer would be “yes” because the value of preserving intra-document links is so high.  One thing to be careful about however is that the default URL for resolving dynamic links is a layouts page in the current site.  Unless you are planning to install Quest’s Front End Services or Sandbox Link Redirector solution, that redirector page is not going to be there.  It is a good idea in this case to specify an alternate Redirector page URL, otherwise users would see broken links until you got around to finalizing them.

Back on the main environment configuration dialog, click on the Credentials link to specify your method of authenticating with the server.


Once you have configured the type of connection you want and related options, everything else works pretty much the same as it did when you were migrating via the Import Service. 

So what are the limitations of migrating via web services instead of via the Import Service?  The good news is “not much”.  The new SharePoint 2010 web services are surprisingly complete and our developers have found ways to do almost everything our tool needs to do through them.  As of today, there is only one known limitation:

  • Can’t migrate to SharePoint 2010 managed metadata fields.

To overcome this and any future limitations, we have introduced a new component called the “Lightweight Migration Service”, which I will discuss in more detail tomorrow.  (Unfortunately, this option is not yet available on Office 365, but it is available for BPOS-Dedicated and on-premises servers.)

One additional issue is performance.  In some (but not all) cases, it takes longer to migrate through the SharePoint 2010 web services than it would have to migrate through the Quest Import Service.  Also the default connection timeouts etc., for the web services reside in SharePoint config files and some people would not want to have to reconfigure them for the sake of a migration tool. 

For these reasons, we don’t expect the Import Service to go away any time soon.  But for many people the ability to get up and running without having to install anything on the server is a huge benefit.

Getting Started with Migration to Document Sets

Notes Migrator for SharePoint 6.0 now allow you to migrate to SharePoint 2010 Document Sets.  Document sets are a great way to keep multiple related files together as one logical document group.  In many respects, one can think of this as a new more-powerful type of folder.  Documents in the same document set may be secured together, approved together, versioned together, etc., and the document set as a whole is displayed with a nice, customizable user interface.  In the following screen shot, the “Notes Migrator for SharePoint” document set in our marketing library contains six documents.


From a Notes migration perspective, there are number of ways to think about migrating content to document sets:

  • Map multiple Notes documents into the same document set.  Typically you would use some Notes data item (for example the Category field, the Product Name, or the Binder fields) to define the document sets.  In the above example, “Notes Migrator for SharePoint” was actually a Domino.Doc binder name and the six files were the documents inside the binder.
  • Map each Notes document to a unique document set.  Each attachment, image, or embedded object can now become a document inside the document set.  Not only that, you may map the rich Notes document itself to a document in the document set.  In the following screen shot, we generated a Word document to contain all the Notes rich text content and migrated all the attachments as siblings inside the document set.


You can easily add document sets to any migration job.  In your target data definition, simply add a field of type “Document Set” and give it a name.


If you are using generic document sets, that’s all you need to do here.  If you have designed a custom document set (that is, a custom content type derived from “Document Set”) edit the Document Set Template property where you can specify your custom content type as well as any additional document set properties you wish to map Notes data to.


Finally, return to your job Map Data tab in the Notes Migrator for SharePoint Designer and map data into your document set.  At a minimum, you need to map something to the Name property of your document set.  This value defines the name of the document set and ultimately controls what constitutes a unique document set.  Two documents migrated with the same document set Name will be packaged together inside the same document set.


Most the standard features that you have come to know and love when migrating documents apply to document sets as well, sometimes in interesting new ways:

  • You can migrate additional properties at the document level, the document set level or both.
  • You can migrate Notes readers and authors fields to document set permissions
  • You can place document sets into dynamically generated folders
  • You can migrate version histories of documents inside document sets
  • Document links are still preserved between documents

Take Command of Your Notes Application Migration to SharePoint 2010

Here is a webcast I recorded in December that covers new SharePoint 2010 capabilities (and how to migrate to them from Lotus Notes).  Along the way, it shows off a number of new Notes Migrator for SharePoint 6.0 features:  http://www.quest.com/events/ListDetails.aspx?ContentID=13273

PS:  In case you missed it, the beta program Notes Migrator for SharePoint 6.0 is still running.  Click here for details.

Migrating Notes workflows that implement “dynamic” document security

We have discussed various issues about workflow in the past [link].  To make a long story short, there is no way to press a button and magically translate Notes code-based workflows to SharePoint declarative workflows, but Notes Migrator for SharePoint does an excellent job at migrating your workflow state. 

Recently we have been getting a few questions about how people should handle workflows that automatically change the security of the document as it moves through various workflow stages.  For example, imagine a Notes application that lets an “Author” add or update travel requests until they are ready to submit it.  Once the request is submitted, however, the Author can no longer make changes and it us up to her “Manager” to approve it, reject it, or make further changes.  Real-world Notes applications can easily have many such dynamic access rules.

The way Notes developers typically implemented this type of workflow was was to have buttons, formulas and agents that implemented the right steps.  The actual security rules were usually implemented using reader / writer fields that listed specific people (or groups) that were currently allowed to update the document.  So when the Author pressed the “Submit to Manager” button, some code would run which looked up the manager and updated the reader / writer fields on that document so that now only the manager could edit it.

(Side note, there are also some cases where people did the security enforcement in the user interface.  That is to say, they tried to hide the parts people were not allowed to see in the UI.  But most Notes developers understood that this was not true security.)

So when we migrate this document, we have the option to map those reader / writer fields over to the equivalent document-level permissions in SharePoint.  Notes Migrator for SharePoint makes this trivial.  But it is important to remember that the security on this document is really just a snapshot of its current workflow state.  A workflow process on the SharePoint side is going to need to pick up the document from there. 

In the SharePoint world, you will really have two choices.   If you are using something like InfoPath to design complex forms, it will be possible (though not necessarily a good idea) to implement the workflow the old way:  with code on your form buttons and other form events.  It is possible that you could write code that set the appropriate document level permissions as described above. 

It is more likely however that you will want to switch to declarative workflow instead.  Declarative workflow means that you have a workflow engine interpreting a set up rules that someone (not necessarily a developer) has configured.  This could be a built-in SharePoint workflow, something designed in SharePoint Designer, or something designed in Visual Studio.  Another great choice is to implement the workflow with an add-in tool such as Nintex.  Regardless, your workflow definition will include rules to update the document level permissions according to your business rules.

The workflow capabilities in SharePoint Designer get stronger with each new release.  For example, SharePoint 2010 now has explicit actions for Adding, Removing, or Replacing the permissions on a list/library Item.  This is one more example of something powerful you can do in SharePoint 2010 without writing code!


Note that you will not see these particular actions in the standard drop-down action list; you will only see them if you are inserting actions into an “Impersonation Step”.

Cool stuff in SharePoint 2010 that Notes customers will love: Declarative Workflow

When people think of complex custom Notes applications they think of workflow.  Workflow is an especially important consideration when migrating Notes applications because migration tools, which can do a great job migrating schema, content, security and forms, have a hard time translating Notes workflows to SharePoint workflows.

Notes workflows are almost always implemented as code attached to various buttons, form events, and agents.  By contrast, the Microsoft platform encourages you to use declarative workflows where you express your workflow as a set of rules that can be entered, modified, and (best of all) understood by a non-programmer.  You can write code if you need to, but this code is usually confined to “activities”, the units of action that you wire together in your declarative workflow.

Declarative workflow capabilities have improved significantly in SharePoint 2010.  First of all, you get a much richer set of out-of-the-box workflows that you can use in your applications.  This list depends on what edition of SharePoint you install and which SharePoint template you are using, but at a minimum it should include an Approval Process, a Collect Feedback review process, a Collect Signatures review process, and a Disposition Approval workflow for managing content lifecycles.  You can now customize the out-of-the-box workflows if needed or design your own from scratch.


If you do need to design your own workflows, you can benefit from the new capabilities in SharePoint Designer.  This was a somewhat limited option in SharePoint 2007, forcing many companies to use Visual Studio instead, but those days are gone.  Now SharePoint Designer workflows can address the need of the majority of the workflows found in Notes applications without have to write code.

Users have a much bigger vocabulary of workflow “conditions” and “actions” to choose from, including Notes-like things such as changing the permissions on a document after it is submitted for approval, sending mail notifications, looking up a person’s manager, and moving content to another location.  A particularly powerful feature is to impersonate other users during a workflow so it can perform certain actions using the workflow author’s credentials.  You can even use InfoPath to design nicer forms for collecting information from end users.

image image

You can now design workflows that operate at the site level or the list level and you can reuse workflows across an entire site collection and even export them to use on a completely different SharePoint farm.  Workflows can be visualized as a set of human readable steps and even exported to Visio for graphical display.

The takeaway here is twofold.  First you can replace most of your Notes workflows without writing code.  Save your expensive developers for the hard stuff.  Second, do not attempt to translate all the code that your Notes developers wrote into code on the Microsoft platform.  Instead, devote your energies toward understanding what your old workflows did and make sure you have a deep understanding of how to accomplish these same things in a declarative workflow world.

Why is this space so hot right now?

Someone inside Quest recently asked me why the Notes application market is so white hot right now.  Thought I would share my answers here…

1. This is prime time for Notes migrations.  SharePoint 2010 and SharePoint Online have opened the floodgates of a migration wave that was already peeking.  Office 365 in particular delivers many of the improvements that Notes customers were eagerly waiting for.  Hundreds of the world’s largest organizations are committed to migration off of Notes over the next few years.  Similarly, many of the world’s largest system integrators have geared up to help them.

2. SharePoint 2010 and SharePoint Online create many new opportunities – and new challenges – for migrating complex Notes applications.  New capabilities such as document sets, managed metadata, search and scalability improvements, wiki pages, office integration are all seen as game changers for Notes shops looking to migrate.  InfoPath list forms, new built-in workflow and data validation features, and the ability to integrate external SQL Server databases as “external lists” dramatically reduce the cost of rebuilding complex applications.  Quest was the first Notes application migration tool to support SharePoint 2010 and SharePoint Online and (with Notes Migrator for SharePoint version 6.0) is rapidly innovating further ways to allow Notes migration customers to leverage these new platform capabilities. 

3. This is not a job for lightweight migration tools.  Because Notes was the platform of choice for building secure, collaborative applications for a so many years, organizations may have tens of thousands of old Notes applications.  Some are still business critical and many others contain valuable and often highly sensitive data that needs to be preserved with full fidelity.  Migrating all these applications correctly can be a very expensive undertaking for an IT department or an outside consultant.  Quest continues to invest heavily in this problem space because we realize that every incremental improvement we make can literally mean millions of dollars in ROI for our customer base.  It is paying off as the deeper people go into complex migrations, the better we look.

Introducing the Notes Migrator for SharePoint 6.0 beta program

Here we are with Notes Migrator for SharePoint 5.3.3  just out the door and we are already talking about the 6.0 beta!  For a variety of reasons, we were working on both releases in parallel for several months now.  The release is far from done, but the beta already includes some very cool stuff:

  • Support for InfoPath List Forms (SharePoint 2010)
  • Support for Document Sets (SharePoint 2010)
  • Adobe Acrobat (PDF) document generation
  • Option to migrate via native SharePoint 2010 web services
  • Ability to authenticate with servers running Claims Based Authentication
  • Office 365  / BPOS-S support (utilizing the above 2 features)
  • Lightweight Migration Services (for even better BPOS-D support)
  • Migrate to SQL Server databases
  • New Designer menus (including MRU lists)

This time, the beta will be managed on the new SharePoint for All community site.  If you would like to participate in the beta program, go to http://communities.quest.com/groups/notes-migration-product-beta-group.  Sign in with your Quest Community ID, or register to create a new one.  Then press the “Ask To Join This Group” button.


One of the site owners will review your request and will typically approve it the same day.  You will receive a notification and then get full access to technical content and (of course) the beta build itself.

Quest Support will not be able to help you with this version until it releases, so please use the group’s Discussion area for any questions, problems or suggestions.

Recap of Domino.Doc migration features

We have had pretty darn good Domino.Doc migration features since the beginning, but until recently I have not blogged about it very much.  Now that we about to release support for migrating to SharePoint Document Sets in Notes Migrator for SharePoint 6.0, I thought it was time for a quick Domino.Doc feature roundup:

  • Notes Migrator for SharePoint gives you default data definitions for migrating the defaults
    • If you really use Domino.Doc to store attachments with some metadata, than SharePoint “document libraries” are a great choice
    • If you store rich text or multiple attachments in one “document” you might prefer to send it to a SharePoint list instead
  • In the cases where users have build custom “Document Types” we give you full power to migrate the custom fields, etc.
  • We allow you to map Document Types to SharePoint Content Types (but you have to design the target Content Types yourself in advance in the current version)
  • We allow you to map Binders to SharePoint Folders
  • We map access control rules at the Cabinet level and Document level
  • You can migrate complete version histories [link]
  • You can migrate unpublished documents
  • Our analysis tools discover the hierarchy of Libraries -> Cabinets -> Binders -> Documents (similar to what we do with QuickPlace)
    • Using the automation features, you can automatically provision sites/subsites for every Domino.Doc library/cabinet
    • You can also automatically generate a new SharePoint list/library on the same site for each Domino.Doc library/cabinet
  • Our analysis tools help you zero in on which Cabinets have been customized and what customization have occurred (new Doc Types, changed subforms)
  • Using Notes Migrator for SharePoint 6.0, you will be able to migrate to SharePoint 2010 Document Sets.  Either…
    • Map each Domino.Doc Binder to a Document Set and out all the documents inside it
    • Map each Domino.Doc Document to a Document Set and out all the attachments inside it

Putting all this together, we do a good job at automating the discovery, target assignment, site/library provisioning, and content migration.

Notes Migrator for SharePoint 5.3.3 RTM

Version 5.3.3 of Notes Migrator for SharePoint has finally released and will be generally available next week on the Quest web site and SupportLink.

This release contains a larger number of “big ticket” items – far more than would normally be in a minor point release.  Here is the high-level list, with links to detailed blog posts describing some of them.

PS:  Don’t spread this around, but the reason that there is so much in this release is that we held it up longer than expected so we could resolve some thorny customer issues.  Meanwhile, we were finishing some of our 6.0 features!  So we decided to get some of the new goodness into your hands as soon as possible.

How to migrate to SharePoint Wiki pages

Notes Migrator for SharePoint has allowed for migration to SharePoint wiki pages for over a year now.  Wiki pages were of mild interest in SharePoint 2007, but as described in my last post they have evolved into an awesome target choice in SharePoint 2010.  For example, you may have noticed that the Site Pages library in many of the new 2010 site templates is now a Wiki library.

The following steps recap the basic steps and some of the advanced options for migrating Notes documents to Wiki pages.  These steps apply equally well for SharePoint 2007 or SharePoint 2010 (but SharePoint 2010 requires the use of Notes Migrator for SharePoint 5.3.1 or higher).

Basic Steps

  • If using the Designer client, select a source Notes database, QuickPlace or QuickR room, or Domino.Doc library and then select a corresponding source data definition.  If using the Migration Console, simply open the Database Properties, got to the Migration Jobs tab, and add a new migration job.


  • On the second tab, select a target SharePoint site and Wiki page library (or any document library).  When asked whether you want to load a default target definition, say “Yes” and load the “Wiki pages” data definition.  You can also provision a new library on the fly here.

image image

  • On the third tab, press the “Auto Map” button.  The default mappings will create Wiki pages with the same name as the original Notes document, use the rich text Body field as the Wiki page content, and map any embedded elements to files in a subfolder.


  • Press the Run Job button and go!


What you get in the end is a bunch of new Wiki pages in your SharePoint library.  Any embedded images, attachments, or OLE objects shown on the Wiki pages are really stored in the “Attachments” subfolder.



Advanced Job Customizations (optional)

  • If you prefer to put images and attachments into a separate library, simply edit the target data definition, select the Files field, and specify the Alternate Library property instead of the  Alternate Folder property.  (By the way, this is definitely the “2010” way to organize things.  Many 2010 templates contain a “Site Pages” wiki library and a “Site Assets” library where all the images and attachments are intended to go.)


  • If you would like to migrate the original attachment icons for your Notes attachments, simply edit the target data definition and check the “Migrate Attachments as Image files” checkbox.  The additional image files will be saved to the same alternate folder or library described above.

image   image

  • If you are migrating a QuickPlace site or other Notes/Domino application that does not store attachments inside the rich text Body field, you may wish to concatenate a rendered “attachment links” area to the bottom of the page so you can link to them.  QuickPlace and QuickR data definitions already have a built-in “{OtherAttachmentLinks}” section that you map to the existing WikiField in your target.  (If you are using other data sources. you will need to define an AttachmentLinks section in your source data definition.)


  • Notice how you the above job maps multiple source columns to one target WikiField?  You can actually concatenate as many things as you want (multiple rich text fields, text fields, and even static labels) to your WikiField.
  • If you want to map additional Notes items to SharePoint metadata fields, just do that as you would for list items.  The extra fields will show up in the page properties and you can use them in view columns.

image  image

  • Of course, you can use many other Notes Migrator for SharePoint features with your Wiki pages:  created/modified metadata, document level permissions, content types, folders and subfolders, approval status, incremental migrations, and much more.

Migrating Lotus Notes content to Pages in SharePoint 2010

As hard-core Notes Migrator for SharePoint users know, there are about five ways to migrate Notes documents to web pages in SharePoint 2007:

  • HTML pages
  • Basic pages
  • Wiki pages
  • Web Part pages
  • Publishing pages

In our extensive regression testing with SharePoint 2010, we noticed that the rules have changed a few interesting ways.  Here are four basic changes you should be aware of:

1. HTML pages have been “secured” – If you populate a SharePoint document library with migrated HTML pages, everything migrates correctly, but SharePoint does not display the pages the same way when a user clicks on one of them.  Instead of displaying the page in the browser, SharePoint forces the user to download the HTML file and view it locally.  This is annoying at a minimum, but if the file contains relative links to other images or attachments, they will not work at all when opened from a different location.

The reason for this is that Microsoft decided that displaying HTML files indiscriminately was a security risk and they added safeguards to prevent that by default.  The remedy to this is to turn the new security feature off.  In Central Administration, go to Manage Web Applications -> General Settings and select “Permissive” as your Browser File Handling Option.

Be sure to read the description on this option and make sure you understand the security implications.  Going “Permissive” is really no less secure than what we had in SharePoint 2007, but if you have users you don’t trust uploading content to your site, you might be better off choosing a different type of page to migrate to.

2. Basic pages are gone… sort of – If you go to the Create menu in a typical SharePoint 2010 team site, you will see that there is no longer a “Basic Page” option.  As described below, I think there is a good reason for it.

If you use Notes Migrator for SharePoint to generate a bunch of Basic pages, it actually does still work.  Each page looks nice but all the window dressing is gone and you are stuck in read-only mode.  Notice in the screen shot below that there is no Quick Launch menu and the Edit buttons are disabled.


Perhaps some of the new site templates I have not experimented with yet still expose the ‘Basic Page” construct, but I suggest that most of us move on to Wiki pages.

3. Wiki pages are king! – In SharePoint 2007, Wiki pages were a cute, but somewhat limited, list type that not many people used.  In SharePoint 2010, they have become something that is greatly improved and now pretty ubiquitous.  When you create a new “Page” using the Create menu in a team site, you are now creating a Wiki page.  And the “Site Pages” library that (by default) holds pages that users create is now a Wiki Page Library.

Microsoft basically merged the concept of Basic pages, Wiki pages and Web Part pages into a single construct that is much more powerful – and much more user friendly – than before.  Remember that crappy rich text editor in SharePoint 2007?   Now the editor sizzles.  End users can upload images and files and can even embed Web Parts in their rich content (similar to the way they used to embed OLE objects in their Windows applications).


NOTE:  Don’t attempt to migrate to SharePoint 2010 Wiki Pages in Notes Migrator for SharePoint version 5.3.  Somewhere between the 2010 beta and RTM, there was a breaking change in how one of the SharePoint APIs worked and we had to make a two line change to accommodate it in our product.  Notes Migrator for SharePoint 5.3.1 fixes this issue which will RTM in a couple weeks.  If you can’t wait that long, contact me through your Quest rep and we will get you a build.

4. Put your Assets in the right place – When migrating to any of the above page types, it has been common practice to put the associated images and attachments in a subfolder inside the same document library you were putting the pages in (described in this post).  That’s not the 2010 way to do it, and there are some cases where it actually does not work out very well. 

Page Libraries in particular are not really designed for holding binary files.  Our tool will let you migrate attachments and images there, but the result is not always satisfying.  For one thing, you loose some of the nice integration that you have between Office applications and “normal” document libraries.  We have seen cases where Word will not open .doc files from a folder in a Page Library.

The right solution here is to put images and attachments in the “Site Assets” library, or whatever place the designer of your site template intended such things to go.  As shown below, this matches perfectly what users will  be encouraged to do when they upload new attachments while editing a new page.  Putting images and attachments into different libraries is nothing new for Notes Migrator for SharePoint and the technique is pretty simple (described in this post).


I will have a lot more to say about SharePoint pages – especially Wiki pages – in future posts.  Web Part pages and Publishing pages still exist as distinct page types and migrating to these work pretty much the same as they did in SharePoint 2007. 

How to migrate to SharePoint Publishing Pages

Many Notes applications were designed primarily to publish rich content to a wide audience.  These often included some type of approval process, management of draft content, version control, etc.  These are great examples of applications that may well to the “publishing” site templates available in SharePoint Server 2010 and MOSS 2007.  Here, for example, is a rich text Notes document (with embedded images, attachments and doc links) that has been migrated to a 2010 “Publishing Portal” using Notes Migrator for SharePoint.


If we put this page into edit mode, we can see that a great deal of out-of the-box functionality is available with no development required.


Notes Migrator for SharePoint supports migrating any Notes content to publishing pages.  This is a little more complex than doing other wiki pages or basic pages and uses the tool’s unique capability to create pages using custom ASPX template code.  The remainder of this walkthrough will use screen shots from SharePoint 2007, but the process is nearly identical for SharePoint 2010.

If you do not already have a publishing site, create one using SharePoint Central Administration and specify one of the “Publishing” templates.


Next, we need to create a “template” for generating pages from your Notes documents.  Go to your new SharePoint publishing site site and create a sample page by selecting Create Page from the Site Actions menu.


Select the page layout you want for your new pages.  The list of layouts may vary depending on the site template you started with and may include custom layouts designed by your site owners.


Now populate the page with a little sample data and save it. 


Feel free to experiment with checking the page in and out, versioning it, scheduling it’s release or submitting it for approval.  These are all powerful features of the SharePoint publishing templates, but you actually do not need to use them for the task at hand.

For designing a migration job, we need to extract the page to a local file so we can example the ASPX layout.  Select View All Site Content from the Site Actions men and then go to the “Pages” document library.


In the Pages library locate the test page you just created and pick Send To –> Download a Copy from the drop down menu for that page.


Save the ASPX file to your computer and edit in any text editor.  I like Visual Studio or SharePoint Designer, because it gives me nice color coding and formatting, but Notepad also works just fine.  Keep this ASPX file handy, because will be using it later.


Digression:  ASPX developer’s may be interested in how this page is constructed.  It inherits from a class in the Microsoft.SharePoint.Publishing namespace, but does not actually specify any HTML markup.  Instead the code behind the pages uses the data in an XML data island to render the page.  Notice that the XML parts specify not only content properties such as PublishingPageContent but also the page layout in the PublishingPageLayout property.  

Now you have what you need to create your Notes Migrator for SharePoint migration job.  You can start from scratch or customize an existing job if you prefer, but you might prefer to start with an existing job that I created.  I suggest downloading one of the following jobs, depending on which version of SharePoint you are targeting:

[DocLibrary to Publishing Page 2007.pmjob]

[DocLibrary to Publishing Page 2010.pmjob]

If you are starting with the above jobs, should first change the source Notes database to refer to the your database and you may need to customize the source data definition to extract different Notes data items than the default ones specified (“Subject”, “Body”, etc.). 

You should also change and target SharePoint URL to point to your publishing site.  Both jobs are already configured to create new pages in the “Pages” library, place any embedded objects in the “Images” library, and place any attachments or embedded objects in the “Documents” library.  This is consistent with the way things work normally when a SharePoint user created content in a publishing site, so you probably do not need to change those parts. 


If you open the target data definition in the migration jobs, you will notice that there is a target field of type PageName and that the PageType property of this field is set to “Template”.  This PageType allows you to specify your own custom ASPX code in the PageTemplate field.   


Remember that ASPX code we looked at when we downloaded a sample ASPX page from the server?  That is the code we need to put into the PageTemplate field.  But we don’t want all of it, just the bits that describe the page structure.  We can leave out the content parts and, as you will see shortly, we will specify the content in a different way (mapping the data dynamically from Notes).  Your ASPX page may be different than the one I showed above, but generally you want the ASPX tags at the top (which start with “<%@”) and the <html> tag.  In my example, I am going to grab the first four lines and paste it into the little drop down editor for the PageTemplate.


Notice that the target data definition also specifies several fields that allow data to be mapped as content in the generated pages.  Some of these you may recognize as the properties that were specified in the XML data island (the green part) in the above example.  We included PublishingPageContent for mapping the Notes rich text and PublishingPageLayout for specifying the page layout.  Other page types may require additional properties but you will find that many of them can be omitted as the defaults are acceptable for migrations.  Title and ApprovalCode allow setting of metadata on the page.  ExternalImages and ExternalAttachments allow mapping of additional files to the appropriate SharePoint libraries.

Press OK to save the target data definition.  Next go to the Mapping tab to review how various fields are set from the dynamic Notes data.  Most of these mappings will make sense to an experienced Notes Migrator for SharePoint user, but two deserve special attention.

The PublishingPageLayout is set to a constant value, which is the URL of the appropriate layout page.  It is critical that you replace this value with the the address of a layout page on your SharePoint server.  Recall that when I created a test page in the example above, I selected the page layout “Article page with body only”.  In the resulting ASPX file, this translated to the PublishingPageLayout property in the XML data island (the green bit) set to “http://quest-e52a78ada/sites/publishing/_catalogs/masterpage/PageFromDocLayout.aspx”  This is the URL that you need to use here.  If you do not get this part right, your pages will not open.


The jobs are also designed to set any migrated content to the “Approved” state.  This is accomplished by mapping a constant value to the ApprovalCode field.  Of course you can change this to a different constant value or even make it dynamic depending on the state of your Notes document.

Depending on the page layout you selected, you may need to map other properties as well.  When you are ready, press the Run Job button and start migrating! 

Upcoming releases of Notes Migrator for SharePoint will add a few things to make the above process a bit easier, but there is really no need to wait.  You can generate great looking publishing pages now.


Ten Ways SharePoint 2010 Will Impact Your Notes Migration

Here is a link to my new white paper, hot off the presses: 



Many organizations are moving from Lotus Notes/Domino environments to Microsoft Exchange Server, SharePoint and Office. However, applications that are migrated from Notes to SharePoint may need to be rebuilt – typically an expensive and time consuming process.  Even then, the new applications may not function as well as the legacy ones. But with the release of Microsoft SharePoint Server 2010 and SharePoint Foundation 2010, things have changed.  This paper discusses 10 ways that SharePoint 2010 will change the game for enterprises of all sizes who want SharePoint to replace or enhance their Notes environments.  You will learn about major platform and functionality improvements and discover how SharePoint 2010 simplifies rebuilding Notes applications after a migration.

Feel free to post comments here or send to me privately.