Migration Choices

If you've never touched FileMaker Pro prior to version 7 or 8, the material in this chapter might not be of much use to you. On the other hand, anyone who has ever built or currently maintains systems in previous versions of FileMaker Pro faces a significant set of decisions regarding whether and how to migrate those systems to FileMaker Pro 8.

You've likely heard, read, or discovered on your own that the 2004 release of FileMaker Pro 7 brought tremendous changes to the FileMaker product line. The last time the product experienced such a fundamental change was in moving from version 2.1 to 3.0. If you were working with FileMaker back then (way back in 1995), you probably remember that a lot of unlearning, relearning, converting, and rebuilding had to take place. For the first time, in FileMaker Pro 3.0, the product contained such important tools as relationships and portals. It took quite a while for developers proficient with FileMaker 2.1 to fully understand relational database concepts and the benefits that portals and related fields offered over repeating fields and lookups. It was possible to convert solutions from 2.1 to 3.0 without loss of functionality, but to take advantage of the powerful new features required either extensive redevelopment or, in some cases, rebuilding the files from scratch. The same holds true of the migration from FileMaker 6.x to 7 or 8.

The features introduced in versions 4.x, 5.x, and 6 can perhaps be described as more evolutionary than revolutionary. Web publishing, plug-ins, and data exchange via ODBC all were important extensions to FileMaker, but none of them required fundamental mind-shifts, nor was there any concern that a converted solution might not function exactly as it had previously.

FileMaker 7, on the other hand, represented a revolutionary shift from its predecessors. The ability to place multiple tables in a single file, the addition of an entirely new security model, the ability to create relationships based on multiple match fields, the ability to have multiple windows open in a file, server-based web publishing tools, and custom functions are some of the biggest changes, but there are myriad subtle changes as well, ranging from being able to add comments to fields and calculation formulas to changes in how alphabetic characters placed in number fields are interpreted.

Because of the sweeping changes, conversion of existing solutions into FileMaker Pro 7 or 8 becomes a complex issue. There are circumstances where it will be a better idea to rewrite a solution completely rather than convert it; even if you do convert, you may need to do considerable development work and testing before the converted solution can be deployed. In the end, the effort to do either is well worthwhile. This chapter helps you identify the migration strategy that makes the best sense for your solution and how to go about it.

Conversion What s New in 8?

FileMaker 8 builds on FileMaker 7's deep architectural changes with many new, powerful features, but the conversion picture, with respect to systems written in FileMaker 6 and before, stays more or less the same. Converting a system to FileMaker 8 entails the same range of considerations as converting to FileMaker 7. By contrast, FileMaker 7 and FileMaker 8 share a common file format; files are virtually interchangeable between the two. FileMaker 8 clients can access files served on a FileMaker 7 server, and vice versa; the only provision is that a FileMaker 7 client will not be able to use features specific to FileMaker 8.

In any case, all considerations in this chapter apply equally well to files being converted from FileMaker 6 and before into either FileMaker 7 or FileMaker 8. Occasionally, we might refer to "FileMaker 8" as shorthand for the more cumbersome "FileMaker 7 and/or 8." Rest assured that the fundamental distinction here is between FileMaker 6 or earlier (.fp3, .fp5) and FileMaker 7 or later (.fp7). This chapter deals with converting .fp3 and .fp5 files to a .fp7 system.

Note, however, that FileMaker 8 Advanced does offer a number of useful tools (such as the capability to copy and paste fields and tables) that can make post-conversion work, such as consolidating tables, easier.

 

Factors Influencing Your Migration Strategy

By the term migration, we mean simply the concept of moving a solution from version 6 of FileMaker or earlier to version 8. You can employ two primary strategies to effect a migration. The first is to convert your solution using the built-in routines in FileMaker 8. The other is to rewrite your solution as a fresh set of FileMaker Pro 8 files.

The decision about how (and indeed whether) to migrate your older solution will be informed by a number of factors, including your future needs, the benefits you hope to reap through migration, the complexity of your solution, and your timeline and available resources. You may decide that some of your solutions can simply be converted; other solutions may be better off being rewritten from scratch.

Migration Benefits

Of all the new features and benefits of FileMaker Pro 7 and 8, there will undoubtedly be some features that matter more to you than others in a decision to convert. For some people, support for Unicode may be a compelling reason to upgrade, whereas others may not find this feature relevant. Some people will choose to migrate to use the new security features; others for the new Instant Web Publishing. For existing solutions, determine what specific benefits you hope to achieve by migrating to FileMaker Pro 8; if you decide to migrate, you'll then need to determine whether those benefits can best be attained by conversion or rewriting. Sometimes the desired benefits will completely drive the migration strategy; other times they will play a lesser role in the decision.

Centralized security is a good example of a reason to rewrite rather than convert. Anyone who's maintained complex security settings in a 50-file solution will welcome the ability to assign accounts and privileges for all the tables in a file at once. When you convert a multifile solution from an eralier version of FileMaker, however, each file in the existing systems turns into a one-table file in the new system, and there's no easy way to consolidate tables into the same file (although FileMaker Pro 8 Advanced does offer some useful toolssuch as the capability to copy and paste tables and fieldsthat can make consolidation a bit easier). So, after converting a 50-file solution, even if everything works flawlessly, you'll still need to manage accounts and privileges in 50 different places. If centralized security is a crucial feature for you, you may prefer to rewrite your solution as a single-file application in FileMaker 8.

If you do attempt to consolidate tables, there are some potential issues you should be aware of. See "Repointing Table Occurrence References" in the "Troubleshooting" section at the end of this chapter

Many other benefits will be just as achievable through straight conversion as through a rewrite. Examples of these include larger field and file size limits, the ability to put binary data into container fields, support for Unicode, and encrypted data transfer between FileMaker Server and client applications.

Another class of benefits can be achieved by a rewrite or through a hybrid of conversion and subsequent development. For instance, your solution may have work-arounds to get around limitations of previous versions of FileMaker. After conversion, those work-arounds will still be in place, but they may no longer be necessary; your converted solution may be FileMaker 8 compatible but it may not be FileMaker 8 optimized. Examples of features that you won't benefit from unless you rewrite or do post-conversion development include custom functions, script parameters, script variables, text formatting functions, new layout objects such as the tab control and calendar picker, and relationships based on complex match criteria.

Complexity

Complexity is such a subjective and nebulous concept that it's hard to pin down the effect of solution complexity on the decision to convert or rewrite. All other things being equalwhich of course they never arewe feel the more complex a solution is, the more likely it is that you'll prefer to rewrite from scratch rather than convert.

To some extent, complexity can be measured by sheer numbers: number of scripts, number of files, number of relationships, and number of layouts. But there are qualitative measurements of complexity that may override the quantitative: Having a hundred simple navigation scripts is less complex than having a hundred scripts that do, well...complex things. Complexity also may involve interactions with external systems, or simply very complicated business logic.

So why is it better to rewrite than to convert a complex solution? If some features don't work properly in a complex system after conversion, it can be very time consuming to find and fix the problems. Further, it can be almost impossible in complex systems to systematically test every button and script to ensure that it functions as it's supposed to. It's possible that some conversion issues won't be easy to discover, resulting in problems well down the road.

When you create a system from scratch, you test components as you go, so it's less likely that there will be lingering issues after the system is deployed. Also, in a rewritten FileMaker 8 system, it's almost always possible to achieve your previous functionality with significantly fewer objects and global fields: fewer fields because you won't need as many unstored calculations; fewer scripts because of script parameters and the capability to define multiple different finds and sorts within a single script; fewer relationships because they're all inherently bi-directional.

It will also be easier and more efficient to maintain a complex solution in FileMaker 8 if it's been rewritten than if it's been converted. Figure 18.1 shows the Relationships Graph of a very large, complex file after conversion. Keep in mind, of course, that you'll have similarly impenetrable graphs in manyif not allthe files in your solution. Grooming all those graphs into something that can be efficiently maintained is time-consuming. A rewrite, on the other hand, gives you the opportunity to systematically plan how to arrange tables in your graphs; you can also choose the file architecture that's best for your solution rather than passively accepting the one-table-per-file architecture obtained through conversion.

Figure 18.1. After conversion, each file in your solution will have a hub-and-spoke design graph with the current file at the top center of the graph.

Note

Each relationship in the previous file is converted into a table occurrence in the new file, named by the relationship name from the old system.

 

Condition of the Existing System

The condition of your existing system can have an impact on your migration decision. Plenty of systems out there have grown more like weeds than well-tended gardens. Such systems exhibit inconsistent naming conventions, have fields, scripts, and layouts that are no longer needed, use inefficient and/or idiosyncratic processes, and usually have data integrity problems to boot.

Converting these systems often accomplishes little more than paving the cow path: It's using a new technology to do things the same, inefficient way they've always been done. Chances are that you'll end up disappointed in the new product because it doesn't solve any of your inveterate problems. It will also be very difficult to do proper post-conversion testing and development on such systems, as you'll always be plagued by the detritus from the old system.

On the other hand, if your solution has been well tended over the years, or has recently been overhauled, there's a good chance it will convert well and be easy to maintain going forward. A well-tended solution will have consistent, intuitive naming conventions, will have a minimum of unnecessary objects, and will have ample data protection in place. If that's not a description of your system, you may want to use the upgrade to FileMaker 8 as your excuse to do the rewrite that your system needs. Rather than blindly replicating the existing system, take the time to redesign and rebuild it correctly from the start.

Future Needs

Your future needs for a particular solution may influence your decision whether to convert or rebuild. If you have a solution that does x, y, and z, and all you need to have it do going forward is x, y, and z, conversion might be the best path for you. In such cases, your primary motivation for conversion is likely something like the larger file size limit in FileMaker 7 or 8, or the ability to make schema and privilege changes without kicking users out of the system. Even if it takes kludgy work-arounds to do x, y, and z, if you don't foresee a likely need to do much future development or maintenance work on the system, it's probably just fine to leave those kludgy work-arounds in place.

At the other end of the continuum is a solution (and likely an organization) that's in constant flux. You need a system that's easy to maintain and is nimble enough to adapt to changing needs and conditions. Or maybe your current solution is phase one of a larger, grander application. If for these or any other reasons you foresee a need to do considerable post-conversion development for a solution, it's likely that you'll be better off rewriting your solution. If you don't, you'll probably end up with a stratified solution, where old features and objects are noticeably "B.C." (before conversion) and new work is noticeably "A.C." (after conversion). Such a system will invariably be more difficult to build upon and maintain than one developed entirely in FileMaker 8.

Time and Cost

There's little question that rewriting a solution from scratch requires more time and/or cost than simply converting a solution. Be aware, too, that conversion itself carries time and cost requirements: You will always need to do significant testing before deploying a converted solution, and you'll often need to do some post-conversion maintenance as well.

Estimating the time and cost requirements for either migration strategy is difficult because you won't know what issues you'll face until after you're underway. Conversion is like a home remodeling job in many ways. After you tear down a few walls you may be faced with a bigger problem than you anticipated. Similarly troublesome, rewriting is prone to the "while-we're-at-it" factor (that is, "as long as we're rewriting the solution, let's hire a designer to create a new interface while we're at it," or "while we're at it, let's build those hooks into the accounting and shipping solutions we've always talked about adding").

Rewriting a solution from scratch certainly sounds like it will involve more significant time and cost than conversion. Keep in mind, though, that you have your original solution as a blueprint, and that you'll probably be able to copy significant portions of the system, including layouts, scripts, and calculation functions. It certainly won't require the same resources as it did to build the system originally.

When you think about the time and cost of migration, it's also important that you take a long view. What might be more time- and cost-efficient in the short term might have significantly higher costs in the long run because of inefficiency and lost productivity. For example, it may take longer to add new features in the future to a converted solution. Or, if your present system has inefficient processes, an initial time and cost outlay to rewrite your systems may result in a steady stream of cost savings in the future.

There's another way that time plays into your migration plan, and that's the timeliness of your need. If you have a solution that's on the verge of surpassing the old file size limit, or if you have been teetering along with an unstable, crash-prone solution, you probably want to migrate as quickly as possible. It's calendar time, not programming time, that matters the most to you, and conversion is your best course of action. Even if you decide that your solution needs to be rewritten in the future, you may opt to deploy a converted solution as a stopgap until a more permanent solution can be achieved.

The Bottom Line

You might have noticed that nowhere in the preceding discussion did we specifically recommend conversion or rewriting as absolutely preferable. We instead pointed out factors that might cause you to prefer one method to another. In the real world, of course, you must figure out how to weigh all these factors against each other. You might have a very clean, very complex system that won't need much future development. Or you might have a simple solution that's used by a hundred users, each with a separate password. There are no simple rules you can follow to determine which path is best, but to make an informed decision, it certainly helps to have all the issues on the table.

Converting Files