In theory, yes, for vanilla code. but it's a bit more complicated than simply run the database scripts. http://doc.otrs.com/doc/manual/admin/4.0/en/html/upgrading.html http://doc.otrs.com/doc/manual/admin/5.0/en/html/upgrading.html http://doc.otrs.com/doc/manual/admin/stable/en/html/updating.html Note that any customizations in code and plugins will very likely not work if they're referenced, and not upgraded as well or available. For instance in Kernel/Config.pm or Kernel/Config/Files/. And always use the latest patch level for each revision to upgrade (3.1.latest -> 3.3.latest) Make sure you have SQL backups for each step, and it'd be preferred to do a dry run against another install out of production. Yes, then you can restore that backup to new production version. Also, what I've found in mysql backup is that I've had better luck with backups when using mysqldump --hex-blob. This makes a larger dump file, but it also made my restore less likely to fail. https://stackoverflow.com/questions/16559086/does-mysqldump-handle-binary-da... Also, make sure your max_allowed_packet is fairly large in [mysqld] so your import won't die. On Thu, Nov 8, 2018 at 8:36 PM Mike Morris wrote:

Hi,

I have an old (3.x) installation that I want to migrate to current 6.x.

Can I run the DB upgrade scripts from all intermediate versions against my database, and then expect that upgraded database to work on a brand new installation? (Assuming I handle migration of the config files to the new install, of course.)

I don't see why this wouldn't work, but thought I should at least ask the experts...

Thanks in advance,

Mike Morris

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