Thanks for your kind wishes and apologies on my slow reponse (I was enjoying a little time off over Christmas/New Year). I hope that you had a lovely holidays.

There are 2 main options:

• Migrate your data using TKLBAM; or
• a "Debian style" in place upgrade

As noted on the relevant doc page we technically don't support the second ("in place") upgrade option as not all of our changes and tweaks are packaged. A system upgraded to a newer Debian release is sort of a hybrid of the old TurnKey release, with a new base OS and newer packages (inc TurnKey ones), but it won't receive any additional new default config tweaks. That's not a show stopper, but it will mean that things may not always work exactly the same on your system as they would in a "proper" TurnKey release. It's Linux so you can do whatever you want and odds are it will work fine plus I'll try to assist regardless, but unless you know your way around Debian really well, I recommend avoiding that option.

As such, I suggest migrating your data with TKLBAM.

Please note that the DB schema for MySQL/MariaDB users changed between v16.x & v17.x. Specifically, what was the mysql.user table is now a view (for backwards compatibility), with the user info now in a different table (I forget the name OTTOMH).

Unfortunately it was a while before I realised and the default TKLBAM (in both v17.x & v18.x) will choke on that. But I have since fixed the issue. For v17.x, the new package needs to be manually downloaded (see the TKLBAM v1.4.3.3 release page for details). All new releases of v18.0 (from here onwards) will include the fixed TKLBAM, but for the existing v18.0 builds (e.g. Nextcloud) you'll need to install it with apt:

apt update
apt install -y tklbam

The fixed version (on v18.x) is v1.4.6:

root@test ~$ apt policy tklbam
tklbam:
  Installed: 1.4.6
  Candidate: 1.4.6
  Version table:
 *** 1.4.6 999
        999 http://archive.turnkeylinux.org/debian bookworm/main amd64 Packages
        100 /var/lib/dpkg/status

FTR there really isn't any reason why you need to use TKLBAM for that, it just makes it easier. You could do the data migration manually. The bits you'll need are the 'nextcloud' DB and the Nextcloud directory; /var/www/nextcloud (or directories; I forget when we moved the default data dir outside the default webroot? - it should be /var/www/nextcloud-data). After you've replaced the dir(s) and the DB, the only thing you should need to do is update the DB user password to match what's in your Nextcloud config. Rerunning the firstboot script should fix that (although again, it can be done manually if you prefer):

/usr/lib/inithooks/firstboot.d/20regen-nextcloud-secrets

That will also regenerate some other stuff, so all logged in users will be logged out and will need to log back in again (not necessarily a bad thing IMO - but worth noting).

That will migrate your current Nextcloud site and data to the new server, so you'll still need to actually update Nextcloud itself.

My only concern there is that Nextcloud state:

• You cannot skip major releases. Please re-run the upgrade until you have reached the highest available (or applicable) release.
• Example: 18.0.5 -> 18.0.11 -> 19.0.5 -> 20.0.2

So you'll need to upgrade like this: v23 -> v24 -> v25 -> v26 -> v27. But each of those versions has different PHP requirements (v24 has a minimum requirement of PHP7.4; max of PHP8.1 - but v18.x has PHP8.2). So it may actually be easier to hack on your current server (i.e. installed newer PHP as required) until you get your current install up to date. Then migrate to v18.x once you have a version that supports PHP8.2 (it seems that v26 is the first version to support PHP8.2).

Actually, migrating to v17.2 first might make that a bit easier!? That is already preconfigured to use PHP8.1 (from a trusted third party source - Debian 11/Bullseye only had PHP7.4). Nextcloud v24 supports PHP8.1 and Nextcloud v27 does too so you could do the whole update (to Nextcloud v27) in v17.x if you wanted. And then if you are still keen, you could migrate your data again to v18.x.

Sorry that I don't have better news for you, but hopefully that helps. Whatever you do, take a snapshot and/or a backup of your current server before doing anything (I prefer having both as snapshots are quicker and easier to recover to exactly where you were, but a backup is also really good to have IMO). And take notes along the way. That way if things go pear shaped at any point, you can roll back and get back to where you were relatively quickly and easily. Also, you can then share anything of value with us! :)