cancel
Showing results for 
Search instead for 
Did you mean: 

Upgrade project - Keeping deveopments in Sync

Sajid
Participant
0 Kudos

We have just started ECC 6 EhP4 to EhP7 upgrade project. We have EhP4 production support landscape and have setup a parallel EhP7 landscape for the upgrade. In order to sync upgrade development with production changes, we plan to import production transports (EhP4) into upgrade development (EhP7). I have done some research on this and have read notes 1090842, 1688610 and KBA 1742547, all these notes suggests there is no issue if moving a transport from lower to higher version.

I want to ask folks who have done similar upgrades and what approach you followed. How did you keep upgrade development with production changes? If you moved production transports, was there any issues such as objects inconsistencies, data loss, any other technical or logical issues? I just want to make sure we won't run into these issues if we decide to bring EhP4 transports into EhP7 systems.

Thanks

Sajid

Accepted Solutions (0)

Answers (3)

Answers (3)

Sajid
Participant
0 Kudos

Thanks manu. That was a good suggestion that we will look into while planning ahead.

Anyone else want to chime in? I am still looking to hear from folks who have moved transports from EhP4 to EhP7 in parallel landscape scenario.

Sajid

manumohandas82
Active Contributor
0 Kudos

Hi Sajid ,

Unfortunately we have several projects currently going on in production support landscape and freezing the development for longer time is not feasible

  1 )  Do you have   the timelines on when the above will be moved to production ?  ie  what is the plan  to move this projects ( before / after upgrade )? .

     Normally (as you have already  started the projects) have to be go live  before the Upgrade in  production   - Is this your case . - Then you could follow as suggested above .

2 ) Does the project ( which are currently running )   directly depend on the upgrade   , ie  if you are already working on some  functionalities  that already comes as part of your upgrade ( EP7 )  then you are doing double work .Also you SPAU/SPDD changes will be affected .

     If they are not dependent then  whats holding you  ..  You will have a parallel DEV1 system from which you can continue your development on existing      projects

Here i believe you need to make a decision on  what  is on priority . The current projects  which is still in DEV or the upgrade .

Fact : Moving transports b/wn system which are in different versions  could cost you dear so believe don't consider this option especially in  your current situation .

Thanks ,

Manu

Sajid
Participant
0 Kudos

Hi Manu,

The projects I am referring to are smaller improvement projects on existing EhP4 functionalities which will go live before production upgrade. These changes might impact SPAU/SPDD and that's why we want to capture/test them in upgrade landscape. We only have SBX upgraded, DEV1 will be built soon.


Referring to your landscape example, It will take us 4 months to upgrade PRD once we upgrade DEV system. One option is to redo the change in DEV that will be done DEV1, but as I said above it might not be feasible due to the volume of the change and the duration. Hence we are exploring transport option. It seems your were able to completely freeze development during the upgrade? Btw, how long did it take you to upgrade from DEV to PRD?

Thanks for your help so far.

Sajid

manumohandas82
Active Contributor
0 Kudos

Hi Sajid ,

You have posted SBX was upgraded . Was it a copy of the Production system  ( recent copy ) . If it was a recent production copy  you need to track the SPAU/SPDD as this is sure to appear in production .

In our case we did the upgrade in 3 months  ( moved through SBX ,DEV , QAS , PRE- PROD and prod - didnt have a parallel landscape ) but was not constrained by on going activity .


Best option for you is to do a restore   to DEV1 ( from  DEV )  and start the work on SPAU , SPDD  ( of SBX here )  and  continue the work from here  . Those changes which can be ok to move to PROD by the time you upgrade  your PRE-PROD system can go through , the rest have to wait until the upgrade is complete on PROD .


We completely freezed the changes by the time  the upgrade reached our pre-prod system . The last one month we had to wait  . No new transports were allowed into the upgraded preprod ( other than the SPAU/SPDD and other upgade related fixes ) .


The idea around these at this point is to make sure that the pre- prod ( may be in ur case QAS ) upgrade is as close to the production upgrade. Here other projects have to wait  as the importance was given to business continuity .


In your case you should plan in such a way that the business at no cost is affected even if other pjts have to wait or work needs to be re-done.


Thanks ,

Manu

manumohandas82
Active Contributor
0 Kudos

Hi Sajid ,

In your post you say that you have a parallel EHP7 landscape  . Dont you have a development system for this parallel landscape .

The idea is PRD , QAS , DEV ,SBX

     parallel : DEV1,QAS1,

DEV1 copied from DEV

QAS1 copied from  QAS /PRD

You start with upgrading SBX, and then DEV,QAS,PRD in that order .

DEV1,QAS1 will remain in EHP4 until you upgrade the production .

Once your DEV system is upgraded to EHP7   Your transports should be freezed from that point and  any new / emergency correction should follow the route DEV1- > QAS1->PRD .

DEV->QAS  should be used as to fix any issues in EHP7 / requirements thereafter  that needs to be moved once PRD is upgraded to EHP7

Once PRD is upgraded  you should follow  or revert to DEV-QAS-PRD route  . you can then upgrade DEV1 and QAS1 to EHP7.

As far as i know it is not recommended to move transports between systems which are in different  Version /SP level .

Thanks ,

Manu

Sajid
Participant
0 Kudos

Hi Manu,

I understand your approach. We are still in SBX and will be building and refreshing upgrade development in coming days. Unfortunately we have several projects currently going on in production support landscape and freezing the development for longer time is not feasible.

Any other ideas?

Sajid