why you should not do transports into production when users are working
of course it depends what is in the transport but its always a good solution to do transports at times with low activity like lunch or evenings
for program-changes, there might occur a DUMP (/NST22) Type LOAD_PROGRAM_LOST, this is nothing critical as the next time when the user calls the program it will be the new version.
For Classes (typical CRM) there might be DUMPS with LOAD_PROGRAM_CLASS_MISMATCH (Users have to re-login into CRM Session again)
for CRM it might be necessary to reset Shared Memory (Webui caching) using /NSHMM see KB http://service.sap.com/sap/support/notes/1870987
most critical are changes in data dictionary structures (tables and structures):
if after a transport into the production system a lot of transaction generate a short dump with ‘LOAD_TYPE_VERSION_MISMATCH’, one of the transported tables/structures/append was used during generation of the new structure which causes a mismatch in dictionary and not matching with the current load of the abap reports.
if this is for example VBAP or BSEG, you might have thousands of dumps in a short time an nobody can work
the table is active in data dictionary and also the new field is corretly transported, its just a load-version that does not match. solution is described in sap note 1567187 – LOAD_TYPE_VERSION_MISMATCH
in the dump you see the table name which causes the problem
first you should just activate this table in se11 again
if this does not help, use program TOUCHTAB, after that all programs using this structure will be generated next time someone calls the report (this takes just a sec, or select ‘direct generation’ for immediate generation – this will take some time
if you have multiple appservers they need to be restarted (you can try with transaction code $sync first)
another common issue with transports into production is, that if a db-index has to be re-generated, the update process is stopped during the generation,
this might be too long for large tables