I thought the migration should have moved @Richie’s configuration from the component to the core settings and should have also enabled the hidden site setting show_additional_about_groups. A reason why it didn’t work could be that he changed the name, because that’s easily doable in the interface.
Is there a reason why the migration relies only on the name instead of also checking for a component where the remote_url from the remote_themes table matches? That would catch renamed components as long as they were installed from the official repository.
The hidden site setting, which wasn’t enabled because the migration didn’t happen, prevented core from showing the groups, and instead, the component still showed the groups. But the global notice from the component told him to delete the component. Then core still didn’t show the groups because show_additional_about_groups was still disabled, and it wasn’t easily possible to enable it.
So if the automatic migration didn’t work, how do admins migrate manually? Copying the configuration isn’t the problem. But when do they switch between the component showing the groups and core showing the groups without needing to enable the hidden setting?
Maybe it would have been better to enable the show_additional_about_groups for everyone or show it in the interface before adding a notice to the component that it should be deleted. Then a manual migration would have worked, and core would show the groups afterward, so deleting the component wouldn’t leave admins without any groups on the about page.
Right now, when an admin adds groups to the about page extra groups site setting, nothing happens because the hidden show_additional_about_groups setting isn’t enabled. That feels like a bug, even though from a developer’s perspective, everything is working as expected. I think it would be easier for an admin to understand what happens if the setting were visible instead of hidden.