6 Cloud Migration Strategies for FileMaker Apps

In 2021, cloud data centers will process 94% of workloads (Cisco). The big enterprises are already fully migrated or working hard at completing the transition. However, many of our clients, mostly SMBs, are still trying to navigate the possibilities and plan their approach. As AWS consultants, we strive to help each client understand how a cloud-first strategy can benefit their business and built a custom plan to help them launch a cloud migration.

The Six Rs

  1. Re-Host (“lift and shift”): moving existing infrastructure and recreate it in the cloud
  2. Re-Platform: making minor adjustments to better leverage benefits of cloud services
  3. Re-Factor or Re-Architect: completely rewriting an application in cloud-native technologies
  4. Re-Purchase: moving from perpetual software license to a software-as-a-service model
  5. Retire: removing applications that are no longer needed from your tech stack
  6. Retain: keeping what you have and revisiting at a later time

Each of these strategies represents different options with a range of cost implications. No one strategy is better than any other, necessarily; your specific situation should dictate your strategy. You might also employ more than one strategy for different infrastructure and applications.

Cloud Migration for SMBs

Many SMBs are more comfortable moving resources to the cloud in batches instead of going “all-in,” defined as a hybrid approach to cloud migration. Each application in their tech stack requires a specific strategy and level of prioritization, and FileMaker is no exception. As a Claris Platinum Partner, we have a depth of experience in helping SMBs transition their FileMaker applications to the cloud and want to share our insights with you.

Migrating FileMaker to the Cloud

If we have a FileMaker deployment that we want to migrate to the cloud, you have to make several core considerations.

For example, you may only consider a re-purchase strategy if you plan to replace your FileMaker application with something else. Many of our clients work in FileMaker for critical operations and workflows and want to maintain their highly-customized system.

Let’s focus on the first three listed above – re-hosting, re-platforming, and re-factoring — since those are the most relevant to an SMB leveraging FileMaker.

1. Re-Hosting in the Cloud

This is probably the most obvious option and serves as the first step for many of our FileMaker clients. If you have a FileMaker Server on-premises, we can simply want to recreate that server infrastructure and environment in the cloud, delivering the same access you have now. Nothing new here — we use the same approach for setup, backups, and other cloud services so clients can immediately take advantage of AWS hosting benefits. Depending on the application, this process can move especially quickly if the file sizes involved are relatively small.

For example, consider a FileMaker deployment consisting of a large amount of data, either large FMP files or external container data. Your backup strategy is to keep seven daily backups scheduled to run each night. If we assume the total file size is 1 GB of FMP files, then you’d require 8 GB of total disk space: 1 GB for the live files and seven copies. If your files are 100 GB, then you would need 800 GB. I know external container data backup is a little different, but the root issue is the same. Volume space costs in the cloud get more expensive as you need more. This is an area that can be improved with a little adjustment.

You have a few potential problems with this option, though. It’s a costly first step for FileMaker users. Also, applications designed for an on-premises deployment may not be optimal when translating that to cloud-hosted infrastructure. Therefore, a simple “lift and shift” will not necessarily make the most of what the cloud has to offer, but it can usually be the quickest path to cloud migration.

  • Effort in time and cost: Low
  • Opportunity to optimize: Low

2. Re-Platforming on the Cloud

Also referred to as “lift, tinker, and shift,” this strategy involves making a few adjustments without changing the core application.

Are there areas that could be re-thought in order to better leverage what the cloud offers? While each version of FileMaker improves the WAN performance of hosted files, you can do a lot in your applications to optimize for performance and responsiveness.

You could also utilize snapshots instead of on-volume backups since snapshots are a fraction of the cost and automatically redundant and durable. In fact, we do just that in Soliant.cloud FileMaker managed hosting. This strategy makes the time to back up even a very large solution almost instantaneous. With the way that AWS Snapshots work, only blocks that change in a given volume are included in the storage between given snapshots; two snapshots of a 100 GB volume, for example, will take up 100 GB each. Only the size of a subsequent snapshot changes from the previous snapshot.

Other changes might include reimagining external storage to leverage storing objects in S3 instead of on a volume. You can leverage the AWS API to manage data stored in a FileMaker container field and simply reference the file when needed. You can do this securely and even improve network performance since container data does not need to be served through the database server. We really like the additional capabilities and lower costs offered by S3. Server-side encryption, write locks, versioning, replication, and lifecycles rules are just some of what can be configured to enhance storing container data in S3.

Those are just a few ideas. You have a lot more to consider depending on the specifics of your FileMaker application.

  • Effort in time and cost: Moderate to High
  • Opportunity to optimize: Moderate to High

3. Re-Factoring Your Application for the Cloud

Could your application be completely (or partially) rewritten as a Cloud Native Application? Cloud-Native is a term you will likely hear more and more going forward and for good reasons. This option is usually driven by strong business needs to scale or improve performance that would otherwise be difficult to meet. This may go against the conventional wisdom of doing everything in FileMaker, but if it’s the right thing to do, then I would recommend you consider this option.

If you really want to get the most from a cloud migration, re-factoring an application that uses a decoupled approach utilizing serverless architecture, for example, could fit the bill. By following best practices for a well-architected application, we can really make cost-effective, scalable, and resilient applications without a single point of failure.

This strategy often has higher development costs but can reduce long-term overall technology costs, an important factor when comparing total costs. You may need to shift your thinking in terms of operational expense (Op-Ex) vs. a more traditional approach of capital expense (Cap-Ex) and look at the broader picture over an extended period of time.

  • Effort in time and cost: High
  • Opportunity to optimize: High

Final Thoughts on Cloud Migration

Cloud migration strategies are not always clearly evident, just as they are not mutually exclusive. Experience in dealing with requirements pays off. We have worked with hundreds of clients with the ever-changing needs of their businesses to help them make the best choices in their FileMaker applications and deployments. We would be happy to chat with you about your needs and offer support in your cloud migration strategy. Contact us to set up a call with one of our consultants.

Learn more about the 6 R’s:
https://docs.aws.amazon.com/whitepapers/latest/aws-migration-whitepaper/the-6-rs-6-application-migration-strategies.html

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top