Migration strategy for RT 2.x --> 3.4.5 upgrade

Greetings, all

First, I want to take a moment to thank Jesse Vincent and this list for RT
itself and the support I’ve received here. Last weekend I managed a full cutover
of a nonprofit organization’s corporate email infrastructure. Over 60 RT
tickets figured prominently in the planning process and in trouble resolution
during and after the cutover. I can’t imagine how we could have coordinated and
executed this cutover so smoothly without RT, because so many things would have
slipped through the cracks. THANKS!

Next, my for-profit employer also uses RT, and we’re preparing to move from
version 2.x on Postgres to version 3.4.5 on MySQL within the next month or
so. Nothing against Postgres, but we have lots of expertise in-house on MySQL
and all our other systems use that, so we want to consolidate. I will
probably take the approach of using native SQL DUMP facilities to move the
data to MySQL at the RT 2.x level and then run the migration against
MySQL – again, the idea being that I’m more familiar with troubleshooting
in that environment, so the faster I can move into my database-of-expertise
the more likely I am to be able to quickly resolve problems found during
the RT upgrade itself.

We have the luxury of deploying a new server host at the same time, so we
will be able to bring up RT 3.4.5 fully in parallel before we cut over. My
plan is to get the migration “down to a science” using a test snapshot of
the RT 2.x database, and literally script the process end-to-end so that on
cutover day I have a canned script that will just work because I’ve tested it
repeatedly in our exact environment. I’ve got lots of up-front time to do the
pretesting, but RT is mission-critical to our company and therefore I need to
get it right the first time when we decide to go live.

I’m confident of my ability to install and configure 3.4.5 itself, now that I
have experience with 3.4.4 in the nonprofit environment. But I’ve not tried
an upgrade of 2.x to 3.4.x before, and the person who was our company RT admin
before me indicated (without being very specific) that the migration scripts
were broken with regard to binary attachments.

It’s been at least a year since my predecessor tried to do an RT upgrade, so
I am wondering if the problems he encountered still exist, or if it is now
a reasonable certainty that an upgrade will “just work” if done according to
the RT instructions.

Has anyone done this recently, and would care to post a quick "snapshot"
of where we are with regard to migrating an RT database that has attachments
embedded? I’m not looking for detailed, step-by-step instructions – I can
get that by the old-fashioned RTFM method. :slight_smile: What I’m seeking is simply
a commentary of, “Yes, it basically works as advertised,” or “Well, most of
the upgrade works but attachments are still broken,” or “I have no idea
what you’re talking about, attachments have always worked fine.”

Thanks for suggestions/advice/comments.

Scott

Scott Courtney | “I don’t mind Microsoft making money. I mind them
scott@4th.com | having a bad operating system.” – Linus Torvalds
http://4th.com/ | (“The Rebel Code,” NY Times, 21 February 1999)
| PGP Public Key at http://4th.com/keys/scott.pubkey

I’ve done an upgrade of RT 2.0.something to 3.4.2 with no problems. I
tested it repeatedly on another machine until I got it right. I took a
dump of the old RT database over the weekend because we have thousands
of tickets. When I got in on Monday I did a snapshot of everything
since the last full dump, took a 30 minute outage to migrate to the new
server and I was back up with no issues. The trick is to follow the
directions exactly and do it a few times on your test machine (from
fresh install to final migration) with no problems. You’ll be fine.
Piece of cake.

Jason-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Scott
Courtney
Sent: Wednesday, January 18, 2006 3:37 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Migration strategy for RT 2.x --> 3.4.5 upgrade

Greetings, all

First, I want to take a moment to thank Jesse Vincent and this list for
RT itself and the support I’ve received here. Last weekend I managed a
full cutover of a nonprofit organization’s corporate email
infrastructure. Over 60 RT tickets figured prominently in the planning
process and in trouble resolution during and after the cutover. I can’t
imagine how we could have coordinated and executed this cutover so
smoothly without RT, because so many things would have slipped through
the cracks. THANKS!

Next, my for-profit employer also uses RT, and we’re preparing to move
from version 2.x on Postgres to version 3.4.5 on MySQL within the next
month or so. Nothing against Postgres, but we have lots of expertise
in-house on MySQL and all our other systems use that, so we want to
consolidate. I will probably take the approach of using native SQL DUMP
facilities to move the data to MySQL at the RT 2.x level and then run
the migration against MySQL – again, the idea being that I’m more
familiar with troubleshooting in that environment, so the faster I can
move into my database-of-expertise the more likely I am to be able to
quickly resolve problems found during the RT upgrade itself.

We have the luxury of deploying a new server host at the same time, so
we will be able to bring up RT 3.4.5 fully in parallel before we cut
over. My plan is to get the migration “down to a science” using a test
snapshot of the RT 2.x database, and literally script the process
end-to-end so that on cutover day I have a canned script that will just
work because I’ve tested it repeatedly in our exact environment. I’ve
got lots of up-front time to do the pretesting, but RT is
mission-critical to our company and therefore I need to get it right the
first time when we decide to go live.

I’m confident of my ability to install and configure 3.4.5 itself, now
that I have experience with 3.4.4 in the nonprofit environment. But I’ve
not tried an upgrade of 2.x to 3.4.x before, and the person who was our
company RT admin before me indicated (without being very specific) that
the migration scripts were broken with regard to binary attachments.

It’s been at least a year since my predecessor tried to do an RT
upgrade, so I am wondering if the problems he encountered still exist,
or if it is now a reasonable certainty that an upgrade will "just work"
if done according to the RT instructions.

Has anyone done this recently, and would care to post a quick "snapshot"
of where we are with regard to migrating an RT database that has
attachments embedded? I’m not looking for detailed, step-by-step
instructions – I can get that by the old-fashioned RTFM method. :slight_smile:
What I’m seeking is simply a commentary of, “Yes, it basically works as
advertised,” or “Well, most of the upgrade works but attachments are
still broken,” or “I have no idea what you’re talking about, attachments
have always worked fine.”

Thanks for suggestions/advice/comments.

Scott

Scott Courtney | “I don’t mind Microsoft making money. I mind
them
scott@4th.com | having a bad operating system.” – Linus
Torvalds
http://4th.com/ | (“The Rebel Code,” NY Times, 21 February 1999)
| PGP Public Key at
http://4th.com/keys/scott.pubkey
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Download a free sample chapter of RT Essentials from O’Reilly Media at
http://rtbook.bestpractical.com

WE’RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
San Francisco - Find out more at
http://bestpractical.com/services/training.html