9 Replies Latest reply on Oct 19, 2012 11:08 AM by martinc

    Should we proceed and convert to v12?

    kiwikaty

      I would like to do a poll of the community that requires only a "yes convert" or "no wait" answer

       

      We have 200 users that will need to be upgraded to v12 from v11 on a PC by PC basis and the solution to be converted from v11 to v12 is not small... 16 integrated files, 240 tables, 13,500 fields and over 1000 layouts.

       

      We are using other technologies like CWP, OBDC/JDBC and XML exchanges and run a large number or daily scheduled scripts (some of which create pdfs for the websites).

       

      Everything I read on the forum about v12 is rather frightening. If you were in my position would you proceed with the conversion or wait until more of the "bugs" are ironed out?

       

      Note: They are currently "letting staff go" at my workplace so I would rather not come under the spotlight by introducing a host of problems that we do not have already. We have a VLA.

       

      I just need simple "yes convert" or "no wait" answer to the question "Should we proceed and convert to v12?" ...and am especially interested in responses from anyone who works for fm inc!

       

      Many thanks for your time.

        • 1. Re: Should we proceed and convert to v12?
          wimdecorte

          I don't think a poll will do you much good... the only safe way to proceed is to convert your solution and test it before going live with it.  You really do not want to trust your busines critical solution to somebody's opinion, me thinks.

          • 2. Re: Should we proceed and convert to v12?
            kiwikaty

            I appreciate what you are saying but so many others on this forum have the benefit of experience.

             

            To do the conversion I have to put a development freeze on the production system and initial testing I have done suggests I will probably end up applying a theme to the layouts rather then leaving them with the converted css. I was also going to take the opportunity of having a good clean up because this system has gone through over 10 years of conversions now and was originally created in fm 5!

             

            I just don't want to spend all this time to discover that fm12 can no longer generate the pdfs for the websites without crashing or print users reports or become inexplicably slow when doing layout development or any of the other things I have read about on this forum.

             

            Sure I can do a straight conversion and put it on my dev server and have a play with it (actually I have done this) but my own experience has taught me that this will not give me any real indication what is going to happen once in production where users are connected to a huge range of peripherals and the system is actively integrating with the other university systems. I have been doing this too long now not to be very very weary.

             

            I just am curious how many fm developers who have done fm12 migrations would suggest to hold off a little longer. I am well aware that no one can predict what will happen in our environment - it would be nice to have that crystal ball though !

            • 3. Re: Should we proceed and convert to v12?
              mardikennedy

              I'm choosing to postpone the upgrade until after I have a Test/ Sandpit install of FMSA v12.  (That'll be about Jan 2013.)  The idea is to run user/ load tests in the sandpit for two to four weeks before doing a formal migration from FMSA v11 to FMSA v12.  Environment is a bit different to yours.  Less complexity in the solutions but more of them, each one accessed by a (different) smallish group of geographically dispersed users.  Number of users per solution varies considerably, but still at the small end of the scale.

               

              Cheers,

              Mardi Kennedy

              • 4. Re: Should we proceed and convert to v12?
                wsvp

                I agree with wimdecorte...

                 

                Also consider what you will gain by upgrading.  If your plan is to keep your solution pretty much "as is" then I don't see a tremendous reason to upgrade... Thus I would adhere to the "IF IT AIN'T BROKE, DON'T FIX IT" rule.  On the other hand if you really need to leverage any of FM12's new features (mostly graphical) then I would proceed with caution.  Prepare for a "lot" of layout work if you convert.

                 

                There are many things I like about FM12, But for me... most of the enhancements will improve interface design options.  Very little has changed in the Data Structure of FM (at least from our perspective.)

                 

                In either case TEST EXTENSIVELY, before implementation.

                • 5. Re: Should we proceed and convert to v12?
                  GordonShewach

                  Testing your specific solution, as Wim suggested, is of course the only way to know for sure.

                   

                  But since you're looking for words of experience, I will tell you that I've upgraded 10 solutions from 11 to 12. Eight of them did fine with, at worst, some minor issues that were easily handled. One encountered a major performance issue that prompted my client to ask for a downgrade (we HAD tested first!). I did some workarounds to avoid these issues, so this client is now successfully upgraded to 12. And one solution simply had too many performance issues during testing, so this client has stayed at 11.

                   

                  What do the latter 2 solutions have in common that created issues? Complexity. The one I found workarounds for is of above average complexity. The one that stayed at 11 is of high complexity. The main problem I've found is a slowdown in the calculation engine that can bring complex calculation fields to a crawl. While a Filemaker engineer told me to just change these to indexible fields based on script triggers, that's not a realistic solution to a database that's been upgraded daily/weekly for the past 15 years, without spending months and tens of thousands of dollars.

                   

                  Your solution appears to be very complex and I would speculate that you would run into problems.

                   

                  Gordon Shewach

                  Desktop Services

                  Ann Arbor, MI

                  1 of 1 people found this helpful
                  • 6. Re: Should we proceed and convert to v12?
                    kiwikaty

                    Perfect, thank you, this was just the type of advice I was after.

                     

                    This gives me another thing to add to the list of things to specficially test as we have hundreds of unstored calcs and as a large quantity of data is brought in each night from other systems (this process already takes 5-6 hours); script triggers would not be a solution and I am not going to run nightly replaces after the data imports because there are far far too many of them to make this even a consideration.

                     

                    I really appreciate your time in writing a response.

                     

                    Kind regards

                    Katy

                    • 7. Re: Should we proceed and convert to v12?
                      beverly

                      An auto-enter calc is a calc that fires upon entry (import, typing) It would not be any slower than your current multi-tude of calculations. With the change to these, the fields are highly indexable. The question becomes: do these need to constantly change or would a trigger 're-calc a previous auto-enter' when needed? If the field doesn't change once "set", then I opine that changing to auto-enter is the way to go.

                       

                      If you change a field from previous "calculation" to "auto-enter", the field definition should retain the calc and the field should retain the value as it was last calculated.

                      Beverly

                       

                      This gives me another thing to add to the list of things to specficially test as we have hundreds of unstored calcs and as a large quantity of data is brought in each night from other systems (this process already takes 5-6 hours); script triggers would not be a solution and I am not going to run nightly replaces after the data imports because there are far far too many of them to make this even a consideration.

                       

                      • 8. Re: Should we proceed and convert to v12?
                        DavidJondreau

                        No, wait.

                         

                        Based on your description, I would say definitely do not convert.

                         

                        I love FMP12. Any new solutions I build will be in 12. We've converted our templates and smaller solutions. But not our big ones.

                         

                        The issue for me is not any possible bugs in FMP 12, but that users hate change. The conversion process is mostly painless, but any slight pain will get magnified.

                         

                        You have a thoroughly developed, well-functioning system already built. Wait until users and management request changes to the system that can't be done in 11. That may be several years down the road. Or never. There are companies happy today with their FMP 5 systems.

                        • 9. Re: Should we proceed and convert to v12?
                          martinc

                          Don't do it.  We installed FMsa12 on its own server and after 30 minutes of testing found it crashed the app when creating PDFs and was slower loading forms.  And yes, I'm not happy.  If I ran my business like that (selling hard on a bad product), I'd be done.