In many businesses FileMaker, now Claris FileMaker, is what Access is in others: a database that someone in-house or a freelance developer set up years ago. Customers, orders, projects, machines, inspections - it often covers more than any off-the-shelf program, because it has grown with the business.

That is exactly what makes it valuable. And that is exactly what makes replacing it tricky, because the solution holds years of experience that is written down nowhere else.

Why FileMaker is so widespread

FileMaker made it easy for people without programming training to develop their own applications: create tables, draw layouts, automate workflows with scripts. With a FileMaker Server several people work at once, and there is a dedicated app for iPad and iPhone. For many businesses it was the fastest way to software that fits exactly.

So the solution is often not a bad one. It has simply reached a point where its strengths are no longer enough.

Signs that it is time

  • One person knows the solution. The developer is retiring or hardly has time any more, or the colleague who set it up has left the business.
  • Changes become risky. Every adjustment has side effects in places nobody thought of.
  • The solution no longer fits the devices. The field team uses Android phones, or customers and partners are meant to get in through the browser.
  • Other programs need the data. An online shop, accounting or a customer portal is to be connected, and that gets laborious.
  • Licensing comes up again at every renewal, and nobody knows whether it is still worth it.
  • Nobody knows exactly what the scripts do any more. They run, and everyone hopes it stays that way.

None of these signs alone is a reason to replace the solution. If several apply, it is worth a closer look. More signs are covered in Signs your system is at its end.

What a FileMaker solution contains

Replacing a FileMaker solution means taking over more than the tables. When recording what is there, look out for these parts:

  • Tables and relationships: which data exists and how it hangs together. Usually the easiest part.
  • Scripts: this is where the workflows are. What happens when an order is closed? When is an email sent? Which numbers are assigned, and how?
  • Calculated fields: prices, discounts, deadlines, status. Important business rules often sit in a formula nobody looks at any more.
  • Layouts: not only screens but also print templates for quotes, delivery notes, inspection reports. They show which details are really needed day to day.
  • Permissions: who may see and change what? In solutions that have grown, this is often more generous than it should be.
  • Connections: exports for accounting, imports from the shop, emails to customers. They often run quietly in the background and are only noticed once they are missing.
  • Documents: pictures, PDFs and attachments stored directly in the database.

Step by step rather than a cut-over date

The obvious plan is a cut-over date: switch everything over one weekend. With a solution that has grown, that is risky, because you only find out in live use which rule was forgotten. The phased route is often safer where data and areas can be separated sensibly. Both routes are compared in Cut-over date or step by step.

1. Record what the solution does today

Together with the people who work with it every day, write down which areas exist, who uses what and which rules lie behind them. Scripts and calculated fields are read, not guessed. It often turns out that some parts have not been opened in years.

2. Choose the first area

Which area causes the most trouble today, or brings the greatest benefit once moved? Start there. That might be the field team, who should finally be able to work on any phone, or quoting, which is to be connected to the shop.

3. Settle the transition

While both systems run, it must be clear which system leads which data. Where possible, the two systems exchange data during this time, for example via an export or an interface. FileMaker can output data in common formats, and there are several ways to access it from outside. Which of them your solution can use depends on how it is set up.

4. Move area by area

Then the next area follows. Once the last one has moved, the FileMaker solution is switched off, and a read-only copy stays as an archive for as long as it is needed.

What happens to the data

Getting data out of FileMaker is usually not the technical problem. The harder part is what you find along the way: duplicate customers, free text instead of a fixed choice, fields whose meaning has changed over the years. The migration should therefore be rehearsed early - transfer everything once, check it, clean it up, repeat. How that works is described in Moving old data to a new system.

What to replace it with

There are three routes for the new solution: standard software that covers the workflow, an application developed for you, or a mix of both. Because FileMaker solutions are usually tailored very closely to the business, standard software rarely fits without compromises. The question is which compromises you can accept.

We replace old systems with ElbDesk, the foundation we build on: ElbDesk brings sign-in, permissions, collaboration and documents with it, and only what defines your workflow is developed. What that looks like step by step is shown on our page about replacing old systems. A similar approach for Access is described in Replacing an Access database.

Checklist before you start

  • Who knows the solution best, and can that person be reached for the review?
  • Are all access details with you: server, admin account, licences?
  • Is there a current backup that has actually been restored once?
  • Which scripts run automatically, at night or on saving, for instance?
  • Which other programs read or write data?
  • Which area causes the most trouble today?