Legacy Production Management Systems | Scoring the Replacement Decision

An ageing production management system rarely announces itself. It does not freeze, and it does not slow to a crawl. In most factories the system runs perfectly well today, which is exactly why the decision keeps getting deferred until the support deadline for the underlying platform is suddenly upon you. This article is not about replacing PLCs or control panels. It is about the production management system itself, meaning the business software and the platform it runs on. It sets out a scoring model that takes the decision out of the realm of gut feeling, and it lays out the alternatives to a full rebuild.

Why “it still runs” and “we are fine” are two different statements

Raise the subject of a system refresh with a factory team and the reaction is almost always the same. We are not having trouble right now. We will deal with it when it stops. For physical equipment, that position has a certain logic behind it. Plenty of machines can reasonably be fixed after they fail, and a shelf of spare parts buys you time.

Production management systems fail differently. They do not wear down and gradually lose performance. Instead, on a specific date, the people who can fix them cease to exist in the market. The vendor publishes that date years in advance, and it arrives regardless of what suits your schedule.

The end-of-support date was set without consulting you

Concrete dates make the point faster than an argument, so here are two platforms still widely used in the core systems of Japanese-owned factories.

The first is IBM i, the descendant of the old AS/400. Extended support for IBM i 7.3 ends on 30 September 2026. That same day is also the end of standard support for IBM i 7.4, so two deadlines of quite different character land together. A plant still on 7.3 and a plant that upgraded to 7.4 and assumed it was safe are both forced to decide on the same date.

The hardware carries its own deadlines. IBM has announced that standard hardware maintenance for some Power9 models ends on 31 January 2026. Software support dates and hardware maintenance dates are set independently, and a plan built on only one of them will slip.

Systems running on Windows servers are in the same position. Mainstream support for Windows Server 2016 ended in January 2022, and extended support ends on 12 January 2027. Extended Security Updates (ESU) remain available as a paid mechanism after that, but the pricing is designed to rise in steps each year. ESU is therefore not a way to keep running. It is a way to buy time with money until the migration is finished.

Line these dates up and the pattern is clear. Between 2026 and 2027, the deadlines for the platforms under the core systems of Japanese-owned factories are clustered together. Because so many companies face the same decision in the same window, it is worth assuming that engineers capable of carrying out migrations will become harder to secure.

“Discontinued” and “out of support” hurt in different places

In the world of control equipment there are two deadlines, the end of production and the end of repair service, and the practical risk really begins with the second one. That is an equipment story, but the structure is remarkably similar in software.

What differs is the availability of a fallback. With a PLC, even a discontinued model leaves you the second-hand market and independent repair specialists for a while. The physical object exists, so there is a chance of finding one if you look. Software support expiry offers no such fallback. Security updates do not circulate on a market, and patching a publicly disclosed vulnerability yourself is not realistic.

The blast radius is different too. When a piece of control equipment stops, what stops is that machine, or at most that line. When the production management system stops, orders, work instructions, production records and shipping stop at the same moment. The whole plant drops into emergency operation on paper and Excel.

The “2025 cliff” has not closed

Despite the name, the “2025 cliff” raised by Japan’s Ministry of Economy, Trade and Industry has not been resolved even in 2026. Analysis as of January 2026 indicates that 74% of large Japanese enterprises still hold ageing IT systems, the ones commonly labelled legacy.

That 74% figure needs to be read carefully. It does not mean that 74% of companies are in a dangerous state. What it actually tells you is that continuing to operate with legacy systems in place is the norm rather than the exception. You are not uniquely behind. But deadlines arrive on a schedule that has nothing to do with each company’s circumstances, so being typical is no comfort.

There is encouraging movement as well. In February 2026, JFE Steel announced that it had completed the migration of the core systems at all of its steelworks and manufacturing sites to an open environment. The scale and the organisation behind it are nothing like a factory in Thailand, so it is not a case study you can copy directly, but it does demonstrate the unglamorous fact that a migration planned over a long horizon and executed does finish.

The warning signs show up in operational friction, not technical metrics

Most people trying to judge whether a system has aged start by looking for technical indicators. Years in service, response times, disk utilisation. Those indicators barely move in the early stages of decline, because a system can be old and still perform for a long time.

What moves first is operational friction. Not the system itself, but the effort people expend around it, quietly increasing. The four signs below are the ones that come up most often in practice as triggers for a replacement review.

Sign 1 The shop floor routinely fills the gaps with Excel

A production management system is in place, yet the actual plan is built in somebody’s Excel file, and the results are keyed into the system afterwards. This is the most legible of the warning signs.

What matters here is not the use of Excel as such. Excel is an excellent tool, and there is plenty of analysis that has no business living inside a system. The question is whether that Excel file exists to cover something the system cannot do. Requirements changed, the system could not follow, and people are closing the gap by hand. Once that structure sets in, the real functionality of the system has migrated to the individual who maintains the Excel file.

Sign 2 Quotes for new functions keep climbing, and requests get dropped

You ask for a modification of roughly the same size as one you commissioned before, and the quote comes back an order of magnitude higher, with reasoning that is hard to follow. There is usually a technical explanation for this.

A system that has been in service for years accumulates exception handling with every modification. Nobody holds the full picture of what touching one function will affect. So the vendor loads the estimate with impact analysis and testing. The price is not rising because the vendor senses weakness. It is rising because the risk of change genuinely has.

And the real problem is not the price itself but what happens next. The quote is too high, so the request is withdrawn. The withdrawn request goes into an Excel file on the shop floor. Sign 1 gets worse. The two are linked.

Sign 3 The vendor’s support team has thinned out and responses have slowed

Replies take longer. Your contact changed. Questions that used to get an immediate answer now get taken away and researched. These shifts usually indicate that the number of engineers at the vendor who understand your system is falling.

People who work with older technologies retire or move on, and vendors find it hard to justify training junior engineers on a technology with no new projects behind it. This is structural, not malicious. Your maintenance contract may still have years to run, but once nobody is genuinely able to respond, the date on the contract means very little.

Sign 4 Internal security audits have started flagging it

The corporate IT function or a group internal audit begins raising items that were never raised before. The OS version in use, encryption methods, password policy, log retention periods.

What makes this sign awkward is that the deadline is imposed from outside. You may be able to run the system technically for several more years, but once an audit says “remediate before the next review”, that date becomes your effective end-of-support date. And audit remediation deadlines are usually set shorter than the time a migration actually needs.

What all four signs share is that none of them are recorded as system failures. Availability stays at 100% while the load on the people around the system rises. Which is exactly why reports based on availability keep saying everything is fine.

A six-variable scoring model for the replacement decision

When the presence or absence of these signs is debated by feel, the conclusion depends on who is speaking. The shop floor says it has reached its limit, finance says it still works. Both are being honest. They talk past each other because they do not share a measuring stick.

So here is a model with six variables, each scored from 0 to 3, giving a total between 0 and 18. First, the variables themselves.

The scoring criteria for each variable follow. Read them while applying your own figures. Where you do not know the number, the fact that you do not know is itself scoring material.

V1 Years remaining until end of support

Take the earliest deadline across the OS, database, middleware and hardware maintenance. This is the variable where factories most often answer “we still have time” without having checked all four.

When you check these dates, look at the manufacturer’s published material rather than your contract. Your maintenance agreement with the vendor may still be live, but if the platform manufacturer’s support has lapsed behind it, the vendor cannot fix a serious problem.

V2 Deterioration in recovery time

Measure the trend, not the absolute value. A system that has always taken half a day to recover is not showing its age if that has not changed.

Where a 3 applies, the problem is usually not the system but the disappearance of the people who understood its structure. Partial modification will not fix that.

V3 Extent of Excel workaround

Measure what Excel carries, not whether Excel is used.

A score of 3 does not fix itself when you replace the system. If anything it becomes the single most labour-intensive part of the project, because the decision logic sitting in one person’s Excel file has to be articulated as requirements.

V4 Shrinkage of the vendor’s support team

It is an awkward question, but worth asking directly. Ask “how many engineers at your company can work on this system?” and if the answer does not come back immediately, assume you are effectively dependent on a very small number of people. Anyone who knows the headcount can answer on the spot.

V5 Security audit findings

Look at whether corporate IT, group internal audit or a customer audit has raised findings. The severity of the finding matters less than whether a remediation deadline has been attached.

V6 Integration demands from adjacent systems

Look at what the system must be connected to within the next two years. A link to the parent company’s consolidated core system, an EDI requirement from a customer, automatic collection of production records from equipment. All are typical.

Once all six are scored, place the total in one of the following bands.

There is one exception rule attached to this table. If V1 scores 3, meaning support ends within a year or has already ended, treat the result as at least “budget for it” regardless of the total. The other variables may look healthy, but the deadline itself is not negotiable.

There is no exception in the other direction. Even with V1 at 0, a system scoring 3 on both V3 and V4 has already broken operationally, well ahead of any technical deadline. Having time on the clock does not cancel out the other problems.

If you land on a band boundary, 9 against 10 for instance, separate the variables pushing the score up into those describing today and those describing what is coming. V1 and V5 have deadlines imposed from outside, so if they are the ones driving the score, it is safer to take the higher band. Conversely, if V6 is inflating the score on the strength of an integration request that is still under discussion, you can stay in the lower band until that plan is actually decided.

Scoring a model factory

Abstractions only go so far, so here is one plausible factory scored end to end.

A Japanese-owned electronic components manufacturer in Chonburi province, 240 employees. Fifteen years ago it built its production management system by porting the parent company’s approach from Japan, and has made incremental modifications ever since. The platform is Windows Server 2016.

The total is 12, which lands in “budget for it”. V1 also scores 3, so the exception rule points to the same conclusion. What this factory should do is put the project in next year’s budget and decide the team and the timing.

The point worth noticing is that this factory’s system runs perfectly normally today. Incidents are not increasing. Judged on availability alone it looks healthy. It still scores 12 because pressure is arriving from four directions at once, namely deadlines, operations, staffing and new requirements. The value of the scoring model is that it puts a number on exactly this state, where nothing is broken and yet the limit is close.

A full replacement is not the only answer

Even a high score does not lead straight to a full rebuild. The modernisation strategy that has become mainstream in 2026 points in rather the opposite direction.

The practical consensus now is a hybrid configuration that preserves the core business logic and extends only the peripheral functions in the cloud. Costing and production planning logic built up over many years stays where it is, while APIs, screens, analytics and AI are built on the new platform. The view that phased migration is more realistic than a big-bang move has become widely shared.

The reason is simple. Full migrations fail too often. A system that has run for fifteen years has undocumented business rules embedded in it. Excavating all of them and reimplementing them in a new system is the kind of work where estimates go wrong most often.

In practice the available moves come down to four.

Each option carries its own trap. Choosing on headline price alone costs more later, exactly as it does with equipment renewal.

Extending the maintenance contract is not a standalone option. All it buys is time, and unless you have decided what to do with that time, you will simply repeat the same decision next year.

Choosing between a package and a scratch build is a separate question in its own right. For a structured look at the criteria, see our comparison of package versus scratch-built production management systems. Once your assessment has settled on migration, that is the natural next read.

The realistic duration and cost of a replacement

On duration there is one figure worth committing to memory. From the EOSL announcement, meaning notice of end of service life, to production go-live, a production management system replacement realistically takes 12 to 18 months.

That 12 to 18 month figure assumes approvals move smoothly and requirements are broadly settled. One rejected approval round and several months disappear.

Apply it to the IBM i 7.3 example from earlier. The deadline is 30 September 2026. Set the 12 to 18 month lead time against it and, to meet that date, the work would already have to be under way. If you are starting the review now, the conversation is not about whether you will make it but about how to cope on the assumption that you will overrun.

It is also worth understanding where the time goes. The longest phase is not building the system. It is taking stock of how the business currently runs. Deciding what is specification, what is an operational workaround and what is simply inertia takes more time than anything else. The second longest is parallel running and migration sign-off. Production management work is heavily tied to monthly closes, so you need to run at least a few closes on both the old and the new system and reconcile the results.

On cost, quoting a single market rate would be meaningless. Plant size, process complexity, how well the current system is documented and the volume of data to migrate all shift the order of magnitude. The structure of how costs accumulate, however, follows common patterns. Including the point that recurring annual costs after go-live often exceed the initial investment in total, we cover this in detail in our breakdown of factory system maintenance costs. It gives you the material to compare the cost of keeping the ageing system alive against the five-year total for a new one on equal terms.

One further decision affects both duration and cost, namely whether the new platform sits in the cloud or on premises. More factories are moving to the cloud when they modernise, but in Thailand, network quality and corporate policy mean the cloud is not automatically the right answer. We set out the criteria in our comparison of cloud and on-premises production management systems.

Considerations specific to Japanese-owned factories in Thailand

Everything so far applies equally to a factory in Japan. Operating in Thailand adds a further set of factors.

When the deadline arrives, you cannot simply buy more locally

In Japan there is a reasonably deep market of specialists willing to maintain older platforms and dealers handling second-hand hardware. In Thailand, the odds of finding a local provider that can support the same generation of equipment or the same technology are lower. Sourcing from Japan or Singapore adds days for customs and shipping.

This gap bites precisely when you choose “extend the maintenance contract” from the four options. The fact that head office in Japan has made the same call and extended does not mean the same move is available at the Thai site. The feasibility of a life-extension strategy has to be verified site by site.

The constraint of securing local engineers

The shortage of engineers who can work with older technologies is more severe than in Japan. Trying to recruit a Thai engineer who can maintain a system written with twenty-year-old technology is unlikely to produce candidates.

Turned around, this becomes a secondary benefit of replacement. Moving to a modern platform is not only a way of avoiding a deadline. It widens the pool of people you can actually hire. If maintenance of the current system depends on one named individual, removing that dependency is a legitimate line item in the return on investment.

Reconciling the corporate standard with local optimisation

This is the hardest point for factories in Thailand. Head office has issued a policy of consolidating onto a single core system, while the local site runs the way local commercial practice requires. Thai-specific tax requirements, customer-specific delivery instruction formats, the reality of dealing with local suppliers. Force all of that into the corporate standard and the shop floor stops working. Insist on local optimisation and you cannot produce the reporting head office needs.

The workable compromise is to decide where the line falls before anything else. Align financial accounting and costing to the corporate standard, allow local optimisation for production instructions and shop-floor data collection, and agree that boundary before requirements definition begins. Without that agreement, the same argument resurfaces at every requirements session and the schedule stretches.

The hybrid approach helps here too. Build only the parts needed to connect to the corporate standard on the new platform, and keep the local business logic as an existing asset. Not trying to deliver everything at once gets you there sooner.

Language and handover

You also need to decide what language the migration documentation will be written in. Design documents produced only in Japanese become unreadable the moment the Japanese manager who commissioned them finishes their posting. Because Japanese managers at Thai sites rotate every few years, this problem develops faster than it would at a plant in Japan.

At a minimum, keep operating procedures and incident response procedures in Thai or English as well. It is a relatively cheap insurance policy against the freshly modernised platform becoming, five years from now, another system that nobody understands.

How to choose who runs the migration

Before listing detailed evaluation criteria for choosing a partner, here are three practical disqualifiers.

The first is whether they can read your current system. The ability to build something new and the ability to decode something old are different skills. Migration work needs the second, and if your partner is weak there, cataloguing the current functionality falls entirely on you. At the proposal stage, look for a concrete explanation of how they intend to investigate the existing system.

The second is whether they can complete maintenance within Thailand. An arrangement where a team in Japan builds the system and also supports it after go-live tends not to work in practice, given time zones and the limits of travel. Ask before you sign who responds when an overnight batch fails, and where that person is located.

The third is whether they can propose a phased migration. If the only thing on the table from the first meeting is a quote for a full rebuild, that partner has not considered the options. Whether they are recommending a full rebuild after comparing it against hybrid life extension, or whether it was the only answer from the outset, is visible in how the proposal is structured.

On selecting a development company in Thailand more broadly, including contract structures and communication arrangements, see our guide to choosing a system development company in Thailand. If you have reached the stage of gathering competitive quotes, that is worth reading alongside this article.

One note on timing. Even if your score puts you in the “start planning” band, there is nothing wrong with opening conversations. What you should be asking for at this stage is not a quote but information about which options are viable given your specific conditions. Collect quotes first and your own judgement gets pulled along by the scope somebody else proposed. The order is assessment, narrowing the options, then estimates.

Frequently asked questions

When should we start considering a production management system replacement?

The clearest trigger is the announcement of an end-of-support date for the platform software or hardware. You do not have to wait for that announcement, though. Score the six variables in this article, and once the total reaches 5 or more, it is realistic to start comparing options and gathering rough estimates.

You can also work backwards from duration. A replacement takes 12 to 18 months, which makes two years before the earliest deadline your effective start-by date. That two-year cushion exists to absorb the things you cannot write into a plan, such as an approval sent back for revision or a key person transferring out.

What happens if we keep running past end of support?

Nothing stops immediately. In most cases the system keeps running as though nothing had happened, which is what makes the decision so hard.

What changes is your options when something does go wrong. A security vulnerability is disclosed and no fix is issued. An incident occurs and there is no manufacturer to ask. Hardware fails and no maintenance parts appear. None of these surface in normal operation, and all of them surface at the worst possible moment.

The treatment in customer and corporate audits also changes. Running core operations on an unsupported platform is an explicit finding under most audit standards. It is not unusual for these internal and external requirements, rather than the technical risk, to be the deadline that actually forces action.

How much does a replacement cost?

Because scale and current condition shift the order of magnitude, there is no useful market rate to quote. Between two factories of the same size, whether the existing system is documented can change the investigation effort several times over.

The realistic approach is not to hunt for other companies’ numbers but to line up two figures for your own. The first is the cumulative cost of keeping the current system alive for another five years, including paid support such as ESU, modification costs that keep rising, and the labour spent on Excel workarounds. The second is the five-year total for a new system. Compare those two on equal terms and you can decide without knowing any market rate. For how to build the cost breakdown, see our analysis of system maintenance costs.

Are there ways to extend the system’s life short of a full replacement?

Yes. The mainstream approach in 2026 is a hybrid configuration that preserves the core business logic and extends only the peripheral functions in the cloud. Phased migration is regarded as the practical answer over a full move, with the advantage that logic refined over many years does not have to be discarded.

There are conditions for it to work, however. The core business logic must still be valid, and the platform hosting that core must still have headroom before its deadline. With under a year left on the platform, you may want to preserve the core but the ground underneath it expires first. In that case the answer is not hybrid. The platform has to be migrated first.

Summary

The ageing of a production management system cannot be measured by availability. The essentials of the decision come down to the following.

A system running is not the same as a system being safe. Extended support for IBM i 7.3 ends on 30 September 2026, which is also the end of standard support for IBM i 7.4. Standard hardware maintenance for some Power9 models ends on 31 January 2026, and extended support for Windows Server 2016 ends on 12 January 2027. The fact that 74% of large Japanese enterprises still hold legacy systems makes the situation typical, but not safe.

The warning signs appear as operational friction rather than technical metrics. Routine Excel workarounds, escalating quotes, a shrinking vendor support team, security audit findings. None of the four is recorded as an incident, so all four coexist happily with reports of “no problems” based on availability.

The decision can be structured by scoring six variables. Years remaining until end of support, deterioration in recovery time, extent of Excel workaround, shrinkage of the vendor’s support team, security audit findings, and integration demands from adjacent systems. The total sorts you into monitor, start planning, budget for it, or start now. If support ends within a year, though, treat it as “budget for it” regardless of the total.

A full rebuild is not the only move. Compare four options, namely extending the maintenance contract, hybrid life extension, full migration to a package, and rebuilding from scratch. The practical answer in 2026 is the hybrid configuration that preserves the core and extends the periphery in the cloud.

Then there is duration. From the EOSL announcement to go-live takes 12 to 18 months. Knowing that figure moves your start date by a year.

If you are still weighing where your own system sits and whether life extension or migration makes more sense, that is a perfectly good time to talk. Given your platform versions and the operational load you are carrying today, we can return a first-pass score against the six variables and the options that are actually viable for you. For a conversation ahead of any estimate, feel free to reach us through our contact page. Drawing on our experience of implementation and migration in Thailand, we will tell you where the sensible scope sits, neither over-engineered nor endlessly deferred.

References

• End of extended support for IBM i 7.3 and end of standard support for IBM i 7.4

https://www.c3index.co.jp/blog/blog_3456/

• End of standard hardware maintenance for IBM Power9 models

https://www.c3index.co.jp/blog/blog_3082/

• AS/400 and IBM i Modernization Guide 2026 – Aurant Technologies

https://aurant-technologies.com/blog/as400-ibm-i-modernization-guide-2026/

• Planning ahead for Windows Server 2016 end of support – Microsoft

https://www.microsoft.com/en-us/windows-server/blog/2026/02/25/planning-ahead-for-windows-server-2016-end-of-support/

• Risks of running past maintenance expiry, replacement lead times, and practical signs to begin a review – Venture Net

https://www.venture-net.co.jp/netsuite/risk-of-expiry-of-maintenance/

• Analysis finding that the 2025 cliff remains unresolved in 2026 – ITmedia Enterprise

https://www.itmedia.co.jp/enterprise/articles/2603/30/news017.html

• Completion of the migration of core systems at all steelworks and manufacturing sites to an open environment – JFE Steel

https://www.jfe-steel.co.jp/release/2026/02/260226.html