How to re-migrate tickets only?

PVA1862

Hello,

after years of successfully running a customized (on the frontend) version of osTicket 1.9.12, we recently started the project to upgrade to the current release version.

We took a database dump of the production machine in early May, did a test migration and made ourselves familiar with the current version. Because that went swimmingly and everyone involved in the project had time and was on a roll, we spent the whole month tweaking lots of settings, revised the help topics, message templates and many, many other little things. Originally that was only a proof-of-concept idea, but the results turned out extremely polished and would be absolutely fit for production.

Now we have a system we're absolutely happy with... just with meanwhile outdated ticket data in it. Since we would like to avoid going through every step again and could deploy the current test machine as the new production server: Is there a way to re-migrate only the current production ticket data from the old 1.9.12 instance, leaving everything else alone?

Thanks in advance for your help and advice!

KevinTheJedi

PVA1862

You will need to write your own migration script. Otherwise you will need to redo the settings.

Cheers.

PVA1862

KevinTheJedi Guess I'd have to dig through the official upgrade/migration script then...
So apparently osTicket does not provide any way to prepare a new installation before launching it in production use, if you want to retain any existing data? Kinda surprised about this conclusion, tbh.

Maybe it might be worth a shot to approach this from the other direction:
Do you reckon it might be possible to put the existing tables aside using a prefix, import the old 1.9.12 tables again, drop everything except for the ost_ticket tables and remove the temporary prefix from the others, which should restore the settings, help topics etc?

KevinTheJedi

PVA1862

The IDs of everything wouldn't match unless you map them and run a script to update them.

So apparently osTicket does not provide any way to prepare a new installation before launching it in production use, if you want to retain any existing data?

No, but this is something we've been thinking about for v2.0. Some sort of import/export tool for objects like help topics, departments, etc. as well as things like system settings, etc. This will make it easy for situations like this but also have some sort of "templating" that people can download or share for a faster onboarding process.

Cheers.

PVA1862

KevinTheJedi Definitely something that should firmly be on the roadmap. With how polished osTicket is otherwise, admins, users and decision makers don't expect the only supported solution to this problem is starting over new... and either require a long downtime, or pushing a bone stock default system into production because you have no other choice but to work on it as you go.

Speaking of supported, I spent the past hours trying an unsupported solution:

Put aside the prepared new version's data folder and database tables containg your modifications
Start a new migration install with a fresh copy of your production data from the old machine
Replace the necessary tables with the ones carried over from step 1, in our case i. e. ost_config, ost_filter* or ost_help_topic*
Replace the data folder with the modified one carried over from step 1

Turns out as long as you had a change freeze in place for the old system's configuration (which we did when we started the upgrade project) and carefully only renamed, disabled or added things, but didn't delete them in the test instance of your new osTicket (as we did), you apparently don't run into duplicate or mismatched ID problems. Will need to test it more thoroughly, but it looks like this procedure worked for us! We have all prepared modifications in place, like several dozen new complex filters, or all the renamed, disabled and added help topics, but with the current day's production state of tickets, attachments, etc - just like we'd hoped.

PVA1862

For those who are interested how this turned out in the end:

After more than two weeks in production use, we can confirm this unsupported migration method worked out for us (and might possibly work for others, provided your circumstances are exactly the same as ours outlined earlier). Zero ID mismatches or other issues came up, the osTicket instance works 100% fine.