I have a growing challenge and hope the community here at The Soup can help.
Like some of you, I have customers that use old versions of the FileMaker platform. I consider this far from ideal. In my opinion, the minimum version of a mission-critical software an organization should use is a version supported by its publisher. Per Claris policy (available here) anything older than two years is unsupported.
This is one area where I get push-back from IT departments. That two year policy is short for mission-critical software. Interestingly, cost is rarely the roadblock. I have customers that use much older software and hardware and, believe me, using old stuff costs a lot. For these customers, changing software requires committees, substantial resource commitments and a willingness to potentially disrupt business.
Some of you have more success than me in convincing customers to upgrade on a timely basis. I am looking for your wisdom. How do you go about convincing customers to do just that?
Unfortunately not. Customers have their own defined live cycles for corporate software. Only very small customers with not overly complex solutions can adapt to a 2-year cycle.
P.S. pushing this too hard can backfire...
We can get some more granularity about the FileMaker 19 & 2023 EOL dates here: ClarisPKB
It is an interesting topic.
Customers have to understand how running unsupported software (or hardware) can limit us in servicing them. Kind of like when they are running on an unsupported OS.
On my end, I try to be as clear as I can on that end of things. The other element is about the versions that I myself can run without too much effort. I plan on changing my hardware soon, and most everyone I deal with is no longer running FileMaker 17. So once that gets past my own "cliff", people who want to get service will be asked to upgrade first. But that is generally a much longer window than the 2 years we get before the Claris software reaches EOL.
Another point to consider is that some audits may require customers to not rely on software that has reached EOL.
I see it as a habit to have, just like we rotate tires on a car and change the batteries in the smoke detectors.
In some instances, it is possible to invoke some of the improvements tied to the newer versions. Like you say, most of the time, it is not about cost, the license or maintenance is already paid, but people still feel like changing anything about the configuration is a bit like applying a fix while your car runs on the highway. Interconnectivity with other systems can make this worst.
The best is if you can get IT to spell their policy about both hardware/software replacement/upgrades. I tend to prefer changing as few variables as possible at the same time, but in some instances, it can be beneficial to lineup software upgrades with hardware upgrades (specially from the downtime angle).
Everyone is different, and some customers may see things under a different angle.
Are there impacts to you and your business @bdbd ? Or is this mostly about things not being matching our optimal setup? That could help shape the discussion.
No for me or my business. Yes for some of my customers' business. Here is an example.
Some of my customers are 24 / 365 businesses. There is no ideal downtime for these customers. Their support requirements are quite high. I have had to deal with SLAs that give little time to solve downtime issues before penalties hit. They like it when things just work. They generally avoid changes because of the potential disruptions these can cause.
When changes are needed or wanted, they are carefully planned. Deployments are rehearsed. There are rollback contingencies. Training documentation is created or modified. Same with support and other relevant materials. Training is dispensed prior to deployment. And so on and so forth!
You can imagine, considering all the effort that goes into making a change, that these customers resist changes unless there is a compelling reason to do so. Compelling, here, is from the customer's point of view. "If it ain't broke, don't fix it" is a very real mantra for these customers.
And compelling is where I seem to fail too often. For these and other customers, I find it hard to give them compelling reasons to upgrade FileMaker. Most of my customers say "meh" to the new features Claris posts about during each major upgrades.
So I ask again: How do you go about convincing customers to upgrade?
we are very strict in upgrading if they want us to support update add new features etc we only use the latest version. not even the previous ones. this method from 2017 till now works like a charm
Well, it is like our release stuff.
Do it often and you get a routine, a good procedure with steps to follow.
If you only do it every few years, it is a big job and calls for trouble.
It may be good to tell the client to update their software once per quarter to stay current. Have a procedure, where you first upgrade the test/development system and check if all still works.
And don't do it first day after release, but maybe always wait 2 months to see if Claris provides a .0.1 update for it.
So for FileMaker 2023, maybe wait a month and see if there is a 20.1.2 or similar coming.
Upgrade first a few FileMaker Pro and then one weekend the server by switching from one VM to another by reassigning the IP to the new VM. And keep the old VM, so you can switch back I needed.
if Your company or Your customers are ISO27001 certified, You need to do test-cycles before updating. The IT department (and the production departments as well) will kiss You if You ask them to do this every quarter year
(-:
Updating FMS has become much easier - but still fails sometimes and one has to uninstall, install, etc.
Some IT are puzzled about the versioning of Claris (solved now with '2023'), thought that they were just one version behind - and at the same time lost believing because of 'no updates'.
Here, that lead to evaluating for another software (resulting in mostly MS servers/technonolgies)
Quite difficult.. we (my company) are up to date (production still on 19.6, but 2023 installed and used frequently). Updating the FM Servers lacks the updating speed... (although the main server for production is also on 19.6 in the meanwhile)
Warning: FileMaker 2023 could potential include multiple releases:
FMS 20.1.1, current spring releease
FMS 20.1.2 , bug fix patch
FMS 20.2.1, summer release
FMS 20.2.2 , bug fix patch
FMS 20.3.1, fall release
FMS 20.3.2 , bug fix patch
We'll see how Claris really names these.
And I hope they plan a quick bug fix release for each bigger release to hammer out issues without having everyone wait 3 to 4 months for next cycle.
If you can't make a valid argument to upgrade other than "I wish you did" then I'd say the client is right to push back. It sounds like your only reason is you wish it was a newer version, but it doesn't impact their business or yours, so I'm struggling to understand why you want to convince them to potentially break things by upgrading more often?
How likely is it "something" will happen? What's the cost if they don't upgrade and something happens?
vs.
What's the cost of upgrading? How likely is it "something" will happen in the upgrade? What's the cost if "something" happens in the upgrade?
To me the math just doesn't add up for upgrading Filemaker unless it can be done incrementally unless:
There's a new feature with a clear cost advantage.
There's a known security issue in the wild for Filemaker.
IDK how far behind they are in terms of versions, but if I had a client like yours I'd probably recommend they're ok with a 4-8 year old version of Filemaker assuming there's no known security issue in the wild.
I have a client who always updates to latest greatest and a couple of versions ago there was a bug that was throwing "record in use" errors non-stop in their standard workflow. It was a subtle use case that didn't show up in testing, but then due to seasonality it started being a pain for EVERYONE. Ended up rolling everyone back and locking them in there.
For a client like you're describing that sounds like a VERY expensive proposition, both in terms of manpower, and lost time/functionality throughout and I wouldn't recommend a client like you're describing step into that unless there's a very compelling reason.
Have good backups. Have an emergency plan and budget signed off on and reviewed annually in case it's necessary some time in the future to make a fast change-over, but otherwise just let it keep doing what it does.