Thinking of finally making the move from Windows SharePoint Services 3.0 to Microsoft Office SharePoint Server...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
2007? If you're serious about SharePoint, then migrating to MOSS 2007 makes sense because your organization can get a lot more out of Microsoft SharePoint Server.
There has been a lot of confusion regarding the differences between the Enterprise and the Standard Client Access License (CAL) suites for SharePoint. If you're struggling with which one to choose, consider that there isn't one right answer. However, the compelling reason to spend more for the Enterprise CAL comes down to a few key services: Excel Services, Forms Server and unlimited search indexing.
In addition, Microsoft just recently granted Enterprise customers a license to use their Business Intelligence tool PerformancePoint for SharePoint. This effectively makes SharePoint a very compelling BI platform in addition to a content management tool.
Once the decision is made to move forward with the broader SharePoint offering, companies are left trying to determine what the best approach is for migrating and what to retain in their existing SharePoint infrastructure. They also have to integrate the new features and either ensure that user data remains in place or that it's migrated to the "new" location.
The good news is that WSS is the core of the SharePoint product line. That means the larger MOSS product depends on the foundational services provided by WSS. Because of that, moving from WSS to MOSS isn't as painful as you might expect. There should be no instances where you lose functionality — MOSS will simply add to the functionality you already have.
To begin your migration, make sure you take a proper inventory of your existing environment. Pay particular attention to the architecture of the existing WSS farm. Be sure you understand not only the physical configuration of the server or servers that support your WSS implementation but also your software configuration.
Here are some elements to pay special attention to:
- Farm configuration: A SharePoint farm generally describes the number and configuration of your servers. In many small WSS implementations, a single server may have been used. In moving to MOSS, you may convert to a small or medium farm. This will affect the configuration of the SharePoint application and security.
SharePoint applications: In SharePoint terms, an application is essentially an IIS website that is "SharePoint-enabled." If you've started with WSS, you're likely to have at least two applications defined. With MOSS, there will be at least four or five applications.
Site collections: Next in the hierarchy are SharePoint site collections. SharePoint applications can house one or more site collections, usually off one or more URL elements like http://yourapplication/sites/[sitecollection]. The biggest challenge here is really all about site structure. Your MOSS implementation may have a radically different taxonomy, and you'll need to move things around.
Sites: A site is a basic unit within a site collection, which has to have at least one site. Your existing sites will have been created with a WSS Site Definition. Those definitions will still exist in MOSS, but with the addition of MOSS Site Definitions, there may be opportunities for migrating content to a more appropriate MOSS Site Definition from the existing WSS Site Definition.
Once you have a good handle on your existing WSS environment, follow these migration tips to ensure a successful migration to MOSS:
If you already have a stable WSS environment, consider leaving it in place and installing MOSS in parallel, which would enable you to continue to leverage the WSS environment while gaining the benefit of MOSS. This is especially relevant if your WSS environment was largely used as a team or project collaboration.
If you're moving from a single server implementation to a small or medium farm, make sure you know which service identities are being used. Each SharePoint application is tied to an application pool that has a specific network identity. Some WSS implementations may use SYSTEM or NETWORK SERVICE. On a single machine, this may be fine. If you create a new farm with more than one server — or you simply expand your farm to include more servers — you'll need to use domain accounts, even if your users use Forms to authenticate. This will affect your ability to access the WSS content databases as well as the configuration database. You must either grant the new network identities access to the existing databases or back up and move the existing sites/site collections.
If you're changing the taxonomy/ structure of your WSS sites to better integrate with your new MOSS environment, you may be able to use the export and import capabilities of the STSADM command to move existing sites and site collections into the new structure. This option won't solve every problem, but it can be very effective in helping the migration to MOSS and a new structure.
You can't change the site definition used for a site after it's been created. If you want to leverage MOSS site definitions, like Publishing Sites instead of a WSS site definition, you'll have to move the content. Take a look at companies likeMetalogix or free utilities on CodePlex to assist you in moving user content.
Workflows and other customizations created with SharePoint Designer can't be moved to the new MOSS environment. This is not a limitation of WSS but rather a fact of SharePoint even in the MOSS environment. Consider recreating the workflows or more global customizations in Visual Studio and installing them as a site collection feature to enable broader distribution.
In all migrating to MOSS 2007 from WSS may be a challenge. However, given that WSS is the foundation of MOSS, your chances for success are high. Just make sure you take care of the details when you make the move.
ABOUT THE AUTHOR
Shawn Shell is the founder of Consejo Inc., a consultancy based in Chicago that specializes in Web-based applications, employees and partner portals, as well as enterprise content management. He has spent more than 20 years in IT, with the last 10 focused on content technologies. Shell is a co-author of Microsoft Content Management Server 2002: A Complete Guide, published by Addison-Wesley, and the lead analyst/author on the CMSWatch SharePoint Report 2009.