Why This Matters

I’ve seen it too many times. Someone uploads their FileMaker database to a server, and suddenly nothing works right. Scripts fail, relationships break, users can’t log in. It’s frustrating, but it’s also completely avoidable.

Here’s the thing: FileMaker databases that work great on your local machine can have all sorts of hidden issues that only show up when you move to a hosted environment. Let’s fix that before it becomes a problem.

The Pre-Flight Checklist

1. Clean Up Your File References

This is the big one. If your database references other files (and most do), those references need to work on the server.

What to check:

Open File > Manage > External Data Sources
Look for any file paths that use absolute paths like file:/C:/Users/YourName/Documents/
Change them to relative paths or use fmnet: protocol
Better yet, use $ for files in the same directory

Pro tip: If you see file:/ anywhere in your external data sources, that’s a red flag. It won’t work on the server.

2. Test All Your Scripts

Scripts that work on your desktop might not work on the server, especially if they:

Open files from specific locations
Use Send Mail without proper SMTP configuration
Rely on local plugins
Use Open URL for local file paths

What to do:

Run through your critical scripts manually
Check for any script steps that reference local paths
Make sure SMTP is configured if you’re sending emails
Test any plugin-dependent scripts

3. Check Your Accounts & Privileges

This one bites people all the time. You’ve been developing with Full Access, but your users shouldn’t have that.

Before hosting:

Create proper privilege sets for different user roles
Test logging in with non-admin accounts
Make sure users can actually do their jobs with limited privileges
Document the admin password somewhere safe (seriously, write it down)

4. Verify Your Relationships

Sometimes relationships work locally but break on the server. Usually it’s because of:

Case sensitivity issues
Trailing spaces in key fields
Number vs. text field mismatches

Quick test:

Go to Manage > Database > Relationships
Check that your key fields are the same type on both sides
Look for any relationships using calculations
Test a few records to make sure related data shows up

5. Remove Development Cruft

Your database probably has stuff in it that doesn’t need to go to production:

Test records with fake data
Old layouts you’re not using anymore
Commented-out scripts
Debug fields on layouts

Clean it up. Your users don’t need to see your development mess.

6. Optimize for Performance

Hosting changes how your database performs. What was instant on your local machine might be slow over the network.

Things that help:

Reduce the number of portals on layouts
Use filtered portals instead of showing all records
Minimize calculations in list views, heck, minimize unstored calculations, period.
Consider using OnFirstWindowOpen to cache commonly-used data
Use OnOpen to pre-load data into variables
Use global fields instead of calculations
Use scripts instead of calculations
Use variables instead of calculations
Use value lists instead of calculations

7. Configure Server-Side Settings

Some things only work if they’re configured on the server:

SMTP for email
SSL certificates for secure connections
PHP/XML web publishing (if you’re using it)
External authentication (if applicable)

Talk to your hosting provider about these before upload day.

The Upload Process

When you’re ready to upload:

Close the file - Make sure nobody is using it
Make a final backup - Seriously, one more time
Upload to the server - Use your hosting provider’s method
Test immediately - Don’t wait. Test it right away.
Have users test - Get real users to try it before you call it done

Common Gotchas

“It works on my machine!” Yeah, we’ve all said it. The server environment is different. Test everything.

Forgotten passwords Write down your admin password. Put it in a password manager. Tell someone you trust. Just don’t lose it.

Plugin dependencies If your database uses plugins, make sure they’re installed on the server. And make sure they’re the right version.

Network paths Anything that references a network drive or local path will break. Fix it before you upload.

After You’re Live

Once your database is hosted:

Monitor performance for the first few days
Watch for error messages in the server logs
Ask users to report anything weird
Keep that backup handy just in case

Final Thoughts

Preparing a FileMaker database for hosting isn’t rocket science, but it does require attention to detail. Take your time, work through this checklist, and you’ll save yourself a lot of headaches.

And if something does go wrong? That’s what backups are for. You did make a backup, right?

Updated January 2025 - Originally published on ZeroBlue Technology Solutions blog. Updated with current best practices for FileMaker 2024/2025.

Preparing Your FileMaker Files for Hosting: A Practical Checklist