We've just recently completed a similar exercise. We had dev/test sharing one saptrans and prod with its own.
I treated this as two distinct activities - consolidation of the saptrans directory and consolidation of transport domains.
The domain consolidation was really a trivial exercise which involved using STMS to delete systems from one domain controller then running STMS in the managed system to join the new domain.
Consolidation of the saptrans was a little more tricky.
The data, cofiles and log directories were copied from dev to prod WITHOUT OVERWRITING and then the filesystems were remounted so all systems referred to the production version. The tricky bits were:
Data files are created at export time and don't change thereafter so they are easy. Your current process involves a copy from dev/test to prod which produces identical copies in each saptrans. You need to copy from dev/test any data files which belong to transports which have not yet moved to production.
Cofiles contain import instructions and import history. They are created at export time and updated each time you run an import. Again, copying to production in your present process means that anything already in production has a full history in the cofile and copying without replacement adds the information for transports which are not yet in production. It's important NOT to replace cofiles in production with the dev/test copies because you lose the production import history.
Logfiles are of two types: system wide and transport/system specific.
System wide logs (ALOG, SLOG etc) are useful for debugging and for audit but are not operationally critical. If you lose the history in these by not copying them from dev/test to prod saptrans I don't think it's critical (and you can keep the dev/test saptrans for reference if someone objects).
Transport/system specific logs are named uniquely so can be copied. This provides you with a complete history of all activity for each transport so anyone who needs to can find out what they need.
The other directories in the saptrans filesystem are maintained automatically by tp configuration (e.g., STMS). They will not need to be copied since the domain reconfiguration activities will address those. You may need to resave the TMS configuration after copying the saptrans.
I also used this exercise as an opportunity to remove the rubbish from saptrans. Way too many people have had access over time to store scripts, patch files, temporary notes and an unbelievable amount of garbage in this directory. I burned GBs of stuff that didn't belong there.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.