Anyone procuring software for machines and plants sooner or later faces the same question: is what the machine builder or a software vendor supplies ready-made good enough, or does your own process need a solution built specifically for it? This covers everything beyond the PLC program itself: operator interfaces and visualization, data acquisition, business and backend software, and the connection to ERP systems and databases.
There is no one-size-fits-all answer. Standard solutions are mature, quickly available and the right choice for many tasks. Custom software shows its strengths where workflows, data flows or traceability requirements differ from the norm. Often the best solution lies somewhere in between. Below you will find criteria to assess your situation, a proven approach for implementation and questions for a self-check.
What standard solutions do well
Many machines ship with an operator panel and a visualization from the manufacturer. These interfaces are tailored to the machine, tested and usually ready to use right away. For standalone machines that largely do their job on their own, this is often all that is needed day to day: operation is clear, alarm messages are understandable, and the manufacturer knows the system best.
The same applies to standard visualization packages and off-the-shelf software for typical tasks such as KPI displays, recipe management or logging process values. Such products have a large user base, are maintained continuously and offer features that would hardly be worth developing in-house. If your process matches what the product was designed for, a standard solution is usually the most economical choice.
The limits rarely show on day one. They become visible when a plant needs to work together with other systems, when data is needed beyond the machine itself or when the process changes over the years. That is exactly when it makes sense to go through the following criteria.
Criteria: when custom software pays off
The decision depends less on the size of the plant than on how well your process fits a predefined pattern. In practice, the following points are the most common reasons to consider a purpose-built solution. A single point is rarely decisive – it is usually the combination.
- Process specifics: if your workflow includes steps a standard solution does not know – such as special inspection steps, changing variants or approvals by several people – workarounds via paper notes, spreadsheets or double entry quickly creep in. Custom software maps the workflow the way it actually runs.
- Data flows to ERP and database: as soon as orders travel from the ERP system to the plant and results need to flow back, the interface determines the value. Transferring data by hand costs time and invites errors. The goal is not as much data as possible, but the right data in the right place.
- Traceability: if you need to prove which batch was produced with which parameters, at what time and by whom, a local log on the machine is often not enough.
- Weighing and data acquisition: measurement and weighing data usually needs to be more than displayed – it has to be assigned to an order or batch and passed on to downstream systems.
- Operating concept: if the same people operate several machines, a unified interface organized by roles and tasks rather than by machine origin helps. Otherwise, a line made up of machines from different manufacturers often comes with just as many different operating concepts.
Costs, dependencies and service life
Besides functional requirements, economic and long-term considerations matter. Standard software is often paid for through licenses that may be charged per workstation, per data point or per plant and that grow with every expansion. Custom software involves higher initial costs, but running costs are often easier to plan. Which model is cheaper depends on the individual case and should be assessed over the entire service life, not just at the time of purchase.
Every solution creates dependencies. With standard software, you depend on the product maintenance, version changes and license terms of the vendor. With custom software, you depend on the source code, the documentation and the people who understand the system. The second kind of dependency can be reduced deliberately: with well-documented code, widely used technologies and a handover that enables your own maintenance team or another service provider to carry on.
An often underestimated factor is service life. Machines and plants frequently run for decades, while software, operator PCs and operating systems have much shorter cycles. Ask early how the software can be updated, moved to new hardware or extended ten years from now. Maintainability is not an add-on but part of the requirements – for standard and custom software alike.
Hybrid setups: standard plus interfaces
In many projects, the decision is not standard versus custom but a combination of both. The manufacturer panel remains in place for operation at the machine, a proven visualization stays in use – and lean, purpose-built software takes over exactly the tasks that are missing: the link to the ERP system, assigning measurements to orders or a cross-plant dashboard for production.
The technical basis for this is open interfaces. Many current controllers and devices offer OPC UA or MQTT, and older plants can often be reached via fieldbuses and vendor-specific protocols. This way, what works well stays untouched, and custom development is limited to the part that truly belongs to your process.
Hybrid setups have another advantage: they can be extended in a targeted way. Instead of replacing everything at once, you start with the interface that delivers the most value and add further functions as the need arises.
Approach: from analysis to a running solution
Whether standard, custom development or a hybrid setup – a structured approach reduces risk considerably. A sequence of four steps has proven effective. If the software also involves changes to the PLC, a well-prepared specification is worthwhile as well; our guide on writing a PLC programming brief explains what to include.
- Analysis: clarify workflows, data flows, current state and target picture before a single line of code is written. This includes the question of what the existing systems already do well.
- Prototype: a functional model shows early on whether an idea holds up in practice – for example, whether data from the controller arrives in the required quality or whether the operating concept works in everyday use.
- Iterative implementation: the software is built in stages with working intermediate versions that you can review and test with your staff. Change requests are incorporated while they are still easy to implement.
- Commissioning and operation: integration into existing systems, acceptance under real conditions, training and handover documentation – and, on request, maintenance and further development.
Replacing legacy systems without stopping production
Often the task is not a new plant but an existing system that has to be replaced: the visualization runs on outdated hardware, the operating system is no longer supported, or nobody is able to modify the old software anymore. Shutting down production for the switchover is usually not an option.
Replacement starts with an inventory. Legacy systems often contain functions that are not documented anywhere but are needed in daily operation. Documenting them before anything is replaced prevents something that used to be taken for granted from going missing after the switchover.
Parallel operation has proven effective. At first, the new software only listens in: it receives the same data as the legacy system, displays and stores it, without intervening in the process. This allows results to be compared and discrepancies to be resolved while production continues unchanged. Only once both systems demonstrably match does the new solution take the lead.
The actual switchover follows a cutover plan: when does the switch happen, which data is migrated, who checks what, and what is the way back if something does not go as planned? A fallback option is part of every go-live. The legacy system therefore remains ready for operation until the new solution has proven itself in daily use.
Questions for a self-check
The following questions help you assess your situation. The more of them you answer with yes, the more it is worth looking beyond a pure standard solution – whether as custom software or as an extension via interfaces.
- Do employees regularly transfer data by hand between the plant, spreadsheets and the ERP system?
- Do you need to provide complete evidence of batches, parameters or weighing data?
- Do your operators work with several different interfaces for similar tasks?
- Are there process steps that are currently handled outside the software, on paper or in spreadsheets?
- Do your license costs grow noticeably with every expansion?
- Is the plant expected to run for many more years even though the operator PC or operating system is already outdated today?
- Do you know who will still be able to modify your current software five years from now?