“Notes to SharePoint” Isn’t “SharePoint to SharePoint”
My team recently wrapped up a year-long migration of 70-plus Notes databases to SharePoint 2010. Although the end product is, for the most part, something I’m proud to put my name on, we didn’t get there without learning a few lessons the hard way.
With many businesses previously heavily-invested in the Lotus Notes platform now spinning up Microsoft SharePoint servers, it’s an exciting time to be a SharePoint developer. But don’t be so quick to don that I Heart SP hoodie yet; true success hinges upon Notes and SharePoint developers working together to understand the business and technical hurdles that can hamper a migration.
As a SharePoint developer and enthusiast, my experience working with tremendously talented Notes developers to migrate Notes solutions to SharePoint has reinforced our belief that successful migrations can be achieved only through collaboration between developers of both platforms, and has brought to light several key ideas that I hope can help to make your N2S migration a roaring success.
1. Two heads are better than one.
The concept of Notes and SharePoint experts building a migration plan together seems obvious, but is easily overlooked as a “nice to have” feature. Having spoken with current and prospective clients about their previous N2S experiences (or vicariously via one of my constituents), many of the horror stories involving N2S migrations can be traced back to the shortsightedness of a single developer who took it upon himself to decide how a Notes application ports to SharePoint. Said application was crammed down users’ throats as either a sexy-looking SharePoint cocktail that doesn’t work– or a functional hot mess with as elegant a UI as a GeoCities personal website circa 1997, complete with odometer-style hit counter.
Strike a balance. Bring a Notes developer on-board to truly analyze the structure and purpose of the Notes application, relying on business stakeholders to bridge the gaps between the database design and its purpose. Open the forms and take note of key user interaction principles. Observe how the application performs with real data. Identify gotchas and hidden complexities. Anticipate where and how data can be lost during the migration process.
Bring the SharePoint developer into the fold when the Notes developer can describe the business needs of the application and (more importantly) how each has been implemented in the Notes application. Successful N2S migrations recreate the pieces of the Notes application that work well; instead of duplicating Notes, they stay true to the strengths of the Notes application while shoring up its shortcomings. Ensuring that an application’s strengths make it through the migration requires a Notes developer who can point out what the application does and doesn’t do well; some of our biggest “wins” were born from “how would you ________…?” conversations that took place early on in the discovery phase of projects.
2. Don’t cut and paste.
I admit that when I first open a Notes database migration candidate that hasn’t been touched since 2001, I sometimes have to restrain myself (after suppressing my gag reflex). [Insert “OOB SharePoint UI sucks, too” comment here; duly noted.] My innate response is to begin mapping the application to SharePoint before I even know what it does.
“Say, this looks like a team room– this will indubitably migrate magnificently to a SharePoint Team Site!”
“Look at all these agents– these little fellas will make swell timer jobs!”
“Oh boy, 25 rich text fields! That’ll make one doozie of a modal form dialog!”
Remember that you aren’t migrating applications because they’re new and awesome; you’re migrating them because they are outdated, but important enough to the business to survive the jump to a new platform. The Notes application might have been built to solve a very simple business problem, but it may do so in a convoluted, overly-complicated way (by today’s standards). And that may have nothing to do with the platform; don’t pretend you’ve never built something like that in SharePoint. You have. Especially if you’ve ever used IPFS.
Here are a few guidelines for avoiding the “cut and paste” trap:
- Heed the Notes forms. For each form in the database, ask the Notes developer why that form was used (of course, if you have access to the original database developer, utilize this opportunity…). You might be able to accomplish the functionality of 5 Notes forms in one SharePoint list item form (or custom ASPX page/InfoPath form)– or you might need to split a single Notes form into several screens in SharePoint.
- Choose a destination site template wisely. Choosing a SharePoint site template is often the easy part of standing up a new site collection, but when you’re choosing where to migrate Notes databases, the lines can blur rather quickly. In general, I learned to avoid Team Sites for publishing rich text Notes documents; publishing pages just work better than wiki pages, and the Publishing Site template does an overall better job of handling rich text and publishing workflows.
- Don’t assume that you need to migrate EVERY field. And please, for the love of naming standards, don’t create SharePoint fields with the same names as their Notes counterparts. The right time to create SharePoint columns identical to Notes fields is during a POC migration, where your goal is to present successfully-migrated documents to the stakeholders.
- Use content types. “Category” and “sub-category”-type fields have their place in many an application, but when possible, build content types for each choice in the “category”-type field. Why? You would be surprised how often these categories actually represent unique business cases that require (or will require) additional fields to completely define them.
- Be careful with attachments. Best practice for N2S migrations is to move attachments from Notes rich text fields to document libraries, but don’t just “migrate and forget.”. Use auxiliary fields to track where each attachment came from, and give it a content type besides “document”. This will make it easier for users to manage, search for, and link to documents.
- Security sucks. Notes developers will be the first to tell you that Notes role-based security almost never directly translates to SharePoint. Know who needs access to what before you migrate, so that you can build your migration for the proper site inheritance structure. Avoid item-level security when possible, and don’t be afraid to stand up a site per security group designation.
- Track column mappings. We use SharePoint (gasp!) to track information about each Notes field we migrate, including its source form(s), source database(s), destination SharePoint column, destination SharePoint content type, etc.
3. Define SharePoint fields and content types in Visual Studio ONLY.
This is often a tough pill to swallow; defining fields and content types in Visual Studio solutions can be a barrier to rapid development. But N2S migrations should consist of anything but rapid development, and here’s why:
- Every field, and every content type, should have a purpose. Creating columns and content types in the SharePoint web GUI tends to, in this developer’s humble opinion, undercut the notion that these entities are precious.
- It helps to curb scope creep. The second you squash stakeholders’ notions that site columns and content types can be spun up at the snap of a finger, you take a productive first step in eliminating scope creep. In my experience, forcing yourself to define fields and content types in Visual Studio helps you to, in turn, be more forceful and direct about taking the necessary steps to formalize a scope change document when the client requests a change to said fields and content types in the middle of a development cycle.
- It’s best practice. SharePoint fields and content types defined in CAML are redeploy-able, upgrade-able , manageable, and more easily documented. But you already know that.
4. Content = Deliverable
The major difference between building N2S migrations and developing any other software application is that the deliverable– that is, the tangible product that you hand to end-users at the end of the project– is just as equally rooted in content as it is in lines of code.
Think about that. Outside of standard SharePoint development packages which, for developers like me (who frequently develop custom-coded solutions), tend to live in the user solution/timer job/web part/etc. space, N2S migrations can’t be deployed in a .wsp package. Sure, your migration solution may contain batches of custom code, but it also contains migration jobs, configuration and deployment instructions and, most importantly, content.
The meat of an N2S migration may very well be its content, especially if the destination is a publishing site or document library. Part of defining a migration strategy should involve defining incremental backups of your destination sites, libraries, etc., as well as agreeing upon a central location to which migration jobs can be backed up (we use TFS).
And finally, identify early-on how you plan to move migrated content through various farm levels (Development/Test/Stage/Production), whether that be via site collection backup, content database backup, or a straight migration of existing content directly into a production site collection. The latter is often the easiest to execute and the most difficult for which to obtain permission (you would likely need to install the server-side migration utility on production boxes, a sure no-go).
5. Get granular
Your statement of work for the final content migration from Notes to SharePoint should define, down to the document (or specific criteria that explicitly defines a set of documents), what is being migrated, where it’s going, and how you are going to migrate it. In addition to helping you avoid scope creep, getting granular about the content being migrated helps to ensure that there are no surprises when everything is said and done.
By identifying precisely what will be migrated (and what won’t!), it will force stakeholders to get real about what is and isn’t important to migrate, and you will find yourself focusing more on developing useful content types for relevant documents than deciding where to migrate Doris’ private mp3 collection.
6. Estimate carefully
When asked about lessons learned from writing dozens of migration jobs, my friend and colleague, John Bigenwald (@john_bigenwald), noted that costs are generally higher than anticipated and that accuracy and completeness are often achieved at the expense of speed. Writing good migrations takes time.
The above list of recommendations– which isn’t complete by any means– should make it clear that N2S migrations absolutely cannot be half-assed; rather, they must be approached meticulously and thoughtfully. And the opposite of “half-assed” is– you guessed it– “expensive.”
That’s a wrap
In short (I know, too late), successful Notes to SharePoint migrations require an extraordinary amount of planning. The necessity of both SharePoint and Notes developers putting (and butting) their heads together to build a migration job is one of the principles to which my PSC Group colleagues and I adhere firmly, and (shameless plug alert) one that we believe always results in the best product possible: a complete, successful migration.
Taking the time to learn an application before migrating it often makes or breaks a migration entirely, and nobody understands Notes applications like the guys who can write them.
Migrations are simple in nature, fast in theory, and challenging in practice. I made plenty of mistakes whilst building my first N2S migrations, and it is my hope that you can learn from my mistakes.
Oh, and lay off the Notes guys– your migration is DOA without them.
Note: I owe a special thank-you to my colleagues, John Bigenwald and Eric McLaughlin, for not only helping to write the aforementioned migrations, but for taking the time to teach me about Notes. We may never agree on which platform is better, but we will always share the Quest migration tool as a mutual punching bag.