Check every year which of your platforms is losing, and start planning before somebody sends you the notice. I don’t trust modernization pitched as vision. Most of the time the vendor or the market has already made the call, and the executive presentation dresses it up as strategy after the fact. Companies that believe their own presentation start late, and starting late is the most expensive mistake you can make with a platform.
Why do companies replace working systems?
Because something outside the company made the decision for them, and anyone who pretends otherwise is dodging.
The version in the sales deck is different, and most of it is fiction. A new platform makes new things possible, the business grows into it, and the investment pays for itself. Somewhere that happens. In practice, most modernization projects start when a support contract ends, a database vendor loses a market, hardware can no longer be expanded, or a compliance requirement lands that the current system can’t meet.
None of those are opportunities. They’re deadlines with a cost attached, and the cost was set by somebody who doesn’t work for you.
What happens when your database vendor starts losing?
Calling a deadline an opportunity insults the people who’ll be working nights to meet it. I’ve been through two of these transformations.
The first one took a year and moved the company off paper and onto a large minicomputer running a database called Unidata. It worked, and it ran the business for the better part of a decade.
Then the ground moved. Unidata was clearly losing the database wars. The platform we were on was in decline, and my recollection is that we’d reached the point where we couldn’t upgrade further.
Neither of those facts had anything to do with us. Our systems worked, our people knew them, and the business was running fine. It’s galling to replace something that works, and the market doesn’t care how well your system runs.
The decision arrived from outside anyway, and the only question left was whether we moved on our schedule or on somebody else’s.
What order should a forced migration follow?
People first, then processes, then technology, in that order. Nobody used that phrase at the time, but it’s what we did. Start with what the people needed. Then work out how the process would run inside each department. Then handle the technology.
That order matters more when the technology is already fixed than when it’s open. We were moving to a specific platform and that part was settled. That meant technology was the least negotiable item in the entire project.
It still went last. Most teams invert this. They pick the platform, design the process around whatever the platform does easily, and then tell the people. When adoption comes in poor they act surprised, and the surprise is unearned, because the people were the last to hear and they’re the first to be blamed.
Technology was the least negotiable item and it still went last; most teams run this order backward.
What is different about the second transformation?
More capability, and considerably more scope.
The first time around, the technology available to connect a warehouse to a head office was limited. By the second, we had high-capacity circuits to the stores and satellite communication, neither of which existed for us in the first project.
The scope grew to match. Accounting, human resources, merchandising, and eventually warehousing. That came later than the rest. Some of it went to hosted software instead of something we ran ourselves. That was new at the time. Bigger capability produces a bigger project instead of an easier one. That’s a pattern I’ve watched repeat, and it catches people who assume better tools mean less work.
How do you know a platform is going to lose?
Watch the signals that appear before the vendor announcement.
Hiring is the earliest one. When people with skills in your platform become hard to find and expensive, the market has already made a decision that hasn’t reached you yet.
Companies that believe their own presentation start late, and starting late is the most expensive mistake you can make with a platform.
How often the product ships is the second. Something releasing maintenance updates and nothing else is being maintained and not developed. The third is the vendor’s own behavior. When a vendor stops sending anyone to see you, when their conferences shrink, when the account team turns over repeatedly, the platform isn’t where their attention is. Don’t wait for the vendor to warn you. The account team gets paid to keep you renewing, and no salesperson is going to tell you the product he sells is on its way out. Reading that market is your job, and I’d put it on somebody’s calendar by name.
None of those are secrets and all of them show up years before an end-of-support notice. A yearly review of which of your platforms is losing costs an afternoon and buys you the difference between planning and reacting.
What does a forced migration cost that a chosen one does not?
Bargaining power. That converts directly into money, and giving it away by waiting is just dumb. A company that starts early can evaluate options properly, negotiate from a position where walking away is real, run the move at a sensible pace, and stop if something better appears.
A company on a deadline set by a vendor gets none of that. Every negotiation happens with the counterparty knowing the date. Every corner gets cut because the date doesn’t move. The technical work is identical in both cases. What differs is the price and the number of compromises, and both of those track directly to how much time is left when the project starts.
| Factor | Chosen (started early) | Forced (vendor’s deadline) |
|---|---|---|
| Bargaining power | Walking away is a real option | The counterparty knows the date |
| Evaluating options | Done properly | No time to do it |
| Pace | A sensible pace | Corners cut because the date doesn’t move |
| Changing course | Can stop if something better appears | Locked in |
| Technical work | The same | The same |
| Price and compromises | Lower, with more time left | Higher, on the vendor’s schedule |
My take
Start looking before the vendor tells you. Modernization shows up as a bill, and the companies that get hurt find out on someone else’s schedule. Watch the signals. Specialists in your platform get hard to hire, the releases turn into maintenance only, and the vendor starts acting differently. When those show up, start planning. Expect a bigger project than last time, too. Better tools bring bigger scope, never less work.
Should a small company modernize before it has to?
Not everything, and not on a schedule somebody sold you. Replacing systems that work is expensive and disruptive, and a company with forty people can’t absorb that repeatedly. Plenty of software should be left alone for years.
The useful discipline is narrower. Know which of your platforms is in decline, and start planning for the one closest to the end. Planning here means understanding what the move would involve, what it would cost and roughly how long it would take, well before anybody migrates anything.
That planning is cheap. The notice will arrive whether you’ve done it or not, and a company that skipped it spends the next year paying the vendor’s price on the vendor’s schedule. That’s a lousy trade, and an unfair one, because the executives who skipped an afternoon of planning aren’t the ones working weekends to hit the date.
