I have a test server set up with 5.0.3 where I’ve imported the 4.4.4 db and upgraded it. I’m now adding customizations. The plan is that when it’s ready I’ll clone the VM, change the IP and settings, and it’ll be the production server. Where I’m getting tripped up is how to import the tickets that are created in the meantime without losing all the customizations that are in the new database. I feel like I’m overlooking an obvious solution since this must come up all the time. Ideas?
When we migrated from 4.x to 5.0.x we did much the same thing for testing/tweaking all our local customisations (of which we have quite a few). On change over day we turned off the mail processing and web server on the old server so no new tickets would be entered, copied the database over to the new live server and then re-ran the DB upgrade on there. Once we were happy that the new 5.x server was happy with the database, we turned its mail handling on and switched the DNS over to make that our live service. Total outage was probably a couple of hours, but we didn’t lose any mailed in tickets because the MTAs just queued them waiting for our server to start accepting them again.
I want to add a bunch of new features. From what you’re saying, it sounds like I should release the 5.0 with feature parity and then down the road add the new features. I was hoping to get everything I wanted installed and tested on the test server so I wouldn’t have to do it there and then do it again on the production server.
As I said above we put all of our local features in during testing (and we’ve got lots), and then just reimported/upgraded the database. Of course if your “bunch of new features” are altering the database schema that makes it more complicated for you.