How I’m using the Strangling Fig pattern to breathe new life into a decade-old FileMaker database
The Challenge: A Digital Archaeological Dig
When I inherited a FileMaker system last updated in 2013, I found myself staring at what felt like a digital archaeological site. Over 100 tables, 100,000+ records, 100+ scripts, and 100+ layouts—all frozen in time from the early 2010s. The system worked, but it carried the technical debt of a decade and the user experience expectations of a bygone era.
The traditional approach would be to plan a massive system rewrite or migration. But anyone who’s worked with legacy systems knows how that story usually ends: months of planning, scope creep, user resistance, and often, project abandonment. As the lead developer for a small team I had to find a more measured approach.
Instead, I turned to a concept from software architecture that’s as elegant as it is effective: the Strangling Fig pattern.
What is the Strangling Fig Pattern?
Named after the strangling fig trees that grow around host trees until they eventually replace them entirely, this architectural pattern involves gradually replacing parts of a legacy system with new implementations. Rather than a big-bang migration, you incrementally strangle the old system by:
- Identifying discrete components that can be isolated
- Building modern replacements alongside the legacy system
- Gradually routing traffic from old to new
- Eventually removing the obsolete components
The beauty of this approach is that the system remains functional throughout the transformation, users experience gradual improvements rather than jarring changes, and you can validate each component before moving to the next.
Breaking Down the Monolith: Finding the Seams
The first challenge was identifying where I could “break” components away from the legacy system. In FileMaker, this meant analyzing:
- Table relationships and dependencies
- Script interconnections and shared workflows
- Layout hierarchies and navigation patterns
- Data flow between different functional areas
I started mapping the system like an archaeologist documenting layers of sediment. Some areas were tightly coupled and touching one table would cascade through dozens of relationships. But other areas, like my coupon management system, had clearer boundaries.
The coupon manager became my proof of concept. It had:
- Defined data boundaries (coupons, manufacturers, activation details)
- Limited integration points with other system components
- High user interaction (perfect for demonstrating UI improvements)
- Complex business logic that could benefit from modernization
The Transformation: Old vs. New
The Legacy Interface
The original coupon management interface was functional but showed its age:
- Dense, form-heavy layouts reminiscent of desktop software from the 2000s
- Limited visual hierarchy and overwhelming information density
- Navigation that required multiple clicks to access related information
- No responsive design considerations
The Modern Approach
My strangling fig replacement focuses on:
Clean, Modern UI Design
- Contemporary web-style interface that doesn’t scream “FileMaker”
- Improved visual hierarchy with strategic use of white space
- Tabbed navigation for better information organization
- Card-based layouts for better scanability
Consolidated Data Architecture
- Reduced table complexity by combining related entities
- Streamlined relationships for better performance
- Eliminated redundant data storage patterns
Enhanced User Experience
- Intuitive navigation that reduces cognitive load
- Contextual information display
- Modern form design principles
- Responsive layout considerations
The Migration Strategy: Data in Motion
One of the trickiest aspects of the strangling fig pattern is handling data migration while both systems are running. My approach involved:
- Creating bridge scripts that can sync data between old and new structures
- Implementing validation routines to ensure data integrity during transition
- Building rollback mechanisms in case issues arise
- Establishing monitoring to track system performance and user adoption
The goal is to make the transition invisible to end users while ensuring no data is lost in the process.
Performance Gains: Numbers Don’t Lie
The modernization has yielded measurable improvements:
- Faster load times due to optimized table structures
- Improved query performance from better indexing strategies
- Reduced clicks for common workflows
- Lower maintenance overhead from simplified relationships
But perhaps most importantly, user feedback has been overwhelmingly positive. The interface feels contemporary and intuitive, which increases adoption and reduces training needs.
Lessons Learned: The Path Forward
What Worked Well
Incremental Approach: Users barely noticed the transition, which eliminated resistance to change.
Component Isolation: Focusing on discrete functional areas made the project manageable.
Modern Design Principles: Applying contemporary UI/UX standards made the system feel completely new despite running on the same platform.
Challenges Faced
Dependency Mapping: Understanding all the interconnections took longer than expected.
Data Consistency: Maintaining sync between old and new components required careful planning.
User Training: Even with intuitive design, some workflow changes required user education.
The Bigger Picture: Why This Matters
Legacy system modernization is about more than just pretty interfaces. It’s about:
- Reducing technical debt that slows development
- Improving user productivity through better design
- Enabling future enhancements with cleaner architecture
- Maintaining business continuity during transformation
The strangling fig pattern offers a pragmatic path forward for organizations sitting on valuable but aging systems. You don’t have to choose between “replace everything” and “change nothing.”
Conclusion: Patience and Persistence
The strangling fig doesn’t kill its host overnight, it’s a gradual process that takes patience and persistence. Similarly, modernizing legacy systems isn’t about dramatic transformations but about consistent, thoughtful progress. The key is thinking like a gardener rather than a demolition crew: nurture the new growth while gradually removing what no longer serves.
Need help with a legacy system modernization in your organization? Drop me a line at sam@plumcoveconsulting.com