How to Migrate Sites from (WSS-WMSDE) to (SPS-SQL)

Imagine a nice client doing good testing of a default WSS installed over WMSDE in a single server pilot installation.

They will ask during the pilot “We saw what WSS can do for us, Can you install SPS and show us some more?”

“Sure” you reply like a good architect would because SPS will really help them in collaboration with all the nice features.

And then they say “We want SPS with SQL Server on the same pilot box”.


You do realise that the default WSS installation that you did on their pilot box was with WMSDE. And you realise there already is some data in that WSS/WMSDE box with some additional sites and important documents that they dont want to loose.

So here is the problem statement “We would like to perform an in place upgrade / migrate of a pilot or a staging box which was installed with WSS and WMSDE to SPS and SQL Server”.

There are a couple of options which one could go for. Read through these scenarios and in the end I will explain which one I choose and why. Assumption is made that SQL Server is now installed on the pilot box as we need the SQL Enterprise Manager to connect to the local WMSDE instance (computer\sharepoint) and perform backups of WMSDE config and content databases. (to be saved onto media in case you land in trouble)

First scenario:

“Upgrade WSS/WMSDE to WSS/SQL and then install SPS over existing WSS”

[A] Migrating from WMSDE to SQL Server

[B] How To Integrate an Existing Windows SharePoint Services Installation with SharePoint Portal Server 2003

So you have upgraded in-place WSS/WMSDE to WSS/SQL in Step A and then from WSS/SQL to SPS/SQL in Step B.

Second scenario:

“Using the stsadm.exe tool with WSS/WMSDE create full site backups of all induvidual sites”

stsadm.exe -o enumsites -url http://localhost/
I have stsadm in my path. You will probably get a couple top sites including the top level. e.g.
http://localhost” Owner=”Domain\Administrator”
http://localhost/sites/government” Owner=”Domain\Administrator”
http://localhost/sites/mergers” Owner=”Domain\Administrator”

Now you would want to create 3 backup files for each of the above 3 sites, see below
stsadm.exe -o backup -url http://localhost/ -filename default.dat
stsadm.exe -o backup -url http://localhost/sites/government -filename government.dat
stsadm.exe -o backup -url http://localhost/sites/mergers -filename mergers.dat

It is now a good idea to backup the WMSDE config and content databases using the SQL Enterprise Manager. (Right Click on Database name, All Tasks, Backup)

And now the important part. We must check if Windows SharePoint Services Service Pack 1 was applied or not. If it was applied then in a later SPS installation we must apply it again before stsadm -o restore, else there will be an error. An easy way to check is using Control Panel – Add Remove Programs – Microsoft Windows SharePoint Services – Click here for support information. If the Version says 11.0.5608.0 then the SP was not applied, on the other hand if the Version says 11.0.6361.0 then SP1 was applied. Make a note of the Version Number.

Click for a large view (new window)

The image above shows a WSS & SPS installations with Version Numbers. Click on image for full view.

Now that we have all data, we can uninstall WSS
1. Uninstall WSS
2. Install SPS with SQL Server, Create a portal.
3. Ensure that the default out of the box portal is working (news, topics, site directory, etc)

At this point we have a clean SPS with SQL installation and a functioning Portal. As said earlier compare the WSS Version Number from control panel with the Version Number noted earlier from the WSS/WMSDE stage. If they dont match these next steps wont work.

We have 3 files that need to be restored to the portal http://server/sites/wss http://server/sites/government and http://server/sites/mergers

So lets fire away
stsadm.exe -o restore -url http://localhost/sites/wss -filename default.dat
stsadm.exe -o restore -url http://localhost/sites/government -filename government.dat
stsadm.exe -o restore -url http://localhost/sites/mergers -filename mergers.dat

All done, so far so good. If you were successfull you should add links to these under Site Directory

Third Scenario:

“Backup the WMSDE content database and add this backed up content database as “Additional Content Database” in a new SPS SQL installation.”

In the WSS/WMSDE situation
Enterprise Manager -> Connect to you WMSDE instance (computername\sharepoint)
Right Click on the content database (STS_123456, etc) All Tasks, Backup the database to a file on your filesystem. Call it c:\temp\WMSDE_STS_12356.dat

1. Uninstall WSS
2. Install SPS with SQL Server, Create a portal.
3. Ensure that the default out of the box portal is working (news, topics, site directory, etc)

At this point we have a clean SPS with SQL installation and a functioning Portal. As said earlier compare the WSS Version Number from control panel with the Version Number noted earlier from the WSS/WMSDE stage. If they dont match these next steps wont work.

Under SQL Enterprise Manager import the “c:\temp\WMSDE_STS_12356.dat” file as a new Database called PORTAL_SITE_01.

How to import an WMSDE DB into SQL Server?

SQL Enterprise Manager -> Expand SQL instance -> Right Click on your Databases (top one with open folder icon) -> All Tasks -> Restore Database -> General Option Tab -> Restore as Database “PORTAL_SITE_01” -> Choose “From Device” -> Select Device -> Add “c:\temp\WMSDE_STS_12356.dat” (which is the filename of the backup created from WMSDE using SQL Enterprise Manager) -> OK -> Options Tab (within Restore Database window) -> Ensure “Move to Physical File Name” have correct file path entries, they both should point to your SQL Server instance DATA directory.

Begin the Restore. It takes about 3~4 minutes for each Gig of data you have. (depending on your server power)

There, the WMSDE content database is now within the SQL Server as a new Content Database.

Goto SPS Central administration – Windows SharePoint Services – Configure Virtual Server Settings – Default Website – Manage Content Database – Add a Content Database.

Use the PORTAL_SITE_01 as your Database name, 9000 and 15000 as warning and maximum sites. Click OK. Your content databases page now will have 2 databases listed, PORTAL_SITE and PORTAL_SITE_01.

Here in this scenario I noticed that the top level site in WSS http://servername/ was not pulled over for some reasons, so I just used stsadm for the top level site and brought it as http://servername/sites/wss

Add links to the individual sites http://servername/sites/wss , http://servername/sites/government and http://servername/sites/mergers under the SPS Site Directory. If you wish you could go into each one of the restored sites and “Configure Connection to Portal” settings so they have “Up to Portal Name” in the navigation bar.


The first scenario is out of option, too complex and had to deal with host header names, (yikes, I already have enough issues with virtual server, eh). Not feasible in a large enterprise environments where you have to do a dozen paperwork for a hostname dns entry.

Second is good if you only have less than a dozen sites to move/upgrade and they are relatively small (not in Terrabytes). You could potentially write a script to stsadm -o restore looping through the enumsites, but I like to do them one by one just because I have been bitten in the past. (in prior assignments, users stored mdb files onto WSS [apparently then the admin removed this extension & I have no idea why] and this extension is blocked by default in WSS). Just a note that each prior existing installations are very unique and will vary a lot in mileage. So expect anything.

I really like third scenario, where there is not much work to be done if you had over a dozen sites or a Terrabyte of data. I actually did the entire Scenario Three in less than an hour for a database size of about 1.5 GB, (and that includes uninstall WSS, Install SPS, Move the Database, etc). Please note however that the top level WSS site was not available under SPS using Scenario Three and I had to manually stsdam to bring it over. Your mileage may vary. stsadm will migrate all documents, sites, sub sites and the permissions as well. Its a great quick fix tool.

Good luck to all performing these steps.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s