3 Replies Latest reply on Sep 17, 2017 10:53 PM by CameronS

    HCM upgrade where upgraded copy of production and production is on separate networks


      In reviewing the process for our upcoming HCM 9.1 to 9.2 and PT 8.53 to 8.54 upgrade, the documentation states that in change assistant, the final MTP pass source is the final upgraded copy of production instance and the target is your production system. 


      In our current architecture, the upgraded copy of production is located on an entirely separate network.  All previous patches and updates were installed via change packages that were delivered to the production system using an approved release file transfer and version software.


      Is there a way to upgrade (HCM specifically) our production system on a separate network without having to deliver and stand up the entire final copy of production PS environment and DB instance on the production network to be the source?


      Thank you for any suggestions.





        • 1. Re: HCM upgrade where upgraded copy of production and production is on separate networks

          I think the simplest answer to your question is to state that you require physical connection to both your source and target databases simultaneously in the MTP process.


          There are three possible ways of handling this that I can see:

          1. Work from a system that is able to connect to both networks at the same time (sits on the fence).  You don't need to establish network bridging to do this, so it is possible to assert that the networks are still separate even though one machine connects to both.
          2. As you have mentioned, copy the source database and setup all architecture around it into the target network for the duration of the MTP
          3. Similarly to 2, you can copy current production database to the development network (where you have architecture ready and waiting).  Once the MTP is complete, you can copy the production database back to the production network.


          I have listed these in my order of preference.  1 is most preferred, as it uses all systems in situ and therefore the least risk to the MTP process.  2 is relatively easy, yet an entire database copy is not a quick process.  It additionally introduces a risk to the MTP process where potentially untested infrastructure is used.  3 is least preferred, as the final production hardware does not get tested until the shakedown following MTP, increasing the chance that problems are found post-MTP (and therefore less time is available to fix them).  Remember that the MTP process itself uses much of the architecture and can therefore be part of the testing of target infrastructure.

          • 2. Re: HCM upgrade where upgraded copy of production and production is on separate networks



            Thank you for your response, unfortunately option one isn't feasible because development environment is a completely separated from production. Option 3 is out of the question.


            Option 2 is being reviewed as a possibility but there are concerns on introducing possible transaction data from the development into the production enclave.  Are you aware of what the source is being used for in the final move to production pass if most scripts are created in the initial passes and subsequent move to production passes? 


            Is there a way to create a change package from the final move to production system that can be applied to the production system?


            Thank you again for your response.



            • 3. Re: HCM upgrade where upgraded copy of production and production is on separate networks

              The MTP itself is a change package if that helps your discussion at all.


              What specific transaction data are you trying to eliminate?  Having been through a number of MTP processes myself, I can say that transaction data has never been an issue.  What has created (temporary and minor) issues is that some development environments use dummy or obfuscated data.  In one particular case, email addresses had been set to an unmonitored account in development to avoid confusion in the user base when emails are triggered.  As the PS_EMAIL_ADDRESSES table is exported from the source database and imported into the target, this caused problems.


              To overcome this, the client site had taken backup copies of a number of similar tables, from which the data was recovered into the new structure - a ten minute task.  To avoid this issue completely, it is worth familiarising yourself with the data mover tools export and import steps, so you can understand the impact of these.