You Chose to Build. Twenty Years Later, That Decision Is Still Running Your Business.

The build vs buy decision doesn't end when you ship. It continues every time you need to modernize what you built. Here is what happens when your custom system becomes your biggest constraint.

Twenty years ago, your predecessor made a good decision. They looked at the off-the-shelf options available, found that none of them fit the business well enough, and chose to build something custom. That was the right call. The custom system fit the business perfectly. It encoded exactly the right workflows, the right business rules, the right integrations.

And now it runs everything. Still. The team that built it has largely moved on. The technology choices that made sense in 2005 are now dependencies that constrain every new decision. The system that was built to fit the business perfectly now makes the business slow to change.

This is not a story about a bad decision. It is a story about time.

Why custom-built systems age differently

Off-the-shelf software gets updated by its vendor. Security patches, performance improvements, new integrations — these happen whether you ask for them or not. The software you pay for stays current because the vendor has an incentive to keep it current.

Custom-built systems age on a different schedule. They get updated when you prioritize updating them, which means they often do not get updated until the cost of not updating becomes impossible to ignore. The language version falls behind. The dependencies accumulate vulnerabilities. The architecture that was modern in 2005 becomes a constraint on everything you want to build in 2025.

There is nothing wrong with custom software. The problem is that custom software requires ongoing investment to stay current, and that investment is easy to defer when the system is working well enough. Until it isn't.

The moment the system stops fitting

The build vs buy decision has a second act. It arrives when the custom system that fit the business perfectly in its original form stops fitting the business as it exists today.

Maybe the business has grown beyond what the system was designed to handle. Maybe regulatory requirements have changed in ways the system cannot accommodate cleanly. Maybe new technology, AI capabilities, modern APIs, cloud-native architecture, requires a foundation that the legacy system cannot provide.

At this point, the original build vs buy decision reasserts itself. Do you buy something new and migrate? Do you modernize what you have? Do you rewrite from scratch? Each option has costs that are easy to underestimate and risks that are easy to overlook.

Why the migration option fails so often

The instinct when a custom system becomes a liability is to replace it. Find a modern off-the-shelf solution, migrate the data, retire the old system. Clean. Simple.

The problem is that twenty years of custom development encodes twenty years of business logic. Rules accumulated through real-world operation. Edge cases discovered through failure. Calculations that look simple but depend on context that only exists in the old system. When you migrate to a new platform, you do not just move your data. You abandon the accumulated knowledge of how your business actually works, and you hope that the new system's standard functionality covers enough of it.

It usually does not. Not completely. The gaps surface after the migration, in production, when something fails that nobody expected to fail.

Why rewriting from scratch fails just as often

The rewrite option has a similar problem. If you do not fully understand what the old system does — and after twenty years of accumulated changes, most organizations do not — you cannot fully specify what the new system needs to do. You build what you know about, which is most of it. The missing piece is the undocumented behavior that the business depends on and nobody thought to include in the specification.

These are the failures that damage organizations most. Not spectacular crashes, but subtle behavioral differences that take months to identify and trace back to the migration decision.

The third option

There is a third option that most organizations do not consider seriously enough. Modernize incrementally, rather than replacing wholesale.

Map the existing system first, at the level of what it actually does rather than what it was designed to do. Identify the modules that are most constraining current priorities. Extract those modules, rebuild them with modern architecture, validate the new behavior against the old before retiring anything. Keep the existing system running throughout. Move one piece at a time.

This is slower than a migration on paper. In practice it is faster, because the failure surface at any point is small. A problem with one extracted module does not take down the whole business. And because you are moving incrementally, the full understanding of the system develops as you go, reducing the risk of each subsequent extraction.

The companies that chose to build twenty years ago made a good decision. Their systems carry real value — decades of accumulated business knowledge that no off-the-shelf product contains. The question is not whether to replace that value. It is how to preserve it while modernizing the infrastructure that delivers it.