Merging 2 RT systems

Hi All,

I have a request from business to merge 2 RT systems. One is RT 3.x and
the other is RT 2.x

Is this possible, if yes could anyone advise on best route to take?

Thanks

bashir jahed
nha | enhance

5 protea road | claremont | 7708
po box 24 | newlands | 7725

telephone +27 (21) 657-2574

mobile +27 (83) 414-0453

facsimile +27 (21) 657-2575

e-mail | messenger bashir.jahed@nha.co.za
mailto:bashir.jahed@nha.co.za

this message is subject to the disclaimer at
www.nha.co.za/disclaimer.asp http://www.nha.co.za/disclaimer.asp or
disclaimer@nha.co.za
mailto:disclaimer@nha.co.za?subject=request%20disclaimer

Hi,

If I remember correctly,
we use RT-Extension-RT2toRT3 several years ago.
Kevin programmed it.

http://www.cpan.org/authors/id/F/FA/FALCONE/RT-Extension-RT2toRT3-1.26.readme

Cheers,
Björn

Bashir Jahed wrote:

I have 2 instances of RT running at my location. As of last week they
are both running 4.0.5 (Postgres 8.4.11) and we would like to merge
them into one system within the next quarter. Just to give you a
little background on the systems:

System A: Has been running for about 9 years and has approximately
30,000 tickets

System B: Has been running for about 1.5 years and has approximately
4,000 tickets
Also there are some specific custom fields which are heavily used.

My main question is:

What is the best method to merge the 2 systems. I have a couple of
thoughts on what I can do to accomplish it and would like some advice.

Method 1: Migrate System A into System B
At the time of migration, delete all tickets in System A up to the
current ticket number in System B. This way all references within the
tickets would remain intact, the custom fields would function normally
and after manipulating the sequence numbers to start at the next id.

Method 2: Migrate System A into System B
And add a field to the tickets table that could be searchable within
RT to cross reference old ticket number to new ticket number. The
more I say that the more I don’t like the idea. It would definitely
make for tedious upgrades in the future.

Method 3: There may be a method someone else has used or a written
procedure for accomplishing this that I do not know about. I am wide
open for discussions, ideas, thoughts, etc.

Any insight would be greatly appreciated.