FileMaker to React: A real migration story — and what we learned the hard way

"We love FileMaker. It's been running our business for 15 years. But we're terrified of what happens when it stops working."

That's what the operations director of a mid-sized manufacturing company told us during our first discovery call. It's a sentiment we've heard dozens of times — that peculiar mix of gratitude and dread that comes from depending on a system that's been rock-solid for years but feels increasingly fragile.

This is the story of what happened when we helped them make the leap from FileMaker to a modern React-based application. Spoiler: it wasn't always pretty, but the ending is happy.

The starting point: a FileMaker app that ran everything

The company — let's call them Midwest Manufacturing — had been using a FileMaker Pro database since 2011. What started as a simple inventory tracker had grown into the nervous system of their entire operation.

By the time we got involved, this single FileMaker solution handled:

• Inventory management across three warehouses
• Order processing from quote to shipment
• Customer relationship tracking with 15 years of history
• Production scheduling and work order management
• Reporting for everything from sales forecasts to compliance audits

The database had grown to over 200 layouts, 150+ scripts, and roughly 2 million records across 47 tables. It was accessed by 35 users daily, with 12 concurrent connections at peak times.

And here's the thing: it worked. Really well, actually. The FileMaker developer who built it knew the business inside and out, and the system reflected that deep understanding.

So why change?

The triggering factors: why they decided to migrate

Three things pushed Midwest Manufacturing toward modernization:

1. The bus factor

Their original FileMaker developer had retired two years earlier. The company had been limping along with occasional contractor support, but finding qualified FileMaker developers was getting harder — and more expensive — every year.

"We had a script break last month," the IT manager told us. "It took us three weeks to find someone who could fix it. Three weeks of manual workarounds."

2. The integration wall

Modern business runs on integrations. Their e-commerce platform, shipping carriers, accounting software — everything wanted to talk via REST APIs. FileMaker can do this, but their aging system wasn't built for it. Every integration was a custom project.

3. The mobile reality

Their sales team and warehouse staff needed mobile access. FileMaker Go exists, but their layouts weren't designed for it, and rebuilding them would be almost as much work as starting fresh.

The final straw? A key customer started requiring real-time inventory visibility via API. That single requirement would have meant a major FileMaker overhaul.

The discovery process: mapping what we were really dealing with

Before writing a single line of code, we spent six weeks in discovery. This phase is where migrations succeed or fail — and we've seen too many fail because teams underestimate what's actually in the legacy system.

What discovery looked like

Week 1-2: Documentation and interviews

We interviewed every department that touched the system. Not just power users — everyone. The receptionist who occasionally looks up customer phone numbers? She showed us a workflow nobody else knew existed.

We documented:

• Every layout and its purpose
• Every script and when it runs
• Every relationship between tables
• Every user and their specific workflows
• Every report and who needs it

Week 3-4: Data archaeology

FileMaker databases accumulate cruft. We found:

• 23 layouts that hadn't been accessed in over two years
• 47 scripts that were never called by anything
• 8 tables that existed for "historical reasons" nobody could explain
• Duplicate records that had been manually worked around for years

Week 5-6: Workflow mapping

This was the crucial part. We created detailed flowcharts of every business process, from "customer calls with a question" to "monthly compliance report generation."

The deliverable? A 60-page specification document that became our bible for the next eight months.

Technology choices: why React, and what else

Choosing the tech stack required balancing several factors: the client's existing infrastructure, their team's capabilities, long-term maintainability, and — let's be honest — budget.

The frontend: React

We chose React for several reasons:

• Talent availability — Finding React developers is dramatically easier than finding FileMaker developers
• Component reusability — Many of their layouts shared similar patterns that could become reusable components
• Ecosystem maturity — Libraries for everything from data tables to PDF generation
• Long-term viability — React isn't going anywhere; Meta continues active development

We paired React with TypeScript for type safety and Tailwind CSS for styling. The combination gave us rapid development without sacrificing maintainability.

The backend: Node.js with Express

Their existing team had some JavaScript experience, making Node.js a natural fit. We built a REST API that would serve the React frontend and — crucially — be available for all those third-party integrations they needed.

The database: PostgreSQL

Moving from FileMaker's proprietary database format to PostgreSQL was a significant decision. We chose PostgreSQL because:

• Robust and battle-tested — It handles complex queries and large datasets with ease
• Open source — No licensing costs, ever
• Excellent tooling — From backups to monitoring to replication
• AWS RDS support — Managed hosting reduced their operational burden

The infrastructure: AWS

We deployed everything on AWS:

• RDS for PostgreSQL hosting
• ECS for containerized application deployment
• CloudFront for CDN and caching
• S3 for file storage (replacing FileMaker's container fields)

The migration approach: phased, not big bang

We've seen enough "big bang" migrations fail to know better. Instead, we used a phased approach that kept the business running throughout the transition.

Phase 1: Core infrastructure (Months 1-2)

We built the foundation:

• Database schema design and creation
• API architecture and authentication
• Basic CRUD operations for all entities
• Data migration scripts (tested, not yet executed)

During this phase, FileMaker remained the system of record. Users noticed nothing.

Phase 2: Read-only parallel operation (Months 3-4)

We migrated the data and built read-only interfaces for the new system. Key users could view data in both systems, helping us catch migration issues.

"Wait, this customer's address is different in the new system."

"That's because the new system pulled from the 'shipping address' field, not 'billing address.' Good catch."

These parallel operation weeks caught dozens of edge cases we'd missed in discovery.

Phase 3: Module-by-module cutover (Months 5-7)

We migrated functionality in order of complexity:

1. Customer lookup and basic reporting — Low risk, high visibility
2. Inventory management — Critical but well-understood
3. Order processing — Complex, required extensive testing
4. Production scheduling — Most customized, saved for last

Each module went through a two-week "shadow period" where both systems were available. Users could fall back to FileMaker if they hit issues.

Phase 4: FileMaker retirement (Month 8)

Only after every module was stable did we finally shut down FileMaker access. Even then, we kept the database available (read-only) for six months in case we needed to reference historical data.

Challenges encountered: the hard parts

Let's be honest about what went wrong. Every migration has problems; the question is how you handle them.

Challenge 1: Data quality issues

FileMaker's flexibility is a double-edged sword. Over 15 years, users had entered data in... creative ways.

• Phone numbers in 47 different formats
• "States" that included Canadian provinces, country names, and in one case, "overseas"
• Dates stored as text in some fields, actual dates in others
• Customer records that were duplicates but not quite

We spent three weeks longer than planned on data cleaning. Our advice: budget 50% more time for data migration than you think you need.

Challenge 2: The "but FileMaker did it this way" problem

Users had muscle memory. Fifteen years of clicking the same buttons, using the same shortcuts, expecting the same behaviors.

"In FileMaker, I could just type the first three letters of a customer name and it would autocomplete."

"Why do I have to click twice now when I only had to click once before?"

"The old report had the columns in a different order."

Some of these were legitimate UX improvements we should have made. Others were pure change resistance. Telling the difference was harder than we expected.

Challenge 3: The features nobody mentioned

Remember that 60-page specification document? It missed things.

Week 6 of development: "Oh, we also need to print shipping labels directly to the Zebra printer in the warehouse."

Week 9: "The system needs to automatically email customers when their order ships. Didn't we mention that?"

Week 12: "Wait, you didn't include the thing where we can adjust historical invoices for price corrections?"

We built in a 20% contingency buffer for exactly these situations. We used all of it.

Challenge 4: Performance expectations

FileMaker running locally on a desktop is fast. Like, really fast. Data is right there on the machine.

A web application making API calls to a cloud database has inherent latency. Our first beta users noticed immediately.

"This is slower than FileMaker."

We spent considerable effort on optimization:

• Aggressive caching strategies
• Pagination for large datasets
• Background loading for non-critical data
• Local storage for frequently accessed reference data

The final application is actually faster for most operations — but getting there required work we hadn't fully anticipated.

Timeline and investment: the real numbers

Let's talk about what this actually cost. These numbers are representative of this project's scope and complexity.

That's a significant investment. But consider the context:

• Their FileMaker licensing was running $1,200-1,500 per user annually for concurrent connections
• Emergency FileMaker developer support was costing $15,000-25,000 per year
• Lost productivity from system limitations was harder to quantify but very real

The break-even point, by their calculation, was approximately 3-4 years. After that, they're saving money every year while running on a more capable system.

Results: what changed

Six months after full deployment, here's where things stood:

Performance improvements

• Report generation: What took 3-5 minutes in FileMaker now completes in seconds
• Search functionality: Near-instant results across millions of records
• Mobile access: Full functionality on phones and tablets, not just "FileMaker Go compatible" layouts

Business capabilities

• API integrations: Connected to their e-commerce platform, shipping carriers, and accounting system within weeks of launch
• Customer portal: Built a customer-facing order status portal in a single sprint — something that would have been a major project in FileMaker
• Real-time inventory: That customer requirement that triggered the whole project? Delivered as a standard feature

User feedback

We surveyed users at 30, 60, and 90 days post-launch:

• 30 days: Mixed reviews. "It's different." "I miss some things about FileMaker." "The search is amazing though."
• 60 days: Warming up. "I'm getting faster." "The mobile app is a game-changer." "Can we add [new feature]?"
• 90 days: Acceptance. "I can't imagine going back." "We should have done this years ago."

The transition period was real. User adoption doesn't happen overnight, especially with a 15-year-old system being replaced.

The unexpected wins

Some benefits we didn't anticipate:

• Onboarding speed: New employees reached productivity in days instead of weeks
• Remote work: When they needed to go fully remote (sound familiar?), the web-based system made it seamless
• Hiring: "Modern tech stack" in job postings attracted better candidates than "FileMaker experience required"

Lessons learned: what we'd do differently

Every project teaches you something. Here's what we'd change:

1. Even more user involvement, earlier

We thought our discovery process was thorough. It was — for understanding the system. We should have spent more time understanding how users felt about the system.

Some features we built because they existed in FileMaker weren't actually valued. Other workflows users had developed workarounds for could have been properly solved.

2. Parallel operation should be longer

Two weeks of parallel operation per module wasn't quite enough. Four weeks would have caught more edge cases and given users more confidence.

3. Budget more for data cleaning

We knew data migration would be complex. We underestimated how complex. If we scoped this project again, we'd add 50% to the data migration budget.

4. Plan for the "feature discovery" phase

Those features nobody mentioned until development was underway? They're inevitable. Build a formal process for capturing them, prioritizing them, and deciding what makes the initial release versus a future phase.

5. Celebrate the wins along the way

We were so focused on delivery that we didn't take time to acknowledge progress. User morale matters. When the inventory module launched successfully, we should have made a bigger deal of it.

The bottom line

Migrating from FileMaker to a modern stack is absolutely doable. It's also absolutely not trivial.

The companies that succeed are the ones that:

• Invest properly in discovery
• Choose a phased approach over big bang
• Budget realistically for timeline and cost
• Plan for user adoption, not just technical migration
• Partner with teams that have done this before

Midwest Manufacturing is now running on a system that will serve them for the next 15 years — and beyond. They can integrate with anything, access from anywhere, and hire developers without posting on FileMaker-specific job boards.

Was it easy? No. Was it worth it? They'd tell you yes without hesitation.

And that FileMaker database that ran their business for 15 years? It's archived, backed up, and available if they ever need to reference it. Because you never throw away 15 years of institutional knowledge — you just build something better on top of it.

Entvas Editorial Team

Helping businesses make informed decisions