none
SharePoint 2007 Database Migration RRS feed

  • Question

  • SharePoint 2007 Environment:

    a.  2 - Web Front Ends

    b.  1 - App Server

    c.  2 - Clustered SQL 2000 Servers

     

    Objective:

    Keep a and b...replace C with new hardware.

     

    Our objective is to get rid of the existing SQL 2000 cluster (aging hardware) and put in a new SQL 2005 cluster.  I have a ticket open with Microsoft support and I have been reading blog and forum posts about this procedure.  Microsoft's stance on the issue is that we would have to migrate the content DBs to the new server and then create a new Config DB to contain the information about the new database server thus wiping out all configuration data.

     

    I honestly can't believe that their suggested migration path is basically to wipe out the existing SP 2007 configuration.  We have a fairly large SP 2007 implementation and it would be a bear to have to set everything up again.  They have a firm stance that the Config DB cannot be moved from one database server to another.

     

    Has anyone performed a similar type of migration from old to new hardware that could share the steps that were taken to ensure that no configuration data was lost.  We are even entertaining the option of naming the new hardware the same thing as the old hardware, but Microsoft told me that this also was not an option. 

     

    Thank you very much for any assistance.

    Wednesday, December 12, 2007 5:25 PM

All replies

  • You have to realize that the 2 SQL 2000 clustered servers is where ALL the data is housed for SharePoint (well... all the meaty stuff anyway).  What Microsoft orginally told you was correct.  You will have to perform a migration of sorts from MOSS to MOSS.  This can be achieved fairly easy (sort of).  Pretty much need to backup the entire portal (or however many you have) and wipe everything clean on both the front end and back end servers.  Then perform a restore using the backup you created.  Honestly the easiest way depending on how many sites there are and how large in size.

    Thursday, December 13, 2007 4:12 AM
  • Yeah, that is definitely our main issue.  From what I have seen moving the content databases poses no problem...its a simple backup/restore to the new SQL box.  The issue lies with the Config DB. 

     

    So, you are suggesting that we go into SharePoint and use the backup feature in Central Admin to backup EVERYTHING at the FARM level?  That will be about 350 GB of data. 

     

    Then you are suggesting that we wipe out the existing FEs and BEs.  What exactly are you referring to there?  Are you saying to run the SharePoint Prod and Tech wizard to point to the new DB server and new Config DB on that new server?  Won't that effectively wipe everything out?  Or are there additional steps that I need to perform to do this?  Or does the restore ask you for the name of the new Database Server and Config DB as well? 


    Also, when I restore...will everything be as it was in the previous system (web Apps...etc?)

     

    We are trying to get a process down so that we can start testing our migration strategy on our test evironment. 

     

    I definitely appreciate your assisitance. 

     

     

    Thursday, December 13, 2007 1:14 PM
  • We're currently at the tail-end of our lab environment.  We need to migrate roughly 300GB of data from SPS2003 to MOSS.  Luckily it's to a completely new server farm instead of the current servers. 

     

    To my extent of knowledge, you'll need to reinstall SharePoint with the new cluster of SQL servers.  Everything at the portal level will migrate over with their current settings, the only settings you'll need to adjust are those withing Central Administration... but really no getting around that because of the new SQL Servers.  Just mimic the current settings of your SharePoint farm again and restore all of the sites.

     

    I hope I'm wrong for your sake, but that's what I know.

    Thursday, December 13, 2007 1:23 PM
  • Thanks again, I appreciate it.  So, your method wouldn't be much different than moving all of the content databases to the new server then creating a new config db?  I would still need to re-establish all settings within Central Admin such as re-creating my web applications.  Right?

    Thanks.

    Thursday, December 13, 2007 1:28 PM
  • It's possible there's another way around doing it this way, but it's a way that I know would work.  Maybe Bill Gates will post on here in about an hour updating you on exactly how to do it.

    Thursday, December 13, 2007 1:38 PM
  • Ha!  Something tells me that Bill Gates would be just as stumped as the rest of us on this one.  I just find it very hard to believe that Microsoft's only supported migration path is to wipe out your configuration any time that you want to move your databases.  Do they think that people will stick to the same hardware for the entire life of their SharePoint implementation?  It seems a little short sighted to me. 

     

    Thank you very much for your help.  I appreciate it. 

     

    Thursday, December 13, 2007 2:17 PM
  • Hmm... if you want to test this out there's a possibility it could work.  Just use the new servers as a testing ground for it.

     

    Make a backup of your current SQL 2000 databases, restore it to one of the new servers with SQL 2000 installed.  Upgrade to SQL 2005.  Then through SharePoint, just try to go through and repoint it to the new database servers, see what happens.  No harm in trying. 

    Thursday, December 13, 2007 2:40 PM
  • To be more precise.

    When a new SQL server comes into picture, you have to have a new configuration database. You have to move the content databases to the new SQL.

    Microsoft does not ask youi to use the same hardware through out your life and they would definitely help you in data migration from one SQL to another. Also to get your entire configuration the way you want.

    However when you are using SharePoint Microsoft would support the out of the box features. They can give best efforts to retain your customizations which again is not supported.

    The way you are freaking out about new config suggests you have done customizations on the site. So of-course you have to take care of that when it comes to a new config. You can't blame MS for that.

    Again as a best practice MS always suggest to perform migration/upgrade on a DEV environment first before actually doing it on the Production environment.


    Regards, Vishwas
    Thursday, November 10, 2011 5:34 PM