Stop making changes.

Whatever broke this, the wrong instinct right now is to try another upgrade, another patch, another restart of something else. Every additional change makes it harder to isolate what actually failed. Freeze the environment as it is — even broken, it is diagnosable.

The five things to check in the first thirty minutes.

  1. What changed? Identify the exact thing that was upgraded — FileMaker Server version, the host OS (macOS, Windows Server), a plugin (MBS, ScriptMaster, others), hosting provider, TLS certificate, Claris ID configuration. If more than one thing changed, list all of them. This is the input to everything else.
  2. Do you have a working backup? Locate the most recent backup taken before the upgrade — of both the data files and, ideally, the pre-upgrade system state. Verify it opens. This is your safety net. Do not overwrite it.
  3. What does the FileMaker Server admin console say? Log into the Admin Console (or check whether it comes up at all). Look at recent event log entries — the last few hours before the failure and everything since. Server usually tells you what it tried to do and what stopped it.
  4. What does the OS say? On macOS, Console app filtered to the FileMaker Server processes. On Windows Server, Event Viewer. Look for the moment the upgrade completed and any errors that followed. Permission errors, missing paths, and framework-load failures are common.
  5. Are users seeing "connection refused" or "file damaged"? These point in very different directions. Connection refused usually means Server itself did not start. File damaged points at the file format or a bad copy. The right next step depends on which one it is.

Common breakage patterns.

macOS upgrade broke FileMaker Server. Most common cause. macOS point releases move framework paths, change permission behavior, or tighten Gatekeeper. Server may need reinstalling on top of the new OS, or a specific pre-existing folder may need permissions reset. Check whether the FileMaker Server processes are running at all before assuming file corruption.

Windows Server or Windows point-release broke it. Similar shape. Windows updates occasionally change service behavior, TLS configuration, or firewall rules. Check whether the FileMaker Server Windows service is set to auto-start and whether it actually did.

FileMaker Server version upgrade broke it. A Server upgrade sometimes surfaces incompatibility with older plugins (MBS versions from a few years ago, older ScriptMaster) or requires files to be opened once in the new version before serving. Server logs are explicit about this most of the time.

The file itself won't open in the new version. If the file was converted (fmp7 → fmp12 many years ago, or from an older Server version), a broken conversion mid-upgrade is the culprit. Restore from a backup taken before the conversion.

Hosted (Claris cloud or third-party hosting) migration issue. The failure is usually on the hosting side, not yours. Open a ticket with the host immediately — their support has visibility your local access does not.

When to bring in help.

Three signals mean this is beyond a quick self-fix:

  • You do not have a clean backup from before the upgrade.
  • The Server admin console does not come up at all.
  • Users are seeing "file damaged" errors and you do not know what changed the file.

Any one of these and the cost of a wrong next move goes up sharply. This is when a phone call earns its price.

Every additional change makes it harder to isolate what actually failed. The first hour matters more than the fix does.

Why this keeps happening without a steward.

Upgrades break systems for one predictable reason: something in the environment changed and nobody checked whether the FileMaker system could survive the change. macOS and Windows both ship regular updates. FileMaker Server has its own version cycle. Plugins have theirs. Hosting providers migrate. Any one of these can be the thing that takes your system down on a Tuesday morning.

The defense is not luck. It is a staging environment that mirrors production, a small routine of testing planned upgrades against a real copy of the file before touching the live server, and someone whose job is watching for compatibility notes before Claris or Apple pushes the update. This is exactly the routine work a stewardship retainer covers. It is boring in the way that "system that has not broken in five years" is boring.

What to do next.

If your system is down right now, call or text 760-889-9299. If it is running but you know an upgrade is coming and you want the staging environment set up before it hits, the free triage call is the right first step. Thirty minutes, and you leave with a plan for the next upgrade cycle instead of hoping it goes smoothly.