I've been developing FileMaker solutions for about 29 years now, and I have a few clients with fairly old solutions that are getting clunky and out of date (and downright ugly on the inside!) I'm looking for a resource or testimonies/explanations some of you might have used regarding the benefits of investing in rebuilding a 10 year old mission critical database system. While this would involve getting a beautiful brand new interface, some of my clients don't want to spend the budget on what they see is just a new pretty face. How do I explain that the underlying technology is really what makes all the improvements in performance and ability to move into the future with a piece of software?
Anyone trying to run a 10 year old 'off-the-shelf' software would never be able to do so with our new operating systems and technologies required to do business today. But FileMaker has done a great job of allowing old databases to convert to newer upgrades of the app (almost to a detriment), so it's harder to defend the need to upgrade the schema. I sometimes get 'if it's not broke, don't fix it', so how do I convince them it's a poor investment to continue to build on an old foundation? (Or do some of you disagree?)
Although I have been able to get most clients to upgrade to the current version of FileMaker, I feel like continuing to use their old database schema is like riding a bicycle when there's a Harley available! The old build doesn't take advantage of new technologies, mobility, integration, etc, and old code is clunky and inefficient. One day they will run into issues of incompatibility with new versions of FileMaker or Operating Systems that will not support the old build, forcing the issue. A prudent, competitive company will not wait for failure that could cause down time, lost revenues and an emergency rebuild. But more importantly, I would be remiss as their developer to not try to keep their mission critical system up to current standards.
Linda Carter, Compu-Books