Skip to Content
Author's profile photo Karin Spiegel

CTS+ or HTA?

You might have noticed that there are now two options to transport SAP HANA objects via ABAP: SAP HANA transport for ABAP and the enhanced Change and Transport System (CTS+).

If you do not know about these options, yet, please refer to the following documentation and presentations:

After having gone through these options, you might now ask yourself: Can I use SAP HANA transport for ABAP to transport my SAP HANA objects via CTS?

The answer is: yes, you can – but you should only do so for a special use case.

At first, please think about your SAP HANA systems. How are they set up?

Do you use SAP HANA systems in a stand-alone set-up? Then you should use CTS+ for transporting your SAP HANA objects (or native transports via SAP HANA application lifecycle management).

Details about these options are provided in here:

Do you use ABAP systems with an SAP HANA database as primary database? Then you should use the SAP HANA transport for ABAP.

But let’s have a closer look at the different types of SAP HANA applications that might exist on your systems:

  • Do you develop SAP HANA applications which are closely related to ABAP development objects or rely on them? Then SAP HANA transport for ABAP is the right choice. You can have the ABAP and SAP HANA objects in one transport request. You can assign the SAP HANA packages to the ABAP package that you already use for your ABAP development. Transaction SCTS_HTA offers both, the synchronization (and, with this, the transport) of complete packages or of individual (changed) objects.
  • Do you develop native SAP HANA applications (using the SAP HANA repository) which do not have any relation to tables or views that exist on the ABAP side, but nevertheless run on the SAP HANA Database of and existing ABAP system? Then you have two options: you can use CTS+ or SAP HANA transport for ABAP. Both options are valid:
    • CTS+ is a good option, if you already work with CTS+ for other applications or come from a single SAP HANA system and now consolidate your systems. The developers working on the SAP HANA applications can continue working in the way they did in the past. They might only have to get used to a new SID. With CTS+, you can use change recording which is part of SAP HANA application lifecycle management. Each developer can work on his changelists.
      From a configuration perspective, you don’t need a separate transport track in transaction STMS. You can re-use the existing ABAP landscape and just add the parameters required for CTS+.
    • HTA is a good option if you started with ABAP development, then you moved on to some SAP HANA for ABAP applications and now you also want to create a native SAP HANA application. You can continue to use the transport mechanisms that you already know: SCTS_HTA for synchronizing the SAP HANA objects, SE09 for managing the transport requests. In this case, there is no need to configure change recording or CTS+. In fact, you should not enable change recording on the SAP HANA side (in SAP HANA application lifecycle management) if you want to use SAP HANA transport for ABAP to transport your modified SAP HANA objects. Keep in mind that with SAP HANA transport for ABAP, you can transport changed objects, but there is no way to find out who changed which object whereas in change recording in HALM, changelists are user-specific. In addition, with SAP HANA transport for ABAP, you always transport the active version of an object that is currently stored in the repository. If you used change recording and HALM, then you would transport the version of the object that is stored in the released changelist.

Decide on the option that suits you best and then stay with it and only use this transport option for your system landscape. Do not use several transport options for one development system. If you have to change the way you transport for one or the other reason, make sure that you do this in a safe way. This means that, if you move away from using change recording in SAP HANA application lifecycle management (HALM), always close all open changelists and transport them (via CTS+ or in native mode – whatever you were using). If you decide to stop using SAP HANA transport for ABAP, make sure that all objects are synchronized. In any case – for any switch of the transport mode – make sure that all transport requests are released and imported into all systems of your landscape.

And what if you decide to switch from CTS+ to HTA?

Follow these steps:

  1. Make sure that all of the systems that belong to the ABAP on HANA system landscape are on NW7.40 Sp11 at least
  2. Clean up your CTS+ imports:
    • Make sure that no-one creates new transport requests any more (by informing people and to be safe on a technical level by setting system specific permissions for this CTS+ landscape so that only the administrators involved in the migration can still work on the transport requests for this landscape)
    • Release or delete all open transport requests in DEV
    • Import all transport requests into all systems of your landscape
  3. Delete the CTS+ configuration
  4. Make sure that the transport landscape for the ABAP systems where you would like to use HTA is set up – there is no additional configuration required for HTA
  5. Make sure that all people involved have the require permissions (mainly for transaction SCTS_HTA as this is a new transaction needed for HTA)
  6. Now you can start using HTA

Consider the following before you switch:

  • Be aware that there is no continued import history. As there will be new SIDs in use, you will have one import history for the CTS+ times and another one for HTA.
  • Old transport requests 8created during CTS+ usage) cannot be imported any more – even if you attach them manually to an import queue or use the same SID because the deploy method used for HTA is different from CTS+

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Santosh Chawala
      Santosh Chawala



      Thanks for this blogpost which we found very useful.


      Scenario we are working on is as follows , and we would like to understand potential options and its implications.


      Currently we have,

      • SAP BW on HANA instance which has HANA DB and ABAP Stack using different SIDs (call it landscape A), This landscape uses SAP HTA for transports
      • SAP Native HANA DB for which we are using CTS+ for transporting/managing changes (call it landscape B)


      We are working on a project to merge both landscapes. Merge option chosen is having a new schemas for landscape B on landscape A.

      Landscape B will not need any ABAP development or synchronizing whereas landscape A will need that.


      What would be the SAP recommended option in this case, is it using CTS+ or HTA or both? Can you help us provide pros and cons for these 3 options?





      Author's profile photo Karin Spiegel
      Karin Spiegel
      Blog Post Author

      Hi Santosh,

      I assume that we talk about SAP HANA repository content (so SAP HANA 1.0) for both landscapes, right? (and not HDI)

      And to make sure that I got the facts correctly: you plan to delete landscape B so that the SIDs of this landscape don't exist any longer, right?

      So about the different options:

      CTS+ only this would mean that you transport ABAP and SAP HANA parts of landscape A in separate transport requests. There is then no option to keep control on dependencies between ABAP and SAP HANA parts. It might happen that activation in SAP HANA does not succeed because of missing dependent objects.
      When using this option, you would need separate transport routes for the HANA parts (be it one for landscape A and one for B or one for both). As the real SIDs are already needed for the BW landscape, this would mean that you have to invent new SIDs for your systems. This is possible, but you should keep in mind that you use SIDs that have nothing to do with the real SID of your systems

      HTA only: this option allows avoiding activation errors if SAP HANA and BW objects are transported together and have dependencies. See here for details: and here

      HTA and CTS+: in this case, you also need to invent SIDs - most probably for the former Landscape B systems. When choosing this option, you have to be very careful when you synchronize objects in HTA. This transaction does not differentiate between objects 'controlled by HTA' or 'controlled by CTS+' or something alike. There is no such mechanism. You can synchronize in principle all objects which are part of the repository. If you accedentially transport an object that should normally transported via CTS+ via HTA, this will cause issues in TMS - see above in the blog where we described that you should always make sure that you really stopped using one transport method before starting to use the next one.

      I personally would go for HTA only

      If you decide to go for any option that involves inventing SIDs, I would not recommend to re-use the SIDs of the former landscape B to avoid any hick-ups and confusion with the old CTS+ transport requests that were created while landscape B was in use for transports.

      Hope this helps
      Kind regards

      Author's profile photo Rahim Kassam
      Rahim Kassam

      Hi Karin Spiegel

      Is there any documentation available on how ChaRM works with HTA, and a configuration guide?



      Author's profile photo Karin Spiegel
      Karin Spiegel
      Blog Post Author

      Hi Rahim,

      there is nothing special to configure to enable ChaRM for HTA. If CTS works for your system landscape and if the systems run on SAP HANA database, you can use HTA. You can find more details / links for HTA in here:

      If you are on newer releases and develop in HDI context,HTA for HDI has to be used for transports. This requires configuration. You can find details and a like to the configuration guide in here But again: there is no special configuration required in ChaRM. As soon as you configured the transport option in general, you can use it with ChaRM

      Kind regards


      Author's profile photo Darshala Gurugowtam
      Darshala Gurugowtam

      Hi Karin,

      Good day!!!

      Currently we are using Native HANA for transports with Change recording disabled.

      We are planning to enable  change recording and switch the transport to CTS using solution manager.

      Here, we already have objects developed in Development and came to know that a base change list for each delivery unit  would be created when we enable change recording and all the objects would be imported into target for the consistency with the first transport requests.

      we don't want to move all the existing changes in the system and we only want to move some specific changes and we are thinking of the below


      We will not transport the base change list and we will create a new delivery unit and assign the required packages to it and will only transport the required changes meaning we will not import or touch the change list-Is this a possible operation?


      we are in plan of deleting the base change list or the  release change lists -Is that possible?


      we will not touch the base change list as we don't need all the changes to move to target now.-can we skip the base change list import and proceed with new delivery unit and change lists with the required packages..


      Could you please provide your suggestion here.




      Author's profile photo Karin Spiegel
      Karin Spiegel
      Blog Post Author

      Hi Gowtam,

      do you know this blog by Yury: ?

      It should provide an understanding on how the transport of changes works.

      You cannot overcome the issue that all objects of a DU are transported when you transport the first changelist that contains an object of a DU that had never been transported before.

      But you could make sure that only relevant objects are transported.For this, you should design your DUs in a suitable way before you switch on Change Recording. This does not mean that you should collect all packages that you plan to change in a certain DU. But rather organize your DUs by applications - so encapsulate functionality that forms a logical (business) entity in one DU.

      With this, I hope that it is possible to make sure that DUs are not that big that the initial import takes that long.

      What would be the benefit of not transporting all changes? How can you make sure that everything will work in the same way on the target system as it did on the source system if you leave out some changes? It sounds to me a bit risky to transport just some changes. This would mean that the coding in development differs from all follow-on systems. Fixing issues will become hard.

      And one last remark: the whole XSC topic is deprecated. Switching to XSA is highly recommended. Please check the following SAP Note for details:

      Hope this helps
      Kind regards

      Author's profile photo Manish Umarwadia
      Manish Umarwadia

      Hi Karin,


      Excellent blog. We have implemented CTS+ without change recording (entire DUs are transported). I was wondering if it's possible to transport more granular objects like packages or views using CTS+. If that's not possible, would HTA be the only option? Can CTS+ and HTA co-exist?

      Author's profile photo Karin Spiegel
      Karin Spiegel
      Blog Post Author



      first of all: CTS+ and HTA cannot coexist for one system landscape as HTA uses the ABAP transport landscape whereas you have to create a separate landscape for CTS+ (see here for details: If you would use both in parallel, you would have two different transport landscapes for one system and two import queues. No-one would be able to follow up un what has been imported where and which state of software is the active one for a system.

      If you use CTS+ with HALM (without change recording), you can only transport full Delivery Units.

      But the decision whether you use CTS+ or HTA is based on how the systems are set up (one system with ABAP or is HANA running on a different system) not on the transport options that are available


      Kind regards