It's not easy, the upgrade you missed from 5 to 7 can make it difficult. The upgrade from 7-11 to 12/13 is much easier. AFAIK, you can NOT directly convert a .fp5 file to .fmp12, even if you could I would advise against it.
If I were you, I would set up and build your entire environment in FM13, based on the data separation model (single file for data, single file for interface). You could then convert all of your .fp5 files to .fp7, then .fmp12, and finally import them into your "live" environment. You could script all the imports into your .fmp12 data file, so in later "updates", the only step to import/update data from the V5 system would be to convert the files to .fmp12, drop them in a directory, and run a script.
Obviously, the most ideal thing would be to have a hard cutover to the new system, and have it thoroughly vetted before you migrate the 20 users. Having users in mixed-use is not great at all.
Make sure the client is firmly aware of the horsepower requirements to run the FM13 platform, as it will most likely run like poo on old hardware (which could make you look like the bad guy).
Thanks for the quick reply. My response is Ugh... darn I wish it were easier but you make some good points.
So if I understand your suggestion correctly:
a) I should manually rebuild their tables, layouts, etc in V13. Correct me if I read your response wrong. (probably not too terrible as their older stuff is not that complex). I agree on the data separation
b) I guess then I could either convert their data or perhaps I could even just export/import it. Their entire data file is like 14mb so we are not talking much.
I agree about the hard cut. I was thinking perhaps we could keep things working in parallel but perhaps that is asking for disaster.
I'll check on their new server. I think it is Zeon based but good point.
a) You can build the "data" file of your data separated model by importing all of the converted .fp5 files into a single file. You will most likely have to re-establish some relationships and update calculations as part of this. BUT, it comes with the distinct advantage of "script as you go", so you only have to do the work once, script to duplicate the functions you just did manually, then it's automated from there out.
Your database will perform better if you rebuild the layouts, that's the nature of 13, and it opens up a better gateway to Filemaker Go and WebDirect use by your client. You might be able to convert / copy / paste / restyle a lot of your layout objects.
As for scripts, you can convert / copy and paste some of it, but you might offer optimization/rebuild as part of your agreement, you'd be surprised how much you probably code better, and how much has changed in filemaker, over the past 13 years.
b) that makes a) above even easier.
Besides, V5 pegs the solution at 13-14 years old, it will be worth the development investment for them to do it "the right way" now for an equal return on investment for the future.
Mike B is correct; you cannot convert directly from .fp5 to .fmp12. You'll need to go through the .fp7 format first.
We've done a lot of these conversions in the last several years. (I have some holdouts here who are still clinging to their .fp5 applications.) Mike is 100% correct about the gains you can see from a rebuild. As an example, I had one solution that was a multi-file (over 60 files) .fp5 solution. It had one script that printed out at 151 pages. Even in the .fp7 days, I was able to reduce it to a page and a half, just because of improved scripting techniques available in version 7 and using the separation model. (The savings in my sanity were a bonus.)
So I would push to do a rewrite. Keep the feature set; scrap the old implementation and go with doing things as you're able to now.
I would also recommend against trying to run the systems in parallel, except perhaps in a testing / evaluation mode. It might be useful to get the client's feedback as you build, simultaneously making sure the new version performs as expected compared to the old one.
For your consideration, I've attached a migration strategy document from several years back. This covers moving from .fp5 to .fp7, so take it with a grain of salt, but it does cover the crucial paradigm shift that came with the ability to have multiple tables per file (i.e., breaking the one table = one file setup we had prior to version 7).
Good luck, and feel free to jump back into the forum and ask questions as you proceed.