Skip to Content
Author's profile photo Hema Suryapalam

Release Management in SAP Solution Manager 7.2 — Part 3

Release management is the process of managing, planning, scheduling and controlling a software build through testing and deploying in the production environment.

Release & Deployment Management is responsible to manage successful deployment of all related changes into a productive environment

Release Management defines dates and schedule for Releases

Release content determined by Projects and Work Packages or Requests for Changes and related Work Items or Change Documents

Release Cycle  acts as technical container and model for the release content

Types of Releases:

a. Major Releases:

Major Releases are typically big releases which contain big changes to the solution. This includes changes to the user interface, new business processes or renovated processes. Often major releases also contain technical upgrades to newer support packages or software versions. The frequency of major releases is typically between 1 and 4 per year.

b. Minor Releases:

Minor Releases are usually processed in parallel to Major Releases. Minor Release contain smaller enhancements and features, which only have a smaller impact to the end-user. Typically no drastic UI changes or major changes of business processes. The frequency of minor releases is much higher compared to major releases. Mostly per major release several minor release will be deployed in between.


Release Management helps in easier planning and more flexibility in planning change execution. It also aids in –

  • Better Risk mitigation through extensive testing possibilities.
  • Less risk for downgrades or over taker situations.
  • Stable test system environment due to central release schedule.
  • Increased productivity due to increased standardization along the entire process.
  • Better tracing and tracking of implementation activities (also post go-live).
  • Possibility for controlled handover and maintenance processes

Whenever something shall be deployed into the productive environment, it will be handled via a Release. The release content consists of all developments  during the Build Phase, that have been created as part of the same release. The release has many different phases which all have a defined process. The phases of the release also control which activities are possible during that phase related to the release e.g. assignment to a release, development, testing, import of transports, deployment to production etc..

1. Scope: In the scope phase, the business requirements that have transitioned to IT Requirements is reviewed.  The Business Manager evaluates the needs of the changing or evolving business to approve business  requirements. Business Process expert will be involved in defining the business requirements. The Requirements Manager is responsible for collecting, effectively processing, and documenting missing information. He or she should have a good understanding of the requirement as well as an overview of its possible technical implementation. For this reason, the requirements manager  is often referred to as the “interface between business and IT.” The requirements manager,  is responsible for managing the requirement, which involves changing the status of a requirement, defining dependencies, or assigning dependencies to a release. The solution architect translates IT requirements created by Requirements Manager into the architecture for that solution.

2. Build: In the build phase, the content of the release will be finally defined. This is the time, when the release manager needs to make a decision about which changes shall take part in the release deployment and which shall be taken out (e.g. postponed to next release).

3. Test: In the test phase, the testing of the release takes place. The content is finalized.This is the final release test, which means the entire package needs to be validated and tested for functional and technical correctness before the import into the Production environment.
Usually this involves a whole series of tests including
–Acceptance Test
–Regression Test
–Integration Test
In case of bugs or issues, a defect correction can be created to fix the errors.

4. Deploy: The deploy phase includes actual technical cutover of the entire release into the production environment.
–This means all transports will be imported into the production environment.
–The activity to trigger the import will be done by a Administrator or Technical Release Manager from within SAP Solution Manager.
–The content of the package will be calculated automatically by SAP Solution Manager and imported in the correct sequence.

5. Hypercare: After the deploy phase there is a special phase called “Hypercare”. This is due to the fact that usually shortly after a go-live, the number of incidents increases significantly. Sometimes this is due to missing information about the new functionality, wrong documentation or bugs which have not been detected and solved before. During this time, there is still a high attention on the release and a consistent monitoring of the incident queue. Usually this phases ends after a few days or weeks –

6. Operate: The release will be formally handed over from the Project Team to the IT Operation Team, which ensure production support.

Now let’s go through the steps in SAP Solution Manager 7.2 to plan, create and assign requirements and changes to a release (Major or Minor) :

1. Planning and Creating Releases and Release Cycle.

A. Open the CRM UI with transaction SM_CRM to access the SAP Solution Manager ITSM. Click on the Change Request Management Tab and then choose “Release Planning”

B. Select “Create” and then address the fields that require input

C. An example is shown below.

D. Create Release Cycle

E. The Release cycle should then be activated

F. After activating the task list, we need to make sure that the transport routes and landscape track is defined correctly

G. The release cycle can now be set in the phase “Build” to start development work

2. Assigning requirements to a release — The business requirements that evolve from the business and translates to IT Requirements can then be assigned to the respective releases (Major or Minor)

3. Assigning Changes to a release — Similarly there are opportunities to assign changes to releases (Major or Minor)

Part 2 of the blog is in the below link

Integration of Requirements Management with SAP Project Management in SAP Solution Manager 7.2 — Part 2



Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo L.K Vinodh
      L.K Vinodh

      Hello Hema,

      Very  Good  blog .  Can  you  please  share solman 7.2    link  which will  be  useful    functional  Consultant  for  Implementation, like  requirement  gathering ,  BBP, Testing  and  Configuration  documents genaration  from  Solaman  7.2.

      Vinodh L K

      Author's profile photo Hema Suryapalam
      Hema Suryapalam
      Blog Post Author


      Hi Vinodh,

      Please check the Solman 7.2 link in SMP.




      Author's profile photo Tom Cenens
      Tom Cenens

      Hi Hema

      I expected something different to a certain extent when SAP announced Release Management coming into CHARM on SAP Solution Manager 7.2. At SolEd 2016 SAP said that the major / minor release concept is for Dual SAP Landscapes. This default to large customers mostly, meaning other customers will resort into only using "minor release". It doesn't really go much further than visualizing the "upcoming releases" and moving them if you move something along the way and there are dependencies.

      Somehow I imagined this scenario would be worked out further and be capable of doing more. Like synchronizing different releases and cross release importing for example from a technical, TMS perspective. That's not there as far as I know, might be on the planning or something but right now it seems very limited in terms of functionality.

      Best regards


      Author's profile photo Hema Suryapalam
      Hema Suryapalam
      Blog Post Author


      Hi Tom,

      Yes cross release dependencies and sequencing can be managed using CSOL and DGP functionalities just like in ChaRM. The major/minor releases can be used for dual landscapes as well. The concept in 7.2 was to provide an umbrella to manage release on top of the existing ChaRM infrastructure.



      Author's profile photo Tom Cenens
      Tom Cenens

      Hi Hema

      Anything on the horizon like cross release import (TMS) from a technical point of view, if both releases are to be delivered at the same time? As far as I know, this is currently still an operation per release, regardless of checks in terms of potential sequencing issues.

      Best regards


      Author's profile photo Former Member
      Former Member

      Hi Hema,


      Thanks for sharing the wonderful knowledge Base. Do you have any end to end document on explaining the solution creation  in 7.2 . if you have any could you please share the link or doc , that would be helpful.




      Author's profile photo Naveen Inuganti
      Naveen Inuganti

      Nice Blog!!


      I have one general and basic question - We have project that is divided into 2 phases. While we finished first phase, we closed "Phase Cycle" created for first phase and created new "Phase Cycle" for second phase. Now, to support production issues (which needs to be resolved and released as soon as possible and retrofit to second phase systems - we have N+1 landscape), should we go for "Phase Cycle" or "Continual Cycle"? And, do we need to create new change cycle for each production defect if we want to deploy change related that defect to production system?




      Author's profile photo Jonny Gil
      Jonny Gil

      Hi Hema,

      Thanks for your nice blog, a question, Release management can be used for Non-SAP Systems? What do you think?

      Thanks in advance and regards,



      Author's profile photo Benjamin Kreuscher
      Benjamin Kreuscher

      Hey Hema,

      thanks for the great blog!

      How can I manage to fill the field Release/cycle via ABAP Coding?

      I have tried several days to fill the field in a request for change...


      Greetings Benjamin

      Author's profile photo K. Lai
      K. Lai


      Is there a way in the Release Planning functionality to change the name of the Release?

      Currently the name is system generated like Major Release X.0 or Minor Release X.1. And you can't edit it afterwards to give it a more understandable name that makes more sense from customer point of view.


      Kim Lai

      Author's profile photo Samikhya Dash
      Samikhya Dash



      We have a requirement to have Release Management with out creating change requests to bundle Transports and Release them till Pre-PRD system till testing phase of Project . We want to create Change Requests at later phase .


      How can we bundle the Transports to Release and deploy from DEV to QAS till Pre-PRD ? We do not have Focus build .

      Is this possible to simulate same like a work package thing or a bucket to bundle TRs to move in lower landscape ?


      With Regards