Advice on a 6 to 8 rollout plan!

[ktstem]

Hello All!

I work for a school district that is happily running on FileMaker 6 Server. This summer we’ve decided that it’s time to convert to 8, we don’t want to get too behind and there NEVER seems to be a “good” time to make the jump. I’m not nervous about the conversion part, even though we haven’t been running 8, I have been working in it and already have FM8 Server running.

My issue is that I’m so unsure of the best way to roll it out. See I’m not just converting the existing databases, I’m merging a lot of it together once it’s converted. For example, there is a staff roster database that I now want to make the core of it all. Then there are conference requests, field trips, work orders and much more that I want to link all together for one school-wide system (super excited). So what do you do when there are always people working in these files? Plus I have to worry about getting FileMaker 8 installed on about 200 teacher laptops. That’s JUST elementary school teachers, the rest should be taken care of according to tech support because they are getting upgraded with new software through imaging.

Meanwhile my head is spinning because I’m trying to do all my “year-end” procedures! So at this point, since I wrote this all out I’m thinking is it best to let everyone run on FileMaker 6 while I convert to FileMaker 8. I can import the work they do in 6 while I’m working on 8, right?

I just need a little guidance and a shove in the right direction!

Thanks so much,

Kate :P

Edited June 22, 2006 by Guest

[John Mark Osborne]

One option is to convert the solution to FileMaker 8 with no modifications. You may have to fix some problems but it shouldn't take you long. This could be minutes, hours or days of work but certainly a lot less than rewriting it. This will allow you to take your time rewriting the solution so you can benefit from the advantages of FileMaker 8 and the FileMaker 8 Server. Once you are done rewriting the solution, import the data from the old solution into the new one and you are ready to go.

I'm sure others will provide different advice. There is no right way to do this. Pick and choose the options you think are best.

[Tricky]

Hi Kate,

I am in a similar situation and have asked many developers the same question.

I have actually tried to upgrade and not change much, but to me, that was not satisfatory for two reasons:

-the solution, once upgraded, is excruciatingly slow

-there are calcs that no longer exist or need to be approached in a different way

Example: I rely, in 6, in many cases on the fact that I do a 'go to related set' script step and trust that if there are none, the table will have zeroe records selected. The same goes for a perform find that is not valid. But FM8 behaves in a different was. Same for imports. You need to be very aware what you are doing and where you are doing it, what with the relation between table occurrences and layouts. That is, by the way, the only thing I do not like about 8: that link between layouts and table occurrences. But I guess that is a different subject altogether.

So, what I have done is ask a fellow developer I work with, who is proficient in version 8, to advise me. And he told me: re-design the whole thing. He has run into many, many people who believe that they can use FM8 in the same way as FMP6 and earlier versions, and they almost always run into problems. FM8 simply is no longer as tolerant as previous versions when it comes to creative programming, to put it nicely.

I can give you a nice example. I replied to a post the other day of somebody who wanted a field to reflect the items from a value list, one by one. So, with previous and next buttons. I am not saying the script I posted in that topic was the best you can do in FMP6. There are possibly other approaches. But if you then look at the solution built in FM8, it is shocking to see the differences. Mine is a three part, multi script step script, with three new fields that must be created as well. In FM8 on the other hand it is a one line single script, that uses not only the new variables, but also the option of passing info via script parameters. We do not have all of that in FMP6. My solution would probably work in FM8, but would it be the best I could do? Certainly not!

Also, in the way of understanding and organising your design, there is so much more simplicity in doing stuff, that it is simply a lost chance if you would not re-build.

You can upgrade the files to make the contents available, that is a good idea. And import them into the new solution when you are ready. But that is a bit of a daunting task as well, I can tell you that beforehand.

As FM8 and FMP6 can run together, albeit on separate server machines, you could maybe take your sweet time to rebuild and test and by the time you are ready to rock, your IT guys would have finished the roll-out of the new software for all of those who are required to have it.

Filemaker allows for both versions to run for awhile under the same licence agreement, as long as you upgrade in the end, or the total of seats installed does not exceed the agreement. A permanent mix of versions would then not be a breach of contract.

Anyway, I would like for you to keep me posted on this, as I will have to do this also. I have been redesigning a legacy solution in FMP6, always with the clear objective of moving it to FM8. That is also how I built it. But the upgrade to FM8 has not happened yet. While my 300 users are getting used to the new design, I will be rebuilding it, using the new design as a functional and technical specification.

Good luck with your decisions!

[IdealData]

"Excruciatingly slow" - you must fix the file references.

I did a conversion last year (20 dbs) and it went pretty smoothly and I am also facing the same problems with my own 60db system within 12 months.

Personally I'll go with JMO's philosophy as I reckon I an fix it on the fly - athough it will be hell for a few weeks.

[Tricky]

Did that, fixing the refs. Whichever choice to make depends on whether you like to be in hell for awhile... I'd rather start from scratch, but hey, that is just my approach...

[ktstem]

I'm just starting my day with a BIG cup of coffee and reading your advice and trying to take it all in! I think what John said was kind of what I was thinking....convert, modify and import.

I think I was getting myself all up in a bunch thinking I had to do everything at the same time. Convert, get the users on 8 and merge into one solution. I realize now that I have to take everything in steps! OH yeah and in this district, it's never take your sweet time! My boss is a Mac lover (me too) and his mentalitly follows that of Mac....out with the old and in with the new...NOW! Jump, jump, jump!! I guess I like the pace though

Tricky, I will definately keep you posted of the bumps and bruises I encounter along the way!

Kate :D

[Ender]

Hi Kate, I'd recommend you read FileMaker's Migration tech brief:

http://www.filemaker.com/support/whitepapers.html

It outlines a few different migration strategies (some of which are mentioned here), listing some of the pros and cons of each.

In any case, converting a complex solution is not likely to be a simple matter, even to get it working in its current multi-file architecture. There are a number of conversion issues that need to be checked before you make the solution available to users (again, see the Migration tech brief.)

I'd also advise against the strategy of running both versions simultaneously. In complex solutions, the data from different tables/files is usually interrelated enough that splitting the solution into separate applications would not be desireable. And duplicating a table/file into both versions would also be problematic as they would not be syncronized.

In my opinion, it's best to spend the time before rolling out to users, either fixing and testing all of the conversion issues in the converted solution, or rewriting the solution from scratch. While either option can be a lot of work, it's much better to get the kinks worked out before users get in there and either start getting frustrated with the new version, or worse, manage to scramble existing data because of some bug.

I don't know what the cause of Tricky's speed issues might be, but with good server hardware/software, FM8 performs noticeably faster in almost all tasks.

[Søren Dyhr]

FM8 simply is no longer as tolerant as previous versions when it comes to creative programming, to put it nicely.

This is a very important point she makea here, especially the forgivingness when applying relational mechanics to your solution ...requires stronger skills and disipline to prevent your relations graph from confusing you more that being a tool to approach and understand the inner mechanincs of a solution.

One of the most indigestive issues is that although you can mix querries in the graph with datastructure - but if you need it to work predictable do you have to make several more table occurences of the involved tables...

--sd

[ktstem]

Thanks for the link Ender, I'm going to sift through that this afternoon!

Running both versions would not be an option for me, not because of splitting solutions up but because I don't want my users to have to remember which version of FileMaker to open to get which database they need. That will REALLY confuse those who are not tech savvy. I want everything to be ready on 8 before I take them there.

I have seen and worked with how relationships are handled differently in FM8, but once again...I don't think my solutions are complex enough that this will be a big issue. I understand the concepts and can get things to work, that's what I love about FileMaker! I don't have to be an expert developer to create efficient solutions, but I'm striving to get there! I hope this doesn't sound like I'm taking a naive approach to this :)

[Søren Dyhr]

I don't have to be an expert developer to create efficient solutions

How is it the saying goes?

Good judgement comes from experience

But experience comes from bad judgement.

--sd

[ktstem]

hahaha, good one. I definately make my share of bad judgement calls.

[Oldfogey]

My 2 cents' worth.

I second JMO's strategy. There are many reason for doing so but, for me, one of the main ones is that the different behaviour of V8 compared with V6 uncovered some semi-bugs in my stuff that V6 had let me get away with.

Also, I am guessing that your application has been developed over many years. Re-designing it is going to take ages. Also, V8 is so different from V6 that you need to get immersed in V8 before you re-design.

[ktstem]

"oldfogey" (now I was taught to respect my elders), you make a great point about getting immersed in version 8 before re-design. I've worked with it, but am not completely comfortable in it. I think I've been given a lot of great advice here to push me in the right direction, I'm so thankful for that :)

[Tricky]

Kate: good luck with your decisions!

Someone says: it takes ages to re-design. Yes, this is true. I have been doing it and not even from one Filemaker version to the other, but from one old legacy solution (very complex) and up until now it is taking me 3 years. Still no launch. Do I regret doing that and having to redesign again in FM8? Nah. The new design has been set up with FM8 in mind (well, 7 at the time). So, the new design in FMP6 is excellent specification material for re-design in 8. Whether it is worth redesigning or upgrading to me is not a question. I believe that older solutions always have stuff in them that should be cleaned up and can be done better in FM8. Sure it takes time, but the end result, I believe, will be a lot better. If you allow yourself to get stuck in upgrading and then searching for bugs, I believe you will get confused.

But, it is your decision and I am looking forward to hearing more about the process!