locked
Cross-Forest Migration - MOSS 2007 to SharePoint 2010 RRS feed

  • Question

  • Hello SharePoint experts,

    I am planning a migration from MOSS 2007 in a source forest to SharePoint 2010 in a target forest.  A two-way transitive trust exists between the forests and Active Directory users/groups used with SharePoint have already been migrated over to the target forest with SID history.

    Where my question resides is how should I approach the content database.  One approach that a colleague suggested was to do a simple copy of the content database to the SharePoint 2010 server and attach it.  Then, I could test permissions out in the target forest and make any clean-up/correction on the live copy back in the source forest.  When I'm ready to do the final transition, just copy once again and attach.

    Is it really that simple?  I'm sure there are some additional steps that would be necessary.  I ran across an article earlier that mentioned an stsadm command to change the NETBIOS domain name in the database which seems like a step I would need to take.

    I am new to SharePoint, but am an old hat at Active Directory.  Could somebody point me in the right direction as to how to handle this migration cross-forest?

    Thanks very much!

    Friday, February 10, 2012 2:13 AM

Answers

  • Nothing special about going between stand alone SQL 2005 and a SQL cluster.

    There should not be much to remove.  You're only (presumably) migrating your content databases into new Web Apps on  SharePoint 2010.  As long as you've run stsadm -o migrateuser for each user account/group when you moved them, there should be no references (except for old, dead accounts in the User Information List, which shouldn't be removed anyways).


    http://sharepoint.nauplius.net

    • Marked as answer by GuYuming Monday, February 13, 2012 8:39 AM
    Friday, February 10, 2012 3:01 AM

All replies

  • So I'm assuming you've migrated the users already in the content databases attached to MOSS 2007.  So all you need to do is build SP 2010 in your new forest and perform a database-attach upgrade (Mount-SPContentDatabase).  It really is that simple, given you've installed SP2 or better on MOSS 2007 and have run stsadm -o preupgradecheck to resolve any errors.

    http://sharepoint.nauplius.net

    • Proposed as answer by Jason Warren Friday, February 10, 2012 2:38 AM
    Friday, February 10, 2012 2:32 AM
  • Thanks Trevor!  Yes, the users and groups have already been migrated and are active in the target domain for other purposes (Exchange, file access, etc).

    We are getting SP2 loaded up right now actually.

    Anything quirky about going from a standalone SQL 2005 installation (MOSS 2007) to a SQL 2008 R2 cluster (SP 2010) in regard to the database attach process?

    How about any additional clean-up steps to remove references to the old (source) domain name inside of SharePoint?

    Thanks again!

    Friday, February 10, 2012 2:54 AM
  • Nothing special about going between stand alone SQL 2005 and a SQL cluster.

    There should not be much to remove.  You're only (presumably) migrating your content databases into new Web Apps on  SharePoint 2010.  As long as you've run stsadm -o migrateuser for each user account/group when you moved them, there should be no references (except for old, dead accounts in the User Information List, which shouldn't be removed anyways).


    http://sharepoint.nauplius.net

    • Marked as answer by GuYuming Monday, February 13, 2012 8:39 AM
    Friday, February 10, 2012 3:01 AM
  • Whoa, let me back up a minute there.  I migrated my user's and groups using ADMT, not stsadm.  However, my users in the target domain can login to sharepoint still residing in the source domain using their target domain account.  What exactly does stsadm -o migrateuser do for me?

    Friday, February 10, 2012 3:29 AM
  • stsadm -o migrateuser migrates the user within SharePoint.  Do this prior to migrating the content databases.  SharePoint currently has references to their old SID and domain\user.  E.g., you'd run:

    stsadm -o migrateuser -oldlogin olddomain\user1 -newlogin newdomain\user1 [-ignoresidhistory]


    http://sharepoint.nauplius.net

    Friday, February 10, 2012 3:58 AM
  • Hi,

    The best approach is to migrate your server to SharePoint 2010. It is safe and reliable. To achieve you have to follow these steps

    1. Take the backup of current live website (wss3.0) using stsadm utility. 
    2. Create a new machine having Windows 2008 64-bit R2 and SQL Server 2008 R2 Express 64-bit.
    3. Install WSS 3.0 64-Bit and created a Site Collection using the same URL of the original server. Then patched it until it matched the 32-bit WSS 3.0 exactly.
    4. Restore backup (created in step 1) on to newly created machine.
    5. Once we had a working site on newly machine then simply install SharePoint Foundation 2010 and it upgraded the server to WSS 3.0 to WSS 4.0.
    6. Upgrade all SharePoint custom web parts (previously build in 32 bit with VS 2008) as per 64 bit configuration.

    Refer article Upgrade SharePoint 2007 to SharePoint 2010


    My Blog
    Twitter @jaggavivek

    Friday, February 10, 2012 4:08 AM
  • There is zero reasons to go from 32bit MOSS to 64bit MOSS prior to upgrading to SharePoint 2010.

    http://sharepoint.nauplius.net

    Friday, February 10, 2012 4:19 AM
  • Hi Trevor,

    Since each user account in the target forest already has SID history of the account from the source forest (where SharePoint 2007 is installed), will it be necessary to run the stsadm command.

    Is there an option to pipe data to it from a CSV or something like that?  I don't want to run the command 100+ times.

    Thanks again!  Excellent support.

    Friday, February 10, 2012 2:47 PM
  • Also, I am seeing some information online as to how I am supposed to migrate service accounts.  I will be using different service accounts in a different SQL cluster on the target domain.  Will the instructions in this article suffice:

    

    Friday, February 10, 2012 3:51 PM