Last updated: June 2026
Leaving FileMaker is not a data copy. FileMaker stores apps in a proprietary format, so the data, the business logic, and the screens all get rebuilt on the target1. SQL Server suits .NET shops, PostgreSQL or MySQL fit teams that want open-source capacity, and a full web rebuild modernizes access. The right target follows where the rest of the business already runs.
A software architect mapping a FileMaker application to a SQL Server and .NET migration target on a whiteboard in 2026

Why is migrating off FileMaker not an automatic conversion?

FileMaker can talk to SQL databases through ODBC, JDBC, and External SQL Source, the last introduced in FileMaker 91. Those are connectivity bridges, not a migration. A real move exports the data, redesigns the schema for a standard relational database, and rebuilds the layouts and scripts as application code.

Migration tools such as FmPro Migrator and Full Convert automate the data transfer over ODBC, but data types differ between FileMaker and the target and have to be remapped2, and the FileMaker ODBC driver carries quirks, including access to one database file at a time and DROP COLUMN passes that fail and have to re-run in reverse order3. The principle is the one Microsoft documented years ago for Access upsizing: the move requires real refactoring of structure and code, not a wizard click4.

The data is the part the tools handle. The business logic locked inside FileMaker scripts and calculations is the part that gets rebuilt by hand, and it is what sets the real size of the project.

When is SQL Server the right target?

SQL Server is the default when the business already runs on Microsoft and .NET. The data lands in SQL Server, the app gets rebuilt in C# .NET using Blazor, WPF, or a web front end against a .NET API, and reporting moves to SQL Server Reporting Services or a modern reporting tool.

This target wins when IT already supports a Microsoft stack and wants the new system to sit inside it, sharing authentication, backup, and monitoring with everything else the company runs. The migration becomes one more application on infrastructure the team already knows, rather than a new platform to learn.

When do PostgreSQL or MySQL make more sense?

Open-source databases fit teams that want to avoid per-core licensing or that run on Linux. PostgreSQL brings stored procedures, triggers, and replication for higher-capacity systems5, and the same class of migration tooling supports the FileMaker to PostgreSQL path2.

Pick this route when the cost model or the hosting environment points away from Microsoft licensing. A company already running web services on Linux, or one watching database licensing line items closely, often lands here. The application layer can still be .NET or a JavaScript front end. The database underneath is simply the open-source one.

When should you rebuild as a web or .NET application instead of just moving the database?

Sometimes the database is the easy part. If users need browser or mobile access, if the workflow has outgrown FileMaker's layout model, or if the app has to serve people outside the office, the right move is rebuilding the application layer, not only the data.

A web app on a .NET or modern JavaScript front end, backed by SQL Server or PostgreSQL, replaces the FileMaker Pro and FileMaker Go clients with a browser. Nobody installs anything. Access control, updates, and integrations live on the server, which is where a growing business usually wants them. For buyers weighing whether the spend is justified at all, the companion piece covers the cost and lock-in case for leaving FileMaker.

What breaks when you migrate, and how is it handled?

Four parts of a FileMaker app behave differently on the target. Naming them up front is what keeps a migration on a predictable schedule.

Data types

FileMaker types do not map one to one onto SQL types. Each gets remapped during transfer so the target schema is clean, not a literal copy.

Container fields

Images and files stored in FileMaker containers move to the target as binary or large-object columns, or to referenced file storage, handled by volume.

Scripts and calculations

FileMaker script steps and calculation fields are business logic. They get rewritten in the application language, not auto-translated.

Layouts are the fourth part. FileMaker layouts are rebuilt as forms or web pages that match the workflow, not the pixel layout of the original. Where a user community depends on a familiar screen, visual parity becomes a goal. Where the layout was a 2008 workaround, the rebuild is a chance to fix it.

Already decided to leave FileMaker?

A 20-minute call. PCG asks about your tables, scripts, and integrations, then tells you which target fits.

Book Your Free Consultation

How does PCG choose the target on a real project?

PCG runs a discovery phase before naming a target. The team reads the FileMaker file and inventories the tables, scripts, calculations, layouts, and external connections, then picks the database and application stack that fit the business and quotes a fixed scope.

The target is an outcome of discovery, not a guess made before reading the app. That sequence is what separates a migration from a second migration. Choose SQL Server for a Microsoft shop because it sounded safe, then discover the workflow needed a public web portal, and the project pays twice. The companion legacy work on the same principle is documented in PCG's Visual FoxPro migration guide, and the broader service is conversion, migration, and integration.

Pick the target before discovery

The shortcut that costs twice
  • Target chosen on familiarity, not on the app
  • Workflow needs surface after the build starts
  • Reporting or integration gaps found late
  • A second migration two years later

Pick the target after discovery

How PCG runs it
  • File read, logic and integrations inventoried first
  • Database and stack chosen to fit the actual workflow
  • Fixed scope and timeline quoted on real numbers
  • One migration, built once

31 years of running custom software projects points to a single rule on target selection. The wrong target does not announce itself during the demo. It announces itself two years later, when the workflow the discovery phase never examined turns out to need the one thing the chosen stack cannot do cheaply.

Map your FileMaker app to the right target

PCG runs a fixed-fee discovery that reads your app and recommends the target with a fixed scope.

Book Your Free Consultation

Frequently Asked Questions

Can you migrate FileMaker directly to SQL Server?+
The data can be transferred to SQL Server through ODBC-based tools, but it is not a one-click conversion. Data types differ and must be remapped, and the business logic in FileMaker scripts and calculations has to be rebuilt in the new application rather than copied.
Should I move FileMaker to SQL Server or PostgreSQL?+
SQL Server fits Microsoft and .NET shops. PostgreSQL fits teams that want to avoid per-core licensing or run on Linux. The deciding factor is usually where the rest of the business already runs and how the team prefers to license and host.
Do I have to rebuild the FileMaker layouts and scripts?+
Yes. Layouts and scripts are application code in FileMaker terms. They are rebuilt on the target as forms, web pages, and server-side logic that match the workflow, not the original pixel layout.
What happens to images stored in FileMaker container fields?+
They migrate to the target database as binary or large-object columns, or to file storage referenced by the database, depending on volume and how the app uses them.
Is a web application a better target than a desktop rebuild?+
A web app is the better target when users need browser or mobile access, or when people outside the office must use the system. A desktop rebuild can fit a closed internal workflow, but most modern migrations move to the web.
How long does a FileMaker migration take?+
It depends on the number of tables, scripts, calculations, layouts, and integrations. A small single-table app is a short project. A multi-module app with hundreds of scripts is a larger one. A discovery phase that reads the file produces the real timeline.
How does PCG decide what to migrate FileMaker to?+
Through a discovery phase that reads the FileMaker file and inventories its tables, scripts, layouts, and integrations before choosing a target. The target follows the business and its existing stack, and PCG quotes a fixed scope once discovery is complete.
About the Author

Allison Woolbert

CEO and Senior Systems Architect, Phoenix Consultants Group

Allison Woolbert is the principal of Phoenix Consultants Group, the custom software consultancy founded in 1995. PCG has run legacy migration projects across Microsoft Access, FileMaker, Visual FoxPro, Paradox, and VB6 for industrial, manufacturing, and environmental services clients since the late 1990s.

Allison leads PCG's discovery and architecture practice, where the first deliverable on every legacy engagement is a written inventory of what the existing application does and the target it should move to. LinkedIn.

1 Claris; O'Reilly, FileMaker 9 Developer Reference. FileMaker connects to external SQL data through ODBC, JDBC, and External SQL Source (ESS), introduced in FileMaker 9. oreilly.com

2 Spectral Core, Full Convert (FileMaker to SQL Server); .com Solutions, FmPro Migrator (FileMaker to SQL Server, PostgreSQL, and others). Data-type differences are remapped during transfer. fullconvert.com; fmpromigrator.com

3 .com Solutions, FmPro Migrator FileMaker to SQL Server migration documentation. FileMaker ODBC driver accesses one database file at a time, and DROP COLUMN commands may require a second reverse-order pass. fmpromigrator.com

4 Microsoft; Wikipedia, Upsizing (database). Database upsizing requires refactoring of the database structure and source code, not only a data copy. en.wikipedia.org/wiki/Upsizing_(database)

5 PostgreSQL Global Development Group. PostgreSQL provides stored procedures, triggers, and replication for higher-capacity systems. postgresql.org

This article is informational and not legal, financial, or compliance advice for a specific situation. Phoenix Consultants Group has provided custom software development since 1995.