The Conversation I Have More Than Any Other

At least once a month, a business owner or CTO reaches out with some version of the same situation: a system that runs the business, was built five to fifteen years ago, and terrifies everyone on the team. Nobody wants to touch it. Nobody fully understands it anymore. And yet the business depends on it every single day.

The instinct is to replace it. That instinct is sometimes right and sometimes catastrophically wrong. The answer depends on a specific set of questions that most teams skip in their rush toward a rewrite.

The Three Paths and What They Actually Mean

Refactoring means improving the internal structure of the existing system without changing its external behavior. You clean up the code, break apart tightly coupled components, improve test coverage, and make the system easier to understand and modify. The system keeps doing what it does — it just becomes less fragile and more maintainable.

Replatforming means lifting the core logic to a new technology stack, infrastructure, or architecture while preserving the fundamental business model the system implements. You are not reinventing the wheel — you are putting better wheels on the same vehicle.

Leaving it alone — properly understood — is not giving up. It is a deliberate decision to accept the current cost and risk profile because the cost of change exceeds the cost of continuity. Sometimes this is the right call, and saying so clearly is worth more than an expensive migration that creates new problems.

When Refactoring Is the Right Answer

I recommend refactoring when the system's core logic is sound but the code has accumulated debt. You can see what it is doing, the business rules are correct, but it is slow to change because every modification requires deep archaeology.

Signs that refactoring is the right path:

  • The system works reliably but new features take three times longer than they should
  • The original developers are gone but the logic is at least comprehensible
  • Test coverage is low or nonexistent, and every deployment carries unnecessary risk
  • Performance is acceptable but the codebase has clear structural problems that compound over time

Refactoring is also the right answer when a full replacement would require recreating business rules that are not fully documented. I have seen rewrites fail catastrophically because the new system did not replicate an edge-case pricing rule that was buried in a twenty-year-old stored procedure — and nobody knew it existed until a major client's invoice came out wrong.

When Replatforming Makes Sense

Replatforming is justified when the underlying technology is the limiting factor, not the logic. The business logic is solid, the requirements are well understood, but the current stack cannot scale, cannot integrate with modern systems, or is approaching end-of-life in terms of vendor support.

Typical replatforming triggers:

  • The system runs on infrastructure that is no longer supportable (end-of-life OS, discontinued database version, hardware that cannot be replicated)
  • Integration demands have outgrown what the current architecture can handle — the system was never designed to expose APIs or accept real-time data feeds
  • The security posture of the current stack is a liability that cannot be patched away
  • Hiring has become difficult because the technology is too niche or too old to attract competent developers

Replatforming done right is not a big bang rewrite. I almost always recommend a strangler fig approach: build the new platform alongside the old one, migrate functionality incrementally, and decommission the legacy components as replacements are validated. This reduces risk dramatically and lets the business continue operating throughout the transition.

This connects directly to the integration challenges I discuss in my article on custom API integration — legacy systems that cannot expose clean APIs are often the root cause of broader automation failures.

When to Leave It Alone

This is the answer nobody wants to hear, and it is frequently the correct one. A system should be left alone when:

  • The cost of change exceeds the benefit over any realistic time horizon. A system that costs $5,000 per year to maintain but would cost $200,000 to replace, and whose core function is stable, is a system you should leave alone.
  • The system is a black box with invisible business rules that you cannot safely extract. Attempting to rewrite it is more likely to destroy value than create it, and the risk cannot be managed down to an acceptable level.
  • The team proposing the rewrite is not the team that will live with the result. I have seen expensive modernization projects driven by a CTO who left six months after launch, leaving the operations team with a new system they did not want and do not understand.

Leaving it alone does not mean doing nothing. It means making a documented decision, ensuring the system is properly backed up, documented to the extent possible, and that the organization is not making business decisions that increase its dependency on the fragile component.

The Framework I Use Before Recommending Anything

Before I advise a client in any direction, I work through four questions:

1. What is the actual cost of the current system? Not just maintenance cost — include the cost of slow feature delivery, integration workarounds, recruiting friction, and business risk from outages.

2. What is the cost of change? Full replacement cost including discovery, development, testing, migration, training, and a realistic contingency buffer (which should be 30 to 40 percent of the base estimate on any legacy migration).

3. What are the constraints the new system must respect? Regulatory requirements, data retention rules, integration obligations with third-party systems, and contractual obligations that depend on specific behaviors.

4. Who owns the business rules? If the answer is "the system itself," you have a much harder modernization problem than if a domain expert can walk you through the logic in a whiteboard session.

For organizations weighing this against the alternative of buying packaged software, my article on custom versus off-the-shelf software covers that dimension of the decision.

The Mistake That Costs the Most

The single most expensive mistake I see is conflating technical discomfort with business risk. Developers hate working in old codebases. That discomfort is real, but it is not a business case. The business case has to be built on measurable costs, realistic timelines, and honest risk assessments — not on the fact that the code is unpleasant to read.

I have walked away from engagements where the proposed modernization project was a solution looking for a problem. That honesty sometimes costs me a contract in the short term. It preserves the relationship long term, because the client avoids spending $300,000 on a project that would have delivered them back to the same operational state they were already in.

What Comes Next

If you have a legacy system that is causing concern, the first step is a structured assessment — not a commitment to replace it. Understanding what you actually have, what it costs you, and what the realistic options are takes two to four weeks and gives you everything you need to make a defensible business decision.

Let's talk through your situation. I have done this assessment across ERP systems, custom CRMs, financial platforms, and operational tools built on every technology stack you can imagine — and a few you cannot.