none
TFS Post production deployment step....?

    Question

  • We have a 2013 prod box with a Project named "claims". We upgrade it to TFS 2017 on new hardware  (after copying 2013 databases) and the 2017 version also has the Project "claims". A Dev checks out the new 2017 "claims" project using VS and continues working on the 2013 "claims" project. Finally the 2017 server goes live and the 2013 server is (probably) powered down.  Will there be any issues with the client workspace accessing the new 2017 "claims" as the workspace previously pointed to the 2013 server? If so, what post deployment steps should we expect to carry out?

    TIA,

    edm2

    Friday, March 17, 2017 3:21 AM

Answers

  • Just to make sure I understand you correctly.

    You want to migrate and upgrade a 2013 server to 2017 and will have them both online in a short period?

    Thats not a good idea as the servers has the same GUID. You can change the server GUID with TFSconfig command, but then the clients will see them as two different servers and your workspaces will not Work for the changed server

    The workspace mappings will survive a migration/upgrade as longs as you don't change the server GUID.

    • Marked as answer by edm2 Sunday, April 09, 2017 6:24 PM
    Friday, March 17, 2017 7:01 AM
  • If your 2017 server is only for test purpose, you can do it as you describe.

    Be aware, when you do the real migration without changing the server ID, clients with workspaces to the 2017 test server, will not work. The workspaces from 2013 will work fine.

    • Marked as answer by edm2 Sunday, April 09, 2017 6:24 PM
    Monday, March 20, 2017 6:42 AM

All replies

  • Just to make sure I understand you correctly.

    You want to migrate and upgrade a 2013 server to 2017 and will have them both online in a short period?

    Thats not a good idea as the servers has the same GUID. You can change the server GUID with TFSconfig command, but then the clients will see them as two different servers and your workspaces will not Work for the changed server

    The workspace mappings will survive a migration/upgrade as longs as you don't change the server GUID.

    • Marked as answer by edm2 Sunday, April 09, 2017 6:24 PM
    Friday, March 17, 2017 7:01 AM
  • Kim,

    >>> You want to migrate and upgrade a 2013 server to 2017 and will have them both online in a short period?

    Yes. Maybe up for several weeks. My understanding is that the TFS pre-production (not sure about Production) upgrade process will change all IDs and remap DBs so having both servers up at the same will not be an issue.

    >>> You can change the server GUID with TFSconfig command, but then the clients will see them as two different servers and your workspaces will not Work for the changed server

    We need to change the server IDs to have the 2013 and 2017 boxes running at the same time.  Are you suggesting the proper way to do the final production upgrade (after it passes the QA tests) is to backup the 2013 DBs on the 2017 server, power down the 2013 server, restore backups on the 2017 server, leave the server IDs alone, and then clients won't have any issues with their workspaces?

    edm2



    • Edited by edm2 Friday, March 17, 2017 1:36 PM
    Friday, March 17, 2017 1:34 PM
  • If your 2017 server is only for test purpose, you can do it as you describe.

    Be aware, when you do the real migration without changing the server ID, clients with workspaces to the 2017 test server, will not work. The workspaces from 2013 will work fine.

    • Marked as answer by edm2 Sunday, April 09, 2017 6:24 PM
    Monday, March 20, 2017 6:42 AM