This project is read-only.

Migrating Sharepoint and SLAM

Oct 13, 2009 at 3:13 PM


I currently have a sharepoint system working with SLAM on a clients Site.

I would like to port this system to our office to provide a test enviroment for our support staff.

What is the best practice for migrating sharepoint with SLAM lists to a new server?

Does SLAM provide an export Tool?



Oct 13, 2009 at 3:19 PM

There is no need for an export tool.  With SLAM, the data - unless you are using the Hierarchy SLAM profile - is authoritative in SharePoint.  All you need to do is backup/restore SharePoint, install SLAM on your dev environment (including setting up a blank slam DB), copy over your SLAM config and synchronize.



Oct 13, 2009 at 4:31 PM

Thank you for the prompt response.

I will give it a try

Oct 15, 2009 at 5:34 PM

Hey all,

@awellenstein: If the SLAM Hierarchy component is being used, what would you recommend in order to persist the hierarchical data during migration? Simply backing up/restoring the SLAM DB too?

Thanks, Pete

Oct 15, 2009 at 6:26 PM


Oct 20, 2009 at 2:43 PM

@awellenstein: We tried following this method, we migrated the SharePoint data/content using the stsadm cmd line tool. This seemed to go fine....

The next step was to backup the slam db, and then restore it to the new database in order to maintain the hierarchical lists that existed in the original content. This again was fine, however; after the restore we checked the data in the table which was ok - but in SharePoint the lists were no longer showing their hierarchy.. Following this we reactivated SLAM and syncronised. This lead to all the Lft/Rght and HierarchyLevel data being reset (NULL/NULL and 1 respectively).

We summised that the reason for this may be that the guids assigned to the content during migration no longer matched the previous entries in the SLAM db, and therefore SLAM cleared out the old entries and added the new ones - which would have no hierarchy. But this is not what we wanted, I think from your last comment you did not expect this either. Is this a bug? or can you suggest another way to migrate the SLAM db content such that it won't be cleared when re-syncing with SharePoint?

Many thanks


Oct 21, 2009 at 3:49 AM

@peteski22: I was wrong with my response.  I assumed backup would maintain the list GUIDs.  This issue is sort of a bug but really more a feature we haven't gotten around to building yet.  The issue is this: with SLAM, SharePoint is typically king.  All the data lives in SharePoint so you can always resynchronize to recreate your SLAM database.  The hierarchy profile is different because of how nested set hierarchy works.  When you make a change in the hierarchy, many records get changed as the left right values are recalculated.  The SLAM profile does this in one SQL statement so it's very efficient.  While we could technically update all the affected items in SharePoint, it would seriously drag, especially with large hierarchies.  That’s why hierarchy data (left and right) only lives in the database. 

What actually gets stored in the custom field type are the instructions that the hierarchy profile reads to know where to slot that item into the hierarchy.  As you suspected, the list GUIDs are what we key on and when you copy the site, the list items get new GUIDs.

We have designed a solution to this problem – an interface that would allow you to “prepare the hierarchy for synchronization” – it would save data into sharepoint to preserve the hierarchy (basically the left right values) and then the slam profile would implement custom synchronization behavior to pop the data back into the slam database.

It’s an enhancement that’s been on the list for a while. Sooner or a later I’m sure we’re going to need it on a clients’ project and so will be forced to prioritize it. 

Oct 21, 2009 at 5:37 PM
Edited Oct 23, 2009 at 9:50 AM

Hi all,

I think we can achieve migration of hierarchical data from one sharepoint server to another using following steps.

For example: We want to migrate the HList from SPServer_Source to SPServer_Destination.

  1. Install spcontentDeploymentwizard ( , SLAM and SLAM hierarchy on both servers.
  2. User SharePoint content Deployment Wizard to export the HList from SPServer_Source to a .cmp file.
  3. User same wizard to import that .cmp file during import (make sure that you specify both site URL and import web URL, although wizard does not complain, but it will throw a unrelated exception in the end)
  4. Make sure you check the Retain object IDs and location on deployment wizard.
  5. After this HList should be in SPServer_Destination but the hierarchy is broken.
  6. Delete the table corresponding to that list in DBDestination_Slam database (if any)
  7. Modify slam.config in SPServer_Destination to include your new HList.
  8. In order to get the hierarchy (left/rigth etc.), we can use some sql query to copy data from the SLAM table correspondong that list to destination. e.g.
    select * into DBDestination_Slam.HList
     from DBSource_Slam.HList
  9. Activate your SLAM, SLAM Hierarchy. So that it picks up changes.
  10. Just hit refresh on destination HList.

Hope everything goes well.




Nov 17, 2009 at 3:49 PM

Hi @awellenstein:

I have created a custom tool to import Data from an Excel sheet to an existing or new SLAM Hierarchical Data.

Everything seemed OK except when you click on edit item. It does not pick the parent, When i looked into code it was unable to find the GUID supplied,

The Guid which I was supplying was in lower case while that of SLAM was in upper case, so i did a little change in the code. which is like this:

File: SLAM Hierarchy 1.0.1 Source>AWS.SLAM.Hierarchy>HierarchyPositionFieldControl.ascx.cs  in the set value of override object Value of class HierarchyPositionFieldControl

after the line

ListItem selectedParent = ddlParents.Items.FindByValue(valueParts[0]);

my added region is this

#region ExcelImport for SLAM data

                        // Added following this region to use ExcelImport for SLAM data
                        // Little change of 'ToUpper()' here, in order to use our custom Hierarchical position
                        // As in GUIDs two are equal even though their case is different.
                        // Without this code SLAM thinks these are different.
                        if (selectedParent == null)
                            selectedParent = ddlParents.Items.FindByValue(valueParts[0].ToUpper());

Do you think it is a good change or there are some issues.

because i think Guid should be found even if their case is different.

For me it worked well.












Nov 18, 2009 at 4:29 PM

This seems fine.  I think that the ListItemID will always be upper case from the database.  You might change the line in LoadChildrenForParent where items are added to ddlPositions to ensure that your cases will always match when pulled from the db as well.  I will make this change as well.



Nov 18, 2009 at 9:29 PM


Would you care to share your custom tool to import Data from an Excel sheet to an existing or new SLAM Hierarchical list?  We're happy to include it in the project (and credit you if you'd like).