The way I would think of doing this kind of thing (switching consensus protocol), which includes switching to a different hash function for proof of work, is to have a transitionary period where both consensus mechanisms are used to mine. This transitionary period should be long (perhaps years) to give miners time to manage the logistics of switching over. However, because there would be no trustless mechanism to automatically relate the amount of work (or burn, or whatever) done between the two consensus mechanisms, there would need to be some manually determined estimate of equivalence hard coded into the software. Eg, if we're talking about a different hash function, we could define in software that 100 current hashes is about equal to 10 hashes using the new algorithm. This could even be set such that its marginally (but significantly) favorable to use the new hash function, to give additional incentive to miners to switch. The risk with that is that hardware that processes that new hash function might innovate arbitrarily more quickly than the old hash function (which is likely to have somewhat plateaued), and this might make the manually estimated equivalence become inaccurate in a way that could significantly reduce the security of the network. a change like this could be fraught with perils if the miners using each mechanism don't end up cooperating to ensure that equivalence is set fairly, and instead make efforts to attempt to unfairly increase their share.
In any case, the idea is that you'd have a smooth switch over from (blocks the old mechanism creates / blocks the new mechanism creates) 100%/0% -> 75%/25% -> 50/50 -> eventually 0%/100%. Or at some fraction of total hashpower, (eg 95%) the old consensus mechanism could simply be shut off - which would give additional incentive for miners to switch sooner rather than later. However, it would probably be best to make this cut off more like 99% than 95%, since screwing over 5% of the hashpower for a few months is probably not necessary or ideal. It might actually just be better to have a time-based cutoff. Or have the final switch over lock in at 95% with a few months to give the other 5% time to switch over (and if they don't then its on them).
I would think this could work for switch between any consensus mechanism. However, how to do this in a soft fork is another story. It sounds like its doable from other people's comments.