Skip to Content

How to Migrate Developed Software Components to a New Release in NWDI

You have set up SAP NetWeaver Development Infrastructure on NW 04 and developed your own software components (SCs). Now some time has passed, and you want to upgrade your landscape to NetWeaver 2004s, which also makes it necessary to move your SCs to a new version.

So how would you do this? First of all, a few remarks on terminology and the technical background:

  • The terms “Release” in NWDI and “Version” in SLD are synonymous. So if you create a software component version 1.0 in SLD, it will appear as Release 1.0 in CMS after the data has been transferred (i.e. after you have performed Update CMS).
  • The Software Component Name in NWDI is labeled Name in SLD. The name with which you see the software component version in SLD maps to the caption of it in NWDI.
  • On the basis of the Software Component Name, NWDI checks whether a software component can be transported via a track connection. The release number is not relevant for this check.

Now back to the task at hand.
You want to migrate your SCs from NW 04 to NW 2004s. The following graphic shows what you need to do.


In detail, you need to do the following:

  1. Create a new version of your developed SCs in SLD with new dependencies. For example, if you have an SC Application version 1.00 depending on DI BUILD TOOL 6.40, create a version 2.00 of Application that depends on DI BUILD TOOL 7.00). Your SC might also require new SC dependencies (EPBC, KM, BASETABLES). See the documentation for the specific applications for details.


    Note that the Software Component Name must not change for version 1.00 and version 2.00. Otherwise, the track connection will prevent the import into the new track. In our example, Application must stay Application and cannot change its name from one version to the next.


  2. Update CMS.
  3. Define a new track in CMS using the newer versions.
  4. Create a track connection of type Transport from the old track to the new track.


    Note that the package type for your software components needs to be set to “Source” or “Source and Archive”. This setting defines that the source code for your developed SCs is packed into the SCA during assembly. Otherwise, you won’t be able to change the sources in the new track. If you don’t want your customers to receive the source code for your SCs, you need to define an additional track with package type “Archive” through which you can route your deliveries, so that the source code is separated from your delivered product.
    (For more information, see in the documentation.)


  5. Assemble your version 1 in the old track and approve it for delivery to the next track.
  6. Transport all sources from your old track to the new track.
  7. Import new 04s/7.00 archives to trigger the rebuild.
You must be Logged on to comment or reply to a post.
  • Hello Guenter,

      Thank you so much for the information. We’re in the process of upgrading our NWDI from NW2004 to NW2004s and I’m wondering what exactly I need to do for those old tracks. However, I do have a question and would appreciate very much if you can help.

      Your blog illustrates what we need to do if we need to upgrade our custom SCs to the NW04s version. What about if we don’t need to upgrade them to 04s, we just want to run them as they are based up 6.40 even in the future. Do we need to do anyting after NWDI upgraded to 04s version.


    • Hi Jian Yang,

      upgrading your NWDI does not affect the configuration of your tracks. If you want to keep your SCs based on 6.40 just leave the tracks as they are.
      Just make sure that the runtime systems you deploy to match to the release of your development.

      Best regards,

      • Hi Günter,

        Do you mean that the runtime systems (if you keep your SCs as they are) must be 04 release?
        What if this isn´t the case? but the runtime systems are also being upgraded to 2004s but we would be satisfied if initially they just kept working with the SCAs from 2004 release.

        Is this possible?


        • Hi Andrés,

          the crucial point are generated sources like Web Dynpros whose runtime behavior is closely knit to the release.

          However, a newer runtime system should be downward compatible so that you can run NW04 SCAs on a NW 2004s runtime system.

          So your plan is possible.


  • Hi Guenter,

    We currently need to move our NWDI development from one environment to another.  I have the new environment setup, the track built etc. Now the developers need to move all their work from the current environment to the new one. 

    Any suggestions on how to do this? 



    • Hi Ron,

      in principle it works the same way as described above:
      Have your developers  check-in and activate all their work, assemble the software components with package type “Source” or “Source and Archive” and bring the SCAs into your new tracks. Either via a track connection or with the “Forward”-function in the Transport Studio. (See also SAP Note 790922 which deals with the topic of relocating the CMS, but also describes the relocation of source code.)

      For the description of how to do a system copy in NWDI see SAP Note 877029, but I think this is not necessary in your case.

      I hope this helps.

      Best regards,

      • Hello again,
        Thanks for your reply.  I’m just not sure how to bring in the SCA “assembly” from the current NWDI system to the new NWDI system.  I didn’t see a “forward” option in the Transport studio of the current NWDI. 

        I was able to create a “test” system in the current NWDI that pointed to the new NWDI system / SDM.  I was then able to transport the assembled SCA to the test system.  But, we are not sure if all the developement is now in the new NWDI or not.

        Also, I manually copied and deployed the assembled SCA file in the new NWDI system using SDM.  But still not sure what how to check the results.  The developers are saying their SC’s are still not showing up in the new NWDI’s track.


        • Hi Ron,

          you can find the “Forward” function in the history view of the Approval tab. (see also Forwarding Software Component Archives.)

          To see the development in the new track you need to
          1. import the SCs into the development system of your test track
          2. download the development configuration of Test_dev to the NetWeaver Developer Studio. There you should see everything that has been developed in the DC structure of your development project.

          I’m not sure what you mean by deploying the SCA in the new NWDI system with SDM. This only means that you now have your software running on the same J2EE Engine where NWDI is running. I don’t know if this is what you desire.
          Deploying with SDM means only bringing compiled software into the respective runtime enviroment. You can check whether your developed features are running but you cannot access the sources there.
          The “design time” environment is the NetWeaver Developer Studio. This is the place where you can check whether all your sources are where they belong.
          Alternatively you can browse the DTR web UI. But this is probably only to see if the content of your SCs is where it belongs.

          I hope my answer gets you going. If not, ask again.


  • Hello,
    is it possible to develop WebDynpros for Java with Netweaver Developer Studio 2004s and yet transport them via a 2004 Netweaver Development Infrastructure to a Netweaver 2004s server ?

    Uwe Hauck

    • Hello Mr. Hauck,

      yes, it is possible.
      All you need to do is set up a track for your NW 2004s development in the NW 04 Development Infrastructure and attach the NW 2004s runtime system(s) to it.

      Best regards,

      • Hello Mr. Schiele,

        we have a similar situation; we want to develop for WebAS 7.0 and CE 7.1.
        We have one NWDI 7.0 SP15.

        Do we have to upgrade our NWDI to 7.1? Is the development described above possible with one NWDI server?

        Thanks in advance.

        Best regards,

        • Hello Mr. Zeilmayr,

          you don’t have to upgrade your NWDI to 7.1.
          NWDI can manage release-spanning development because the release specific configuration is contained in the track.

          In your case you need to set up one track for the WebAS 7.0 development and a second one for the CE 7.1 development.

          Best regards,

  • Hi,

    I just want to clarify, whether your method will work in my following scenario:

    “I have two servers.
    One is the DTR/SLD/CMS/CBS working on NW2004.
    The other is the DTR/SLD/CMS/CBS working on NW2004s ie NW 7.0 SP11

    I have tracks on both the DTRs

    I need to transport the SC & DCs created on the track on NW2004, to the new track on NW2004s(NW7.0).

    This way i can have two SLDs, both working independant of each other, so my developemnt can continue in two NW versions, allowing me more flexibility in marketing my product.”

    The suggestion you gave to Ron, will that work?

    If not, then can you please guide me to the steps i need to take??

    • Hi Honaz,

      as far as I understand your landscape, the description for Ron should also work in your case.

      What is not quite clear to me is the fact that you want to run two NWDIs in parallel. Is that because of the two SLDs? Then your landscape is correct.
      Just for the development of different releases, one NWDI would do.

      Best regards,

      • Hi Guenter,

        I’ll rephrase my Question:
        I have one track on a NW04 server(lets call it server ABC).
        I have one track on a NW7.0 server(lets call it server PQR).
        I want to do the migration of my projects from the track on ABC, to the track on PQR, USING TRACK-CONNECTIONS.
        I have managed to do it, by manually exporting-importing the SCA.
        But i want to know if this kind of migration, from one server to another, is possible through “track-connections”.

        If so, can you please provide details for the same.

        Thanks & Regards,

        • Hi Hanoz,

          unfortunately you cannot migrate between two CMS-servers with track connections.

          This is a technical restriction that prevents track connections over CMS-Domain borders.

          SAP Note 790922 gives a detailed description how you can move you projects from one NWDI server to another.
          If you still have questions, don’t hesitate to ask.

          Best regards,

  • Guenter

    We have our developments on JDI 6.4, This need to be migrated to 7.1 CE.
    1. Is it possible to directly migrate to 7.1 or first to migrate to NWDI 7.0 & then to 7.1 ? We found procedures to migrate from 7.0 to 7.1 but nothing for 6.4 to 7.1
    Can you help us identify the exact procedure to follow ?

    • Hi Vivek,

      do you want to migrate your applications developed in NWDI 6.4 or do you want to migrate the infrastructure to 7.1?

      If you want to migrate your applications then I think the description above should fit your needs.
      However, think about whether you want to migrate in two steps going first to 7.0 and then to 7.1 or whether you want to do everything in one shot.

      Remember that 7.1 is running on JEE 5 which probably will result in significant adaption efforts in your software.

      I hope this helps. If you have additional questions let me know.


      • Günter

        Thanks for the reply.

        We tried doing the steps explained in your blog.
        We created the new track in NWDI 7.0 with Same Product, Software Components & different version & required new dependancies.

        Now, in order to bring the applications developed in JDI 6.40, we are trying to create the track connection between NWDI 7.0 & JDI 6.4.

        Our JDI & NWDI are on different systems. Now we are not able to see the NWDI track in JDI’s track connection tab while trying to create the track connection.

        Please tell if we have missed something

        • Hi,

          so you have set up two infrastructures (JDI 6.40 and NWDI 7.00).
          This was not necessary. You could have created the new track in the JDI 6.40 then it would have been visible for the track connections. The description above is tailored to work inside only one JDI/NWDI. It is the tracks that contain the release information…

          Nevertheless, back to your question. You cannot see the new track because JDI 6.40 and NWDI 7.00 have distinct domains which do not know each other. You cannot create track connections between two domains this is not supported.
          In order to bring the content from JDI 6.40 to NWDI 7.00 you need to copy the assembly results in the 6.40 transport directory to the inbox of the 7.00 transport directory.
          Then you can check-in the content into the new track.

          I hope this answers your questions.

          Best regards,

  • Hello Guenter,

    We are planning to migrate our old NWDI ( NW640) env to NW700.
    At the moment the components of our old NWDI are on different systems. SLD ( xi production) CMS DTR ( xi DEV ) CBS ( MDM dev).
    And in our new env we are going to install 3 NW7 systems 2 for SLD and 1 for ( CBS DTR and CMS). We have read the note you mentioned about JDI move 790922. But there is nothing mentioned about moving CBS and DTR. Is there a way of doing this? And what is the best way of approach.

    Kind regards,
    Chris Grauls

    • Hi Chris,

      I think the answer is not as difficult as you think.

      You set up your new NWDI on the new NW 7.0 system and move your software components as described in the note and blog above.
      The relevant data of your development is stored in the DTR and it will be imported into the new DTR once you have setup your tracks again in the new environment and imported it there.
      What you need to think about though is which of the two SLDs you are using is used in the CMS domain, since NWDI can only work with one SLD.

      An SAP Notes which might also be of help is 877029.

      I hope this answers your questions.

      Best regards,

  • Hello Guenter,

    Thanks for the blog.
    We have a EP 6.0 landscape and a EP 7.0 landscape. We have JDI to support the EP 6.0 landcape and NWDI 7.0 to support the EP 7.0 landscape. We are planning on upgrading hte EP 6.0 landscape to EP 7.0. The code that we have developed on the JDI has to be moved to the NWDI 7.0 environment. From your blog, I have gathered that I cannot do a trnasport connection from the JDI to the NWDI 7.0 because of the CMS level restrictions.

    What is the best way to proceed to move the code?
    We are using XSS on the EP 6.0 environment and we have customized the code heavily. In the end, We want to make sure we have all the custom code embedded into the new XSS ( I believe 600 version).

    Please let me know.


    • Hi Venu,
      sorry for the late reply, but vacation time has created some backlog in my work. Here’s the answer to your question.

      The easiest way to bring your content from JDI 6.30 to NWDI 7.00 is to assemble your components with sources in the old JDI and check-in the SCAs in the new NWDI track.
      The major drawback of this solution is that you cut the version history in the DTR from the sources during the assembly step. So in the new track the sources will have no version history anymore.

      With NWDI 7.00 SP 13 you have the possibility of a workspace replicaton in DTR (see SAP documentation Replicating a Track into a Different DTR Repository).
      Please keep in mind that this just replicates the track content. You cannot update the track content from 6.40 to 7.00 with this step. However, you have moved the complete DTR workspace with version history to the 7.00 DTR and work from there.

      I hope this helps in your task.

      Best regards,

  • Hi,
    I have NWDI 2004s 14 running and we have some custom webdunpro and portal applications developed using tarck and Businesspackages customization of ESS/MSS and WFM also. Now I want to upgrade the SP pack to 16 on all systems like all runtime systems and SLD and for NWDI also. My custom developments and BP enhancements are in progress. At this point can I directly apply the SP16 and import the new depnedenices or should I do anything else.
    I am not upgrading any businesspackges that are under mdodification process.
    Pls suggest me how to progress.
    • Hi Ravindra,

      sorry that this reply comes quite late, but the last time was quite busy for me.

      As I understand your request, you want to update the runtime systems for NWDI and SLD from SP 14 to SP 16. The software components that you are developing are not affected, correct?

      In this case I don’t see any technical restrictions that prevent you from moving from SP 14 to 16. The update will not change the NWDI content to my knowledge. There shouldn’t even be new dependencies in the setup of your tracks since you stay within the same release.

      So from my point of view, you are set to go.

      Best regards,

  • Hi,
    I have a scenario where we have a SC (XYZ) we developed for internal portal. Now we created another SC (eXYZ)& track for external portal. We would like to move the code from XYZ’s track to eXYZ’s track. But due to the pre-condition you mentioned (app names have to be the same), I am unable to do this. How do I get around this problem and start development of eXYZ with code from XYZ as my starting point. Appreciate your help.


    • Hi Bhaskar,

      as you rightfully remarked you cannot simply transport content from one SC into another. CMS prevents this to guarantee the consistency of software components on the runtime system.

      However, if you need to refactor code from one SC into another – as it is in your case – there is the possibility to move Development Components (DCs) from the workspace of the old SC to the workspace of your new SC.
      You find the detailed description how to do this in SAP Note 888969.

      I hope this helps in your task.

      Best regards, Günter

      • Thanks Gunter. I was thinking of using activity integration as a workaround but didnt realize we have a SAP note for it. The DC I was talking about was a CAF DC, containing auto-generated child DCs within it.

        But the issue I still see with this approach is the name prefix used. I would like to use a new name prefix (like exyz created for SC eXYZ) rather than the original name prefix. Does this mean I have to do the following
          – Manually create a name prefix in the NameServer
          – Create a folder structure with the desired name prefix in the new target SC workspace.
          – Name the dcref file appropriately (containing the new name-prefix in its filename)
          – Update the prefix info in all the relevant xml config files under META-INFO

        The above could be done for a simple DC, but still for a complicated on like a CAF DC, I am not sure where all I have to make these name-prefix updates and what problems it could result in.
        Appreciate your feedback/solution.


        • Hi Bashkar,

          unfortunately, DTR does not support the move of resources from one namespace to another because this changes the filestructure itself.

          The suggestion from development is to create the files again under the new namespace with a new name.
          So I’m sorry that I cannot give you a concrete solution for your scenario. And I cannot give you an answer whether the actions you describe will work. Sorry.

          Best regards,

  • Hello Gunter,

       Thank you for your weblogs. They are very informative. I have few questions regarding our landscape here. We have different kinds of developments going on here (Webdynpro development, Visual composer etc). We had NWDI running on 6.40 earlier and now we have completed the upgrade to the NWDI on 7.0. We now need to move all the SCs to the new environment. Before that, I want to get your suggestion in creating tracks for our requirement here. Could you please let me know, if it is required to have separate tracks for different type of developments – meaning one track for Visual composer, one track for Webdynpro development etc?

    could you please provide us your recommendations on this?


    • Hi Sunitha,

      the number of tracks depends on the number of releases you want to develop in. If you develop all your things for one release (e.g. 7.0) then one track should be enough. The crucial question then is rather how you shape your SCs within the track for later shipment.

      In principle that’s it.
      Only if you want to – let’s say Web Dynpro – for 6.40 and Visual Composer for 7.00 then you would have to set up two tracks. One for WD with the build plug-ins for 6.40 and one for Visual Composer with the build plug-ins for 7.00.

      Another consideration could be that you want to keep different developments in different DTR workspaces. This would also require more tracks then. But I think, I’m now starting to do guess-work.

      I hope that my answer contains what you need to know.

      Best regards,

  • Hi Guenter,

    Thank you for your weblogs. Could you please help me with the track creation?
    In our landscape here, we have two phases of development going on. In one phase, We have the following systems:
    DP1, EPQ, EPV (Dress rehearsal), EPR (for PVS testing), EP2 (Training system).
    In our other phase of development, we have the following systems: EPD, EPS(our Q system for this phase).
    Our Production system is EPP which will get the feed from our dress rehearsal system (EPV) and from the EPS (Q system of the second phase).
    There is another training system EPN that gets the feed from the prod system EPP. EPN does not feed any other system in the landscape.

    Could you please suggest the tracks for these systems? We are doing Webdynpro development and some Visual composer development.

    Thanks much for your help!

  • Hello Guenter,

    i followed your guide and migrated already two SCs from 6.40 to 7.00.

    Unfortunatly i have trouble in Assembly step in new version. Only the options:

    Keep Current Support Package Number
    Keep Current Patch Level

    are left. It`s not possible to increase anymore.

    Any ideas how to solve this?

    Regards Oliver

    • Hi Oliver,

      sorry for the late reply but here is your answer:

      As of NWDI 7.00 SP 13 the setting of consistent SP levels is the responsibility of the Domain owner if the track name changes. That means that you can set the SP level as long as you are in the same domain with the new track as with the old one.

      Before NWDI 7.00 SP 13 this is not possible.
      In that case you need to apply SAP Note 973346 section 2.

      Best regards,

  • HI,

    I want to develop a new version of the software component which has been developed already. Is it possible to change the  version of Software Component using the same software component .Or do i have to create a new software component with the enhanced version and then copy the dcs of our initial software component in to the new software component

  • Hello Guenter,

    Thank you so much for the information. We’re planning to set up NWDI for our ESS/MSS Customization  we have 3 system in our Landscape Dev,Test or Prod and we are planning to use Dev as NWDI System also.

    Actually my concern is that we have Dev in 7.00 Version and Test and Prod in 7.02 Version ,so i want  to know we have to create 2 tracks( 1 for Dev  and 2nd for Test and Production for tranporting Dev sca after cutomization from track1) or 1 track is enough means the S/W Componet(buildt,jee,jtechs) used in track creation are diffrent for 7.0 or 7.02 or they are same.