← Field Notes · ESSAY № 03

30 years of Bus, 30 years of COMOS — the same job

Keep a T3 on the road long enough and you learn: „still running" is not a state, it's a practice. The same goes for any COMOS database that has been growing since the 90s. On substance, the seduction of the big bang — and why the most honest migration is the one that ends boringly.

Jan Meyer 14 · June · 2026 9 min read

There is a word I learned from Bus owners that I now slip into every other industrial workshop: substance. Substance means: there is something load-bearing. There is a frame that has held up for three decades. There is sheet metal that is still original. There is an engine that hasn't gotten livelier, but also hasn't gotten weaker. Substance is what remains because it was made properly. Substance is not „new", but it is also not „worn out". It is the foundation you can keep building on.

In industrial software the same thing exists — but nobody calls it that. A COMOS database running since 1998 is substance. A maintenance planner that has survived three ownership changes is substance. A grown permission concept that maps six sites and four languages is substance. All of that has a value that doesn't show on any balance sheet — and that any modernization project tends to underestimate.

What I learned on the lift

Substance maintenance with a T3 works like this: once a year, you go through it. You look at the critical spots — sills, wheel arches, rear tank carrier, longitudinal members. You're not looking for problems — you're looking for developments. Where is paint thinning? Where is a small blister? Where does something smell unusual? You document what you see. Next year you compare. Things you catch with a brush and cavity wax this year will cost you a floor panel in five years. Things you still solve with a floor panel in five years will cost you the frame in ten.

Nobody runs that annual lift-round in industrial IT. There are audits — but those tend to focus on compliance, not substance. There are health checks — but typically from the vendor who would also like to sell the modernization. What's missing is the unspectacular inspection: where is a problem getting thinner right now? Where does something smell unusual?

The most expensive migration is the one that did not need to happen — because the system could have served well for five more years if someone had checked the sills in between.

Three practices I have brought from the workshop into consulting

1. The annual stocktake.

Once a year I sit down with the owner of a system for two hours — not in a workshop, not in an audit, but in a calm stocktake. What went well? What was annoying? Which hotfixes had to happen? Which documentation has gone stale? Which colleagues have vanished who used to be the only ones who understood something? That's the lift. It takes two hours. It prevents four-week crisis meetings.

2. The substance inventory.

For each plant, each platform, each system I keep a short list. What is load-bearing? What is swappable? What is cosmetic? That distinction sounds trivial; it isn't. When I know a customizing script is load-bearing, I treat it differently than when it's cosmetic. When I know an interface is swappable, I can replace it calmly later without panicking. Most migration dramas happen because nobody made that distinction — and then during the rebuild the frame got cut along with the rest.

3. The honest repair, not the showable one.

In the workshop there are two kinds of work: the kind you see (fresh paint, new bumper) and the kind you feel (no rattle, no vibration). Both are legitimate but they have different audiences. In IT, the same: a new dashboard is showable — a clean overnight batch is feelable. Both deserve attention. But the showable things get it anyway. My job as a consultant is often to explain to the board why the feelable things deserve money too.

The seduction of the big bang

With a T3, the temptation is sometimes: full repaint, full new interior, freshly rebuilt engine, all axles overhauled — and at the end you have a bus that looks new and feels like a restoration you never want to touch again because it cost 40,000 euros. Most T3 veterans advise against that. They advise stages. First the roof, then the sills, then the engine, then the seats. Each stage finished, drivable, fit for everyday use. The result looks less shiny, but it runs the whole time, and it's paid for out of cash flow instead of a loan.

In industrial software, the temptation of the big bang is even more seductive because it looks better on a slide. „We replace the old ERP and at the same time roll out a new MES, a new PLM platform and a new maintenance system. Three-year project, nine-figure investment, at the end we're digital." On paper it works. In reality, those are the projects you never hear about again — not because they failed, but because they were quietly retired under a new CEO.

Heuristic
If a project is too big to be stopped in a single board meeting, it is too big to be finished successfully. A migration in twelve stages can be honestly halted after any single stage. A migration that only works as a whole can only fail as a whole.

The boring migration

I've accompanied a number of COMOS migrations in recent years. The best ones were the most boring. Preparation with a test run. Test run, learnings, adjustments. Second test run on a quiet weekend. Production cutover on a pleasant Tuesday, around two in the morning, with a half-staffed team and a prepared rollback. Thursday the system stood, Friday the first productive reports came through, by Monday nobody talked about it anymore.

That's substance maintenance at the software level. No big bang, no PR event, no „digital transformation" banner in the lobby. Just: something load-bearing was supervised from one state into the next. The system keeps running — only now on a database that has another ten years of support. Exactly like a T3 whose rear longitudinal members you've just replaced. You can't tell by looking. You can tell by driving — it feels like before, only younger.

What remains

I think that's the most honest definition of modernization I know: taking something that works and transferring it so it keeps working for a long time — without losing the substance that made it work. That applies to diesel engines. It applies to COMOS databases. It probably applies to most things into which someone, at some point, put enough work that they'd be worth not throwing away.

If I could leave one sentence behind, it would be this: Look at the system from underneath, once a year, before you write a roadmap. Most roadmaps would look different if that had happened.