A manufacturing application is not only software. It is a physical asset with a physical dependency chain, and the chain is what makes the estimate wrong.
Modernising it means dealing with the hardware it is attached to, not only the code it is written in.
This table is why manufacturing application modernisation overruns. Each row is a dependency that does not appear in a code assessment and each one can stop a finished rebuild from going live.
Establish these in the first week. Several of them turn out to be procurement or engineering tasks with their own lead times, and those lead times set the plan.
Aging manufacturing applications and technologies
Applications that work, are relied upon daily, and cannot change. The fact that they work is why they survived and why replacing them is unpopular.
Unsupported software frameworks and infrastructure
Out of support usually means no security patches and no vendor help. The risk is real and it rarely produces urgency until something else forces the issue.
High application maintenance costs
Visible as the time of the one or two people who understand it. The risk is concentrated in those people rather than in the technology, and that is the number worth putting in a business case.
Limited integration with modern ERP and MES platforms
An application with no API becomes a data island, worked around by exports. Enabling an interface is sometimes a better first step than a rebuild.
Poor application usability and mobile accessibility
Although the usability claim needs care: a green-screen application that an experienced operator can drive at speed is more usable for them than a modern interface that is slower. That is the second position on this page.
Application performance and scalability limitations
Often fine for the plant it was built for and unable to serve a second one. Scaling is frequently the real trigger and it is rarely stated as the objective.
Fragmented legacy application environments
Several applications doing overlapping things, acquired with plants or built locally. Rationalisation reduces the modernisation scope before any rebuilding starts.
Security vulnerabilities and compliance concerns
Unpatched hosts, shared logins, embedded credentials and an application exposed more widely than anybody intended. These are the findings that get the work funded.
Manual deployment and release processes
A release performed by hand, out of hours, by one person, with no rollback. Automating this often delivers more value than modernising the application itself.
Application modernisation risks affecting production
The honest risk is a cutover on a line that cannot stop, with an application the plant has trained to for a decade. Section 5 addresses the cutover and section 3 the retraining.
Two things decide the plan and neither is in the code: what the application is physically attached to, and how fast its heaviest users currently work. Both are site visits.
Step 1
Legacy application portfolio assessment
What exists, who uses it, what it is worth and what it is attached to. The physical dependency chain from section 2 is part of this stage rather than a later discovery.
What exists, who uses it, what it is worth and what it is attached to. The physical dependency chain from section 2 is part of this stage rather than a later discovery.
Step 2
Business criticality and dependency mapping
What stops if it stops, and which other systems and people read from it. Including the consumers nobody has recorded, proven from traffic rather than from documentation.
What stops if it stops, and which other systems and people read from it. Including the consumers nobody has recorded, proven from traffic rather than from documentation.
Step 3
Application modernisation readiness evaluation
Per application, including whether the hardware dependencies can be resolved and at what lead time. An application that is ready in code and blocked on a dongle is not ready.
Per application, including whether the hardware dependencies can be resolved and at what lead time. An application that is ready in code and blocked on a dongle is not ready.
Step 4
Target-state application architecture design
Designed after the assessment so it accounts for what has to be kept, including any host that must remain as a protocol box.
Designed after the assessment so it accounts for what has to be kept, including any host that must remain as a protocol box.
Step 5
Modernisation strategy and roadmap development
A treatment per application rather than one approach across the portfolio. The five treatments are set out below.
A treatment per application rather than one approach across the portfolio. The five treatments are set out below.
Step 6
Application refactoring and redevelopment
Built with keystroke parity for the high-volume tasks, which is a design constraint rather than a preference, per the second position on this page.
Built with keystroke parity for the high-volume tasks, which is a design constraint rather than a preference, per the second position on this page.
Step 7
Data migration and integration modernisation
Including the reconciliation, and including the interfaces that other systems depend on, which have to keep working during the overlap.
Including the reconciliation, and including the interfaces that other systems depend on, which have to keep working during the overlap.
Step 8
Automated testing and validation
Tests on the real devices with the real peripherals: the label printer, the scanner, the scale, the gauge. A test suite that passes in a browser proves little here.
Tests on the real devices with the real peripherals: the label printer, the scanner, the scale, the gauge. A test suite that passes in a browser proves little here.
Step 9
Phased deployment and operational transition
Station by station or area by area rather than application by application, per section 5, with the old application available in parallel.
Station by station or area by area rather than application by application, per section 5, with the old application available in parallel.
Step 10
Continuous application optimisation and support
Including the retirement of the old application and its host, which is the step that gets deferred and the only one that ends the dual running.
Including the retirement of the old application and its host, which is the step that gets deferred and the only one that ends the dual running.
The treatment is named for each, because the same capability applied under the wrong treatment is how modernisation budgets are spent without reducing risk.
Application portfolio rationalisation
Treatment: retire. Finding what is used by almost nobody and what is duplicated. The cheapest work on this page and the first to do.
API enablement for legacy applications
Treatment: enable an interface. An adapter with its own contract, so consumers depend on the contract rather than on the legacy system, and the system can be replaced later without touching them.
Legacy application replatforming
Treatment: replatform. Same application, supported technology and infrastructure, screens and flows preserved where users are fast in them.
Application refactoring and reengineering
Treatment: refactor. Internal structure improved so the application can be changed safely, without changing what users see.
Cloud application migration
Treatment: replatform. With one manufacturing caveat: anything a line depends on within a shift needs local capability or local caching, because a plant cannot wait for a link to come back.
Database and data access modernisation
Treatment: refactor or redevelop. Including finding every direct database consumer first, since in manufacturing estates reporting tools and spreadsheets read the database directly.
Application UI and UX modernisation
Treatment: varies. Subject to the keystroke parity constraint. For high-volume operator tasks, a modernised interface must be timed against the old one before it is accepted.
Monolithic to modular application modernisation
Treatment: redevelop. Justified where parts of the application change at different rates. Not justified as a default, because modularity has an operating cost.
Manufacturing application redevelopment
Treatment: redevelop. A genuine rebuild where the behaviour needs to change, delivered with the physical dependency chain resolved first.
Application performance optimisation
Treatment: any. Often the quickest win, and occasionally it removes the reason the modernisation was requested.
DevOps and release automation
Treatment: any, including leave alone. Automating a manual out-of-hours release reduces real operational risk without changing the application at all.
The treatment from section 3 is named for each, along with the risk that actually threatens it, which is seldom the technology.
Legacy reporting application transformation
Old reporting tools replaced by a modern reporting layer.
Manufacturing portal modernisation
An internal portal rebuilt on supported technology.
Desktop to web application migration
A thick client replaced by a browser application.
Legacy database and application integration
Making a legacy system readable by modern platforms.
Legacy quality application modernisation
An old quality application rebuilt or replatformed.
Inventory and warehouse application modernisation
Warehouse and inventory applications rebuilt.
Mobile enablement of manufacturing applications
Making an existing application usable on a handheld.
Shop-floor application redevelopment
An application running at the line rebuilt.
Legacy production application modernisation
A production-critical application rebuilt or replatformed.
Multi-plant application standardisation
Several local versions consolidated onto one.
The architecture decision is per application and per treatment, not per portfolio. A rebuilt application should use what your team can maintain after handover. A replatformed one should change as little as possible beyond what the treatment requires.
Modern application reference architecture
A target shape documented once and applied per treatment, including the cases where a legacy host is deliberately retained as a protocol box with a modern application in front of it.
Cloud-native and hybrid application platforms
Hybrid is the destination for a manufacturing estate rather than a transition, because applications a line depends on need local capability.
Modern web and mobile frameworks
Chosen for the population. A high-volume operator screen benefits from being lightweight and keyboard-driven, which frameworks do not optimise for by default.
.NET, Java, Python and modern backend technologies
Selected against what your team can maintain after handover, which matters more than any comparison between them. An application only we can support is a dependency on us.
Microservices and modular application design
Where parts of an application genuinely change at different rates. Modularity has an operating cost and in a plant estate it is frequently not earned.
REST APIs and event-driven integration
So the modernised application is readable by other systems, which is often the actual requirement behind a modernisation request. Integration patterns are on the API & Enterprise Application Integration page.
Containerisation and orchestration
For consistent deployment and rollback, including to local hosts in plants. The rollback is the part that matters here.
Database modernisation and migration
With every direct consumer identified first, by evidence, because in manufacturing estates reporting tools and spreadsheets read production databases directly.
CI and CD and DevOps automation
Often the highest-value change on this page and deliverable without modernising the application at all, because it removes a manual out-of-hours release performed by one person.
Application observability and monitoring
With alerting treated as a production concern for anything a line depends on, including a visible indication when the application cannot reach what it needs.
Governance defines who may change and release, how exceptions get resolved, and how production continuity is protected. Everything below serves one of those three.
In a plant, the decision to roll back is made at two in the morning by a shift manager who needs it to work and cannot wait for a committee. Every control below exists to make that moment survivable.
Production continuity and fallback procedures
A per-area rollback that has been tested, with the decision criteria written in advance and a named shift authority able to invoke it without escalation.
Application change and release controls
Releases into production-facing applications go through the plant change process in agreed windows. Software a line depends on is a plant change whichever function builds it.
Legacy application dependency governance
The consumer inventory maintained, including the direct database readers and the file drops, since the undocumented consumer is what breaks a cutover.
Data migration integrity and reconciliation
Record counts and field-level comparison, with a reconciliation signed off before the old application is retired rather than after.
Application validation and acceptance testing
Acceptance by the heaviest users, on the real devices, with the peripheral chain exercised. Where your quality function determines that validation applies to an application, we deliver to the approach it defines.
Application security and identity management
Individual accounts, no embedded credentials, and the shared logins that legacy applications permitted removed as part of the modernisation rather than carried forward.
Role-based access and audit logging
Access by role and an audit trail that the legacy application probably did not have, which is frequently a benefit worth stating in the business case.
Business continuity and disaster recovery
Recovery targets agreed with operations per application, tested rather than documented, with particular attention to anything whose host sits in a plant rather than a data centre.
Application lifecycle and technical debt governance
A portfolio register with each application’s treatment, owner and status, reviewed on a cadence. Without it the portfolio only grows, because nothing is ever formally retired.
Vendor and technology dependency management
Including the dongle, the locked licence and the single-version driver from section 2. These are commercial dependencies and resolving them is procurement work with its own lead time.
The two are applications retired and maintenance effort as a share of capacity. Together they say whether the portfolio is shrinking and whether it is becoming affordable, which is the business case.
Technical debt reduction
Applications retired and legacy hosts decommissioned, not applications delivered. The second figure rises in a programme that is going badly as well as one going well.
Application maintenance effort
Share of the team’s capacity spent keeping the portfolio running. If it does not fall, the technology changed and the economics did not.
Application availability and reliability
Per application, measured against the hours the plant actually runs rather than as a calendar average.
Application response time and performance
At the device and for the heaviest task, against the timed baseline from section 3. This is where keystroke parity is proven or disproven.
Application defect and incident rates
With the share caused by a release separated from the share caused by a fault, because a high release-caused share points at the deployment process.
Deployment frequency and release success
How often a change can safely be made, which is the practical measure of whether modernisation improved anything for the people maintaining it.
Mean time to restore service
Measured for an application a line depends on, since that is the number operations will ask for and the one that justifies the on-call arrangement.
Infrastructure and operating costs
Total, including licences, hosting and the effort to run it. Stated honestly, because a cloud platform can raise one line and lower the total.
User adoption and experience
Whether the heavy users are using the new application by choice, and whether throughput returned to baseline after cutover and how long it took.
Modernisation progress and business value realisation
Against the measured baseline captured before the programme started, with the avoided risk stated as what it is: an estimate resting on an assumption.
Reduced legacy application dependency, which requires retirement rather than replacement. Without retirement the dependency is additive
Improved manufacturing application performance, with the heaviest tasks timed against their old baseline rather than assumed to be faster
Better application security and maintainability, much of it from removing shared logins and embedded credentials that the legacy application permitted
Improved integration with modern manufacturing systems, which is often achievable by enabling an interface without a rebuild at all
Faster application enhancement and deployment, frequently from release automation rather than from the modernisation itself
Scalable manufacturing application architecture, where the second plant costs materially less than the first
If a modernisation estimate was built from a code assessment, it is probably missing the dongle, the serial card and the label printer. Those are findable in a week on site, and finding them changes the plan rather than the budget.
CaliberFocus modernises manufacturing applications with the hardware they are attached to in scope from the first week: the PC in the cabinet, the serial card, the dongle and the label printer. We choose a treatment per application, time the heaviest tasks to protect keystroke parity, cut over station by station with a rollback a shift manager can invoke, and retire what we replace.
- The physical dependency chain assessed before any estimate
- A treatment per application, including retire and leave alone
- Keystroke parity for high-volume operator tasks
- Station-by-station cutover with a tested rollback
Security & Compliance
