Why Notes Applications Migrations are Different From Other Types of Migrations
October 10, 2012
Contributed Article. Author: Steve Walch, senior product manager, Quest Software, now part of Dell
Why Notes Applications Migrations are Different From Other Types of Migrations
The company I work for makes a lot of migration tools, and we get to see a large variety of migration projects. These projects range from weekend “self-service” projects to very large projects run by global system integrators. They may be driven by a variety of factors ─ mergers; a change in platform vendors; consolidation or other cost cutting projects; a move to the cloud; or simply by a desire to leverage the latest and greatest technologies. Most of the migration projects we see are moves to the Microsoft platform, including:
- Directory migrations to Active Directory from Novell Directory Services or older versions of Active Directory
- Email and calendar migrations to Outlook and Exchange from GroupWise, Lotus Notes or older versions of Exchange
- Collaboration/document management platform migrations to SharePoint from Lotus QuickR, IBM Connections, Lotus Notes, Exchange public folders, file systems, or older versions of SharePoint
- Custom application migrations to SharePoint or SQL Server from Lotus Notes
Out of all these migration scenarios, migration of Lotus Notes applications stands out as different from the others. The fundamental reason for this is that every Notes database is (potentially) a unique custom-built application. With most other migrations, you can define a set of high level rules for how things should be filtered and transformed, and then you can count on your migration tools to reliably and consistently apply these rules to thousands (or millions) of directory objects, email messages, discussion threads, library documents, calendar entries, user profiles, etc. To be sure, these may be very complex transforms, and achieving a high quality translation with minimal disruption to end users requires high quality migration and coexistence tools, as well as experienced operators and great project management practices. But, with application migrations you have a unique set of additional issues that can make them the most interesting, and, sometimes, the most daunting type of project.
Because each Lotus Notes database contains a complete set of design elements and data documents, each one really is a complete application. And each one is potentially different. In general, some of your Notes databases will be based on standard Notes templates (document libraries, discussion forums, etc.). These will be fairly straightforward to migrate, and a good migration tool should be able to automate these as described above. Others may be completely custom Notes applications built from scratch, containing custom forms, views, actions, and even workflow logic. These are the ones that can turn into expensive migration projects. Since no tool can migrate 100 percent of an application design, there may be a need for a significant amount of custom configuration or development work involved. Many applications will be somewhere in between these two extremes.
For this reason, most large Notes migration projects include a significant analysis phase. If you have thousands of Notes databases, the first thing you want to do is identify which may be migrated as standard applications to out-of-the-box SharePoint templates, which ones will require additional customization, and which will require lots of expensive custom development. In parallel with this process, most people also go through a business justification and rationalization process in which they:
- Eliminate applications that are no longer being used, or simply not worth migrating
- Identify cases where applications can be simplified, eliminating features that would be expensive to rebuild in SharePoint, but not worth the trouble
- Identify cases where old applications can be simply archived in SharePoint without rebuilding the functionality of the application
- Identify cases where applications can be enhanced using advanced SharePoint features such as document sets, content types, InfoPath, managed metadata, and enterprise search
- Identify cases where many Notes databases share the same design or very similar designs, allowing for automated reuse of target application templates and migration rules. Some people refer to this as “consolidation,” as you are consolidating similar applications into a smaller number of application types
- Plan the migration targets for each database. Which databases go to which site collection? Which require their own sub-sites, lists or libraries? What site or list templates should be used? How should access control permissions be organized?
Ideally this analysis phase would be run by experienced people familiar with both Lotus Notes and SharePoint, as well as the capabilities of the migration tools. In addition to technical skills, good project management and communication skills clearly are needed here.
Working with business owners to get agreement on the cost saving compromises to be taken is a critical, but often omitted, step in the analysis phase. A simple decision such as willingness to switch from a custom team room template to the out-of-the-box SharePoint team site template with a just few specific customizations can result in a great deal of time and cost savings, both at migration time and in future maintenance and upgrade costs.
Once all this planning is done, you begin the actual migration work. Again, this phase tends to be a lot slower than other types of migrations, because of the special nature of application migrations:
- The lack of uniformity means that you need to slow down and deal with each application type individually. You don’t push a button and migrate everything on the weekends. You need to carefully set up the migration plan for each type of application on a case-by-case basis. (Note that I say “application type” and not “application” here. You may have hundreds of databases based on the same custom application templates. You will be able to reuse any custom configuration or development work and, if your migration tool allows it, automate the provisioning and migration work in one batch.)
- In some cases, a significant amount of development work will be required for a custom application type. This means you will need to coordinate the activities of your SharePoint developers with the activities of your migration team.
- Target sites must be provisioned according to your migration plan. This may include provisioning of security groups and permissions. In most cases, your migration tool should help you automate it once you have configured your migration plan.
- The actual content migration may be simple or complex. For each custom application type, you will need to consider which Notes items map to which SharePoint columns, and whether any data transformation needs to occur. Some Notes applications will require multiple content migration jobs to populate multiple SharePoint lists or, in some cases, multiple content types or InfoPath forms. If you have lots of big rich text documents and/or large file attachments, the sheer volume of content being transferred may become a factor in your project schedules. For archiving situations, you may be generating Word or PDF documents as you migrate, which can take a lot of processing time as well.
- Depending on your needs, there may be additional work required on the side. This might include provisioning new active directory groups the applications will need, or setting up a link-tracking service that will keep your intra-document links working as content starts moving around.
The good news for organizations moving their applications to Office 365 and other hosted platforms, is that all of this can be accomplished in the cloud just as easily as in an on-premises environment. Other than size limits and possible throttling of bandwidth during a large migration, the only real limits you are likely to encounter relate to deployment of custom code solutions. You may discover that you need to simplify your application designs due to hosting restrictions, but this can actually be a blessing in disguise because applications that are designed to operate in a restricted server environment are ultimately simpler and therefore less expensive to build, deploy and manage over time.
###