What parts specifically do you propose removing?
CentralAuth can currently be used on vagrant, and I use that locally for testing MediaWiki-extensions-GlobalWatchlist as well as centralauth bugs. That should remain possible, and from what I can see it uses migrateAccount.php and migratePass0.php - not sure if these are part of the migration code.

In T288906#7287668, @DannyS712 wrote:

not sure if these are part of the migration code.

Those are. I do want to keep it possible to set up a development wiki, so either initialize new empty account database or turning a single wiki to a CentralAuth one. However, I'd like to drop code that allows, for example, keeping some accounts centralized and some not or renaming conflicting users. I can draft up a more complete list if necessary.

cc @Legoktm in case you have any thoughts about this as you were involved in the original SUL migration and @bd808 in case you have thoughts about Wikitech

In T288906#7291110, @Majavah wrote:

cc @Legoktm in case you have any thoughts about this as you were involved in the original SUL migration and @bd808 in case you have thoughts about Wikitech

I agree that the timeline for T161859: Make Wikitech an SUL wiki is uncertain and currently feels difficult to unblock. I do very much want to see it happen, but I am in no way certain how the necessary migration to SUL accounts for Wikitech is entangled with the parts of CentralAuth that were built for the SUL migration of the project wikis.

This may be naive, but I do not anticipate needing to deal with many of the complications like account name collisions from the original SUL migration in migrating Wikitech's account. I think that the majority Developer accounts currently active in Wikitech would have a direct mapping to an existing SUL account (for example my User:BryanDavis developer account maps directly to either my User:BDavis (WMF) SUL account or my User:BryanDavis SUL account). The few active bots and alts that do not have a direct mapping likely can be dealt with by creating a new SUL account to replace the Developer account. There may be a need to do something more complicated to preserve edit history from accounts which are now long dormant and difficult to establish a mapping to an existing SUL account.

I think it has a much better shot of not bitrotting for the eventual Wikitech SUL integration if it stays in the repo vs being removed and reintroduced later. I also don't really participate in CentralAuth development anymore, so I'm not actually feeling the pain/burden of supporting this code. The two linked bugs don't actually seem like a big deal to me though.

I do think that we can remove some features that didn't really pan out, e.g. Special:UsersWhoWillBeRenamed (lists were too long to navigate using a paged list, ended up just posting plaintext lists of users).

Related: https://www.mediawiki.org/wiki/User:Legoktm/evil-plans2.txt

Change 766237 had a related patch set uploaded (by Zabe; author: Zabe):

[mediawiki/extensions/CentralAuth@master] Drop Special:UsersWhoWillBeRenamed

https://gerrit.wikimedia.org/r/766237

Change 766237 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Drop Special:UsersWhoWillBeRenamed

https://gerrit.wikimedia.org/r/766237

Change 766295 had a related patch set uploaded (by Zabe; author: Zabe):

[mediawiki/extensions/WikimediaMessages@master] Remove obsolete message overrides for Special:UsersWhoWillBeRenamed

https://gerrit.wikimedia.org/r/766295

Change 766295 merged by jenkins-bot:

[mediawiki/extensions/WikimediaMessages@master] Remove obsolete message overrides for Special:UsersWhoWillBeRenamed

https://gerrit.wikimedia.org/r/766295

After T367968#9908254 we may simplify the code to simply "request" a global account (i.e. central user object) for each user, which will automatically connect the local user to CentralAuth. Caveats will be:

1. All users with same username will always be merged to a central user. So sysadmins must manually rename all non-mergable users (i.e. users sharing same usernames but operated by different people) before installing CentralAuth.
2. Each user's password and email (now in CentralAuth) will come from the first wiki that the script run and which user has an account.

TLDR: This will introduce a new maintanence script which will (always, not checking password or email) connect (one specific or all) accounts in specific wiki to CentralAuth, creating new global users with password and email populated from local wiki if one does not exist. Wikis can use this script to populate CA database (replacing current mirgation script - however, users installing CentralAuth on existing wiki farm must first manually rename conflicting local accounts, otherwise they will be always merged) and fix inconsistent users (i.e. local user not existed in CentralAuth database); It will also replace attachAccount.php.

making Wikitech a SUL wiki

Note: In my proposal the process to add a non-SUL wiki to SUL will be following (supposing LDAP is already removed from Wikitech):

• Rename all Wikitech account that does not represent the same user as SUL account to new names
• Enable SUL
• Run the new migration script, which will connect each Wikitech account to their SUL counterpart (ignoring password and email), creating one if not exist
• Stewards can still manually rename local account in Wikitech. They will be automatically connected to the new SUL account of the target name.