Questions on migration Vault 4.1.4/SQL2k5 -> 5.1.2/SQL2k8 R2

[tpait]

Hi,

I have been reading through the knowledgebase and support posts but there doesn't seem to be one conclusive answer for what I am trying to do. I guess I just need some guidance and confirmation on what is the right way for us to approach this migration/upgrade.

I am a network administrator for our office and have some experience with SQL app installation (I upgraded/migrated our previous Vault 3.x.x from SQL2000 -> to 4.1.4 with tomcat on another server with SQL2005 ), but by no means am I an expert!!!

Firstly, our current Vault server is Windows 2003, SQL 2005 with Vault 4.1.4 and shares its existence with a couple of other applications. Due to performance and space issues, we have bought a new dedicated server for Vault and intend to install it with Windows 2008 R2 x64, SQL 2008 R2 and Vault 5.1.2 Professional. We have current maintenance.

My main question is: What is the correct order/procedure of installation/backup/restore of data etc to get our new server operational with the data from the old server? Can you summarise the steps we need to do to get this done?

Some other notes and questions on these details:
I notice that .Net must be installed after IIS so will make sure that will happen.

I think once the OS and SQL is installed, we need to restore data into SQL from a backup of data off the old server before installing Vault? Do we just need sgmaster and sgvault? Also, does it matter that the old server is 32 bit and new server 64 bit?

I see some references in knowledge base that when upgrading to install 5.04 over 4.14 before upgrading to later versions. Does that apply to us here?

Is there a way to convert the 4.1.4 data to 5.1.2 after the upgrade is done? This would make the switch to the new server easier as we can be sure its working properly with an old set of data before transferring the latest data.

Is there anything else that you think might be important in our situation?

Regards,
Barry

[Beth]

The steps for both a move and an upgrad from Vault 4.1.4 to 5.1.2 Professional are:

• 1) Backup the Vault 4.1.4 sgvault and sgmaster databases. You can use either the Vault admin web page or SQL Server for the backup.
  
  2) Restore the sgvault and sgmaster databases on the new SQL Server.
  
  3) Install Vault 5.1.2 Professional on the new server. Allow it to pick up and user the databases that were restored on the new SQL Server.
  
  4) After the install is complete, enter your new license keys into the Vault 5.1.2 Professional admin web page under the license link.
  
  5) Have the users install the Vault 5.1.2 client. It can be obtained from your own server at: http://<your server name>/vaultservice/intex.html. About 2/3rds of the way down the page is a client installer link.

Most servers already have .NET installed. Then you install IIS. After that, rather than installing .NET again, you can just register it with IIS with the command:

Code: Select all

On a 32-bit machine:  
C:\Windows\Microsoft.net\framework\v2.0.50727\aspnet_regiis -i 

On a 64-bit machine:  
C:\Windows\Microsoft.net\framework\v2.0.50727\aspnet_regiis -i 

[/size]
It does not matter if you switch from a 32-bit to a 64-bit server, but you will want to make sure you grab the 64-bit installer.

Our basic upgrading instructions has a person going through each major version. Most people can make the jump from Vault 4.1.4 to 5.1.2 though. If a person was on 4.0.6 though or lower, I'd have them go upwards in steps, or if there are any problems, I'd have them add in the step of Vault 5.0.4. It certainly doesn't hurt to install Vault 5.0.4 first and then 5.1.2 either.

It's possible in some cases to convert the data after the instead of during upgrade, but I wouldn't recommend it. It's a very long process and not always successful. For example, if your upgrading process took an hour, converting it over afterwards could take you a week or more.

Since you want to test, I would recommend performing the upgrade, then going through the process again with a new set of database backups.

[tpait]

Thanks for the info that helps alot.

I just want to confirm a couple of things in your message:

"Since you want to test, I would recommend performing the upgrade, then going through the process again with a new set of database backups."
- Do you mean upgrade the existing installation first, then backup data, transfer to new server, restore, then install the 64 bit version of Vault on the new server to pickup the existing data?

I would prefer to keep the existing installation as is, and do the testing on the new machine if possible. That way we have a known working system we can fall back on. If we upgrade the existing server and something goes wrong, we have nothing to work from.

Could we not do the migration to the new server as planned taking notes as to what needed to be done, but test it first, then when we are happy, uninstall Vault and delete SQL data from the new server, take a new backup of the data on the old server, and then reinstall Vault with the newly restored data using the same procedure we recorded?

Lastly, are there any issues with files having checked in/out status at the time of the upgrade - ie when the user installs the new client will all their check in/out info still be current? Are there any other directions we need to give users before the changeover besides upgrading their client?

Regards,
Barry

[Beth]

Could we not do the migration to the new server as planned taking notes as to what needed to be done, but test it first, then when we are happy, uninstall Vault and delete SQL data from the new server, take a new backup of the data on the old server, and then reinstall Vault with the newly restored data using the same procedure we recorded?

Yes, you can do that.

Users don't have to check in their files for the upgrade or move.

If users are using Vault integrated with another program though, such as Visual Studio, they will need to rebind their projects to point at the new server. Will this be part of your migration as well?

[tpait]

OK Thanks again.

Yes our main reason for using Vault is for integration with Visual Studio 2005. How involved is the procedure you mention about rebinding the project in Visual Studio - I am not particularly familiar with it. Do you have a document you can link me to, or is it something Microsoft would have on their knowledge base?

If it matters, at the moment we have no plans to upgrade our Visual Studio, but I am sure we will have to change in the future to keep up to date..

[Beth]

The basics of what will happen is that 1 user will open the project and receive errors. Then go to File - Source Control - Change Source Control (or File - Vault Source Control - Change Bindings). Unbind all the lines listed and click Ok. Close Visual Studio, then reopen it. This will allow the server it's looking for to be changed. Return to the same binding dialog and bind all the lines. You should be asked to log into Vault and choose a repository. Then check in the changes.

Once the binding changes are checked in, the other users can perform fresh Open From Source Control (or Open From Vault) from inside VS to rebind all their projects, or they can rebind in the same manner as the first person. Performing the Open From Source Control (or Open From Vault) may overwrite changes the user has on disk.

If you need any help with rebinding, then just send an email to support at sourcegear.com with 'attn: Beth'.