When I upgraded several years ago, I had to run rt2-to-dumpfile BEFORE I installed RT3 at all. Something about the version of SearchBuilder (I think) that RT# used broke the data export of RT2. At one point I was very good with the procedure for that upgrade, but my memory seems to have been lost to time and projects past.
I hope this may help you out some. Searching for part of my email on http://www.gossamer-threads.com/lists/rt/ may bring some of those posts back up for you. Brian Friday wrote: > Hello all, > > I am using the RT2-to-RT3 migration tool (latest) to migrate a RT2 > instance (Mysql 3.23, DB is 1+ GB in size) from 2.0.14 to RT 3.6.7 > (Mysql 5). I have copied the original RT2 install, and the new RT3 > from their respective machines to a go between system. I've fixed the > paths and configurations so that both installs still can connect to > their respective databases. > > This go between machine is running perl 5.8.8 with all the modules and > dependancies for a mysql based RT 3.6.7 instance. RT2 is running on a > Mac OS X panther server with Perl 5 (I think 004) and RT3 is running > on a Leopard Server also running Perl 5.8.8. > > I had to update the RT2-to-dumpfile script in the migration package to > change the status as well as the priority of the tickets it exports. > In addition I had to add to RT3 the additional status files used by > the client. After that I was able to successfully run both the rt-2.0- > to-dumpfile script and the dumpfile to rt-3.0 script. All the basic > data appears to have come across intact including queues, acl's, users > and ticket metadata. > > First Problem: > ------------------- > While the ticket metadata has been exported, the actual transactions, > as well as ticket contents, emails, attachments etc have not been > exported. I have verified that they exist in the original database. > > Second Problem: > ------------------------ > Within RT3 I have edited the etc/RT_SiteConfig.pm to include the > additional status lines here: > @ActiveStatus = qw(new open waiting monitoring ongoing stalled verify > EC) unless @ActiveStatus; > @InactiveStatus = qw(resolved rejected dead deferred deleted) unless > @InactiveStatus; > > From the default below: > @ActiveStatus = qw(new open stalled) unless @ActiveStatus; > @InactiveStatus = qw(resolved rejected deleted) unless @InactiveStatus; > > The catch I have discovered is that when the old tickets were imported > about 90% of the tickets which were resolved now have the status of > new (specifically "new (unchanged)" ). These tickets instead should be > listed > as resolved. > > -------------------------------- > > Has anyone seen or experienced either of these behaviors before and > could provide any advice? > > Any help would be appreciated, > > - Brian > _______________________________________________ > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users > > Community help: http://wiki.bestpractical.com > Commercial support: sa...@bestpractical.com > > > Discover RT's hidden secrets with RT Essentials from O'Reilly Media. > Buy a copy at http://rtbook.bestpractical.com > -- Drew Barnes Applications Analyst Network Resources Department Raymond Walters College University of Cincinnati _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com