The reason a shop stays on five systems is not inertia and it is not ignorance. It is that the arithmetic of leaving is genuinely bad.
Replace one of the five and you now have five systems and a migration — the problem got worse. Replace all five at once and you are changing how quoting, scheduling, the floor, and the books all work during a quarter when you still have to ship parts. Every individual step away from the patchwork looks irrational in isolation, which is why the patchwork survives being obviously bad.
So this is about what the move actually involves, and about the one thing that decides whether it works.
The one thing that fails more than anything else
Floor adoption. Not data migration, not training, not configuration. Floor adoption.
The failure runs in a predictable sequence. The system goes live. For the first week people clock carefully because it is new and somebody is watching. In week three a machine goes down, somebody is behind, and the clocking gets done from memory at the end of the shift. In week five a second person notices the first one is doing that. By week eight the floor data is approximate.
Now the costing is approximate, so the margin reports are wrong. Somebody in the office notices a number that cannot be right, loses confidence in the reports, and goes back to the spreadsheet to answer the question properly. And once the spreadsheet is back, the system is a data-entry burden with no payoff, which makes adoption worse, which makes the data worse.
Nothing in that sequence is a software defect. It is a habit problem, and the software's only role is whether it makes the right habit easy or hard.
Two things matter for that. The clocking interaction has to be fast enough that a busy operator does it rather than deferring it — seconds, at the machine, not a trip to an office terminal. And missing data has to be visible, not silently estimated. A system that notices nobody clocked operation 30 and says so is doing its job. A system that quietly fills the gap with a standard produces confident wrong numbers, which is the worst possible output.
Ask any vendor what happens on day three when somebody stops clocking. The answer tells you whether they have done this in a real shop.
The second thing that fails: data nobody scoped
Every shop's data is messier than the shop believes, and the mess is always in the same four places.
Part masters with duplicates and drift. The same part under three numbers from three eras. Revisions that were never superseded properly.
Routings that describe how the shop used to run. Operations on machines that left, standards set before the current spindles arrived, and a few routings somebody built once for a quote and that became the production routing by accident.
Open work-in-process. This is the genuinely hard one. Jobs that are half-run on go-live day have hours and material already consumed in the old system, and those balances have to arrive correctly in the new one or the first quarter of margin reporting is nonsense.
Customer and supplier records. Three spellings of the same company, terms that live in somebody's head, and pricing agreements recorded in email.
None of this is unusual and none of it is anybody's fault. It is also the part we took out. You describe the shop the way you would explain it to a new hire, or drop in the exports and spreadsheets you already have, and the system reads machines, rates, customers, parts, open jobs and your own numbering out of them. Every value is shown next to the words it came from, and nothing is stored until you confirm it. The judgment stays yours; the typing disappears.
What a sane sequence looks like
Not a big-bang cutover across all five systems on one weekend. The thing that makes the arithmetic work is sequencing it so that each step stands on its own.
Quote first. Quoting is the lowest-risk place to start, because a quote that goes out of a new system is still just a quote — if it is wrong, you find out before anybody cut metal. It is also where the fastest visible payoff is, which matters for getting the office to believe the project is going somewhere.
Then jobs and the floor, on a subset. Run one cell or one part family in the new system while everything else continues as it was. This is the step where floor habits get built, and building them on a small footprint means the inevitable first-weeks noise does not contaminate the whole shop's numbers.
Then the rest of the floor.
Then the ledger, at a period boundary. Never mid-period. The accounting cutover is the one step where timing is not negotiable.
Because the quote, the job and the ledger are one record rather than three systems, each of those steps stands on its own — you are never maintaining a bridge between the old stack and the new one while you cross.
What to insist on in writing
A total first-year number. Software, implementation, migration, training, and any module you will need in month four. One number, with the estimated line items marked as estimates.
Your data out, in a documented format. Before you go in, know how you get out. Every table, keys intact. A vendor who is vague about export is telling you something about the next five years.
A named go-live criterion. Not a date — a condition. "Floor data for one part family reconciles to within x percent for two consecutive weeks" is a criterion. "Go live March 1" is a hope.
Who answers the phone during second shift.
Three questions that tell you where you stand
The test is not whether you have five systems. It is whether you can answer these about whatever you run today:
- Which line of last month's worst job missed — material, setup, run or outside service? (Why that question is the whole game.)
- Where is any job right now, in one screen?
- Is the hour your operator clocked the same record that costs the job?
On one record all three are a glance. That is the whole difference, and it is what a demo shows in thirty minutes on a shop set up like yours.
KG Ai ERP runs quoting, production scheduling, shop floor data collection, live job costing, suppliers, quality, CRM and a general ledger on one record. Built inside a working precision machining shop, so the implementation sequence above is the one we ran ourselves. Request a demo.