I might have been a bit optimistic about my particular problem (re. missing forename/surname) as the web GUI and ipa stageuser-add do not allow you to create a user without Surname/forename, so presumably this would end up complicating the staging processes somewhat if you really wanted to allow some sort of unset value.

Assuming that having staging allow things to be unset isn't very feasible, the option for a default value (I'd probably use UNKNOWN/UNSET/NULL etc.) would probably be better, and maybe better still would be some script callback mechanism, for example in my case I could write a script to extract givenName+sn from the upstream GECOS field.

Even if using defaulting or a callback, I'd probably still like the option to stage, but I don't know how much others would like it.

There are currently no plans for enhacements in ipa migrate-ds. Instead, a different tool being created in https://github.com/freeipa/freeipa/pull/7045. You can see current design for this tool in a temporary render of the PR#7255 here: https://freeipa--7255.org.readthedocs.build/en/7255/designs/ipa_to_ipa_migration.html

It is also not considering migration of the users to staged area but it is the tool we are actively working on, rather than ipa migrate-ds.

Thanks for the up-to-date info @abbra, I'll keep an eye on that PR.

re. ipa migrate-ds having no plans for enhancements, if I were to make a PR to migration.py and relevant docs to scratch my itch (defaulting attributes), do you think that would be merged/released? I'd hope that a change in the area would be fairly succinct

It should not be hard to add this functionality into the new tool. I'll look into it...

If the original use-case for putting users into staging was for those that are missing information, that has fallen apart. So is staging still even on the table? I don't see the use-case.

Trying to guess the givenname/surname values there is no common practice across the world. It will frequently be wrong and likely be and endless set of future bugs/customization so that users can define their own regex (which will also likely be wrong, but perhaps less wrong).

I'm going to close this as wontfix. Migration focus has moved to a new tool.