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 do custom-built systems age differently than commercial software?

Custom-built systems age differently because they lack vendor-driven updates and evolve based on the organization's specific constraints and priorities. They accumulate technical debt through architectural decisions made decades ago, lose original developers who understood the codebase, and become increasingly difficult to modify as business requirements change and modern integration standards emerge.

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.

When does a custom system stop fitting your business needs?

A custom system stops fitting when the business model shifts faster than the system can adapt. This occurs when market demands require features the architecture cannot support, when integration with modern tools becomes prohibitively expensive, or when the maintenance burden consumes resources needed for innovation. The gap between system capability and business need widens until operations are constrained.

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 do legacy system migration projects fail so often?

Legacy system migrations fail because organizations underestimate the complexity embedded in decades of undocumented business logic, struggle to maintain operations during transition, and face scope creep as hidden dependencies emerge. Teams lose institutional knowledge, budgets overrun by 200-400%, and business stakeholders lose confidence. Many migrations are abandoned mid-stream, wasting millions in sunk costs.

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 does rewriting legacy software from scratch usually fail?

Rewriting from scratch fails because it repeats the original build-versus-buy trap at massive scale. New systems miss critical edge cases discovered over years of production use, development timelines extend as teams realize the depth of existing functionality, and businesses cannot freeze requirements for 2-3 year rebuilds. The rewrite becomes legacy before launch.

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.

What is the third option for modernizing legacy custom systems?

The third option involves incremental modernization through strangler fig patterns, API-first architecture, and strategic replacement of discrete components rather than wholesale migration or rewrite. This approach maintains business continuity, reduces risk, delivers value in phases, and gradually transitions from custom-built constraints to flexible modern solutions while preserving critical institutional knowledge embedded in the existing system.

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.