Retrofit in solman 7.2 for Project Dev to Maintenance Dev system

[neha_singh18]

Hi Experts,

We have one maintenance landscape D21>R21>P21 and Project landscape D25>R25>V25 where V25 is staging system. Changes are being done in D25 and the team wants to do retrofit from D25 to D21.Is this possible through ChaRM?

Thanks

Neha Singh

[former_member664717 · Accepted solution]

Hello Neha,

Below are my Inputs:

1. Logically and Technically I can't think of any issues as to why the setup as such shouldn't work end of the day its only RFC's [*cwdadm* & *Retro* ] & System which you define as a Retrofit system based on your requirements in chaRM Cycle Definition.
2. However, the point which is not clear to me is how the changes are being made on D25, because the retrofit will only be possible from [D25-->D21] once you Release those transports [we can't retrofit with TOC]. I assume that's not frequent in the Development project at least until UAT, therefore until UAT of the D25 Project changes your D21 will be out of SYNC. ()
3. Another aspect is since D25 is your development project and changes are not tested properly you dnt want to RIsk your live landscape D21 by bringing those changes.
   
   as you have not shared any reasoning of your Project team behind this thought I suggest if its not a critical point, you may Import all D25 transports to D21 once UAT is signed -off on R25 system, this will save your efforts of resolving issues on D21 and also only tested and approved changes could be imported.
   I have been working with Retrofit scenario if you find my input helpful, there are a few more points that I am happy to discuss further if you like.
   
   Thanks
   Prakash

[neha_singh18 · Accepted solution]

Hi Prakash,

Yes, the changes will be moved to D21 only after UAT in V25 system.So to configure retrofit here , we need to maintain Project systems in maintenance branch and maintenance system in development branch in LCG.Please let me know if my understanding is correct here.

D21>R21 in Dev branch (Which is actual Maintenance landscape)

D25>R25 in Maint branch (Which is actual Project landscape)

Prod will be P21

Thanks

Neha Singh

[former_member664717 · Accepted solution]

Hi Neha,

Technically, I d'nt see any problem with what you want to set up as explained by you above, however, I personally will not do that because logically Still the Dev Landscape is [D25-->R25-->V25] and Maint. is [D21-->R21-->P21]. Therefore if you also have plans to utilize other Solman capabilities like Test suite and Soldoc the branches and systems assigned play a crucial role and in that case it will be wrong if we go with the below.
D21>R21 in Dev branch (Which is actual Maintenance landscape)

D25>R25 in Maint branch (Which is actual Project landscape)
To the level, I have to understand you shouldn't face any issues assigning D21 as Retrofit System for Dev Landscape [D25-->R25-->V25] Change cycle.
however since the whole scenario is pretty uncommon I will be open to any surprises, also please confirm on my below understanding:

1. V25 is a virtual system and there is only one prod P21, the future landscape looks as below.
   

- I do have a couple of more suggestions I am sure you have touched upon those anyways,

- during the project phase please get clarity on S4 Upgrade Plans [if there are any] because that will heavily change the retrofit setup and how it behaves eventually. Because Retrofitting from D25 to D21 will not be supported technically if D25 is on a higher version [and vice versa is possible though].
-Since you plan to Retrofit Changes in Mass after UAT for the whole dev project, this will be a very high effort for streams and it may have certain efficiency challenges.
-Retrofit is pretty smooth for Auto and Semi Auto change types but often it doesn't logically explain the Manual changes and with the number of the whole projects transports you may have a lot of manual changes which to me appears very challenging to execute.

- Retrofit via solman is a Continuous process and that's why it's suggested by Maint. to Dev landscape generally because in Maint landscape we only have Small enhancements/bug fixes which are lesser in the effort.

Please ignore if any of the points are repetitive for you, just wanted to complete the loop.

will be happy to share further ..

Prakash Singh

[alwe_festo]

Hello nehasingh89,

Alternatively to the dual-landscape-retrofit, you may probably also want to look into the Focused Build function "Cross-Landscape-Distribution" (XLD).
It can be used stand-alone without the Focused Build process and provides a very similar functionality.
My users prefer it from retrofit because it's better integrated in the ChaRM document UI.

Best

Alex

[VigneshPrabhu99]

Hello nehasingh89

Yes, it is possible to retrofit the changes from D25 to D21.

Check our blog by Irfan, where he has clearly explained about Dual landscape maintenance

A Glimpse at Dual-landscape maintenance | SAP Blogs

[Part-2] A Glimpse at Dual-landscape maintenance | SAP Blogs

Other links for your reference,

Standalone Retrofit SAP Solution Manager 7.2 – Configuration | SAP Blogs

Standalone Retrofit on SAP Solution Manager 7.2 | SAP Blogs

Do mark if my answer is helpful / correct for your use case.

Thanks,

Vignesh

[neha_singh18]

Hi Vignesh,

Thanks for responding.I am aware about Retrofit concept but my doubt is if we can retrofit from Project dev system to Maintenance dev system.

Is it supported by Solman and is it appropriate way because I assume this is not the best practice recommended?

Thanks

Neha Singh

[VigneshPrabhu99]

Hello Neha,

To be very frank, there isn't anything defined as Best Practice approach in Retrofit.

We all have seen customers retrofitting from maintenance landscape to their development landscape. However, it is fesaible to do the vice-versa as well.

If your customer requirement is to move TRs from Project Dev to maintenance Dev and if it is how their process exists, then there is no harm in setting up Retrofit strategy in this manner.

Strategy Considerations for Enhanced Retrofit | SAP Blogs

Thanks,

Vignesh