Most plants shopping for an MES alternative are not really shopping for a different execution system. They are trying to answer questions their current one cannot answer, and replacement is the only option the market puts in front of them. There is another option. You leave the systems that run the floor exactly where they are, and add a layer above them that holds what their records mean. I have sat through a lot of migration planning meetings, and one moment repeats. A maintenance planner does the arithmetic out loud. Eleven years of downtime records sit in the system they are about to retire. Two of those years were coded by a supervisor who used the reason codes his own particular way, consistently, which makes them readable if you knew him. The migration on the table carries the last eighteen months and archives the rest. He asks what happens to year three, the year the same bearing failure ran through the plant twice. The best answer in the room is that they will export it to a file somewhere. What an MES alternative is actually replacing Your execution system is a record. It knows the run started at 06:12, the count hit 4,400, the line stopped, someone picked a code. Your ERP is a record too, of intent and money. Your historian is a record of signals. All three are usually accurate. What none of them holds is meaning. Meaning is the part that says this stop, on this line, against this order, under these conditions, is the same thing that happened in March, and it cost the customer two days. That connection lives in people, in a spreadsheet a planner maintains privately, and in the gap between systems that were each scoped correctly for their own job. So when a plant says the system is not giving them what they need, the missing piece is almost never another record. Buying a second record and turning off the first one moves the same data into a new schema and leaves the meaning exactly where it was, in someone’s head. That is why so many replacements go live and change so little. What stays and what changes when you layer over your MES You can list exactly what stays and what changes. What stays: the execution system and its screens, the historian, ERP, the scales, the label printers, the control logic on the PLCs, the interlocks, the validation status of anything validated, and every operator who already knows where the buttons are. Nobody retrains. Nobody cuts over on a Sunday night. What changes: where meaning is defined, and where questions get asked. The vocabulary of your operation, the orders and lots and machines and holds and the actions you take on them, gets written down once and connected across systems instead of being re-derived by whoever is building this week’s report. New questions get asked of the layer rather than of four applications and a person who remembers. What it costs: read access, which is a real IT project with a real security review, and somebody’s attention to agree on the vocabulary. That second part is the harder one and it is not a software task. It is your QA lead and your afternoon shift supervisor standing at a whiteboard, finding out they do not mean the same thing by a hold, and settling it out loud, which is often the first time anyone has written it down. What a layer will not do This is where these projects go wrong. The layer cannot invent what was never captured. If, say, seven stops in ten are coded Other, they are still coded Other on the day it goes live. What changes is that you can now see that clearly and fix the capture at the source. That is worth something, but it is not the same as having the data. The layer above your systems does not do control. If you need to gate a step, enforce a signature at the point of work, weigh against a tolerance and refuse to proceed, or hold a lot physically, that is the execution system’s job and it stays the execution system’s job. If your vendor is ending support next year, layering buys you time and shrinks the eventual replacement to the parts that actually need replacing. It does not cancel it. And when two systems disagree about what an order is, the layer will show the disagreement rather than settle it. Somebody with authority still has to decide. In most plants I have seen, that is an improvement. The disagreements were always there. They were just being settled quietly, differently, by each person who ran into them. Sort your systems into keep, read, and gap Two hours, a whiteboard, and the people who actually use the systems. No vendor in the room. Pick one product and follow it from order to shipment. List every system it touches, including the spreadsheets and the shared drive. Then for each system, write three things: Keep. What is this the only place to find? Not the only convenient place. The only place. Read. What does it hold a copy of, sourced from somewhere else? Gap. What does it not hold at all that you needed last month? Then take the three questions your team argued about last month and mark, for each one, which column the answer lives in. Read the result this way. Anything in a Keep column is a record you cannot rebuild, and a migration scope that touches it deserves a hard look. Everything in the Read columns is your integration surface, and every place two copies disagree is a decision somebody still has to make. The Gap column is the thing you are actually trying to buy. It is also the test to run in a demo: make the vendor fill that column with your own data. If a proposal does not fill it, it will not help, no matter how much better the screens are. Most operations run this exercise and find that their Keep list is short, their Read list is redundant, and their Gap list has nothing to do with execution at all. What they want is to know why something happened, to see the years behind it, and to connect records that sit in different systems. None of that arrives in the box with a new system. The planner never gets his answer about year three. The migration runs on schedule, the archive goes to a file share, and that bearing failure will surface again. When it does, somebody will work it out fresh, at full cost, for the third time. That is what a rip-out really costs. Not the licence and the integration hours, which are on the quote, but the years of record that stop being reachable. Count the years of history your operation is holding right now. Then read the migration scope and see how many of them make the trip.