Writing it to Postgres directly, even creating all the required meta data, would still break when r3 gets an update. After the update, r3 could handle the meta data differently to before (new stuff coming in, old stuff being removed, options being migrated, etc.).
The only way this is future-proof, is to integrate it into r3. Meaning somebody would have to translate an imported data set (like a set of relations from a CSV file) to r3 internal schema manipulation calls (the "schema" represents the app at any point in time). Then if the schema changes, the import calls would need to be updated to work with the new schema. This still means more work in the future to update r3, but it would be much more robust.
This is possible, but with the amount of features & options, a CSV just for importing attributes (eg. table columns) would be pretty big. One could sit down and consider the features/options that would be most important to import and remove the rest - the last 10% could be configured inside r3. This would be a sensible approach I think.
All this is doable within a week or two, but would only cover basic entities (relations/attributes for example). Importing forms or even code would be orders of magnitute more complicated and not worth it in my view.
If you are interested in helping build this, we could get into touch and I could show you what you would need to do. Luckily, you would not need to interact with 90% of the code base - just the backend calls for manipulating the application schemas.
