Why modernization projects fail before development begins

Your team has agreed: the current system needs to go. The spreadsheets are multiplying, the workarounds have workarounds, and onboarding a new employee now requires a two-week apprenticeship just to understand how things actually work. So you kick off a modernization project — and six months later, nothing has shipped. This article explains exactly why that happens, and what you need to do differently before a single line of code is written.

Why does modernization almost always take longer than planned?

The short answer: because teams scope the new system before they truly understand the old one.

This sounds obvious in hindsight, but it happens constantly. A steering committee agrees on a high-level goal — "replace the old FileMaker system with something modern" — and immediately starts designing the future state. What modules do we want? What does the dashboard look like? Do we want a web app or a native app?

All of that is premature. The old system is not just a user interface. It is a living archive of every business decision your company has made over the past ten, fifteen, or twenty years — many of which were never written down anywhere except in the system's logic itself.

Hidden inside legacy software you will typically find:

• Undocumented pricing rules — a customer gets a 7.5% discount because of a deal made in 2014, encoded in a script that nobody remembers writing.
• Exception workflows — a specific product category skips the normal approval step because a manager requested it once and it was never revisited.
• Data integrity hacks — a field called "Notes" that actually drives downstream logic because the proper field didn't exist when the workaround was built.
• Seasonal or conditional behaviour — processes that only trigger under specific combinations of circumstances, invisible during normal use and invisible during a standard demo.

None of this will appear in a requirements workshop where you ask users "what do you need the new system to do?" Users describe their ideal workflow, not the actual one. The actual one lives in the old code.

What does underestimating legacy complexity actually look like?

Consider a composite scenario that reflects what happens at dozens of mid-sized companies every year.

A regional parts distributor runs its order management on a FileMaker system built over twelve years by two developers who have since left. The operations director commissions a modernization project. A project team is assembled, a vendor is selected, and requirements workshops begin. Three months of meetings produce a detailed functional specification. Development starts.

Six weeks into the build, the development team asks a routine question: how does the system calculate the landed cost for items sourced from non-EU suppliers? The answer, it turns out, is: nobody knows exactly. The original developer had built a multi-step calculation that factored in currency fluctuation buffers, a carrier surcharge table, and a legacy tariff code lookup — all of it in a single FileMaker script, uncommented, never documented. The new specification had described landed cost in one line: "system calculates landed cost per item."

The project stopped for four weeks while the team reverse-engineered the logic. Two rules had to be escalated to the CFO because nobody on the operations team could confirm whether they were still intentional or just historical artefacts. The go-live date moved by three months. The budget overran by 40%.

This is not a story about bad developers or a bad vendor. It is a story about what happens when you skip the audit.

What is a legacy audit and why does it come before requirements?

A legacy audit is a structured process of documenting what your current system actually does — not what it was supposed to do, not what users think it does, but what happens when you trace every workflow, every calculation, every exception path from start to finish.

A thorough legacy audit covers:

1. Process mapping — walk every major workflow end-to-end, from trigger to output, including edge cases and exceptions.
2. Business logic extraction — identify every rule encoded in the system: calculations, validations, conditional steps, automated triggers.
3. Data model review — understand what data exists, how it is structured, where it is duplicated, and what "dirty" data has accumulated over the years.
4. Integration inventory — list every system the current software touches: email, accounting, ERP, e-commerce, carrier APIs, spreadsheet exports that feed other processes.
5. Exception register — document every known workaround, every "don't touch that" setting, every process that only one person knows how to run.

Only after this audit do you have the raw material to write a requirements document that reflects reality rather than aspiration.

For a broader look at how this audit fits into the full modernization journey, see How to modernize business software without starting over.

Why does unclear ownership derail projects just as often as technical complexity?

The second major pre-development failure is organizational, not technical: no single person has the authority — and the accountability — to make binding decisions.

Here is what that looks like in practice. A manufacturing company starts a modernization project for its production planning module. The project has four stakeholders: the operations manager, the IT manager, the CFO, and a senior planner who is the de facto system expert. Requirements are gathered from all four. When they conflict — and they will conflict — there is no agreed process for resolving them. So the project manager does what project managers do under those conditions: they schedule another meeting.

Four months in, the requirements document has gone through eleven versions. The operations manager wants real-time floor data. The CFO wants the system to eliminate one FTE. The IT manager wants a cloud-hosted solution. The senior planner is quietly opposed to the whole project because it will undermine her institutional knowledge advantage. Nobody is wrong, exactly — but nobody is in charge.

By the time the vendor loses patience and the steering committee finally convenes, two of the four stakeholders have changed their positions. The scope is reset. The vendor reprices. The project is now eight months old and has not produced a single deliverable.

How do you establish clear ownership before a project starts?

Before any vendor conversation, before any requirements workshop, you need to answer three questions in writing:

1. Who is the single decision-maker? One named person has final say on scope, priority, and trade-off decisions. Not a committee. Not "consensus." One person.
2. What decisions require escalation? Define in advance which decisions require sign-off from the CFO, the board, or legal — and set a maximum response time (48 hours is reasonable; two weeks is not).
3. What does done look like? Agree on measurable success criteria before development begins: not "the system works better" but "order processing time drops from 4 hours to 45 minutes" or "month-end close no longer requires manual data export."

Without these three answers documented and agreed, you do not have a project. You have a conversation.

What are the other common pre-development failure points?

Beyond legacy complexity and ownership, several other factors consistently kill modernization projects in the preparation phase:

• Scope set by feature wishlist, not by business outcome. Teams list everything they ever wanted the system to do. The result is a specification so large it cannot be built within budget, and so vague it cannot be estimated accurately.
• Vendor selected before problem is defined. Choosing a technology or a vendor before completing the audit and defining success criteria means the vendor is shaping your requirements — not responding to them.
• No migration plan for existing data. Legacy data is almost always dirtier than anyone expects. Migrating twelve years of order history, customer records, and product data is a project in itself. Treating it as an afterthought guarantees a delayed go-live.
• User adoption treated as a launch-day problem. If the people who will use the new system are not involved in defining it, they will resist it — regardless of how technically excellent it is.

Pre-development checklist: are you actually ready to build?

Before you sign a development contract or write a first user story, work through this checklist. If you cannot answer "yes" to each item, the project is not ready.

Legacy audit

• Every major workflow has been mapped end-to-end, including exceptions
• All business logic in the current system has been documented
• The data model has been reviewed and data quality assessed
• All integrations (internal and external) have been inventoried
• Every known workaround and undocumented process has been recorded

Ownership and governance

• One named decision-maker has been formally appointed
• An escalation path with time limits exists for decisions above that person's authority
• Key stakeholders have signed off on the scope and success criteria
• The project has a named internal champion who will drive adoption

Scope and success

• Success is defined in measurable business outcomes, not feature lists
• A phased delivery plan exists (what ships first, what comes later)
• A data migration plan has been scoped and resourced separately
• Budget includes a contingency of at least 20% for legacy discoveries

Frequently asked questions

How long should a legacy audit take? For a system that has been in use for more than five years, plan for four to eight weeks of structured audit work — more if the original developers are unavailable. Rushing this phase is the single most reliable way to guarantee mid-build surprises.

What if the original developer is no longer available? This is common and manageable, but it means the audit will rely on a combination of code/script review, user interviews, and process observation. Budget more time and engage someone with genuine experience reading legacy business logic — not just a generalist developer.

Should we document the old system or just start fresh? Only start fresh if you are genuinely willing to retire every current process and retrain every user from zero. In practice, almost every "start fresh" project quietly replicates 70–80% of the old system's behaviour — but without having documented it first, which is where the cost overruns come from.

How do we handle stakeholders who keep adding to the scope? This is a governance problem, not a technical one. The decision-maker must be empowered to say "that goes on the post-launch backlog" and mean it. If scope cannot be controlled before development, it will not be controlled during development.

What is the biggest sign a modernization project is about to fail? When the requirements document describes the future system in detail but nobody on the project team can confidently describe what the current system does — especially its exception cases. That gap is where projects go to die.

---

If any of this reflects where your organisation currently is — a growing sense that the old system needs to change, but uncertainty about how to start without triggering a costly, months-long derailment — that is exactly the kind of situation Loggix works through with clients. Whether the next step is mapping existing business logic, scoping a phased migration, connecting legacy systems through API integrations, or building a tailored replacement in FileMaker or as a web application, the work always starts with understanding what you actually have before designing what comes next. That conversation costs nothing and tends to surface the critical questions earlier, not later.