[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f14ctMHXTlgqX-XEFtW8qvwfv84_YWsT_laMkiYhHAk8":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":27,"hasDownload":28,"fileName":9,"youtubeId":29,"domainCrumb":30,"clusterCrumb":33},"124","40173286-3089-7249-B637-C8ED1589E57F","5D5F3733-6027-284B-BC54-3DAF4A98517A","C9A2E812-0A2C-FC46-929B-A19F9A440E05","","when-a-complete-rebuild-really-is-the-better-option","When a complete rebuild really is the better option","Patching a legacy ERP can cost more than replacing it. Learn the concrete signs, decision criteria, and step-by-step process for knowing when a full rebuild is the right call.","Your FileMaker ERP has been running the business for fifteen years. It's been customized, extended, patched, and re-patched so many times that nobody — not even the developer who last touched it — fully understands how it all fits together. Every new requirement means negotiating with a fragile codebase, and every fix risks breaking something else. At some point, the honest question has to be asked: are you still modernizing this system, or are you just keeping it alive?\n\nThis article helps you recognize when a complete rebuild has become the more rational choice — and how to make that decision with confidence rather than anxiety.\n\n---\n\n## Why the \"just fix it\" instinct is so hard to shake\n\nMost businesses default to incremental improvement, and that's usually the right call. Rebuilding is expensive, disruptive, and risky. Nobody wants to explain to the board why they're spending six figures replacing something that technically still works.\n\nBut \"technically still works\" is doing a lot of heavy lifting in that sentence. A system can be running and still be costing you far more than a replacement would — in developer hours, in lost productivity, in business opportunities you can't pursue because the software can't support them.\n\nThe instinct to patch rather than rebuild is rational until it isn't. The article [How to modernize business software without starting over](https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-modernize-business-software-without-starting-over) covers all the scenarios where incremental modernization makes sense. This article covers the exception: when the architecture itself has become the problem.\n\n---\n\n## What does a system look like when it's reached the end of its useful life?\n\nThere is no single alarm that goes off. It's usually a pattern — several of these symptoms appearing together, worsening over time:\n\n- **No one fully understands the system anymore.** The original developer is gone. The person who replaced them has documented some of it. The third developer is guessing. Making a change to the quoting module requires testing five unrelated parts of the system because the dependencies are invisible.\n- **Every fix creates a new problem.** A field is renamed and three calculation fields break silently. A layout is updated and a script stops firing. The system has become a house of cards.\n- **New business requirements simply don't fit.** You want to give customers a portal to track their own orders. The database structure makes this architecturally impossible without a complete redesign of the core tables. You want to connect to a modern WMS via API. The data model wasn't built for that.\n- **Security and compliance requirements can't be met.** GDPR demands field-level audit logging. The system wasn't designed with that in mind and retrofitting it would require rebuilding large parts of the data layer anyway.\n- **Performance degrades with scale.** The system was designed when the company had twelve employees and 5,000 order records. Now there are eighty employees and 800,000 records. Searches that once took one second now take thirty-five. Adding an index helps briefly, then the problem returns.\n- **The maintenance cost is a hidden business tax.** Developer invoices for a system this fragile are unpredictable. Three days to change a VAT rate. Two weeks to add a new product category. Each small change is a mini-project with its own risk of regression.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F32?w=700&f=webp\" alt=\"Legacy system buried in layers of patches, tangled arrows showing dependencies between modules\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n---\n\n## The cost calculation most businesses get wrong\n\nWhen companies compare \"keep patching\" vs. \"rebuild,\" they usually undercount the cost of patching and overcount the risk of rebuilding.\n\n**The real cost of staying on a broken architecture includes:**\n\n1. **Direct maintenance cost** — developer hours spent on fixes, workarounds, and regressions. Track this for three months. Most businesses are shocked.\n2. **Opportunity cost** — features you can't build, integrations you can't make, processes you can't automate because the architecture won't support it.\n3. **Staff productivity loss** — users working around system limitations. A warehouse manager who exports a FileMaker report to Excel every morning and re-enters the totals manually into a separate system. Every day. That's not a small number over a year.\n4. **Risk exposure** — one critical bug in a fragile system can halt operations. The older and less understood the system, the higher this tail risk.\n5. **Recruitment and retention cost** — good developers don't want to work in a codebase nobody understands. Finding someone willing to maintain a fifteen-year-old undocumented FileMaker system is getting harder every year.\n\nA rebuild, priced correctly and scoped realistically, is often cheaper over a three-year horizon than continuing to maintain a system that has crossed this threshold.\n\n---\n\n## How to recognize the actual tipping point\n\nHere is a concrete checklist. If you check five or more of these, a rebuild deserves serious evaluation:\n\n**Architecture and maintainability**\n- [ ] No single developer can explain how the full system works\n- [ ] The data model has grown organically and contains significant structural debt (redundant tables, overloaded fields, naming inconsistencies)\n- [ ] Relationships between tables are undocumented or counterintuitive\n- [ ] Scripts and calculations reference global variables in ways that are hard to trace\n- [ ] There is no test suite or change documentation\n\n**Business fit**\n- [ ] A required integration (API, portal, external platform) cannot be built without restructuring the database\n- [ ] Core business processes have changed significantly since the system was designed, and the software no longer maps to how the company actually works\n- [ ] You are maintaining manual workarounds (Excel exports, double data entry, email-based approvals) that should be handled by the system\n\n**Security and compliance**\n- [ ] The system lacks field-level access control or audit logging that regulators or customers now require\n- [ ] Data is not encrypted at rest in a way that meets current standards\n- [ ] User permission structures can't be granular enough for your current team structure\n\n**Cost and risk**\n- [ ] Developer costs for the past twelve months exceed what a focused rebuild would cost in the same timeframe\n- [ ] A single undocumented change has caused a production outage in the last two years\n- [ ] The platform version is no longer supported or is approaching end of support\n\n---\n\n## What a rebuild actually involves — step by step\n\nThe fear of rebuilding is often based on a vague mental image of throwing everything away and starting from a blank page. A well-run rebuild doesn't look like that.\n\n**Step 1: Audit before you architect**\nDocument what the current system actually does — not what it was supposed to do, but what the business relies on today. This is often revealing: many companies discover that 60–70% of the features in their old system are unused or have been replaced by workarounds.\n\n**Step 2: Define the new architecture around current and future needs**\nDesign the data model cleanly for the business as it is now and as it will be in three to five years. This is where the real value of a rebuild is created — not in replicating the old system but in designing one that fits the actual business.\n\n**Step 3: Prioritize a phased rollout**\nA good rebuild is rarely a single big-bang go-live. Define an MVP (minimum viable product) that covers core operations — order management, inventory, invoicing — and go live with that first. Add modules incrementally. This limits risk and delivers value faster.\n\n**Step 4: Plan the data migration seriously**\nHistorical data migration is consistently underestimated. Fifteen years of order records, customer data, and product history need to move cleanly. Budget real time for mapping, cleaning, and validating the migrated data.\n\n**Step 5: Run parallel operation during transition**\nFor a defined period — typically two to eight weeks depending on complexity — run both systems simultaneously for the same transactions. This is your safety net, and it's non-negotiable for a business-critical ERP.\n\n**Step 6: Decommission with a clear cutover date**\nSet a hard date. Systems that are \"kept around just in case\" become a source of confusion and split operations. Once the new system is validated, retire the old one.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F31?w=700&f=webp\" alt=\"Phased rebuild timeline: audit, design, MVP launch, parallel run, cutover, decommission\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-right sm:ml-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n---\n\n## What can you actually preserve from the old system?\n\nA rebuild doesn't mean you discard institutional knowledge. What you preserve:\n\n- **Business logic** — the rules that govern how your business works (pricing logic, discount structures, workflow sequences). These get re-implemented in clean, documented code.\n- **Historical data** — migrated, cleaned, and validated into the new structure.\n- **User expertise** — your team knows how the business works. That knowledge feeds the design of the new system.\n\nWhat you leave behind:\n\n- Structural debt in the data model\n- Undocumented scripts and globals\n- Workarounds that existed because the old architecture forced them\n- Platform limitations that blocked integrations or scalability\n\n---\n\n## Real scenario: when a rebuild saved more than it cost\n\nConsider a distribution company running a FileMaker ERP built in 2008. Over fourteen years, the system had grown from a simple order management tool into something managing purchasing, warehouse operations, invoicing, and customer communication — none of which it was originally designed for.\n\nThe symptoms: a warehouse manager manually copying pick lists from FileMaker into a spreadsheet every morning because the system couldn't print in the right format. A two-week developer engagement every time a new product type was added, because the product table had been extended with workaround fields so many times the structure was incomprehensible. An inability to connect to the company's new logistics platform via API because the data model didn't map to standard structures.\n\nThe company spent three months evaluating incremental modernization. The conclusion: fixing the API problem alone would require restructuring four core tables. That work would destabilize the rest of the system. The estimated cost of that single fix exceeded 40% of a full rebuild.\n\nThe rebuild took eight months. The first four months delivered an MVP covering orders, inventory, and invoicing. The warehouse manager's morning spreadsheet disappeared on day one of go-live. The API connection to the logistics platform was built in week two of the project, not as an afterthought but as a designed feature of a clean architecture.\n\n---\n\n## Frequently asked questions\n\n**How do I know if it's the architecture that's the problem, or just the implementation?**\nAsk your developer to estimate the cost of the next three features on your roadmap. If each estimate comes back with a significant \"first we need to restructure...\" caveat, the architecture is the problem. Implementation issues are fixable locally. Architectural debt spreads through every change.\n\n**Can I rebuild in FileMaker, or do I need to move to a different platform?**\nFileMaker remains a strong platform for custom business applications when used with a clean, modern architecture. The problem in most legacy cases is not the platform — it's the structure built on top of it. A rebuild in FileMaker with proper data modeling, documented scripts, and a clear separation of concerns produces a system that is maintainable and scalable. That said, if your use case has outgrown what FileMaker does well (very high concurrency, heavy web-native workflows, etc.), a rebuild is also the right moment to evaluate alternatives.\n\n**How long does a full rebuild take?**\nFor a mid-complexity ERP (orders, inventory, invoicing, CRM basics), a realistic timeline is six to twelve months from discovery to full go-live. A phased approach — MVP first, then additional modules — means you see working software in production within three to four months in most cases.\n\n**What if the business can't afford downtime?**\nNo well-planned rebuild requires downtime. Parallel operation during transition ensures the business continues running on the known system while the new one is validated. The cutover is a controlled event, not a forced shutdown.\n\n**How do I get budget approval for a rebuild when the current system \"still works\"?**\nBuild the cost case around the three-year total cost of ownership comparison: current maintenance costs + opportunity costs + risk exposure vs. rebuild cost + three years of maintenance on a clean system. Most CFOs respond to a concrete numbers comparison, not a technical argument.\n\n**Will a rebuild become the same mess in ten years?**\nOnly if the same conditions are allowed to develop: undocumented changes, no architectural governance, features added without design review. A rebuild creates the opportunity to establish better practices — version control, change documentation, modular design — that prevent the same accumulation of debt.\n\n---\n\nIf you're recognizing your own system in this article, the next useful step is usually an honest technical audit — not a sales conversation, but a structured review of where your architecture stands and what your real options are. At Loggix, we help businesses work through exactly that kind of assessment: mapping what the current system actually does, identifying where the structural debt is concentrated, and building a realistic picture of what modernization vs. rebuild actually costs in your specific situation. Whether the answer turns out to be a targeted FileMaker rebuild, a move to a web-based custom application, or a phased integration strategy, the starting point is the same — understanding the problem clearly before committing to a direction.","\u003Cp>Your FileMaker ERP has been running the business for fifteen years. It's been customized, extended, patched, and re-patched so many times that nobody — not even the developer who last touched it — fully understands how it all fits together. Every new requirement means negotiating with a fragile codebase, and every fix risks breaking something else. At some point, the honest question has to be asked: are you still modernizing this system, or are you just keeping it alive?\u003C\u002Fp>\n\u003Cp>This article helps you recognize when a complete rebuild has become the more rational choice — and how to make that decision with confidence rather than anxiety.\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>Why the "just fix it" instinct is so hard to shake\u003C\u002Fh2>\n\u003Cp>Most businesses default to incremental improvement, and that's usually the right call. Rebuilding is expensive, disruptive, and risky. Nobody wants to explain to the board why they're spending six figures replacing something that technically still works.\u003C\u002Fp>\n\u003Cp>But "technically still works" is doing a lot of heavy lifting in that sentence. A system can be running and still be costing you far more than a replacement would — in developer hours, in lost productivity, in business opportunities you can't pursue because the software can't support them.\u003C\u002Fp>\n\u003Cp>The instinct to patch rather than rebuild is rational until it isn't. The article \u003Ca href=\"https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-modernize-business-software-without-starting-over\">How to modernize business software without starting over\u003C\u002Fa> covers all the scenarios where incremental modernization makes sense. This article covers the exception: when the architecture itself has become the problem.\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>What does a system look like when it's reached the end of its useful life?\u003C\u002Fh2>\n\u003Cp>There is no single alarm that goes off. It's usually a pattern — several of these symptoms appearing together, worsening over time:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>No one fully understands the system anymore.\u003C\u002Fstrong> The original developer is gone. The person who replaced them has documented some of it. The third developer is guessing. Making a change to the quoting module requires testing five unrelated parts of the system because the dependencies are invisible.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Every fix creates a new problem.\u003C\u002Fstrong> A field is renamed and three calculation fields break silently. A layout is updated and a script stops firing. The system has become a house of cards.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>New business requirements simply don't fit.\u003C\u002Fstrong> You want to give customers a portal to track their own orders. The database structure makes this architecturally impossible without a complete redesign of the core tables. You want to connect to a modern WMS via API. The data model wasn't built for that.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Security and compliance requirements can't be met.\u003C\u002Fstrong> GDPR demands field-level audit logging. The system wasn't designed with that in mind and retrofitting it would require rebuilding large parts of the data layer anyway.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Performance degrades with scale.\u003C\u002Fstrong> The system was designed when the company had twelve employees and 5,000 order records. Now there are eighty employees and 800,000 records. Searches that once took one second now take thirty-five. Adding an index helps briefly, then the problem returns.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>The maintenance cost is a hidden business tax.\u003C\u002Fstrong> Developer invoices for a system this fragile are unpredictable. Three days to change a VAT rate. Two weeks to add a new product category. Each small change is a mini-project with its own risk of regression.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F32?w=700&f=webp\" alt=\"Legacy system buried in layers of patches, tangled arrows showing dependencies between modules\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Chr>\n\u003Ch2>The cost calculation most businesses get wrong\u003C\u002Fh2>\n\u003Cp>When companies compare "keep patching" vs. "rebuild," they usually undercount the cost of patching and overcount the risk of rebuilding.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>The real cost of staying on a broken architecture includes:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Direct maintenance cost\u003C\u002Fstrong> — developer hours spent on fixes, workarounds, and regressions. Track this for three months. Most businesses are shocked.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Opportunity cost\u003C\u002Fstrong> — features you can't build, integrations you can't make, processes you can't automate because the architecture won't support it.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Staff productivity loss\u003C\u002Fstrong> — users working around system limitations. A warehouse manager who exports a FileMaker report to Excel every morning and re-enters the totals manually into a separate system. Every day. That's not a small number over a year.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Risk exposure\u003C\u002Fstrong> — one critical bug in a fragile system can halt operations. The older and less understood the system, the higher this tail risk.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Recruitment and retention cost\u003C\u002Fstrong> — good developers don't want to work in a codebase nobody understands. Finding someone willing to maintain a fifteen-year-old undocumented FileMaker system is getting harder every year.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>A rebuild, priced correctly and scoped realistically, is often cheaper over a three-year horizon than continuing to maintain a system that has crossed this threshold.\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>How to recognize the actual tipping point\u003C\u002Fh2>\n\u003Cp>Here is a concrete checklist. If you check five or more of these, a rebuild deserves serious evaluation:\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Architecture and maintainability\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> No single developer can explain how the full system works\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> The data model has grown organically and contains significant structural debt (redundant tables, overloaded fields, naming inconsistencies)\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Relationships between tables are undocumented or counterintuitive\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Scripts and calculations reference global variables in ways that are hard to trace\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> There is no test suite or change documentation\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Business fit\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> A required integration (API, portal, external platform) cannot be built without restructuring the database\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Core business processes have changed significantly since the system was designed, and the software no longer maps to how the company actually works\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> You are maintaining manual workarounds (Excel exports, double data entry, email-based approvals) that should be handled by the system\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Security and compliance\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> The system lacks field-level access control or audit logging that regulators or customers now require\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Data is not encrypted at rest in a way that meets current standards\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> User permission structures can't be granular enough for your current team structure\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Cost and risk\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Developer costs for the past twelve months exceed what a focused rebuild would cost in the same timeframe\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> A single undocumented change has caused a production outage in the last two years\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> The platform version is no longer supported or is approaching end of support\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Chr>\n\u003Ch2>What a rebuild actually involves — step by step\u003C\u002Fh2>\n\u003Cp>The fear of rebuilding is often based on a vague mental image of throwing everything away and starting from a blank page. A well-run rebuild doesn't look like that.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 1: Audit before you architect\u003C\u002Fstrong>\nDocument what the current system actually does — not what it was supposed to do, but what the business relies on today. This is often revealing: many companies discover that 60–70% of the features in their old system are unused or have been replaced by workarounds.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 2: Define the new architecture around current and future needs\u003C\u002Fstrong>\nDesign the data model cleanly for the business as it is now and as it will be in three to five years. This is where the real value of a rebuild is created — not in replicating the old system but in designing one that fits the actual business.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 3: Prioritize a phased rollout\u003C\u002Fstrong>\nA good rebuild is rarely a single big-bang go-live. Define an MVP (minimum viable product) that covers core operations — order management, inventory, invoicing — and go live with that first. Add modules incrementally. This limits risk and delivers value faster.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 4: Plan the data migration seriously\u003C\u002Fstrong>\nHistorical data migration is consistently underestimated. Fifteen years of order records, customer data, and product history need to move cleanly. Budget real time for mapping, cleaning, and validating the migrated data.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 5: Run parallel operation during transition\u003C\u002Fstrong>\nFor a defined period — typically two to eight weeks depending on complexity — run both systems simultaneously for the same transactions. This is your safety net, and it's non-negotiable for a business-critical ERP.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 6: Decommission with a clear cutover date\u003C\u002Fstrong>\nSet a hard date. Systems that are "kept around just in case" become a source of confusion and split operations. Once the new system is validated, retire the old one.\u003C\u002Fp>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F31?w=700&f=webp\" alt=\"Phased rebuild timeline: audit, design, MVP launch, parallel run, cutover, decommission\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-right sm:ml-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Chr>\n\u003Ch2>What can you actually preserve from the old system?\u003C\u002Fh2>\n\u003Cp>A rebuild doesn't mean you discard institutional knowledge. What you preserve:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Business logic\u003C\u002Fstrong> — the rules that govern how your business works (pricing logic, discount structures, workflow sequences). These get re-implemented in clean, documented code.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Historical data\u003C\u002Fstrong> — migrated, cleaned, and validated into the new structure.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>User expertise\u003C\u002Fstrong> — your team knows how the business works. That knowledge feeds the design of the new system.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>What you leave behind:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Structural debt in the data model\u003C\u002Fli>\n\u003Cli>Undocumented scripts and globals\u003C\u002Fli>\n\u003Cli>Workarounds that existed because the old architecture forced them\u003C\u002Fli>\n\u003Cli>Platform limitations that blocked integrations or scalability\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Chr>\n\u003Ch2>Real scenario: when a rebuild saved more than it cost\u003C\u002Fh2>\n\u003Cp>Consider a distribution company running a FileMaker ERP built in 2008. Over fourteen years, the system had grown from a simple order management tool into something managing purchasing, warehouse operations, invoicing, and customer communication — none of which it was originally designed for.\u003C\u002Fp>\n\u003Cp>The symptoms: a warehouse manager manually copying pick lists from FileMaker into a spreadsheet every morning because the system couldn't print in the right format. A two-week developer engagement every time a new product type was added, because the product table had been extended with workaround fields so many times the structure was incomprehensible. An inability to connect to the company's new logistics platform via API because the data model didn't map to standard structures.\u003C\u002Fp>\n\u003Cp>The company spent three months evaluating incremental modernization. The conclusion: fixing the API problem alone would require restructuring four core tables. That work would destabilize the rest of the system. The estimated cost of that single fix exceeded 40% of a full rebuild.\u003C\u002Fp>\n\u003Cp>The rebuild took eight months. The first four months delivered an MVP covering orders, inventory, and invoicing. The warehouse manager's morning spreadsheet disappeared on day one of go-live. The API connection to the logistics platform was built in week two of the project, not as an afterthought but as a designed feature of a clean architecture.\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>Frequently asked questions\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>How do I know if it's the architecture that's the problem, or just the implementation?\u003C\u002Fstrong>\nAsk your developer to estimate the cost of the next three features on your roadmap. If each estimate comes back with a significant "first we need to restructure..." caveat, the architecture is the problem. Implementation issues are fixable locally. Architectural debt spreads through every change.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Can I rebuild in FileMaker, or do I need to move to a different platform?\u003C\u002Fstrong>\nFileMaker remains a strong platform for custom business applications when used with a clean, modern architecture. The problem in most legacy cases is not the platform — it's the structure built on top of it. A rebuild in FileMaker with proper data modeling, documented scripts, and a clear separation of concerns produces a system that is maintainable and scalable. That said, if your use case has outgrown what FileMaker does well (very high concurrency, heavy web-native workflows, etc.), a rebuild is also the right moment to evaluate alternatives.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>How long does a full rebuild take?\u003C\u002Fstrong>\nFor a mid-complexity ERP (orders, inventory, invoicing, CRM basics), a realistic timeline is six to twelve months from discovery to full go-live. A phased approach — MVP first, then additional modules — means you see working software in production within three to four months in most cases.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>What if the business can't afford downtime?\u003C\u002Fstrong>\nNo well-planned rebuild requires downtime. Parallel operation during transition ensures the business continues running on the known system while the new one is validated. The cutover is a controlled event, not a forced shutdown.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>How do I get budget approval for a rebuild when the current system "still works"?\u003C\u002Fstrong>\nBuild the cost case around the three-year total cost of ownership comparison: current maintenance costs + opportunity costs + risk exposure vs. rebuild cost + three years of maintenance on a clean system. Most CFOs respond to a concrete numbers comparison, not a technical argument.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Will a rebuild become the same mess in ten years?\u003C\u002Fstrong>\nOnly if the same conditions are allowed to develop: undocumented changes, no architectural governance, features added without design review. A rebuild creates the opportunity to establish better practices — version control, change documentation, modular design — that prevent the same accumulation of debt.\u003C\u002Fp>\n\u003Chr>\n\u003Cp>If you're recognizing your own system in this article, the next useful step is usually an honest technical audit — not a sales conversation, but a structured review of where your architecture stands and what your real options are. At Loggix, we help businesses work through exactly that kind of assessment: mapping what the current system actually does, identifying where the structural debt is concentrated, and building a realistic picture of what modernization vs. rebuild actually costs in your specific situation. Whether the answer turns out to be a targeted FileMaker rebuild, a move to a web-based custom application, or a phased integration strategy, the starting point is the same — understanding the problem clearly before committing to a direction.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901658000,[19,20,21,22,23,24,25,26],"business software strategy","legacy systems","FileMaker","ERP rebuild","custom software","software modernization","technical debt","system migration","\u002Fapi\u002Fknowledge\u002Fimage\u002F124\u002F?v=7537cfc04320",false,null,{"title":31,"slug":32},"Business Software Strategy","business-software-strategy",{"title":34,"slug":35},"How to modernize business software without starting over","how-to-modernize-business-software-without-starting-over"]