Which parts of an existing application should you preserve?

Your FileMaker ERP has been running for 12 years. It handles orders, inventory, invoicing, and planning — not perfectly, but reliably. Now the pressure to modernize is real, and someone in the room suggests: "Let's just start over." Before that decision is made, there is a more important question to answer: what exactly are you planning to throw away, and are you sure it has no value?

This article gives you a practical framework for evaluating your existing application layer by layer — so you can modernize confidently without destroying the institutional knowledge, proven logic, and clean data your business has been building for over a decade.

Why "start over" is almost always the wrong default

The instinct to rebuild from scratch feels logical when a system looks old. The interface is dated, the code is hard to follow, and adding anything new takes twice as long as it should. But the visible surface of an application — the UI, the layout, the scripts — is not the same as its value.

The value lives underneath: in the business rules encoded in calculation fields, in the workflow sequences that match how your team actually works, in the relationships between tables that reflect ten years of real operational decisions. A new system built without that knowledge doesn't start ahead — it starts behind.

The most expensive mistake businesses make when modernizing is replacing the entire system without first evaluating which components still do their job well. The result: budgets blown on rebuilding logic that already worked, months of disruption, and a new system that — on day one — already lacks features the old one had on day one thousand.

What does an existing application actually contain?

Before you can decide what to keep, you need a clear mental model of what an application is made of. Most business applications — FileMaker ERPs included — consist of five distinct layers, each with a different modernization profile:

1. Data layer — the actual records, historical transactions, customer data, product configurations
2. Data model — the table structure, relationships, field definitions, and keys
3. Business logic — calculation fields, validation rules, pricing formulas, workflow triggers
4. Process layer — scripts, automations, and sequences that move data through operations
5. Presentation layer — layouts, UI, forms, dashboards, and the user experience

These layers age at very different rates. The presentation layer often looks outdated within three to five years. The business logic, if it was built carefully, may still be accurate and reliable after fifteen. Treating them as one thing — and replacing all of them together — is where projects go wrong.

Layer 1: Your data — almost always worth preserving

Historical data is irreplaceable. A decade of orders, invoices, supplier records, inventory movements, and customer interactions is not just storage — it's the operational memory of your business. Pricing trends, seasonal patterns, customer behavior, supplier reliability: all of it lives in the data.

The question is not whether to keep the data, but whether to clean and migrate it, or keep it live. In most modernization projects, historical data is migrated into the new or updated system with a defined cutover date. Active records — open orders, current stock, ongoing projects — move with full fidelity. Archived records move in a queryable but read-only form.

What to watch for:

• Duplicate records that accumulated over years without deduplication
• Fields used for multiple purposes because the original data model didn't have the right structure
• Data that was entered inconsistently (free-text fields where a dropdown should have been used)

These are cleanup tasks, not reasons to discard the data. A data audit before migration is standard practice — not optional.

Layer 2: Your data model — evaluate carefully, change minimally

The table structure of a mature ERP often reflects hard-won decisions. A "shipment" table that tracks partial deliveries, a pricing table with customer-specific exceptions, a production planning schema that links work orders to stock reservations — these structures were not designed in a meeting room. They evolved through real operational pressure.

Changing the data model unnecessarily is one of the highest-risk moves in a modernization project. Every relationship you rename or restructure requires updates to every script, calculation, and report that touches it.

Preserve the data model when:

• The relationships between entities are correct (orders link to customers, line items link to products)
• The field structure matches how the business actually categorizes and reports data
• Migration to a new structure would require extensive transformation without adding business value

Rebuild the data model when:

• The structure was a workaround that never reflected reality (e.g., a single "notes" field storing five different types of structured data)
• The model prevents a critical new capability (e.g., multi-currency, multi-location, or multi-entity support)
• Performance problems trace directly to structural inefficiency, not just index or query issues

Layer 3: Business logic — the layer most often thrown away by mistake

This is the layer that deserves the most protection and the most scrutiny.

Business logic is the encoded knowledge of how your company operates. A calculation field that computes a sales margin after volume discount, returns credit, and currency adjustment isn't just a formula — it's a decision your finance team made and refined over years. A validation rule that prevents an order from being confirmed without a linked delivery address isn't just a constraint — it's a process mistake your team made once, encoded as a safeguard.

When a company rebuilds its system without auditing this layer, that knowledge evaporates. The new system goes live without the edge-case handling, the exception logic, the constraint rules. And then, three months in, the business starts rediscovering — painfully — why those rules existed.

Concrete example: A distribution company migrates away from its FileMaker ERP to a new platform. In the old system, a calculation automatically applied a freight surcharge to orders below a minimum weight threshold, with different thresholds per product category. The logic had been refined over four years. In the new system, no one documents this during the migration. For six months after go-live, freight is under-charged on a significant portion of orders before the error surfaces in a margin review.

How to audit business logic before a rebuild:

1. Export a full list of every calculation field, every script, and every validation rule
2. For each one, write a plain-language description of what it does and why
3. Flag every rule that references a business-specific condition (customer type, product category, geographic zone, etc.)
4. Mark each as: preserve as-is, preserve and migrate, rewrite with same intent, or deprecate
5. Have a domain expert — not just a developer — review the flagged rules

This audit takes time. It also routinely surfaces rules that no one in the current team knew existed, written by someone who left the company years ago. That's exactly why it's worth doing.

Layer 4: Process workflows — keep the intent, modernize the execution

The scripts and automations in a FileMaker ERP often represent the operational sequence your business actually follows — the real order of steps, not the theoretical one in a process document. An invoicing script that generates a PDF, updates stock, notifies the warehouse, and flags the order as billable is doing five things in a specific sequence because that sequence matters.

The right approach here is to separate what the process does from how it is currently implemented. The what — the sequence, the dependencies, the triggers — is worth preserving. The how — the specific scripting method, the hardcoded paths, the workarounds for platform limitations — often isn't.

Modernization pattern: Map every significant process as a flowchart before touching the code. Document inputs, steps, decision points, and outputs. This becomes the specification for the rebuilt process, ensuring the logic transfers even if the implementation changes entirely.

This is also the layer where API integrations come into play. A process that currently runs entirely inside FileMaker — say, a purchase order workflow that manually requires someone to re-enter data into an accounting system — can often be modernized by keeping the FileMaker workflow intact and adding an API connector to push data automatically. The process is preserved; the manual step is eliminated.

Layer 5: The presentation layer — the safest layer to rebuild

The UI is almost always the right answer to "what should we rebuild?" Layouts that made sense on a 2010 screen with a 2010 workflow often feel clunky today. Navigation that requires five clicks to reach a commonly used function, forms that show 40 fields when the user only needs 8, reports that can't be exported — these are legitimate UX problems, and they are the least risky things to change.

Rebuilding the presentation layer doesn't mean rebuilding the application. A modern UI sitting on top of preserved business logic and a solid data model is a completely valid modernization outcome — and often a much faster, cheaper, and lower-risk one than a full rebuild.

What good UI modernization looks like:

• Role-based layouts that show each user only what they need
• Mobile-accessible or browser-accessible interfaces where field staff need them
• Dashboard views that surface the KPIs a manager actually looks at daily
• Cleaner input forms that reduce errors and training time for new employees

None of this requires touching the underlying logic. It requires understanding what users actually do with the system — which means user interviews, not just developer assumptions.

How to structure the decision: a practical framework

When you sit down with your team to evaluate your existing application, use this five-step process:

1. Inventory all five layers — data, data model, business logic, processes, and UI — separately. Don't evaluate the application as one thing.
2. Score each component on two axes: business accuracy (does it still reflect how operations actually work?) and technical health (is it maintainable, performant, and extendable?).
3. Map dependencies — identify which components depend on which others. A UI change that requires no logic change is low risk. A data model change that cascades into 200 scripts is high risk.
4. Prioritize pain points — which components are actively causing problems today? Start modernization there, not with whatever looks oldest.
5. Define a modernization path — not a binary keep/replace decision, but a phased plan: what gets preserved as-is, what gets migrated, what gets rebuilt with the same intent, and what gets deprecated.

This is how modernizing a business application without starting over actually works in practice — component by component, with a clear rationale for each decision.

Checklist: what to preserve vs. what to rebuild

Almost always preserve:

• ✅ Historical transaction data
• ✅ Core entity relationships (customers, orders, products, suppliers)
• ✅ Business logic rules that encode operational decisions
• ✅ Exception-handling rules and edge-case constraints
• ✅ Process sequences that reflect real operational dependencies

Evaluate carefully:

• 🔍 Data model structure (preserve unless it blocks a critical capability)
• 🔍 Automation scripts (preserve the intent; assess whether the implementation can be improved)
• 🔍 Integrations with other systems (check whether better API options now exist)

Usually safe to rebuild:

• 🔄 UI layouts and navigation
• 🔄 Reports and dashboards
• 🔄 Manual data entry forms
• 🔄 Workarounds that existed only because of platform limitations

FAQ

How do we know if our business logic is still accurate? Have a domain expert — someone who works in the process daily — walk through each rule with a developer. The developer explains what the system does; the expert confirms whether that matches current operational reality. Discrepancies mean the logic needs updating, not necessarily replacing.

What if no one on the current team knows why a rule exists? That's more common than you'd expect in a 10–15-year-old system. The default position should be: treat unknown rules as potentially important until proven otherwise. Test them with real scenarios before deciding to remove them.

Is it ever right to start completely from scratch? Rarely, but yes — when the data model is so structurally broken that migration would cost more than rebuilding, or when the business has changed so fundamentally that none of the existing logic applies. Even then, the data almost always migrates.

How long does a proper preservation audit take? For a typical FileMaker ERP with 20–50 tables, 100+ scripts, and years of calculation logic: expect two to four weeks of structured analysis before any development begins. This is not overhead — it's the work that makes the modernization project succeed.

Can we modernize incrementally, or does it have to be all at once? Incremental is almost always better. Modernize the UI first while leaving logic intact. Add API integrations to eliminate manual steps. Refactor one module at a time. A phased approach reduces risk, keeps the business running, and lets you validate each change before the next one.

---

If you're working through exactly this kind of decision — a mature FileMaker ERP that still does its job but needs to evolve — Loggix works through the analysis with you: mapping your existing logic, identifying what's worth preserving, and designing a modernization path that fits your operations and your budget. Whether that means extending what you have, connecting it to other systems through API integrations, or rebuilding specific modules with a cleaner foundation, the starting point is always a clear picture of what you actually have.