FileMaker to AWS: Migration Architecture Options

Your FileMaker application might fit inside one file. The business it runs almost certainly does not.

Inside are relationships, calculations, scripts, permissions, layouts, documents, and exceptions someone added because “accounting needs it that way.”

Moving that application to Amazon Web Services (AWS) means deciding where each responsibility belongs. That is a bigger decision than choosing a server.

There are three useful starting points: a conventional application, a serverless application, or a container-based application. None automatically wins on cost, reliability, or simplicity.

The best FileMaker cloud migration architecture is the one your business needs—and your team can actually operate.

First, distinguish hosting from replacement

Running FileMaker Server on an appropriately supported Amazon Elastic Compute Cloud (EC2) instance is a hosting change. Rebuilding its workflows with a new frontend, backend, and database is an application replacement.

This guide covers the second path.

You cannot put a FileMaker file into Amazon Relational Database Service (RDS) and expect its scripts, layouts, and permissions to follow. RDS runs supported database engines; it does not run FileMaker applications.

Migrating records moves data. Migrating an application preserves business behavior.

Before selecting infrastructure, inventory calculations, scheduled scripts, integrations, reporting, access rules, and document handling. Those requirements determine the architecture—not the other way around.

Why choose AWS?

AWS offers building blocks for computing, databases, storage, identity, monitoring, and messaging. That ecosystem can make it easier to extend a replacement application without building every supporting capability yourself.

Scalability is another benefit: different parts of the application can grow independently. More document storage does not necessarily require a bigger application server.

Reliability, however, is a design choice rather than a cloud souvenir. A single EC2 instance remains a single point of failure. Database failover, redundant application instances, tested backups, and recovery procedures require configuration and funding.

AWS supplies capabilities. Your architecture determines which ones you actually receive.

Option 1: EC2, RDS, and S3

For a straightforward internal application, a conventional architecture is often the clearest starting point:

EC2: Runs the backend application.
RDS: Hosts a relational database such as PostgreSQL or MySQL.
Amazon Simple Storage Service (S3): Stores uploaded documents and other files.

The browser communicates with the application, which validates requests, applies business rules, and accesses the database. Files can move through the application or through controlled direct uploads to S3.

This suits predictable workloads, familiar web frameworks, and teams that prefer one application over many separately deployed services.

The trade-off is operational responsibility. Someone must manage the operating system, application dependencies, deployments, monitoring, and capacity. RDS reduces database infrastructure work, but it does not design indexes, fix inefficient queries, or decide your recovery requirements.

For stronger availability, add application instances across Availability Zones, load balancing, and an appropriate RDS Multi-AZ configuration. Those additions change both complexity and cost.

“Simple” should mean understandable—not “everything depends on one machine.”

Option 2: Lambda, API Gateway, and DynamoDB

In a serverless design, Amazon API Gateway receives requests and invokes AWS Lambda functions. Amazon DynamoDB stores application data.

This can fit workloads with quiet periods, bursts of activity, and short, discrete operations. You avoid managing application servers and can scale request handling without provisioning individual machines.

But serverless moves complexity rather than deleting it.

Lambda has execution limits, and some workloads encounter startup latency. Long-running jobs need another execution approach or careful orchestration. Retries also require design: a repeated request should not accidentally create two invoices.

DynamoDB is especially important here. Its data model should follow known access patterns. It is not a drop-in replacement for relational joins and flexible reporting queries.

Consider an application where staff continually invent new reports combining customers, orders, inventory, and payments. A relational database may fit better—even if Lambda remains the backend.

Serverless compute does not require a serverless-first database choice.

Option 3: ECS or EKS with RDS

Containers package application code and its dependencies into deployable units.

Amazon Elastic Container Service (ECS) manages container workloads. Amazon Elastic Kubernetes Service (EKS) provides managed Kubernetes. Either can support applications that use RDS for relational data.

This approach suits applications with background workers, specialized dependencies, multiple services, or deployment requirements that outgrow a basic server setup.

ECS with AWS Fargate can remove the need to manage the underlying container hosts. EKS makes more sense when Kubernetes capabilities or existing Kubernetes expertise justify its additional operational surface.

For many smaller teams, ECS is the simpler starting point.

Containers do not require microservices, either. A single well-structured application can run in a container, with separate workers handling document generation or imports.

Splitting every FileMaker script into its own service would create plenty of architecture. It might not create much business value.

Choose the database before chasing the trend

FileMaker applications often contain interconnected records. That makes a relational database a natural starting point.

PostgreSQL is a strong default candidate for relationships, transactions, constraints, and reporting. MySQL is also a reasonable choice, particularly when your team already knows it or an application framework favors it.

The choice should reflect query requirements, compatibility, support skills, and operational needs—not a popularity contest.

DynamoDB deserves consideration when access patterns are well understood and its managed scaling model matches the workload. Expect data-model redesign rather than a table-for-table migration.

Pay particular attention to FileMaker calculations and unstored values. Some belong in database queries; others belong in application logic or background processing.

Also recreate important validation rules. A screen that prevents invalid input is not enough if an integration can bypass that screen.

Frontends: React, Next.js, or server-rendered?

A React single-page application (SPA) works well for interactive, desktop-like workflows. It typically communicates with a backend through an application programming interface (API).

Next.js, a React framework, offers server-rendered and client-rendered approaches. It can suit applications combining public pages with authenticated workflows, although hosting requirements depend on the features you use.

A traditional server-rendered application remains a sensible option for forms, approvals, and administrative screens. Fewer moving parts can make development and maintenance easier.

The interface should follow how people work. Replacing FileMaker does not require turning every screen into a JavaScript engineering project.

Whichever frontend you choose, keep authoritative permissions and business validation on the backend.

Documents and identity need their own migration plan

FileMaker container fields may hold embedded files or references to externally stored content. Inventory both before migration.

A common replacement pattern stores file content in S3 and stores metadata—such as the object key, filename, record relationship, and ownership—in the database.

Keep objects private. Authorize access through the application and, where appropriate, issue short-lived presigned URLs. Possession of an object key should not grant permission to download it.

Amazon Cognito can handle user authentication and token issuance. It does not automatically reproduce FileMaker privilege sets.

Separate authentication, which establishes identity, from authorization, which determines permitted actions. Define who can view, edit, export, approve, and delete each type of record.

Plan account migration carefully; do not assume existing passwords can simply be exported and reused.

Monthly costs: compare equivalent systems

There is no defensible “typical monthly cost” without a region, workload, availability target, and current pricing. Dollar ranges without those assumptions would look useful while concealing the actual decision.

The meaningful comparison is:

EC2 architecture: An ongoing compute and database baseline, plus storage, backups, networking, and monitoring.
Serverless architecture: More usage-sensitive compute and request charges, plus database operations, storage, logging, and supporting services.
Container architecture: Compute capacity or task consumption, database costs, load balancing, and platform overhead. EKS adds a cluster charge.

Serverless can be economical for light, intermittent traffic. Steady workloads may favor provisioned capacity. Containers are not inherently cheaper or more expensive than EC2.

Use the AWS Pricing Calculator with identical assumptions for each option. Include staging environments, outbound data transfer, network address translation (NAT) gateways where needed, backups, and operational support.

Ask for two estimates: normal operation and a plausible busy month. Keep migration development costs separate from recurring infrastructure and maintenance costs.

Choose the architecture your team can sustain

Start with five questions:

Are workflows mainly relational forms and reports, or independent event-driven tasks?
Is demand steady, intermittent, or sharply bursty?
What downtime and data loss can the business tolerate?
Who will deploy, monitor, troubleshoot, and maintain the application?
Which future requirements are concrete enough to design for now?

For a straightforward replacement, a conventional relational application is often a sensible baseline. Serverless becomes attractive when workload patterns and task boundaries support it. Containers help when packaging and deployment needs justify them.

Then test the choice with one demanding workflow—not merely the easiest screen.

If you plan to replace FileMaker with AWS, the goal is not to reproduce its visible interface on fashionable infrastructure. It is to preserve the business rules people depend on while making those rules easier to understand, maintain, and change.