With frequent requests for integration with other environments, I recommend standardizing export/import for all WPMU DEV plugins.
There was just a request to Import FROM Sabai Directory Listings TO Jobs & Experts. We often see Forminator as the FROM or TO. We see WooCommerce as the FROM and MarketPress as the TO, or the other way around. Or we see other plugins and databases as the FROM or TO with the Defender IP blacklist.
It doesn't matter what the FROM/TO points are. And yet all of these requests for specific X/Y translations are approached as though they're separate projects requiring management consideration, evaluation of resources, and other rigorous actions.
Just focus on one plugin at a time. Document a standard database-oriented import and export as database queries. The external sources and targets are irrelevant. Then create import an export functions for major classes, with documentation that reads "Pass 'this' JSON structure to the import() function and a record will be created." Or "Execute the export(ID) function, and the result is 'this' JSON structure."
The problem for us in the field is that we don't know the database schema, or exactly how you craft related records, or what kind of validation is performed to ensure bad data doesn't cause corruption. It would be ideal if you could create import/export functions that threw exceptions or returned documented errors when our source data would cause such errors. But first, please just document how these things work so that we can create our own interfaces until you get around to each one.
This wouldn't just benefit us. When you hire a new developer, they'll have documentation that explains how the data works! And with existing import and export functions, it will be Much easier every time you take on one of these FROM/TO projects, because you'll already have your side of the equation coded and documented.
From a business perspective this would also make it easier for developers of any other plugins to interface with WPMU DEV plugins. When other developers embrace interfaces with your plugins, it's implied that end-users are using your plugins for that integration.
Might easier exports facilitate migrations? I don't know if that's a consideration at WPMU DEV but it's huge in my non-WP industry. To this I suggest paranoia comes from being a poor competitor - we can try to keep people from migrating from our poor products or we can simply improve our products so that people will want to use our import functionality more than our exports. I don't think WPMU DEV suffers from this, but ... just sayin ...
This dove-tails with my other notes about extensibility, but it's not quite the same. Extensibility via hooks allows us to interface with transactions. Import/Export is generally handled outside of that process - though there's nothing wrong with hooks that intercept data which is being exported or imported, so that we can more finely tune the data that we're receiving from business partners or providing to them.
Where exports and extensibility meet is in reporting, where we want to see data in different ways, and make use of that data in other components. For examples: Display a count of how many people have submitted a response to a Forminator Poll. Show the current poll data in Hustle or E-Newsletter. Plot the general locations, using Google Maps plugin, of members who have and who have not responded to specific polls. Extract a list of phone numbers for specific Membership2 members so that we can SMS then a notice of a new Events+ event.
There are SO many things that are not possible right now because all of these plugins live in a silo - just like most plugins. I encourage you to set an example, get some good Marketing for making it a priority to share data. Perhaps others will follow the example. That would be really great for all WP users.