Your hosting company may be able to run WP CLI commands for you. You could ask them in case that’s possible.
I don’t think we’ll add more components to Pods in the future. We are looking at ways to make sure the plugin’s footprint doesn’t grow in size and scope.
As for UI, I’d love to add UI for this and other commands that we have. I just don’t have the UI/code in place to support large processes like this on shared hosting providers with lower resources/limits via HTTP requests.
I was having challenges with the convert command in recent versions; it may need revisiting.
In the meantime, this comment from this week shows a short example of migrating a Post Meta Table Storage Pod to a Post Meta stored in wp/postmeta table Pod.
For use outside of wp-cli, one could run the function attached to cli_init on any page by setting $from and $to to the names of the source and target Pods, then removing lines referencing WP_CLI, such as \WP_CLI::log( ... ).
The limitation of not doing a migration via CLI is most hosts will stop the process after 30 seconds. The above linked example will not import duplicates, so it could be run many times every 30 to 40 seconds until complete, if there are many posts.
If the use case is Advanced Content Types (full custom table storage), one might need to map changes in field names after the lines for $field_values = array_reduce( … ) , for example, reassigning $field_values[ 'name' ] to $field_values[ 'post_title' ].
The core functionality of the example is that it fetches all fields for the source Pod, then uses pods()->save() to copy them to the new Pod. As long as field names are the same or are mapped appropriately, and data types of the sources and destinations are the same, ->save() should handle complex data types, such as multiple relationships or multiple files in one field.
