Thanks for you kind words and deep apologies on my slow response...

TBH, I'm not sure why your original post didn't show, although FWIW it appears to now be showing?!

Anyway, I hope this helps:

To respond to your question, there are 2 pathways to move to the newer TurnKey version. Which path you take will depend on where/how you're running TurnKey, which appliance you are using and how much customisation you've made.

Migrate data with TKLBAM

The generally recommended way to move to a newer TurnKey version is to use our built-in backup and migration tool, TKLBAM. Essentially take a backup of your current system, then restore to a new VM. One of the main advantages of going this way is that you can leave your current server in place and work within a separate "test" server. Once you are 100% happy that everything is working as intended you can then migrate DNS and/or other factors to the new server.

Unfortunately, it's not always as simple as "create backup on old server, restore on new server". Sometimes it is, but sometimes not... It is something that I hope to improve in the future, but I'm not sure when we'll get to that... However, it may be worth a try and see how it goes. If you have issues, please feel free to share and I'm happy to try to assist. Furthermore, TKLBAM supports partial restore of data. Generally I'd recommend just restoring your specific date (so you get your data, but otherwise get all the new config etc). If you'd like to give that a go and need more info, please ask and I'll elaborate.

"In place" Debian upgrade

The other path is to use the "normal" Debian "in place" upgrade pathway. As TurnKey is based on Debian, then in theory this path should work fine and may be the preferred pathway in some specific cases. Some users have already done that and reported issues that are specifically related to TurnKey software have been resolved to the best of my knowledge. However, I have not had reports regarding every single appliance and we have not done much internal testing. So I can't guarantee that it will work flawlessly (or at all).

I don't have exhaustive docs on how to do this, but the Debian docs are usually pretty good with regard to upgrades. If you want further info, then I'd suggest google around using a search such as "how to upgrade debian Stretch to debian buster". Hopefully that should give you some info of value.

If you go with an "in place" upgrade, it is highly recommended that you ensure that you have some sort of snapshot/clone of your server before doing this. That is because once you start doing an "in place" upgrade, there is no going back. Unless you have a snapshot/clone type backup, if things go wrong, you will stuck with a broken server and limited recovery options. Obviously if you have a TKLBAM backup, you could revert to the first option; but you won't have the advantage of being able to rely on your current server while you do that.

Even if you go with the "in place" upgrade, I'd suggest running through the process in a "disposable" VM - ideally with your data in place; e.g. a restore snapshot/clone. That will give this pathway the same advantage that you get via the TKLBAM method. I.e. worst case scenario, you can trash your restore/upgrade and start again.

Regardless....

Regardless of which path you go, I highly recommend that you document as you go. That way if issues occurred to can "replay" your steps to get back to where you were. You will also have notes of what didn't work to share with us so other users may be abel to avoid the pitfalls.

No matter which path you go, and how well or badly it goes, please report back! We'd love to hear!

If you do hit any issues and/or need a hand, please post back as much info as possible (e.g. which appliance, which particular version, what customisations you have made, etc). I'll do my best to help out.