What does a phased modernization roadmap look like?
A practical, phase-by-phase roadmap for modernizing a legacy FileMaker ERP — without downtime, data loss, or starting over from scratch.
Your FileMaker ERP still runs the business, but Excel sheets are multiplying in every department, data lives in three places at once, and every new integration feels like duct tape on top of duct tape. You know something has to change — but a full replacement sounds like six months of chaos you can't afford. The good news: it doesn't have to be all or nothing. A phased modernization roadmap lets you rebuild the plane while it's still flying.
Why "big bang" modernization almost always fails
The instinct is understandable: wipe the slate clean, buy a modern platform, migrate everything at once. In practice, this approach fails more often than it succeeds. The reasons are consistent across companies:
- Nobody fully understands the old system until they try to replace it — edge cases, custom logic, and workarounds that exist for good reasons only surface when they suddenly stop working.
- The business can't pause for a 6-month cutover. Orders still come in. Invoices still go out.
- Historical data migrations are always messier and slower than estimated.
- User adoption collapses when everything changes at once.
A phased approach sidesteps all of this. Each phase delivers real value, real users adapt incrementally, and the old system stays in production until the new one is proven ready to take over.
What does a phased roadmap actually look like?
There is no single universal sequence — the right order depends on where your biggest pain is today. But the structure below reflects what works in practice for companies running a legacy FileMaker ERP alongside Excel and a collection of disconnected tools.
Phase 0 — Map before you build (2–4 weeks)
Before a single line of code is written, you need an honest map of what exists. This is not a project plan — it's a diagnostic.
What to document:
- Every system currently in use (FileMaker, Excel files, cloud apps, supplier portals, etc.)
- Every data flow between them — including the manual ones ("Karen exports a CSV every Monday morning and emails it to finance")
- Every place the same data is entered more than once
- Every workaround that exists because the system couldn't do something
- Every report that lives in a personal Excel sheet rather than the core system
The output: A dependency map and a prioritised pain list. This is what your roadmap is built on — not assumptions, not vendor demos.
Practical tip: Interview the people who actually use the system daily, not just managers. The real logic of the business is usually in the heads of the people doing the work.
Phase 1 — Stop the bleeding: eliminate double entry (4–8 weeks)
The single most damaging inefficiency in a legacy FileMaker + Excel environment is duplicate data entry. An order gets entered into FileMaker, and then re-typed by hand into Exact Online — every single order, every single day. A purchase gets logged in FileMaker and then manually updated in a supplier's web portal. A customer address gets changed in FileMaker and then forgotten in the Excel sheet that drives the weekly mailout.
Phase 1 targets this directly. The goal is not to replace anything — it's to connect what already exists.
Typical deliverables in Phase 1:
- API connectors between FileMaker and the accounting or ERP system (Exact Online, AFAS, Unit4, etc.)
- Automated sync for customer and product master data
- Elimination of the most costly manual re-entry workflows
- Basic error logging so failed syncs are visible and recoverable
Why this phase comes first: It delivers measurable ROI immediately (hours saved per week, error rates reduced), builds internal confidence in the modernization project, and creates a cleaner data foundation for everything that follows.
Watch out for: Assuming the data in both systems is consistent before you connect them. It almost never is. Budget time for a data audit and deduplication before enabling live sync.
Phase 2 — Modernize the core: FileMaker as a proper platform (6–12 weeks)
With integrations stabilised, the focus shifts inward. Most legacy FileMaker systems have accumulated years of technical debt: layouts built for FileMaker 12 that nobody has touched since, scripts that do five things at once, calculation fields doing the work that should be done in a proper data model.
This phase is about making FileMaker a reliable, maintainable platform — not replacing it.
Typical deliverables in Phase 2:
- Data model cleanup and normalisation (reducing duplication inside FileMaker itself)
- Script and calculation refactoring — removing dead code, adding error handling
- Role-based access control that reflects how the business actually works today
- A proper test environment so changes can be validated before going live
- Upgrade to a current FileMaker version if still running an end-of-life release
The business case for this phase: Every hour your in-house developer spends untangling old logic is an hour not spent building new capability. A clean core cuts future development time in half.
Common objection: "We can't afford downtime for a database rebuild." The answer: you don't need to. Schema changes in FileMaker can be done incrementally, one table or module at a time, while the rest of the system stays live. A staging environment with FileMaker Server makes this manageable.
Phase 3 — Extend: add the capabilities the old system never had (ongoing)
Once the core is stable and connected, you can start building the things that were always on the wish list but never possible in the old system.
Examples of Phase 3 extensions:
- A customer or supplier portal (web-based, connected to FileMaker via the Data API)
- AI-assisted features inside FileMaker: auto-classification of incoming orders, anomaly detection on inventory levels, smart suggested responses to customer queries
- Advanced reporting and dashboards — pulling live data from FileMaker into a BI tool like Power BI or Metabase
- Mobile workflows for field staff or warehouse teams
- Automated document generation (quotes, delivery notes, invoices) triggered by FileMaker events
The key principle here: Each extension is a self-contained module. If one doesn't work as expected, it can be rolled back without touching the rest of the system. This is the architecture discipline that protects you from the big-bang failure mode.
Phase 4 — Evaluate: keep, replace, or evolve?
After 12–18 months of phased improvement, you are in a fundamentally different position than when you started. You now have:
- Clean, integrated data
- A maintainable codebase
- Real usage data on what your team actually needs
- A clearer picture of where FileMaker's limits genuinely are
This is the right moment to ask whether FileMaker remains the right core platform long-term — not at the start of the project, when the picture is murkiest. Some companies stay on FileMaker indefinitely. Others use this phase to plan a gradual migration to a custom web application, keeping FileMaker running in parallel until the new system is fully proven. Either is a valid outcome. The point is that the decision is now informed, not panicked.
Phased modernization checklist
Use this before starting any phase:
- Do we have a dependency map of all current systems and data flows?
- Have we identified the top 3 sources of manual double entry?
- Is there a staging/test environment separate from production?
- Do we have a rollback plan if a phase causes unexpected issues?
- Have the daily users of the system been consulted, not just management?
- Is the data in each system audited and reasonably clean before integration?
- Are error alerts and integration logs in place so failures are visible?
- Is there a named internal owner for each phase, not just an external vendor?
How long does a full modernization roadmap take?
Honestly: 12 to 24 months for a company running a mid-sized FileMaker ERP with 5–20 users and 3–6 connected systems. That sounds long, but consider what you're doing: rebuilding a business-critical system without switching it off. Each phase takes 4–12 weeks, and phases often overlap once the team is confident.
The companies that do this well treat it as a continuous improvement programme, not a project with a hard end date. Modernization is not a one-time event — it's an operating posture.
FAQ
Will we lose data during the transition? Not if the migration is done in phases with proper validation at each step. Data loss in modernization projects almost always happens when systems are switched over all at once without adequate testing. Phased migration means you can verify data integrity at each stage before moving forward.
Can we keep using FileMaker during modernization? Yes — that's the whole point. The phased approach keeps FileMaker in production throughout. Nothing is switched off until a proven replacement is in place, and even then only module by module.
What if we discover the old system is more broken than we thought? This is common. The right response is to treat the discovery as a Phase 0 finding, adjust the roadmap scope, and prioritise accordingly — not to panic and accelerate into a full replacement. Most "broken" FileMaker systems are broken in specific, fixable ways, not fundamentally unsalvageable.
Do we need an external partner, or can we do this in-house? It depends on internal capacity. Phase 0 and Phase 1 almost always benefit from external expertise — particularly for API integration architecture and data auditing. Phases 2 and 3 can often be led in-house once the foundation is set. A hybrid model (external architecture + internal delivery) tends to work well for mid-sized companies.
How do we prioritise which pain to fix first? Use two axes: business impact (how much time or money does this cost today?) and implementation risk (how likely is this to cause disruption?). Fix high-impact, low-risk problems first. That's almost always duplicate data entry and broken integrations — not the core FileMaker schema.
If you're looking at a broader picture of why modernization so often stalls before it starts, the article How to modernize business software without starting over covers the strategic framing that sits behind this roadmap.
Loggix works with companies at exactly this crossroads — a FileMaker system that has outgrown itself, a tangle of Excel files and disconnected tools, and a real business that can't afford to stop while the infrastructure catches up. Whether that means building out API integrations to stop the double entry, refactoring a legacy FileMaker solution into something maintainable, adding AI-driven features to an existing workflow, or mapping out the right sequence of steps before any code is written — the work starts with understanding what you actually have and what it's costing you. If that's a conversation worth having, Loggix is a practical place to start it.