Don’t feel bad - most of us are lurkers here.

From my experience:

1.  Create a duplicate of your environment as an “upgrade” platform.  Create another copy as a backup (things will go wrong and you’ll need to roll back)

2.  Run all the upgrade scripts on your “upgrade” platform.  Step by step, paying attention to the upgrade notes for each version.  Maybe create a backup of each as you go - this eases mini-roll backs

3.  Once upgraded, copy that entire tar ball (after dumping DB) to your new environment, restore DB etc 

H

On Tue, Jul 31, 2018 at 22:31 Mike Morris <mike@musicplace.com> wrote:

Hi All,

I've been pretty much lurking on this list for years... and am embarrassed to admit this, but:

I have a 3.3.6 installation that I'm finally turning my attention toward upgrading. I want to migrate from an in-house server to a cloud hosted one in the process, so I don't need (want) to do a series of in-place upgrades if I don't have to.

Questions:

  • Can I collect the DB upgrade scripts for all versions between 3.3.6 and current 6.x, run the upgrade scripts sequentially against my DB, and then just copy the DB into place on a brand new 6.x installation and have it work?
    • A bit of an over simplification... I know I've got to copy over the ZZZAuto.pm files necessary with any upgrade.
    • I have no custom Output "skins", but use plenty of Response Templates. Any other Config file system worries?

  • I am using external storage (Ticket::StorageModule = ArticleStorageFS) for attachments. The path to FS storage would (possibly) change on a new host. Am I right that properly setting the "ArticleDir" value will make this transparent?


Thanks in advance,

MikeM

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