Hello Steven Well, I have MyHammerQueueView installed, other than that, I don't believe so. Thanks //M On Sun, Feb 5, 2012 at 4:19 PM, Steve Clark wrote:

** On 02/04/2012 08:09 PM, Robinson Mitchell wrote:

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.

-- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark@netwolves.com http://www.netwolves.com

--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Just did the migration using the backup.pl script, so far so good and everything looks great! Anything else missing to be done? :) Thank you all! Thanks //M On Tue, Feb 7, 2012 at 8:47 AM, Michiel Beijen wrote:

Hi Rob,

On Sun, Feb 5, 2012 at 02:09, Robinson Mitchell wrote:

...

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.

This is not the complete story; OTRS keeps all the changes you make via SysConfig in a file called /opt/otrs/Kernel/Config/Files/ZZZAuto.pm. You should also copy this file to the new box if you want to bring over your configuration changes. -- Mike --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs