I think this is a very reasonable request that makes sense, both from an end-user's point of view as well as from a sysadmin's POV, especially if we want to increase the adoption of FanBoxes among estabilished communities that use wikitext userboxes extensively. However, in addition to what you wrote about the possible complexity of userbox templates, there are some other concerns that need to be addressed before we can even consider tackling this one:

• FanBoxes does not allow to use pre-existing wiki images; you can upload a new image on Special:UserBoxes to use in your new userbox, but that's about it.
  • Relatedly, shared repo support or the lack of thereof (there's a ticket about this, even); some wikis might have local uploads disabled altogether but still have InstantCommons (or an ordinary shared repo) enabled and thus they'd like to use these images when creating userboxes. This isn't currently possible with FanBoxes.
• Variable support or the lack of thereof. FanBoxes doesn't support fancy magic words (AFAIK) so you can't create a template that says "this user has been a member of this community for X years, Y months and N days", for example, but such userboxes are pretty popular, and users obviously don't want to lose any functionality when migrating over to a new system.

I think a potentially possible way would be allowing some configurations in a mass conversion tool. The way this would (in theory) work is to pass arguments to these variables, where the first variable asks for the template name for basing the data. Then we ask for the template parameter name/number to associate each part of a userbox with so that it can substitute the values.

$wgFanBoxesTemplateName = 'Userbox';
$FanBoxesTemplateParameterBackgroundLeft = 'bg1';
$wgFanBoxesTemplateParameterBackgroundRight = 'bg2';
$wgFanBoxesTemplateParameterContentLeft = 'text1';
$wgFanBoxesTemplateParameterContentRight = 'text2';
$wgFanBoxesTemplateParameterContentColorLeft = 'color1';
$wgFanBoxesTemplateParameterContentColorRight = 'color2';

Also, we might want to create this as an interface (maybe) since web user interfaces can help make processes earlier. Obviously a disadvantage is that this will require more maintenance and resources. This let's configuration on-wiki possible without requiring backend/system administrator access. This will require a new user right to introduce.

And even without a special page interface, it'd be nice to implement a log to record the successful and failed conversions.

Its a bit late at night here and obviously there's probably some drawbacks that I haven't mentioned, but here are some that I want to point too:
We need to be able to definitely support parameter numbers as sometimes parameters in userbox templates aren't named but numbered (an example is Brickipedia's)

We also want to support conditional parameters and make sure that configuration can be marked as optional (and perhaps even able to mark as ignored?)

I hope this makes at least a lick of sense (it's currently a bit late as of the time I'm writing this out)

@ashley: What are you takes on this? Can you comment on what the drawbacks for writing a conversion tool this way (not including the ones you mentioned above?) Is there possibly a better way on writing such a conversion tool, and if so, how would that work?

I also forgot to mention but the tool would/should be able to crawl through the existing templates and find which ones to convert based on if the template use the template mentioned in the configuration

In T156106#3060225, @SamanthaNguyen wrote:

Also, we might want to create this as an interface (maybe) since web user interfaces can help make processes earlier. Obviously a disadvantage is that this will require more maintenance and resources. This let's configuration on-wiki possible without requiring backend/system administrator access. This will require a new user right to introduce.

In this case the page would have to be a simple(r) interface for migrating an individual userbox. I think your usual performance concerns are preventing the creation of an on-wiki mass migration tool (it'd likely need insane memory & time limits).

And even without a special page interface, it'd be nice to implement a log to record the successful and failed conversions.

For a maintenance script, this is somewhat "easy": output something like "Conversion of [[Template:Some userbox]]...SUCCESS/FAIL" and pipe the output to a file.

@ashley: What are you takes on this? Can you comment on what the drawbacks for writing a conversion tool this way (not including the ones you mentioned above?) Is there possibly a better way on writing such a conversion tool, and if so, how would that work?

No idea, I haven't looked at this in-depth, sorry. Right now this falls under "crazy ideas that would be nice to implement in the future but which don't seem very realistic right now" (due to, for example, some of the things you mentioned).