Skip to Content
Author's profile photo Matt Fraser

Migration of Transport Host

When we first install a new ABAP system, one of the parameters required is the name of the transport host. The installation tool defaults to the host on which we are installing, and if this is the first system in the landscape, this is often the choice we make. As frequently the first system installed is the development, or DEV, system, it’s very common for DEV to become the central transport host as well as the transport domain controller (setup almost immediately after installation when we first configure STMS, and not to be confused with a Windows Active Directory domain controller).


This is all well and good, but fast forward a few (or maybe quite a few) years, and inevitably the day arrives when we would like to migrate our systems onto shiny new hardware. The System Copy guide documents the process of moving our ABAP system quite well, but it doesn’t go into much (or any) detail about moving our Transport Domain Controller, nor does it talk about moving our transport host.


The example below assumes a Windows host, but the procedure should be easily adaptable to other operating systems.


What is a Central Transport Host?

Put simply, this is the location of \usr\sap\trans. If, during installation, we specify the current host (i.e., the one on which we are running the installer) as the transport host, then the installer will create the trans folder and its various subfolders, along with the rest of the folder structure required for the installation. If we specify a different host, then the installer will not create the trans folder, but instead will (or might) create a system parameter that points to the other host.


\usr\sap\trans is the folder containing all of our exported (released) transport requests, configuration information for our transport domain (or landscape), logs of transport request exports and imports, and by default the EPS Inbox which is used by SPAM and SAINT for support packs, add-ons, etc.


In a typical scenario, each transport domain will have just one \usr\sap\trans folder, and all the systems in that domain will use that same central folder.


Setting up the New Transport Host

Having determined that we need to migrate the transport host, the first decision is where to put it. It does not actually have to be on an SAP system. It could, for instance, be in a shared network location accessible by all the SAP systems in the transport domain. Or, it could move with the DEV system to the new DEV host. This decision depends upon our needs, and there is no right or wrong answer for all scenarios.


Either way, I recommend migrating the transport host before migrating the DEV system (or whichever system in the domain we are migrating first). This will simplify things later, as then we generally only need specify the hostname of the new transport host during installation with SWPM of each new target system.


Create Folder Structure

This part is simple. On the target host, at the root of the selected drive or volume, create an empty folder called \usr, then subfolder \sap and further subfolder \trans.


If we follow general system installation recommendations, then we may install the Solution Manager Diagnostics Agent (SMD or DAA) on the host before installing anything else, and in this case the \usr\sap folder will already exist, and we should use that.


Make sure the drive has plenty of free space, enough to accommodate the files we’re going to move into it, plus headroom for future transports and support packs.


Copy Files and Subfolders

Easy. Simply copy (or move) all of the subfolders and their contents from the source system \usr\sap\trans to the target system \usr\sap\trans. If our source system is not in use at this point (and it really shouldn’t be), then rename the source trans folder to something like trans.bak to ensure that it doesn’t give us a false positive during our testing for success later.


Create sapmnt Share

Share the folder \usr\sap (not \usr\sap\trans) as sapmnt. For now, give Administrators full control and everyone else no access.


Create SAP_LocalAdmin Group

On the target host, create the local group SAP_LocalAdmin, and add the Active Directory global groups SAP_<SID>_GlobalAdmin to it, where <SID> represents the System ID of each SAP system in our transport domain.


Grant SAP_LocalAdmin ‘Full Control’ to both the sapmnt share and the \usr\sap folder (and all subfolders, which should happen by default).


Test that these permissions are correct by logging on to one of the other SAP hosts as <sid>adm and then navigate to \\<new_trans_host>\sapmnt\trans, and create, read, and delete a test file.



Here is where the fun begins. Depending on how long ago we first installed our source SAP system, and how old the installer program (i.e., sapinst) was, we might find any number of locations where pointers to the transport directory exist. We need to find all of them, and in most cases delete them, so that there is only one.


There are essentially three variables or parameters of importance to us: SAPTRANSHOST, DIR_TRANS, and DIR_EPS_ROOT. Each of these could be set (or not) in the default or instance profiles of our SAP systems, or one of them (SAPTRANSHOST) may be set externally, as an environment variable or as a DNS (Domain Name System) alias.


DIR_EPS_ROOT defines the location of the EPS Inbox and other structures for SPAM and SAINT, and if not explicitly set it will be derived as \\<SAPTRANSHOST>\sapmnt\trans\EPS. Unless we have intentionally separated the EPS inbox from the transport folders, this parameter should be left unset, i.e. at the default. So, delete it wherever we find it.


Likewise, DIR_TRANS defines the location of the transport folder root, i.e. \usr\sap\trans, for STMS. This one is fairly commonly found set in instance profiles, but could also be in a default profile. If we use a central transport host and we stick to the default folder names, as described here, then there is no need to set this parameter. We should delete it wherever we find it.


Parameter Priority

DIR_TRANS is the parameter that STMS will use to find the transport folders. If both SAPTRANSHOST and DIR_TRANS are set in a profile, DIR_TRANS will take precedence in determination. If DIR_TRANS is not explicitly set, then the system will substitute standard values to calculate it as \\<SAPTRANSHOST>\sapmnt\trans.


Therefore, if we eliminate DIR_TRANS from all profiles, determination rests only upon a correct setting of SAPTRANSHOST. This becomes the key to simplifying our migration.


STMS is going to look first for DIR_TRANS to be explicitly set. If it doesn’t find it, it will substitute as mentioned above using the value of SAPTRANSHOST. It will look first for SAPTRANSHOST in the local system’s Instance Profile, and if not found there, then in the Default Profile. If it doesn’t find it in any profile, it will look for it as an environment variable (for the user SAPService<SID> or <sid>adm) or via the operating system’s hostname resolution.



SAPTRANSHOST may be set as a parameter in the instance profile, the default profile, or as an alias in the hosts file or DNS. At various times installation programs and documentation have defaulted to or recommended different approaches.



If we have only a single transport domain, and we have ready access to manipulate our DNS (Domain Name System) server, then setting an ‘alias’ record in DNS for SAPTRANSHOST to point to the IP address of the central transport host may be the easiest option. This is a task usually managed by network operations staff and not SAP system administration staff, so we won’t go into the procedure here. Also, for that reason, it may be simpler to not rely upon DNS for this parameter.


The other complication associated with setting SAPTRANSHOST in DNS is that we may have more than one transport domain, and possibly also more than one central transport host. This could be the case, for instance, if we have one transport domain for our ECC landscape, and another domain for our SRM landscape, and perhaps another for BW, etc.


Finally, a DNS alias ends up as the lowest priority for determination, as it will be overridden by any of the other methods that could be used.



An alternative to DNS is to maintain the alias in the local hosts file. This was very common with early ABAP (i.e. R/3) systems, so we must definitely check for this and correct it (or potentially eliminate it).


The hosts file is a repository of IP addresses and hostnames maintained in the local server’s filesystem. This is a mechanism for name resolution that predates DNS. In the event of an entry in the hosts file that conflicts with an entry in DNS, the hosts entry will take priority (but only for name resolutions on the local host).


The file is located at C:\Windows\system32\drivers\etc\hosts. It is a simple ASCII text file that can be edited with Notepad.


Look for entries similar to:     SAPTRANSHOST


Obviously, the IP address will likely be different. Here, we have two options. We can edit the line so that the IP address and hostname match our new central transport host, or we can simply delete the line (assuming we have a working DNS system so that the actual hostname will be resolved correctly, but this is usually the case).


If we don’t find such a line, we can insert a new one with the correct information, or we can ignore it and leave it alone. After all, there is another option.


Default Profile

The next place to look is for the SAPTRANSHOST parameter to be set in either the Default or Instance Profile. If it is set as a DNS or HOSTS alias, then it may not be set in the profiles at all. Ideally it should only be set in one place or the other, not both. Currently, SWPM will configure this as a parameter in the Default Profile on installation, so this is the practice I recommend.


It should be set in only one place, so we are going to eliminate any SAPTRANSHOST alias from the hosts file and any parameter for this (or DIR_TRANS) in the Instance Profile, and ensure it is set correctly in the Default Profile.


Environment Variable

There is one other possible place where a misconfigured SAPTRANSHOST variable could cause us grief. It is rare, but we might find it set as an environment variable for the <sid>adm user. If so, we should eliminate it and rely instead on the Default Profile. This will be much easier to manage going forward.



Unfortunately, changing this parameter in the system profiles, or for that matter in the hosts file, requires a restart of the application to take effect. In the case of a change in the hosts file, it also requires a restart of the SAP service (which is a good idea generally, anyway, when restarting the system for profile parameter changes, as some parameters require this as well).


Yes, this means there will be a brief production downtime to get this into effect, so plan ahead.


TP at the OS Level

One possible advantage to setting SAPTRANSHOST as a DNS alias or environment variable could have been for use with the tp command when used outside the ABAP system from the server console’s command prompt. It is rare these days to use tp instead of STMS, but there are occasions that call for it. The proper way to handle this, however, is to set TRANSDIR in the transport domain profile. This is done via STMS.


Logon to the transport domain controller (possibly the DEV system), and go into transaction STMS. Select System Overview, then double-click on the system that is the Controller (there is a small icon next to the System ID for the primary and backup controllers; hover over them with the mouse to see a pop-up text identifying them).


Select the Transport Tool tab. There we should see a parameter called TRANSDIR. If it is not correctly set, change to edit mode and correct it.


It should have the Global flag checked, and the value should be \\<central_transport_host>\sapmnt\trans.


Save changes and select Yes to distribute changes immediately.


Testing and Wrap-up

So, we have exhaustively and methodically ensured that SAPTRANSHOST is correctly set in the Default Profile of all systems in our transport domain, and that both it and DIR_TRANS are not set anywhere else. At this point, everything should be working, but let’s double-check.


While still logged into STMS on the transport controller, back out to the System Overview, highlight all the systems in the list (click on the column header), then one after the other select SAP System… Check… Connection Test, then Transport Directory, then Transport Tool. We should see green checkmarks for all tests, and when we expand the test results we should see that the new transport host is being used.


Now select Display Transport Groups, then Check Transport Groups. If all is correct, we should see a grid of green lights.


Back out two steps and go into Transport Routes. Select Configuration… Check… Transport Routes and then Request Consistency… In All Systems. It’s not really all that time-consuming, so select yes for the warning prompt.


Finally, back out one step and go into Import Overview. Select Refresh. After a bit we should see a green status for each of our systems’ import queues. Drilling into a queue should show any waiting requests, and import histories should be complete with logs.


If any of the above checks yields an error, then we will need to go to the system involved with the error and double-check that we have eliminated and corrected all parameters, variables, and aliases, and that the system has read/write access to the transport folder.

Assigned Tags

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

      Hi Matt,

      ... it's very common for DEV to become the central transport host as well as the transport domain controller...

      I've (almost always) done this, and I always feel guilty when i do. Why ?

      Should the most important part of your TMS / CTS system be on the system that gets the least love, the one that has the worst hardware and the lowest resources and the lowest priority from other support teams ? Or should it be on your Prod system ?

      I know it's yet another thing on the to-do list, but we should really consider migrating the Transport Host off Production. Possibly not during go-live, but soon after.

      It does not actually have to be on an SAP system. It could, for instance, be in a shared network location accessible by all the SAP systems in the transport domain.

      Perhaps even talk to your architects / think about about having a system wide or even company wide transport host and start your next installation right ?


      Author's profile photo Matt Fraser
      Matt Fraser
      Blog Post Author


      Yes! This is some of what I was thinking here, in that consideration of where to house the transport host is almost always an afterthought during installation of the DEV system, and thus pretty much by default the DEV system gets this role. It's not necessarily a problem, but as you say, DEV systems often don't get the love they really do deserve.

      I find it odd that QAS systems are often treated better than DEV systems. After all, DEV has perhaps-not-quite-mission-critical-but-important-nonetheless data that exists nowhere else, i.e. all the version history and so forth, not to mention all the work in progress from developers and configurators alike. QAS, on the other hand -- well, many organizations regularly wipe them out with a refresh from PRD, and so generally they do not contain anything that cannot easily be recreated, except perhaps temporarily during a particular testing push. I suppose it is true that QAS systems often have more people banging on them during a testing cycle, and thus may have a need for a bit more horsepower, but we really don't want to slow down our expensive developers, either.

      Another consideration is that, unless you actually prune out your old transport files on some semblance of a regular basis, your transport folders can eventually, after some years, grow to be quite large. If they grow large enough to fill a drive volume, and that happens to be the \usr\sap in which the DEV (or PRD?) system lives, that can bring the running SAP application to a bit of disgruntlement. So, that is another argument for centralizing the transport host to a dedicated (or at least separate) file server of its own, one that may have more flexibility for that volume size.

      Thanks for your thoughts. As always, you have very good insights.



      Author's profile photo Former Member
      Former Member

      This reminds of a the title of very old rock'n'roll song by the Cars...

      You're Just What I Needed.

      Thank you Matt Fraser. That's two times in two weeks that I have gained invaluable information from you. Coming from a UNIX/Linux environment, and now in a very customized Windows environment, this is "just what I needed" to adapt transport defaults from a newly created sandbox to a centralized fileshare for all the systems that ny client has installed.

      Thanks again!!!


      Stephen Ferracioli

      Author's profile photo Matt Fraser
      Matt Fraser
      Blog Post Author

      You're welcome, Stephen, and thanks for the very nice compliments. Oh, and the earworm, too. You're just what I needed... 😉

      Author's profile photo Shkelzen Hasanaj
      Shkelzen Hasanaj

      Thank you Matt Fraser for the very valuable information you provide in this blog.

      I looked into the documentation of system copy (for Netweaver 04) and unfortunately this part is not covered. I was planning an action which was quite the same as the one you have described, but of course the details are crucial and you explain very clearly taking into consideration everything (I assume and hope so 🙂 ) and that is really helpful.

      Thanks and regards 

      Author's profile photo Matt Fraser
      Matt Fraser
      Blog Post Author

      You're welcome, Shkelzen, and good luck with your migration. I know you to be a careful planner, so I'm sure it will all go well.



      Author's profile photo Christoph Baumann
      Christoph Baumann

      Hi together

      Why should I centralize the Transport Directory? What are advantages? Are there any disadvantages?

      Thank you for sharing your ideas!


      Author's profile photo Matt Fraser
      Matt Fraser
      Blog Post Author

      Hi Christoph,

      Thanks for commenting. The advantages of a centralized transport directory are that you can actually manage your transports with STMS. There aren't any disadvantages to this that I'm aware of. This is pretty much standard practice. In short, there's only upside, no downside to it.

      If you don't do this, you'll be maintaining \usr\sap\trans on each and every ABAP system you have, and to move transports between systems will require manually copying them from one server to the other, and then manually adding them to each import queue. That's a lot of extra, needless, and error-prone work.

      Though perhaps I've misunderstood your question. Do you mean to ask whether there are advantages or disadvantages to moving the \usr\sap\trans folder away from your SAP systems, onto a regular file server? If so, I think it's closer to a wash and really a matter of how you want to manage your landscape. On the disadvantage side, you'll have to go through the steps I outline here to manually configure permissions to the folders, but that's not really a lot of work. On the advantage side, you can offload the storage of all the files for transports away from your application servers, which may make it easier to manage disk space, etc. And, it means that if and when you migrate your SAP systems to new hardware, this is one step you won't have to worry about.