We used to have a feature in BE to import data from a previous version of BE into the current one, but it's been removed from the most recent releases.
So back in v3 or thereabouts, we moved to the 3 file model with a separate data file. This wasn't for any "separation" advantages, it was for performance issues ( if you have fewer files open when running imports, then there are fewer Table Occurrences to cache and so record commits are faster. Closing the UI file made a huge difference as there are lots of TOs in that file. )
During that release cycle we tracked whether or not there was a change to the data file, or the UI file and whether or not you could just replace the UI file, or if you needed to re-import from the data file, or re-import from the XML ( because of changes to the import process ).
In almost every case, in order for BE to be accurate, you needed to import from the XML.
This is because we change what data is brought in most of the time, and therefore if you have a feature in BE but no data ( because you imported from a previous version ) it will appear to be wrong.
Accuracy is the priority
The biggest thing we have in our minds when building and developing BE is that it has to be highly accurate. It has to represent the file, or the value of BE diminishes as you no longer can rely on it. An import from previous versions will not be accurate most of the time. So it's not included as a feature.
What else can I do?
Setup a workflow to retain the XML, it's the most accurate and complete data you have. Zip the files, they'll compress well and store just the zip file. Then you can re-import into any future version at any time.