Planning your upgrade to FileMaker 17 platform
As we have noted in our previous articles, FileMaker 17 is a formidable upgrade to an already great platform. While it is a given that one would immediately use the FileMaker 17 platform for developing a new custom App if starting from scratch today, there may be some work to be done if you are planning on upgrading from an older version of FileMaker.
Here is our quick guide of technical considerations to watch out for when updating from previous versions. If you think any of the issues noted are a concern then you are welcome to contact our consulting team for assistance.
Upgrading from FileMaker v12-v16 (.fmp12 format)
Since FileMaker versions 12-16 share the same file format as version 17 there is no need to convert the file. This usually means the file should simply open in the newer version of the application and there are less likely to be significant conversion issues with upgrading.
With FileMaker 16/17 in order to produce a more modern ‘app-like’ experience on the desktop, the footer bar which includes the ability to zoom in & out, change working view mode and show/hide the upper status bar has been removed in FileMaker 16/17. If your users are making use of these features then they will need to adapt to using the upper status and application menus (for changing mode/status bar) or you may find that you will need to program in zoom control into your interface layouts.
While you can mix these client versions to an extent (i.e. if you have legacy machines which are not able to be upgraded to the minimum hardware or OS requirements to run FileMaker 17, then you can still connect to FileMaker Server 17 using FileMaker 15 or 16), this isn’t generally advisable as it means that you cannot make use of FileMaker 17 specific features to users with older client versions.
For optimal security & performance both server and all users should be on the most recent version and patch. To prevent users from accidentally accessing an upgraded server/solution with an older version of the client software you can set the minimum version allowed to access the file under File > File Options > Open tab.
It is worth checking which features are now deprecated in FileMaker 17:
https://support.filemaker.com/s/answerview?language=en_US&anum=000026028
If you are making significant use of any of these features then you may need to develop around these limitations
Upgrading from FileMaker v7-v11 (.fp7 format)
You need to convert from the .fp7 to .fmp12 file format before you can open them in FileMaker 17. While converting does create a copy in the new .fmp12 format it is worth remembering there is no way to convert a file back to the older .fp7 format - upgrading is a one way trip! If users still have the old version of the client software then they will be completely locked out of accessing the converted files until they have upgraded to a compatible version
If you were making use of FileMaker Instant Web Publishing under FileMaker v7-11 then it is important to remember this was abandoned in favour of WebDirect for FileMaker v12 and onwards as it makes use of a newer CSS based layout engine.
While WebDirect is significantly more feature rich (and scalable now with FileMaker 17), you may find that you will need to re-implement and optimise layouts for WebDirect access which may not be a trivial amount of effort if you have a complex solution!
Upgrading from FileMaker v6 or earlier (.fp5 format)
There are potentially lots of issues with converting files which are more than 10 years old, but here are some of the most common issues that need resolving:
The most basic consideration if you have a database file of this vintage is that it isn’t possible to directly convert from v6 or earlier using FileMaker 17. You will need to use an intermediate FileMaker version (v7-11) to convert the file to the .fp7 format which 17 can then in turn convert to the .fmp12 format. FileMaker has a detailed guide on the issues and version compatibility here:
Back in the FileMaker v6 days you could only specify a password and not a login name – in converting it sets the login name to be the same as the password which obviously isn’t very secure so this will need to be changed quickly post upgrade. FileMaker 17 login names are case insensitive, but the passwords are not so it can be easy to get caught out by this. In many cases it is simplest to remove all passwords under the original version, convert and set-up the security again from scratch.
Typically, since having multiple tables in a single database file wasn’t possible back in v6 and earlier, you may find you have lots of files to convert and re-set-up the login/password security across multiple files. If this is the case and you have complex security group arrangements then it is often more appropriate to set-up FileMaker Server to use Active Directory, Open Directory or the newer OAuth external authentication.
Finally, external file references between files could not be directly accessed in the application in FileMaker v6 and earlier, but are exposed from FileMaker v7 onwards (File > Manage > External Data Sources in FileMaker v16). On occasions when the linked files had been re-linked or moved between multiple machines this could result in multiple ‘paths’ being recorded to the appropriate related file – these often need clean-up post conversion so that they are set to the correct relative server location. If there are lots of incorrect/’hanging’ references to old paths then this can cause FileMaker to ‘pause’ while it times out looking for the dead link – this can significantly increase the time to open the files and lead to the perception that the Application is being unresponsive.
General upgrade considerations
In all of the above cases, we are assuming that you have a relatively ‘vanilla’ FileMaker solution without any complex dependencies such as integrations with 3rd party software or plugins.
FileMaker plugins will generally need updating to ensure compatibility with FileMaker 17 and in many cases this will be a paid for update. The syntax and functionality of plugins can change between versions or certain features are deprecated if the core application offers overlapping functionality or similar functionality – this may mean that you will need to re-write elements of your solution scripting to use the new native FileMaker 17 technology or may need to migrate to a different plugin.
We strongly recommend that clients think seriously about how fit for purpose a legacy solution is before deciding that a simple ‘technocratic’ upgrade is an appropriate approach. Most successful businesses change their processes and focus significantly over time as well as the ecosystem of technologies that they adopt to support their workflow. In many cases if the client has a legacy FileMaker solution that has not been updated for several years then it is usually more efficient and cost effective to consider developing a new solution from scratch which exactly fits an organisation’s modern requirements if the older system is no longer a ‘good fit’.
