The system running your operations no longer fits.

The condition this door exists for

Somewhere in your building there is a system that runs the business and terrifies everyone. It was built fifteen or twenty years ago, in Access or FileMaker or a language the market has moved past, by someone who may no longer be reachable. It holds the invoices, the orders, the customer history, and two decades of accumulated edge cases that are, in a real sense, how your company actually works. Nobody dares touch it. Everybody depends on it.

Owners live with this longer than they should, and for a rational reason: every replacement story they have heard involves lost data, broken workflows, staff revolt, and a budget that doubled. Those stories are real. They are also what happens when replacement is treated as a software project instead of what it is: an operational transplant on a living business. The patient cannot be put under. The business has to keep selling, invoicing, and shipping every single day of the migration.

The triggers that bring people to this page are specific: an Access or FileMaker system the operations outgrew. A spreadsheet chain only one employee understands. An internal application whose developer is retiring. A vendor sunsetting the product your workflow lives in. A SaaS tool that cannot encode how your business actually sells. If one of those sentences is yours, keep reading.

One routing note, because the word platform is doing two jobs in this industry. This door is for the system that runs your operations: invoicing, orders, jobs, inventory. If the platform that no longer fits is your commerce stack, Shopify Plus, BigCommerce, WooCommerce, the cart that cannot close your actual sales, that engagement lives at High-Ticket Commerce Platforms. Same engineering practice, same ownership standard, different door, because the problem you recognize is different.

Before you buy an ERP

There is a moment every owner-led operation between five and fifty million hits: QuickBooks plus spreadsheets stops describing the business. Orders live in one place, inventory in another, quotes in email, and the month closes a week late. At that moment every advisor, accountant, and sales rep says the same word: NetSuite. What the quote actually contains is a six-figure implementation, per-seat pricing forever, a certified-consultant dependency that never ends, and modules your business gets reshaped to fit.

Run the six questions against that quote before you sign it. Who owns the account? Oracle does; you are a tenancy. What happens when you leave? A re-implementation project with two commas in it. A mid-market ERP fails the screen more spectacularly than any vendor this site names, and the buyer it traps looks exactly like the businesses I work for.

The pattern I build instead keeps your ledger. The general ledger, the GAAP books, payroll, taxes: those stay in the accounting software that is genuinely good at them and that your accountant already trusts. I build the operations platform around the ledger, owned by you, synced to your books: quoting, orders, inventory, fulfillment, invoicing, the workflow that is actually yours. The reference build runs a luxury import business exactly this way: ERP-class operations on owned software, while the books stayed where the accountant likes them.

And the boundary, stated plainly: I do not rebuild general ledgers. The general ledger, the GAAP books your accountant closes, stays put. The operational payment records, the ones a migration reconciles to the penny, are exactly what I do move. Double-entry correctness, tax treatment, and payroll are a domain where the off-the-shelf products are genuinely good and the liability of a custom rebuild is enormous. Anyone who offers to rebuild your ledger should worry you. If you already run an ERP that works, the same pattern applies in reverse: the owned platform syncs to it, and the ERP stays exactly where it is.

What replacement involves, and how the risks come out

The three fears are data loss, downtime, and broken workflow. Each one is removed by process, not reassurance.

• Data loss: migrations are rehearsed against full copies of the real data, not samples. Every run is verified by record count and by content, including the details that carry business meaning: sequential invoice numbers, free-text fields, the messy real-world records a clean rebuild would silently drop. The rehearsal repeats until the numbers match perfectly, and only then does cutover get scheduled.

• Downtime: the old system keeps running while the new one is built beside it. Cutover is a switch thrown after parallel verification, with a rollback path standing by. The reference migration recorded zero days of operational downtime, and that number was a design requirement, not luck.

• Broken workflow: before any code, I map how staff actually use the system: the searches they run, the shortcuts they rely on, the documents they print. The replacement preserves the behavior that matters and retires the workarounds. Your team should feel like the system got faster and connected, not like they were handed someone else's software.

What actually replaces it

The system you are replacing was never a peripheral: it is a data model, forms over data, business logic, documents, and multi-user access to your operational records. That is a platform, whether it was built in FileMaker, Access, or a spreadsheet chain. Most businesses this size do not have a platform for it to integrate into, because the legacy system IS the platform. What replaces it is an operations application on a foundation you own: your data in a production database, an admin your staff use from any browser, running in your AWS organization. The first module is whatever the old system did. The foundation is built to absorb what comes next, the second database, the QuickBooks sync, the storefront, at your pace, or never. Replacement done properly does not just retire a risk. It leaves you owning the thing you never had.

The proof is a business like yours

Fine's Gallery, a Bonita Springs luxury retailer, ran quoting and invoicing on FileMaker for more than twenty years. Orders routinely reach six figures; deposits, balances, wire transfers, and signed documents ride on every one. If the invoicing system broke, the business stopped. I replaced it with a platform they own: 28,062 invoices migrated with full history and continuous numbering, zero days of operational downtime during cutover, and the FileMaker workflow habits staff relied on rebuilt inside the new system rather than discarded.

That migration was not the end of the story, and this matters for the economics: the replacement became the foundation for an owned commerce platform now supporting millions in annual revenue, and later for production AI agents that work inside it. Legacy replacement done properly is not a cost. It is the first installment on a platform. The full case study documents the build; the FileMaker deep dive documents the engineering, down to the found-set navigation and the PDF fidelity.

Specializations inside this door

FileMaker replacement. The most common entry, common enough to have its own page covering the FileMaker-specific realities: found sets, scripts, layouts, printable documents, licensing costs, and the single aging server everything depends on.

Migration and rescue. Systems already mid-crisis: the migration another firm abandoned, the developer who left with the knowledge, the cloud deployment that is fragile in ways nobody can explain. Rescue work starts with stabilization and evidence gathering, then follows the same discipline: assess, rehearse, verify, cut over. The worse the situation, the more the process matters.

When I will tell you not to replace

Replacement is the expensive option, and it is not always the right one. If the system is stable, single-user, and the blast radius of its failure is small, keep it and spend nothing. If the core works but one report or one integration hurts, a targeted bridge can cost a tenth of a rebuild. If the real problem is a manual step between two systems, that is an automation task, not a platform project. The Architecture Sprint exists to make this call honestly, in writing, before you commit to anything, and some sprints end with the recommendation: not yet. I would rather lose a build than sell you one you did not need. That restraint is also why the recommendation is worth something.

Delivered to the Ownership Standard

Everything this door produces lands in accounts you own and closes against the Ownership Standard: your AWS organization, your repositories, your data, your keys, live operating documentation, and an ownership test I invite you to hold me to. The system that replaces your legacy dependency must not become a new dependency with better fonts. I can remain accountable for operating and improving it after launch, while the client keeps control of the platform and the option to change operators later.

The entry path

Start with a Platform Architecture Sprint: $15,000, three weeks. You get the current-state risk register, the target architecture, the migration plan, and the cost model, in writing, whether or not you ever hire me again. The sprint fee is credited in full against the subsequent build when I perform the build. Platform builds start at $80,000 and typically run three to six months to a rehearsed cutover with rollback criteria and an agreed downtime objective. Pricing is published, which is itself a signal worth demanding from anyone you evaluate.

Every sprint includes a vendor dependency audit: your current stack, scored in writing against the six questions and the Ownership Standard.