i'm unsure what you are asking, sorry.
Have you read through the forum designed for separation? http://fmforums.com/...the-separation-model/ Oh, LOL, you ARE here!
Both your Data file and your pristine master copy of UI should be copied to your Development server and the file references should be local (usually always). In this way, you won't mess up production data during testing and you will not run into (or cause) record locks while you develop. If your system ever crashes during development, trash the UI and grab another clean master. It will be easy to bring a new UI up to synch with your current-version changes since you hopefully have kept meticulous details of every change as you go.
You must be sure to make any changes in production Data file precisely AND in the same *field-creation order and hopefully make those changes when Users are not in the system. This is easy to handle by documenting every Data file change which you should always document anyway. Or you can migrate the data (something I avoid since it opens possibility of error during imports and usually takes much longer).
So User scripts and layouts exist only within the UI. The Data file's graph will only hold the minimal relationship to permit any auto-enter calculations or calculation fields (which should be kept to minimum anyway). The Data file usually only ends up with a single entity-style relationship ( for
passing auto-entering keys or default related data) and a few scripts or developer layouts and of course, proper security.
So perform your work on Development version then schedule a time when you can 1) make the changes (usually few) in the Data file and 2) replace the UI with your Development version. There is another possible detail which should not be forgotten ... if any of your new processes require data be pre-filled with existing data or any of the Production data must be changed to adhere to new business rules being implemented, you must also perform those actions at that time. The easiest way to handle that is to create a script in your Development UI which updates the data (be sure to error trap for record locks if Users must remain in the system).
As you are designing in the UI, create a new script called Update Data (example). In this script, I use comments to list all the changes which require data change and most times, I write the script steps at that too also as I add that functionality, while it is fresh. In this way, you can test: a) copy a latest copy of Data in to Development, b ) make the schema changes you have documented in exact order and c) run your script to update any data. As Developer, you can then perform test runs to be sure the steps are clear and also to provide you with the time required from start to finish. Then the results should be scrutinised both by Developer and Business to be sure the changes translate properly in your Development copy before moving it to Production.
Once those three steps are done, you can move forward with your update with confidence.
* Added: you could also include a gazillion of empty fields in every table so as to adhere to the same order but I see that as unnecessary and bloating when a bit of discipline in documenting does the job as well.
Added also: BTW, I run recover on both a copy of Production and the development version frequently (sometimes every day). Any indication of corruption and I revert to prior pristine UI.