As we have noted in our previous articles, FileMaker v16 is a formidable upgrade to an already great platform. While it is a given that one would immediately use FileMaker v16 for developing a new bespoke 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-v15 (.fmp12 format)
Since FileMaker versions 12-15 share the same file format as v16 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 issues with upgrading.
There is one ‘gotcha’ issue at the moment which can result in data loss if you have scripted modification or deletion of portal rows on layouts with multiple portals without robust error checking in place. See this tech note for more detail:
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. 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 Pro 16, then you can still connect to FileMaker Server 16 using FileMaker Pro 14 or 15), this isn’t generally advisable as it means that you cannot make use of FileMaker 16 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.
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 v16. While converting does create a copy in the new .fmp12 format it is worth remembering there is no way to back convert to the older .fp7 format. 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 v16), 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 v16. You will need to use an intermediate FileMaker version (v7-11) to convert the file to the .fp7 format which v16 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 16 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 new 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 16 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 v16 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’.