Notes to SharePoint migration - Phase Two Design and testing

Once you've completed the Discovery phase of your Notes to SharePoint migrations (see the steps here:
http://moss-exchange.blogspot.com/2009/05/notes-to-sharepoint-migration-phase-one.html ) you are ready for the next steps.

This phase is where you design the migration. First, you need a target environment. If you already have a SharePoint environment setup, it's likely organized by department or geography. This works well for most Notes applications as most are department specific. If they are global, enterprise applications such as a robust employee directory, these can be organized somewhat easily into any SharePoint implementation. Site design, taxonomy, and governance are different discussions. You should have a clear direction for your MOSS implementation, yet be flexible to add features or scale out as your organization consumes the technology differently than originally anticipated. It happens.

Which Tool?
At this point, you should have decided upon a migration tool. I use the Quest tools, but others swear by the Tzunami tools. I like to have the Quest Development Studio, Notes Migrator for SharePoint, and a backup solution. I like the AvePoint backup and recovery tool, but also have had good results with the Quest tool. Each tool I have mentioned has it's advantages and pain points. I make no claim to their effectiveness. You can use your own custom coding to replace the Development Studio or Quest tools. I don't write code unless I absolutely have to as it really slows down the projects when you suddenly have a development effort. Sometimes it can't be helped, but I have found for most things in Notes / Domino / Quickplace I can readily replicate in SharePoint in a few hours or days.

The Microsoft AppTransporter might assist with some simple applications, but it's free. You get what you pay for. Buy a robust migration tool and get this project behind you.

Architecture:
I use 32-bit front-end servers with 64-bit backend server(s). This really helps with iFilters, migration tool configuration, and other compatibility issues. Some enterprises have switched to 64-bit servers and aren't looking back. This requires some work-arounds and changes the steps of the migration, but it isn't a showstopper.

Things you just can't do:
If you have a distributed workforce that synchronizes their Notes databases locally before heading to the field, you have some work cut out for you. There are third party applications to replicate SharePoint content locally or two remote farms across the WAN.
These really help address the issue of the distributed architecture of Notes vs the single farm/site limitations of SharePoint. Another option for less complex Domino applications is to use Groove for a local copy of the workspace. This means Office 2007 and potentially a Groove Server added to the mix.

What version of SharePoint?
First, you need to know which version of SharePoint you need. There is WSS, MOSS Standard, and MOSS Enterprise. We'll work our way down in reverse order of expense:
If you need InfoPath forms, connection to external data sources/applications or Excel Services you have to spring for the Enterprise version.
If you don't need any of the above, but need publishing, life cycle management, user profiles, mysites, etc you need at least the Standard version of MOSS.
If you don't need any of the above but have Office integration needs, document libraries, basic workflow, collaboration needs, and simple site layout WSS is the best and least expensive solution. Contact a knowledgable resource regarding your licensing and requirements. If you have mostly very basic Notes applications and simply want to retire Notes, start with WSS. You can fairly easily migrate from WSS to MOSS if you outgrow the features of WSS.

The Migration Tool:
Start with the easy Document Libraries or other list type applications to get a feel for the migration tool and how it works. If your farm is already in production, setup a dev and / or test farm. Read the manual. This is a complex undertaking. Migrations are never straightforward. Migrate and see what happens. You will likely need to delete your first few attempts.

Migration to a Publishing Farm:
A technique I find particularly helpful when a client is already using MOSS in production is to migrate to a test or publishing farm. You can then deploy the content to a new site in the production farm. This gives the QA team a chance to bless the application. I have had trouble deploying content to existing pages and have really only had luck starting with a new subsite or page. This issue was supposed to be fixed in MOSS SP2, but I haven't verified it. I have yet to see Microsoft admit the feature was broken, but it was definitely unable to update an existing page with dynamic content changes. Leave a comment if you need help with this and I can explain this in more detail.

Test, test, test:
Read the product literature carefully. Learn how the ACLs in Notes translate to the ACLs and audiences in SharePoint. Work with Forms libraries. Try the different settings. Get familiar with the tool.

Leave a comment if you have anything to add or ask!

Comments

Tony said…
Very impressive article! Thanks for sharing this useful information. I own a website related to documentum workflow that might be useful for your visitors. Have a look!
Greg Zook said…
Update: a technique I have started using is opening Notes applications in Domino Designer. This gives me a quick, at a glance view of the applications functionality.

Of the 15,000 Notes applications I have migrated to date, less than ten rquired custom development.

Popular posts from this blog

ADMT fails to migrate SID History

Exchange 2010 event errors 2601, 2604, 2501

Robocopy Error 31 A device attached to the system is not functioning