Check every year which of your platforms is losing, and start planning before somebody sends you the notice.
Why do companies replace working systems?
Because something outside the company made the decision for them.
The version in the sales deck is different. 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 cannot 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?
About eight to ten years after the first transformation I ran, we’d to do it again.
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. The business was running.
The decision arrived from outside anyway, and the only question left was whether we moved on our schedule or on somebody else’s.
How do you plan a migration you did not choose?
People first, then processes, then technology, in that order.
Nobody used that phrase at the time and 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. Then they’re surprised when adoption is poor.
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’d 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, which came later than the rest. Some of it went to hosted software instead of something we ran ourselves, which 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.
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.
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, which converts directly into money.
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.
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 cannot 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. Not migrating. Planning. Understanding what the move would involve, what it would cost, and roughly how long it would take.
That planning is cheap and it’s the entire difference between a project you run and a project that runs you. When the notice arrives, and it will, you either have an answer or you have a deadline.