Another, simpler, idea is to make sure that no user has any of the "lqt-*" permissions, which would create an effective read only state.

I would strongly advise against option 2 - it makes things worse rather than better IMO.

A LiquidThreads page is at its core a wikitext page, with LiquidThreads adding some additional formatting to it. Almost all of the data required to deconstruct a LiquidThreads page back into wikitext is stored in the core page and revision tables, and one could even consider writing a Scribunto module to render a LQT board when LiquidThreads isn't installed.

(It isn't quite that simple - user signatures and the structure of the thread (who replied to whom) is only stored in LQT-specific tables. But the meat of the comment is still there.)

Flow, on the other hand, stores everything in it's own internal opaque database as HTML. The LQT->Flow conversion script moves every single LQT page (to retain the history of the header), overwrites the comments LQT stores in the core database with redirects, and creates its own "Topic:" pages that are just pointers. This is further away from the eventual goal of converting everything to wikitext/discussiontools that you are eventually hoping to achieve, and would make a much bigger mess that you started with.

The Editing team will discuss this topic on December 18.

We have a deadline for LQT - February 2025 - as removing this extension is a requirement to deploy temp accounts.

I would strongly advise against option 2 - it makes things worse rather than better IMO.

While this is true, we have to take into account the scale here. Liquid threads is used minimally on a small number of minor wikis. There is already an existing migration script for LQT->Flow that has been run in the past (e.g. on mediawiki.org).

We also know we have to create a conversion script for Flow to DiscussionTools - and having a handful more Flow boards to convert is going to be much simpler than creating an LQT->DT conversion script.

Liquid threads is used minimally on a small number of minor wikis

That's seriously misleading. Every single published article on enwikinews has an associated LQT page, for example.

Let's be clearer here:

• There are 7,000 pages on enwikinews using LQT: https://en.wikinews.org/w/index.php?title=Special:Search&limit=500&offset=0&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns90=1&ns91=1&ns92=1&ns93=1&ns100=1&ns101=1&ns102=1&ns103=1&ns710=1&ns711=1&ns828=1&ns829=1&search=insource%3A%22%23useliquidthreads%22
• If you were to run the LQT->Flow conversion script and then the Flow move to subpage script the result would be each of those 7000 pages would be moved once to /LQT Archive 1, and then a Flow board would be created, and then it would be moved again to /Flow. That would be 14,000 page moves and the attendant churn associated with each one, in net accomplishing very little and making things a lot worse.

Finally, consider if a LiquidThreads board has zero threads then don't bother archiving it. That would reduce the impact considerably.

In T381906#10413560, @Pppery wrote:

Finally, consider if a LiquidThreads board has zero threads then don't bother archiving it. That would reduce the impact considerably.

I see it as something similar to how you deleted mediawikiwiki's empty Flow boards, before the conversion script run.

I don't like how much I feel like I'm the only person keeping this project from collapsing into a tide of chaos, but fine.

Is there a timeframe on when the LQT->Flow conversion script is likely to be done?

In T381906#10413571, @Pppery wrote:

I don't like how much I feel like I'm the only person keeping this project from collapsing into a tide of chaos, but fine.

Is there a timeframe on when the LQT->Flow conversion script is likely to be done?

What a perfect sentence!