Please make sure there are no more running services or cron jobs that try to access OTRS. This will depend on your service configuration, here is an example:

shell> /etc/init.d/cron stop
shell> /etc/init.d/postfix stop
shell> /etc/init.d/apache stop
            

Stop OTRS cron jobs and the scheduler or daemon (in this order) depending on the OTRS version you are updating from:

shell> cd /opt/otrs/
shell> bin/Cron.sh stop
shell> bin/otrs.Scheduler.pl -a stop
            

or

shell> cd /opt/otrs/
shell> bin/Cron.sh stop
shell> bin/otrs.Daemon.pl stop
            

Verify that all needed Perl modules are installed on your system and install any modules that might be missing.

shell> /opt/otrs/bin/otrs.CheckModules.pl
        

Please run (as user otrs, not as root):

shell> cd /opt/otrs/
shell> bin/otrs.Console.pl Maint::Config::Rebuild
shell> bin/otrs.Console.pl Maint::Cache::Delete
        

e. g. (depends on used services):

shell> /etc/init.d/apache start
shell> /etc/init.d/postfix start
shell> /etc/init.d/cron start
        

Now you can log into your system.

The following packages are automatically uninstalled after the upgrade process (if they where installed before):

From OTRS 5 on, every frontend server needs to have its own unique NodeID. This defaults to 1 and thus does not need to be configured for single-frontend setups. If you have more than one machine, each machine needs to have this value set to a unique value between 1 and 999. This configuration needs to be done in the file Kernel/Config.pm:

$Self->{'NodeID'} =  '2';   # assign a unique value for every frontend server
            

The follow-up detection settings were reorganized. Now OTRS searches by default in email subject and references to detect follow-ups. Please check in AdminSysConfig Ticket -> Core::PostMaster if you need to make any changes to the follow-up detection configuration (for example to search in body, attachments or raw email content).

The new OTRS daemon is responsible for handling any asynchronous and recurring tasks in OTRS. What has been in cron file definitions previously is now handled by the OTRS daemon, which is now required to operate OTRS. The daemon also handles all GenericAgent jobs and must be started from the otrs user.

shell> /opt/otrs/bin/otrs.Daemon.pl start
            

There are two default OTRS cron files in /opt/otrs/var/cron/*.dist, and their purpose is to make sure that the OTRS Daemon is running. They need to be activated by copying them without the ".dist" filename extension.

shell> cd /opt/otrs/var/cron
shell> for foo in *.dist; do cp $foo `basename $foo .dist`; done
            

To schedule these cron jobs on your system, you can use the script Cron.sh with the otrs user.

shell> /opt/otrs/bin/Cron.sh start
            

Please note that if you had any custom cron jobs, you should consider moving them to SysConfig (Daemon -> Daemon::SchedulerCronTaskManager::Task) to have them executed by the OTRS daemon as well. You might also need to adapt your custom scripts, because now most OTRS commands are managed by bin/otrs.Console.pl instead of single scripts.

With OTRS 5 ticket notifications are configured differently than in previous versions. They are now part of the "Event Notifications" that were previously available as well (now called just "Ticket Notifications"). Your existing ticket notifications have been migrated into the list of ticket notifications, but deactivated. You have also received the new default ticket notifications, active by default.

In case you did not modify the old ticket notifications you don't have to do anything. If you have made local modifications or translations, you have two choices: a) you can migrate your modifications to the new ticket notifications (recommended) or b) you can deactivate the new notifications and activate the old notifications again.

Please also review the escalation notification recipient settings and see if they match with your expectations (agents who have the ticket in one of their custom queues vs. all agents with read permissions). This was configured via a setting in the file Kernel/Config/GenericAgent.pm (now obsolete) previously and can now be controlled via the GUI for each notification separately.

If the system is already registered with OTRS Group, it is strongly recommended to update the registration information at this time. This will update the registered version of the system (among other changes) in the OTRS Group records, in order to get much accurate information from the cloud services.

If you don't update the registration information manually, it will be done automatically on a regular basis, but this could happen some hours or days after. During this period it might be possible to get wrong information from cloud services like OTRS Business Solution™ updates.

shell> cd /opt/otrs/
shell> bin/otrs.Console.pl Maint::Registration::UpdateSend --force
shell> bin/otrs.Console.pl Maint::Cache::Delete
            

This is only relevant if you had any custom GenericAgent jobs in Perl OTRS 4 configuration files such as Kernel/Config/GenericAgent.pm that cannot be handled with the regular ticket notifications. Such jobs now need to be registered as OTRS Daemon cron tasks in the SysConfig (Daemon -> Daemon::SchedulerCronTaskManager::Task), in order to be executed on a regular basis.

There are 5 settings in the SysConfig prepared for this purpose (Daemon::SchedulerCronTaskManager::Task###GenericAgentFile1 to Daemon::SchedulerCronTaskManager::Task###GenericAgentFile5). If more settings are needed they can be added in a custom SysConfig setting file.

Please replace "<ModuleName>" with the file that contains the custom GenericAgent jobs configuration, e.g. Kernel::Config::GenericAgent for the file: Kernel/Config/GenericAgent.pm, set the schedule to match the periodicity as it was executed before, mark the setting as active and save the changes.

shell> bin/otrs.Console.pl Maint::GenericAgent::Run --help
            

All regular OTRS command line operations now happen via the OTRS Console interface bin/otrs.Console.pl. This provides an auto completion for the bash shell which makes finding the right command and options much easier.

You can activate the bash autocompletion by installing the package bash-completion. It will automatically detect and load the file /opt/otrs/.bash_completion for the otrs user.

After restarting your shell, you can just type bin/otrs.Console.pl followed by TAB, and it will list all available commands. If you type a few characters of the command name, TAB will show all matching commands. After typing a complete command, all possible options and arguments will be shown by pressing TAB.

Some ticket action screens like "Note" had default subjects in OTRS 4 (configurable via SysConfig, Ticket::Frontend::AgentTicketNote###Subject in this case). These default subjects have been removed to reduce the amount of potentially redundant/meaningless data. You might want to re-add them if they are mandatory for you.

Because of a bugfix in OTRS 5s, configuration names for a few ticket event modules had to be changed. Any possible customizations need to be re-applied. Please review your settings in SysConfig -> Ticket -> Core::Ticket and check all settings that start with Ticket::EventModulePost to see if your custiomizations have to be re-applied. This could be the case if you had activated and configured the event handler to save customer data in ticket dynamic fields, for example.