A FileMaker migration skill upgraded for enterprise complexity. The DDR parser now extracts invisible UI logic — conditional formatting and hide-object-when rules that encode authorization models and business workflows. Seven new explorer workflows analyze scripts, calculations, formatting rules, and access control layers. A multi-file travel agency solution drove every enhancement.
migrate-filemaker v1.1
A FileMaker migration skill existed. Four phases: parse the DDR, discover requirements, recommend a stack, generate a plan. It handled simple and medium apps well — tables, fields, scripts, layouts. The visible stuff.
A travel agency solution arrived and changed the requirement. Multi-file: UI file plus data file, tightly coupled through external table references. Conditional formatting rules encoding authorization. Hide-object-when conditions driving UI state machines. Calculated fields carrying pricing logic, commission splits, booking validation rules. None of it visible in the standard DDR output. All of it critical to the business.
The skill was not ready. The skill got ready.
Extracting invisible logic
The DDR parser had always extracted tables, fields, relationships, and scripts. It produced eight structured JSON spec files covering the visible schema. What it missed: conditional formatting and hide-object-when rules. These are the formulas FileMaker developers use to change field colors, show or hide interface elements, and enforce what different users can see on every layout.
In a travel agency solution, these invisible rules encode the application's nervous system. A field turns red when a booking exceeds the credit limit. A commission field appears only for managers. A set of buttons vanishes when a trip status reaches confirmed. Hundreds of rules across dozens of layouts. Each one a piece of business logic with no representation in the table schema or script catalog.
The parser was extended. Two new spec files now emerge from every DDR: 09_conditional_formatting.json and 10_hide_object_when.json. Each rule gets its formula text, its target layout and object, its condition body. Nothing is dismissed. Everything is cataloged. Eleven spec files instead of eight.
Seven explorer workflows
Extracting the rules was step one. Making sense of them at scale required step two. Seven new explorer workflows were built, each processing one dimension of a FileMaker solution with model intelligence rather than deterministic thresholds.
Classifies every script by type, logic tier, and migration category. Six reports: summary, tier-1 critical list, data-writes analysis, backbone identification, hardest-to-migrate, and module assignment.
Processes every formatting rule per layout. Three reports cataloging financial thresholds, state indicators, and edge cases. The hidden nervous system of the application.
The authorization decoder. Maps every hide condition to its authorization layer. Often more complete than the privilege set catalog — FM developers encode fine-grained access through visibility rules, not privilege sets.
Catalogs per-table calculations — stored for commission splits, unstored for dynamic pricing, summary for booking totals. Three reports: domain identification, cross-table dependencies, migration-priority matrix.
Maps the shared logic layer. Traces every call site across scripts, calculations, and layout formulas. Translates function signatures to modern equivalents.
Reads parsed DDR specs and the tech stack recommendation. Presents key schema decisions for confirmation and generates the complete database DDL. Every FileMaker field type mapped to its modern equivalent.
Generates the full frontend specification — page inventory, component mapping, form specs, responsive requirements. The visual DNA of the old app translated into a modern blueprint.
What the travel agency surfaced
The enhancements were not speculative. A real FileMaker solution drove every decision.
- Multi-file DDR parsing — the travel agency had a UI file and a data file sharing tables through external references
- Conditional formatting explorer — authorization was embedded in hundreds of layout formulas, not in privilege sets
- Hide-object-when explorer — the full UI state machine lived in visibility conditions
- Calculated fields explorer — pricing and commission logic existed only in unstored calculations, invisible to schema analysis alone
The skill at scale
- Phase 1 — eleven spec files instead of eight, capturing conditional formatting and hide-object-when rules
- Phase 2 — smarter discovery questions because explorer reports surface specialized business logic before the first question is asked
- Phase 3 — more informed stack recommendations because complexity scoring accounts for invisible logic, not just visible schema
- Phase 4 — richer output because business logic mapping traces actual formulas through explorer reports
Architecture — v1.1
v1.1 ships. The travel agency was the catalyst.