Hey there @linden06 
I’ll confirm that @reimlima is correct. Between the OS dependencies and the fact that you’re jumping two major versions, it’s easier to stand up a new Graylog stack and import the logs than it would be to try and get your stack upgraded piece by piece. I’ll note that given you’re upgrading major versions, each major version would include some sort of breaking change, as is the case with most projects that use semantic versioning.
Consider this: in order to go from 2.4 to 4.0, you’d have to
-
Upgrade Graylog to ~3.0 first, then upgrade to 3.3, then upgrade to 4.X
- As a note, each time you upgrade, there’s going to be a database migration that happens in MongoDB
-
Upgrade Elasticsearch to 6.X and ensure you reindex, as if you plan to do any upgrades to Elasticsearch in the future, any indices that you have that were created on 5.X won’t work
-
Upgrade Mongodb–I’ve posted on the forums before that an upgrade path for Mongo isn’t as simple as upgrading to the latest version. You’d have to go from 3.2–>3.6–>4.0–4.2 if you were to run 4.2 in your new stack.
So given the amount of leapfrogging that has to happen, you’d be better off spinning up Graylog with Mongodb 4.0 or 4.2 and Elasticsearch 6.X , and then reindexing from remote so that the new Elasticsearch instance can slurp up the old indices.