Migration (3.0 to 4.0) completed. One major and one minor issue left

MAL · Post by **MAL** » 11 Dec 2014, 10:29

Hello everyone.
I will have to perfom a migration from OTRS 3.0.6 to the latest version.
The idea will be to install OTRS (4.x) from scratch on a different machine, but of course we need to have the current content in the new system.
We will also setup a (completely) new database, so that in case of issues during migration we can still use the old OTRS and the old database.

As far as I understood, if we would migrate OTRS itself we would have to go the single steps 3.0->3.1->3.2->3.3 -> 4.x,
but what is the easiest way to bring "just" the database content savely to the new database and the new OTRS version?

Every hint would be appreciated.

jojo · Post by **jojo** » 11 Dec 2014, 11:11

you have to go each single step.

so you need to install

3.1.latest
3.2.latest
3.3.latest
4.0.latest

and perform the SQL and Perl Migration steps as stated in each individual UPGRADING instructions

MAL · Post by **MAL** » 18 Dec 2014, 10:46

Thanks for your reply.
I was hoping that running some (standalone) SQL-scripts would be sufficient so that I can keep the old OTRS installation untouched

Post by **crythias** » 18 Dec 2014, 14:46

You can always migrate on another server.

MAL · Post by **MAL** » 18 Dec 2014, 16:57

That is correct, but I need another server and much more time

The idea was:
1) setup new OTRS version (on new server) (does not really matter how long it takes)
2) stop emailforwarding and shutdown current OTRS
3) clone the database(schema)
4) run migration (SQL)scripts on the (new) database
5) connect the new OTRS to the database and "activate" it (switching URLs)

Step 2) to 4) are tasks that need to be performed in a short time frame (not sure how long the scripts will run actually).
In case of error or it takes longer than expected, we can easily switch back the URLs and use old OTRS and "old" database.

Now I have to:
1) setup new OTRS version (on new server) (does not really matter how long it takes)
2) setup additional server/environment with the same old OTRS version
3) stop emailforwarding and shutdown current OTRS
4) clone the database(schema)
5) connect the second old OTRS to the new schema
6) perform all single OTRS migrations steps + all database scripts
7) disconnect / shutdown the OTRS instance
8 ) connect the actual OTRS instance (from step 1) ) to the database that was just migrated and "activate" it (switching URLs)

step 2) means additional effort and also resources
but especially
step 3) to 7) means much more effort now, is more error prone and so will take much longer

jojo · Post by **jojo** » 18 Dec 2014, 17:03

buy consulting services which will help you on the migration

Post by **crythias** » 18 Dec 2014, 17:32

or you could:

1) copy all of your otrs filesystem to a new folder
2) backup and restore your production database to a duplicate/migration database
3) change config.pm in the migration otrs folder to point to the new data
4) run the upgrade scripts.
5) whatever you need to get the upgrade to the final destination.

Post by **crythias** » 18 Dec 2014, 17:34

or, download virtualbox or something and spin up a linux VM ...

MAL · Post by **MAL** » 18 Dec 2014, 17:46

crythias wrote:or you could:

1) copy all of your otrs filesystem to a new folder
2) backup and restore your production database to a duplicate/migration database
3) change config.pm in the migration otrs folder to point to the new data
4) run the upgrade scripts.
5) whatever you need to get the upgrade to the final destination.

but then I would migrate the OTRS instance which I actually would like to keep as fallback. In addition, we want to get rid of the old installation and think a fresh setup will save us a lot of problems in the future (the current installation is kind of over-configured

)

or, download virtualbox or something and spin up a linux VM ...

That will help with my step 2), but not with 3) to 7)

MAL · Post by **MAL** » 09 Mar 2015, 14:09

So, I finally achieved to migrate the production environment from 3.0 to 4.0 on CentOS 7

This was kind of tricky, since the older OTRS versions could not be installed so easily (centos7 is actually not supported and provides different packages than the installer are expecting).

Issue 1) Major

Correct:
When a customer replies to existing tickets which are new ("created by" otrs 4), all replies are automatically mergerd correctly to the corresponding tickets.

Incorrect:
But when a customer replies to older (existing) tickets ("created by" the older OTRS), every time a new ticket is created.

First I thought the "Ticket::Hook" was wrong, but then also the correct part would not work.

What else could it be? What do miss?

Issue 2) Minor:
The old "freefields" are lost (not appearing anywhere). How can I bring them up again (through the new "dynamic fields") ?

mavrie · Post by **mavrie** » 09 Mar 2015, 14:22

Wait, OTRS 4 does not run on CentOS7?

That could explain the issues I'm seeing.

reneeb · Post by **reneeb** » 09 Mar 2015, 14:44

@MAL: Please check if the SystemID of the old system is the same of your new system...

@mavrie: what makes you think that OTRS doesn't run on CentOS7?

MAL · Post by **MAL** » 09 Mar 2015, 14:49

@mavrie
otrs 4 does,
but otrs 3.0, 3.1 are definetly not designed to work on centos 7

@reneeb
what exactly do you mean?

edit:
Think I found it. Need to change it and test again

reneeb · Post by **reneeb** » 09 Mar 2015, 14:58

When a mail is fetched, OTRS checks if the mail has a reference to a ticket. By default only the subject is checked, but it can be configured that the mail body is checked as well. OTRS searches for something like "Ticket#201503091000016"

The string "Ticket#201503091000016" contains some information:

Ticket# is the Ticket-Hook and can be configured via SysConfig
20150309 is the date
10 the system id (can be configured)
000016 a checksum

This is an example for the DateChecksum ticket number generator.

If the old system had the system id 10 (as shown above) and the new system has the systemid 15, OTRS won't be able to find a ticket as OTRS checks whether the systemid in the string matches the systemid of your OTRS. This is necessary to allow two OTRS instances to exchange mails...

MAL · Post by **MAL** » 09 Mar 2015, 15:09

Thank you super much, Reneeb !!!!!
The old ID was 12, and my new installation had "10". Seems to work now

So open (minor) issues are:
Issue 1)
The old "freefields" are lost (not appearing anywhere). How can I bring them up again (through the new "dynamic fields") ?

Issue 2)
It seems that there is a very high load on the database and it seems that indexes are missing. Could that be? Shouldn't this be done/optimized automatically during the database migration?
Especially during a normal search via OTRS the load on the DB increases heavily (sometimes it ends up in a timeout).

The database is a mariadb, running on the same machine as OTRS does.

mavrie · Post by **mavrie** » 09 Mar 2015, 15:26

I heard around, both on- and offline in preparation for our own migration.

Stumbled upon some problems here and there.
Mostly SQL related, but found a post with a possible fix to that.

So I'm all good, sorry for threadjacking

MAL · Post by **MAL** » 09 Mar 2015, 16:19

@mavrie

no problem, good luck with your migration

So, I found a other problem (in the log), not sure what the impact actually is (see number 3) )

Issue 1)
The old "freefields" are lost (not appearing anywhere). How can I bring them up again (through the new "dynamic fields") ?

Issue 2)
It seems that there is a very high load on the database and it seems that indexes are missing. Could that be? Shouldn't this be done/optimized automatically during the database migration?
Especially during a normal search via OTRS the load on the DB increases heavily (sometimes it ends up in a timeout).

The database is a mariadb, running on the same machine as OTRS does.

Issue 3)
In the log I see (very often):

Code: Select all

Module Kernel/System/Stats/Static/FAQAccess.pm not in @INC (/usr/Custom /usr/Kernel/cpan-lib /usr /opt/otrs/Custom /opt/otrs/Kernel/cpan-lib /opt/otrs/ /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 . /etc/httpd)

FAQ was uninstalled from the package manager. The file Kernel/System/Stats/Static/FAQAccess.pm seem not not exist.
Do I need to reinstall it?
How?

cmstechnical · Post by **cmstechnical** » 24 Jul 2015, 17:35

Hey guys,

i have found your posts here an interesting read and would love some pointers on how to move our OTRS 3.1 to a completely new OTRS 4 install.

i would be grateful of any help.

Thanks

Charlie

Post by **crythias** » 24 Jul 2015, 20:04

Charlie,

upgrade in steps 3.1.x->3.2.latest->3.3.latest->4.0.latest, following each UPGRADING documentation. Test each step. Verify no errors. Proceed to the next.

mavrie · Post by **mavrie** » 18 Aug 2015, 09:50

Charlie,

I can only agree with Crythias.
Take it slow, step by step. Follow the documentation.

Regards

Znuny Open Source Ticketsystem