I routinely use scripted routines for data migration, but have avoided having the database on the server for two reasons. First, the performance isn't so good, since you're dealing with network issues that may be significant (depending on the environment). And second, you have to do something to keep the users' fingers out of the solution while you're performing the migration. I went to a session at DevCon this year about data migration, and the presenter did state that he does his migrations on the server, but uses a "redirect" to bounce users over to a "Maintenance In Progress" file.
It's probably just me, but that sounds like a lot of extra work to set up when you can avoid the whole issue - and the performance hit - by just doing it locally. When the migration's finished, you just upload the new version to the server to replace the old one. Others may have a different take.
I give you the thumbs up. Thats exactly how I do it for the last 15 years.
It is fine that someone can implement a "server work in progress" diversion file to show up and it might be necessary for solutions in large organizations working 24/7 but I play it save and to to actual an upload which is done locally in 10 to 15 minutes.
I do the following:
- upgrade the core and test in FMPA locally and then in isolated test environment
- clean the shell
- reset all ID counters
- clean security access and other settings
- prepare a list of user preferences and security setting for access
- export data from existing dB
- run test import scrips into new application (and test for bugs) and checking conversion log !
- flush dB again
- do another import and implement as much security settings as possible at this stage
- save file(s) to thumb drive
- stop FM server and all related process
- send msg from server (or sometimes not when doing at night time)
- move old dB to (old folder)
- upload new dB to server
- server restart
- start console
- adjust settings in console as required
- test login etc.
If possible do it at night time and with full serer access, either physical or remote access.
It works just fine for 15 odd years, can't be so wrong. ;-)