Moving Document Libraries from WSS 2.0 to Wss 3.0 MOSS 2007

The migration has always been an issue with MOSS as dear Microsoft never provided us with a migration tool. Well here is one way of migrating the document libraries. If you dont have the budget and time to go for a third party software this might help you.

If you have the time and money in the pot I would recommend that use METALOGIX from www.metalogix.com. After testing a number of these migration software for MOSS I have concluded that this one is the most easy to use and most comprehensive. Plus they offer great support and are quick to answer your quries unlike many others.

Ok here is the manual migration process:

Backup the databases for the sites you want to upgrade.  Restore these backups as new databases on the SQL server in your WSS 3.0 farm.  Create web applications in WSS 3.0 for the sites that you are going to upgrade.  Remove the databases that are created with these web applications through WSS 3.0 central configuration.  Now attach the WSS 2.0 databases you just restored to SQL using stsadm -o addcontentdb to the web applications you created in WSS 3.0 for the migrated sites.  This is done through the command prompt.  To do this navigate c:program filescommon filesMicrosoft sharedweb server extensions12bin and type this command filling in the appropriate information.

<strong>stsadm.exe -o addcontentdb -url http://&lt;server&gt;:&lt;port&gt; -databasename &lt;WSS v2.0 content database&gt; -databaseserver &lt;DB Server name&gt; </strong>

for example

<strong>stsadm.exe -o addcontentdb -url http://MyServer:80 -databasename WSS_V2_ContentDB -databaseserver Sample</strong>

This will do an in place upgrade of the database.

Note:  If you SQL box has instances on it you will need to specify the instance the database is in for example &lt;SQL Server Name&gt;&lt;SQL Instance Name&gt; in the &lt;DB Server name&gt; space above.

The Sharepoint Development Experience

I want to describe the development process involved in creating a web part for a Sharepoint site, hopefully to dispel the belief that it’s difficult and time-consuming. What I want to demonstrate is that it’s actually very simple – no more difficult than creating a custom control in ASP.Net 2.0 – provided you have set up your development infrastructure correctly.

Development infrastructure is where most of the pain associated with Sharepoint development really exists, which is why following this article I’m going to continue with a series describing how you can set up the various parts of your infrastructure to enable friction-free development.

This post, however, will show you exactly how friction-free it can be. I’m going to show the steps to build a basic web part and deploy it to your sharepoint solution in a repeatable and reversible way. I’ll also give a tour of how to customise the look-and-feel of a Sharepoint website using the Sharepoint designer. The purpose of this is show to illustrate that developing with Sharepoint isn’t really that much different to developing for a standard ASP.Net 2.0-based website.

Development

Watch me create and deploy a brand new web part to a Sharepoint server:

1. This is my out of the box Publishing Site template

2. I’m going to add a web part to my site by adding a new class to my visual studio project

3. My class must inherit from Microsoft.SharePoint.WebPartPages.WebPart. I’m going to override the Render method to make the web part output some text. Note how similar this is to an ASP.Net custom control.

4.  I build the project. A post-build step creates a CAB file which can be deployed to Sharepoint. This packages up my new features/webparts so that I can manage their usage within Sharepoint and easily repeat/reverse this deployment process.

5.  I run a script to deploy the CAB file to Sharepoint.

6. In Sharepoint I add the Web Part to a page. If I haven’t deployed this web part before I need to Import the web part from the Site Settings menu first.

7. And there it is!

This development process is so simple and repeatable, it’s just like a standard ASP.Net website. What’s more when I set up source-control for my visual studio solution I can set up a continuous integration environment to automatically deploy my changes for me.

Layouts

Now I’m going to change the layout for this page. Most developers seem to believe this is an almost impossible task, or at least much more painful than editing a regular ASP.Net 2.0 Web Forms page. Well, watch:

1. My page layout

2. I open up Sharepoint Designer and browse to the page I want to edit and double click. Sharepoint Designer asks me if I want to edit the content for the page or the layout for the page. I select layout. Here’s what I see:

There are a lot of controls on the page. Most of them have the prefix SharePointWebControls, so we can pretty easily see what they’re doing and we don’t have to be afraid. Otherwise this is just like a standard ASP.Net Web Forms page – it has stuff inside ContentPlaceHolder controls. Sharepoint assigns this page layout a master page at runtime.

3. See those ugly tables in the PlaceHolderMain ContentPlaceholderControl? I’m going to change those to divs:

4. And now I’m going to edit the master page for this page layout. I know that the master page I want to edit happens to be BlueBand.master, because I chose it within the SharePoint Site Settings menu. And I also know that all master pages can be found in /catalog/masterpage in SharePoint Designer. I’ll change the tables there to divs too.

5. I check-in the changes to these files (SharePoint automatically provides versioning on these files because they’re actually in the SharePoint database – more on that in another post) and reload my site homepage:

Not such a visually impressive example, I know, but I just wanted to demonstrate that editing a SharePoint website isn’t really that different to building an ASP.Net website, and it’s no more difficult.

In future posts I’m going to walk through how to set up the infrastructure to be able to enjoy the development experience I demonstrated in the first section, and I also hope to demonstrate some ways to make layout editing more enjoyable, like by removing as much of the .Net cruft as possible and make your pages generate something more like semantic markup.

Source: http://andrewmyhre.wordpress.com ~(thanks)