August 13, 2026
Legacy application modernization for manufacturers fails far more often than anyone in my industry likes to admit. Depending on whose research you read, somewhere between 70% and 88% of modernization programs miss their goals, blow their budgets, or get quietly abandoned. And the analysis consistently points to organizational causes like unclear ownership, scope creep, and lost institutional knowledge rather than to technology choices.
That statistic should change how you approach this. If technology were the hard part, the failure rate would be far lower. What actually derails these projects on a plant floor is a set of predictable decisions made in the first few weeks – before a single line of code is written.
I’ve written this as the list I’d give an IT leader at a mid-sized manufacturer over coffee: the nine mistakes I see most often. Why each one is specific to manufacturing environments, and what to do instead.
First, an honest picture of where manufacturing actually stands
Before the mistakes, some context – because I find most IT leaders assume their peers are further ahead than they are.
Manufacturing remains one of the most legacy-bound sectors in the economy. 74% of manufacturers still operate on disconnected legacy systems, which directly constrains Industry 4.0 adoption. And the consequences are no longer confined to IT: legacy integration is now the single biggest barrier to AI adoption for manufacturers, cited by 55% of them – well above the 41% average across the broader mid-market.
So the pressure is real and the money is moving. One analyst estimate puts the legacy modernization market at $29.39 billion in 2026, growing at a 17.6% CAGR, with small and medium enterprises among the faster-growing segments. Yet three in four manufacturers remain disconnected.
That gap between spending and progress is the subject of this article.
The most expensive assumption I encounter is that an application is safe because it hasn’t failed yet.
Legacy apps in manufacturing tend to run fine right up until one of two things happens: the person who quietly maintained them leaves, or an unsupported operating system finally gets flagged in a security review. Either way, a manageable project becomes a line-down emergency.
The knowledge risk is the one manufacturers systematically underestimate. Research on legacy environments has found that roughly 42% of critical business logic is at risk when personnel leave – because in these systems, “the system is the documentation”. On a plant floor this is rarely a formal developer. It’s the process engineer who built an Access database for scheduling fifteen years ago and has been patching it ever since. When he retires, the logic retires with him.
What to do instead: Treat concentration of knowledge as a risk metric, not a staffing detail. For each critical legacy app, ask a single question – if the one person who understands this left in ninety days, what would we do? Any app where the honest answer is “we’d be in serious trouble” belongs at the top of your modernization list, regardless of whether it’s currently misbehaving.
This is the scoping error that stalls more manufacturing projects than any technical obstacle.
Many manufacturers equate “modernization” with an eighteen-month, rip-and-replace ERP program. They get a quote from a large systems integrator, see the number and the timeline, and quietly decide to wait another year. I’ve watched this cycle repeat for three years running at the same company.
The industry has moved away from that model for good reason. Gartner explicitly recommends continuous modernization over rip-and-replace, and McKinsey’s research on core replacement projects found they routinely run more than 50% over budget. The pragmatic alternative is API-led and incremental: preserve what works, expose what’s trapped, and modernize around the core rather than tearing it out.
What to do instead: Separate your ERP from your ERP-adjacent applications. In most SMB manufacturers, the daily pain isn’t the ERP itself – it’s the ten satellite apps orbiting it. The Excel scheduling workbook. The Access quality log. The homegrown shipping tool. These can be rebuilt and integrated to the ERP without touching the system of record, and they’re where the fastest returns live.
A modernization project justified as “the technology is old” will lose every budget fight it enters, and it should.
I’ve seen IT teams build a thorough technical case – unsupported framework, no vendor patches, brittle code – present it to a CFO, and get nothing. Not because the CFO is short-sighted, but because nothing in that case connects to a number the business cares about. Meanwhile the same CFO will approve a project framed as “this removes four hours of manual reconciliation per shift and eliminates the scrap we can’t currently trace.”
What to do instead: For every candidate application, write down the operational metric it moves – hours of manual work, scrap rate, order accuracy, audit preparation time, downtime hours. If you cannot name the metric, you don’t yet have a project; you have a technical observation. And be specific about baseline: “we spend X hours a week on this today” is a far stronger case than “this is inefficient.”
Not every legacy application deserves the same treatment, and defaulting to one approach across the portfolio wastes money in both directions.
Re-hosting a stable app that works fine is spending money for no operational gain. Re-writing an app that could have been re-platformed is spending five times what was necessary. Conversely, patching an app that genuinely needs a rebuild just extends the problem at higher cost.
The market reflects this spread of approaches: re-platforming held roughly 31.9% of the modernization market in 2025, while re-architecting is projected to grow fastest at 22.7% CAGR through 2031. There is no single correct answer – there is a correct answer per application.
What to do instead: Assess each app on four axes before choosing an approach – business criticality, integration surface, rate of change, and how much of its logic is undocumented. Apps that rarely change and integrate with little can often be re-hosted cheaply. Apps that change constantly and sit at the center of your workflows usually justify a rebuild.
This is where manufacturing differs sharply from other industries, and where I see outside consultants get burned.
A twenty-year-old plant floor application is rarely a standalone system. It reads from a historian, writes to the ERP, feeds a spreadsheet somebody in quality relies on, and triggers a label printer nobody remembers configuring. None of this is documented. Some of it was built by a contractor who left in 2011.
Budget problems almost always trace back to skipped discovery – analysis of modernization costs consistently identifies underestimated data and integration complexity, not scope creep, as the primary driver of overruns, with one review finding 68% of projects exceeding initial estimates by an average of 27%. Deloitte’s banking research found actual legacy total cost of ownership running 3.4Ă— higher than initial estimates once integration friction and compliance overhead were counted (cited in CTO Accelerator, 2026)..
What to do instead: Spend real time on dependency mapping before you commit to a scope or a price. Trace every inbound and outbound connection, including the informal ones – the exported CSV, the shared drive folder, the email report someone built a macro around. In my experience, the informal integrations cause more cutover pain than the formal ones, precisely because nobody lists them.
Manufacturing data carries history that matters. Lot genealogy, calibration records, supplier certifications, quality results tied to specific production runs – this isn’t just data volume, it’s data with regulatory and traceability weight.
I’ve seen modernization projects that planned the application rebuild meticulously and treated data migration as a two-week task at the end. That sequencing is how projects slip by quarters. Inconsistent formats, duplicate records, missing fields in historical data, and unclear retention requirements surface only when you actually attempt the move.
What to do instead: Start data profiling in week one, not at cutover. Decide explicitly what migrates, what gets archived in read-only form, and what gets retired. For regulated manufacturers, confirm retention and traceability requirements before you design the target schema – retrofitting compliance into a migrated dataset is painful and expensive.
Security treated as a post-launch concern is how modernization introduces new vulnerabilities while claiming to remove old ones.
In manufacturing the stakes are structurally different from other sectors. Aging databases, obsolete SCADA platforms, and homegrown applications were built for reliability and long life, not for a hyper-connected world. As IT and operational technology converge, threats that could never previously reach the production floor now can. Modernizing an app that sits at the IT/OT boundary without designing for that boundary is how you connect a previously isolated system to the internet and find out the hard way.
What to do instead: Define the security and segmentation requirements in the design phase, not the test phase. If the application crosses the IT/OT boundary, treat network segmentation, access control, and data-flow visibility as functional requirements with acceptance criteria – the same as any feature.
A modernized application that the shop floor works around is worse than the legacy one it replaced, because now you’re maintaining two systems: the new one and the shadow spreadsheet people actually use.
Manufacturing has a particular version of this problem. The people using these applications are often mid-shift, hands-busy, and working to a takt time. An interface designed by someone who has never stood at that station will fail on details that never appear in a requirements document – too many clicks, unreadable at arm’s length, requires a login the operator doesn’t have.
What to do instead: Put the rebuild in front of actual operators during design, not at UAT. Watch them use it at the station, on the shift, at the pace they actually work. And treat adoption as a delivery requirement rather than a training problem – if people work around it, the project has not succeeded regardless of what the test results say.
The last mistake is the one that quietly contains all the others: attempting a portfolio-wide program instead of a single-scoped project.
A comprehensive modernization roadmap looks thorough on a slide and almost always stalls in practice – too big to fund, too risky to sequence, too slow to produce a visible win before the organization loses patience. Multi-year programs are also precisely where the failure statistics concentrate, because every additional quarter is another chance for sponsorship to change, priorities to shift, and the team that held the context to turn over.
Incremental, domain-focused modernization is consistently identified as the approach that reduces risk and accelerates return, because each step proves value before the next begins. The strangler-fig pattern – gradually replacing legacy functionality with modern services while keeping the business running – converts a high-risk cutover event into manageable increments and delivers value in weeks rather than years.
What to do instead: Pick one application. Scope it to a fixed deliverable and a defined window. Ship it. Then use that win – and the credibility it buys you – to fund the next one.
Putting the nine mistakes in reverse gives a starting sequence that doesn’t require a transformation budget:
Ship it, measure against the baseline, then repeat.
The argument for moving isn’t fear – it’s compounding cost. Estimates consistently put 60–80% of IT budgets into maintaining existing systems rather than building new capability, and most organizations undercount that spend because it’s spread across engineering time, end-of-life vendor contracts, and integration workarounds rather than sitting on one budget line.
But the sharper cost is opportunity. With 55% of manufacturers naming legacy integration as their number-one barrier to AI, and only 27% having a data warehouse or lake at all, the un-modernized application isn’t just a maintenance line item. It is the thing standing between you and every data, automation, and AI initiative you’ll be asked to deliver over the next two years.
If you want a concrete starting point, do step one and step two from the sequence above. Even a one-page inventory of your highest-risk legacy applications, ranked by impact and knowledge concentration, will tell you where a scoped first project should go – and that single exercise is usually the difference between a modernization plan that ships and one that stays on a slide.
Input your search keywords and press Enter.
