Unofficial: get as close as possible to siduction from Debian Stable (I know...)

[cento]

I have searched the forum, the interwebs, browsed the github repository and noticed how many little things go on with siduction customizations on debian sid.
I *fully* understand what I am asking could be considered madness, offensive, dumb and whatnot.
Yet hear me out: I tried siduction on a spare ssd, and the issues I had with Debian Stable on my laptop with shutdown and restart (they just won't work) and standby (will freeze in 1 out of 3 times), appear to have vanished thanks to sid. Too soon to say if the random system freezes after N hours of work have gone, too, but I'm hopeful.
While I copied the home folder over, that's just not gonna cut it, considering the huge amount of other customizations missing, and the fact that Debian Stable sits encrypted on the "good" nvme of the system, while I tested siduction on a 250GB sata ssd. I simply do not want to move mountains to get a brand new siduction installation on the nvme in place of debian, and then reconfiguring everything.
Not going to happen.

I thought just editing bookworm into unstable in sources.list and adding extras.list and fixes.list was enough, as preferences are not used anymore I've noticed. I don't use btrfs so the scripts are not really needed. But on github I found many small edits here and there that won't be covered by the former strategy.
So, what would be a sensible approach (as in, a hour preparation time tops, plus the dist-upgrade, combined with a very reasonable success probability) to upgrading debian stable into as close as possible to siduction? I won't hold you responsible, I promise!

If you are confident there is a high probability of messing everything up no matter what, also please tell me.
I do have a rolling full-system restic backup on a different server.

[dibl]

First, I have been using siduction and its predecessors exclusively for almost 15 years and find it fully satisfactory for my needs, so I'm a fan. 

However, seeing your desire to maintain your stable preferences and configurations, I would say you might be better off spending your efforts on the power management issues, if that's the only problem you're having with Debian. It's been a very long time since I needed to fiddle with cpu power management adjustments, but there used to be a plethora of settings available to twiddle.

Two cents' worth.  Good luck.

[cento]

Thank you for the lateral approach in your reply, you did give me some hope 
I didn't research more carefully before the switch from windows to linux back then, as I missed out on siduction, so right now it would feel too big of an effort to start from scratch moving data and customizations across ssds and then distros.

In any case, I did not find any such advanced settings on the internet to tweak the CPU power management, if this is even about the CPU and not something else.

Reality is, I'd really like to switch to siduction no matter what, but avoiding the start-from-scratch part 

[ro_sid]

"But" you would be going from Debian to a Debian-derived system with a majority of "just Debian" packages, too, so mainly a transition from stable to unstable (skipping testing).
To get an impression of what would happen, I would "clone" my existing system to an external Device (SSD, "Flash", HD, or even SD-Card) or to a Virtual Machine on your existing system; the latter if you have enough free disk space. At this point, I would leave out the "user data", i.e everything from /home, assuming that this contains the bulk of your data.
And then I would "dist-upgrade" it, by just entering the Repository URLs of Siduction and see what happens. Is it smooth or rough, complicated or simple etc? If you do not like, what you see, just re-use the external device or storage or destroy the VM.
Otherwise you can upgrade "your system".
But be prepared, that some things do not (always) work as expected - the danger of "unstable" -, though this is most often just temporarily. Your life (and even your business) should not depend on it to be working all the time. By watching the (Siduction) forum before doing updates, you can avoid a lot of such trouble, though . On the other hand you should (dist-)upgrade regularly and often, as long as no trouble is in sight. An "old" unstable "rots" easily.
Be also advised, that unstable may be vulnerable to security problems as nobody has tested for these thoroughly. It is not "testing"! On the other hand, noone gets fixes faster then unstable .
Good look!

[cento]

To get an impression of what would happen, I would "clone" my existing system to an external Device (SSD, "Flash", HD, or even SD-Card) or to a Virtual Machine on your existing system; the latter if you have enough free disk space.

this is a GREAT suggestion I had definitely not thought about, thanks!
Regarding updates, I've been checking many unstable maintenance guides and I now know the drill, whenever apt suggests weird or huge changes, either upgrade instead of dist-upgrade, or hold back something, or wait a while and try again 

[dibl]

@centro, which desktop environment are you using? I assume you have reviewed and tried the sleep/suspend/resume methods in this wiki: https://wiki.debian.org/Suspend

[michaa7]

Apart from first trying to upgrade with a cloned system, I, if if really wanted to upgrade my system from Debian stable to Debian/sid(uction), would go step by step:

Debian/stable -> Debian/testing -> Debian/sid -> Siduction

To me this seems the predestined path to go ...

You can't skip a hurdle (= testing), because effectively you piling up consecutive hurdles if you try to skip one.

[ro_sid]

@michaa7: You may do so, but "testing" are just the packages from "unstable", that have proven to be "non-destructive" for more than six(?) weeks and a lot of not (yet) included ones. Further, the largest part of Siduction is "unstable" (sid). @towo may correct me, but the main differences lie in the kernel and the full-story (fll) parts (and of course artwork and some valuable bug-fixes).
In my eyes "testing" becomes valuable first (and may be only), when the transition to "stable" is imminent (bug squashing parties, smooth(er) transition paths and so on). Otherwise it is only a less disruptive "unstable".
This is, why I would do so in one step. One has just to decide, which packages of Siduction should additionally be included.

[michaa7]

In my eyes "testing" .... Otherwise it is only a less disruptive "unstable".
...

That's my point ... it surly won't hurt to "stress" the upgrade process of a stable system in a less disruptive way. But you are right, not all the hurdles between stable and siduction are of the same height.