4 Replies Latest reply on May 12, 2014 12:40 PM by Mike_Mitchell

    Server upgrade V5 -> V13


      Hello all,


      I have a client that has FM server V5 (20 users I believe) and they have FM V5 on the clients. They wish to upgrade most of the Macs to the lastest OS and also upgrade FMS and clients to latest versions.


      They've asked me to consider a three phase project:


      phase 1 - The upgrade

      phase 2 - Layout cleanup

      phase 3 - Additional integration of their tables


      Phase 1 is the upgrade. We have a chicken-egg problem in that they cannot upgrade their macs right away to latest OS. So we want to install the server upgrade for FMS on a different, new server computer, but keep the old running until each client can be upgraded to latest OS as well as FM 13.


      Here are my questions:


      1) What will the upgrade process belike from FMS V5 to V13? IE is it as simple as just installing FMS V13 and opening a copy of the prior database and everything will convert? Considering that they are on V5 and really not using much other than some layouts there is not a lot of scripting or other things I would be too concerned about.


      2) Assuming that #1 is as simple as I hope it is is it possible to have their older V5 clients talking to the new V13 server? Probably not but have to ask!


      3) Obviously the company needs to keep working meaning their older V5 server and clients need to stay alive. Ideally after the new server is setup with FMS V13 I'd like to come up with a way that any new data added to the older FMS V5 is automatically pumped to the new server. Anybody tried to do something like this? At worst case we could export periodically and import I would guess. The hope here is that I can keep the new server up to date data-wise so a new client can be compared to the old client to see if things are working.


      Any help/suggestions would be appreciated. I have to put together a proposal for this client in the next couple of days.


      Thanks in advance - Mark


        • 1. Re: Server upgrade V5 -> V13

          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).

          • 2. Re: Server upgrade V5 -> V13

            Hi Mike,


            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.

            • 3. Re: Server upgrade V5 -> V13

              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.

              • 4. Re: Server upgrade V5 -> V13

                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.