Monday, December 27, 2010

SBS Companyweb migration


Series posts:

Introduction – Overview
Part 1 – Caveats and Considerations
Part 2 – Preparation steps on v2
Part 3 – Upgrading v2 database to WSS v3
Part 4 – Attaching upgraded database to WSS v3
Part 5 – Check WSSv3 for migration to Foundation 2010
Part 6 – Move database to SBS 2011
Part 7 – Post migration steps and considerations



So SBS 2011 Standard is now available and Microsoft has even released a document on how to go about migrating Companyweb from SBS 2003 and SBS 2008. You’ll find that document here:

http://technet.microsoft.com/en-us/library/gg563792.aspx

Rather than simply re-hash that document I’m going to do a series of blogs posts on general migration to the latest version of SharePoint. That means both SharePoint Foundation 2010 on SBS 2011 and Office365 in the ‘cloud’. So let’s start with a high level overview.

General

1. You can’t simply back up and restore Companyweb web from SBS 2003 to SBS 2008 or SBS 2011 for that matter.

2. Each version requires a conversion process to be run on the databases. Thus, from Windows SharePoint v2 on SBS 2003 to Windows SharePoint Services v3 on SBS 2008 the database requires an upgrade. Likewise, the same applies from Windows SharePoint Services v3 to SharePoint Foundation 2010.

3. If you want to jump from Windows SharePoint v2 to SharePoint Foundation 2010 you are going to have upgrade to Windows SharePoint v3, then upgrade to SharePoint Foundation 2010. There is no direct process. This means you will need a functioning Windows SharePoint Services v3 site somewhere during the migration to SharePoint Foundation 2010.

4. SharePoint Foundation 2010 on SBS 2011 is limited, by default, to a database size of 10GB (because it uses SQL Express 2008 R2). If you have content large than this you need to look at moving SharePoint Foundation 2010 to a commercial version of SQL (i.e. standard).

5.  Some of the customizations and templates in each version may not migrate and in some cases may actually prevent migration. The general rule of thumb is that the less modifications you make to SharePoint the easier the migration. You’ll need to test for these customizations prior to migration to determine what changes may be required on the original site prior to the migration.

6. Tools such as SharePoint workspace 2010 will not be of assistance for a migration since they ONLY function with the current version of SharePoint (i.e. 2010).

7. You will need to re-establish things like search indices, PDF indexing, etc in the latest version (which can require very different configurations from the original version).

8. Beware of long filenames, blocked file types and filenames with special characters. They may not all be supported in the version of SharePoint you are moving to.

9. Make sure you have enough disk space on your destination server for the SharePoint databases as in most versions of SBS the default location for SharePoint databases is on the system drive (i.e. C:). Best practice is to relocate the databases before you start populating them.

10. There are a few different paths that can be taken for a migration but at the end of the day you typically want a site that is a combination of the existing blank site and you old content. This will means running a merge, which typically means you need to create an import file of your old data in a SharePoint 2010 format first.

From SBS 2003 to SBS 2011

1. You are going to need to ensure that SharePoint v2 on SBS 2003 is full patched. This means at least SharePoint v2 Service Pack 3 needs to be installed.

2. You’ll need to run the prescan.exe tool on SharePoint v2. This will provide you with any warnings that may prevent migration. Note that prescan.exe also changes the databases so that they can’t be upgraded WITHOUT running this tool.

3. Then you’ll have to install Windows SharePoint Services v3 somewhere (on the SBS 2003 box, another box or a virtual machines) and migrate the v2 databases there.

4. You’ll then need to run the v3 command:

stsadm –o preupgradecheck

and resolve any issues.

5. Finally you can migrate the databases to SharePoint Foundation 2010 on SBS 2011.

From SBS 2008 to SBS 2011

1. Again, you’ll need to ensure that SharePoint it totally up to date. Migration will not work unless certain minimum versions are met.

2. You’ll then need to run the v3 command:

stsadm –o preupgradecheck

and resolve any issues.

3. You can then migrate to SharePoint Foundation on SBS 2011.

To BPOS

1. BPOS is currently equivalent to Windows SharePoint Services v3 (like that on SBS 2008). So if you have anything prior you will need to bring the source content up to that level first.

2. You can’t do a database migration under BPOS so you’ll have to use a number of export and import mechanisms to get the content across. This will mean exporting lists to spreadsheets and databases. It will mean using SharePoint templates to save calendars. It will also means using drive mappings to shift data.

3. At the end of the day it is a very manual process and will most likely result in data loss. There are third party tools available, but in my experience they are not cost effective unless you are doing a lot of SharePoint migrations.

To Office365

1. When BPOS is upgraded to Office365 it will upgrade SharePoint from v3 to 2010 which generally means the content from previous versions (i.e. v3) will not migrate easily. This means that any content will need to be converted into 2010 format before it is imported into a 2010 site. That is why it is a good idea to move your SBS 2008 Companyweb data now into BPOS so when it gets upgraded to SharePoint 2010 your data will as well.

2. You can’t migrate a database straight into Office365 (is my understanding although powershell may allow this), thus you are going to have to use a number of import and export mechanisms to get the content across. This will mean exporting lists to spreadsheets and databases. It will mean using SharePoint templates to save calendars. It will also mean using drive mappings to sift data.

3. At the end of the day it is going to be a very manual process and will most likely result in data loss (from what I can currently see). There are third party tools available, but in my experience they are not cost effective unless you are doing a lot of SharePoint migrations.

Conclusion

There are plenty of issues I have glossed over here but hopefully this gives you some idea of what you may be up for during a SharePoint migration.

I’ll provide more details of each of these migrations over the coming posts.

Image: Kevin Eddy