What does 2.0 to 3.0 migration involve?

For each PHP snippet, you need to create a Computed Field plugin. You can use Module Builder to generate the scaffold for the plugin classes, and then you'll need to copy the PHP manually and tweak it a little for the incoming variables.

That makes sense. In such case, do I...

A) Install Module Builder and implement the above steps while still in Computed Field 2, and test that my code in file format works before upgrading (I assume cleanly) to Computed Field 3?
or
B) Upgrade from Computed Field 2 to 3 first, and then install Module Builder and take the steps above (i.e. would my database-stored PHP code still be available upon upgrade)?

Assuming A is what you mean, what do I need to put in the required Code (PHP) value field? Just a php comment or something else?

Thanks

To document the process, I'm attempting Joachim's instructions in Computed Field 2 (option A above) and I've installed Module Builder 8.x-3.34.

@joachim I found your YouTube video on Module Builder workflow. Thanks for that, though as a relatively inexperienced module developer (I've only made a few D7 modules) it doesn't get me close to actually testing module code with Computed Field. I see that a hook is provided in each Computed Field's help text, but I'm not sure how that translates for use in a module. Even a single example of the "Computed Field using code stored in database" ---> "Computed Field using custom module code" pipeline might be enough to get me going.

Is there such an sample of before and after code, or perhaps a guide for translating Computed Field php code into module format? For example, I'd want to know if there are required hooks for Computed Field that must be included with every module translated to the new format.

It seems I got lucky on my first try. Here are the steps I took.

1. Open Module Builder
2. [Analyse Code]
3. [Add Module] (Readable name = Anything; Module dependencies = computed_field)
4. [Save and go to next page] (Hooks)
5. Add any hook you like (doesn't matter because you'll overwrite this code later). I didn't find a better way to generate the necessary .module file
6. [Save and generate code]
7. In the Generate Code tab > [Write all files]
8. Now find the module's folder on your server
9. Edit the .module file
10. Replace all code with the "hook implementation function signature" generated in the Computed Field's help text area. And inside that function, copy/paste your code from the "Code (PHP)..." text area of your Computed Field. Your module code should look like this:
    

    <?php
    function computed_field_field_your_field_name_compute($entity_type_manager, $entity, $fields, $delta) {
      // Paste code from the Computed Field here
    }
    

11. Save changes to the .module file
12. Optionally comment out the code in the Computed Field to ensure the module is overriding the Computed Field
13. Enable the module
14. Test that your computed field works

I realize certain situations may require the original PHP code to be edited, this was not the case for me.

Oh I've just realised you're talking about migrating to version 3. I got the version numbers mixed up -- I was thinking of version 4.

Correct. I'd go right to version 4 but I can't do that while still in D8, and since modules have to be upgraded before Core can be upgraded, it's a chicken and egg situation.