Muhammad:
Because OTRS has almost all of its configuration info in the
database you can simply install OTRS clean on the new system,
create a new database, import the database from the old system
into the new database, then point the new OTRS installation to
the migrated database by entering its name and credentials in
Kernel/Config.pm.
I had to do this when we migrated our system in the Amazon Cloud
from 2.47 to 3.0.11. I took the database from the existing
helpdesk, did a fresh install of 2.47 on a test server in our
office, upgraded the database to 3.0.11, then did a clean
install of 3.0.11 on a new clean AMI Instance (generic Ubuntu).
Once OTRS 3.0.11 was up and running on a new blank install, I
took the database dump from the upgraded instance in the office
(I used PHPMyAdmin to export the database to a .SQL script) and
loaded it into a new database on the new cloud server (I just
used MySQL from the command line to run the database restore
script created by PHPMyAdmin), then edited Kernel/Config.pm to
point this instance of OTRS to the upgraded database. Once that
was done I loaded some additional modules we wanted to use for
our OTRS/ITSM installation.
The main thing that makes this possible is that almost all of
the OTRS customizations are in the database. This explanation
is a bit over-simplified but this method will get you most of
the way to a successful migration, and it's completely
non-destructive to the original instance, so you can continue
running the original instance until you have the new one up and
tested. Stop the web server on the original instance, do a
fresh database dump, restore it into the database on the new
server to get any new changes (tickets, articles, ITSM entities)
that took place since you did the original dump. Don't worry
about my description of upgrading the database if you're going
to the same version as the original. This part would not apply
to your deployment.
Good luck with your migration!
Rob
Had you made any customizations - Like to the output.