Archive for category: Engineers

Software rebuilds tend to become attractive for understandable reasons. Releases are getting slower. Engineers are reluctant to touch certain parts of the codebase. Infrastructure costs keep climbing. A framework is several versions behind, and every major feature seems to require another workaround.

At that point, starting again can look cleaner than fixing what is already there. Sometimes it is. But approving a rebuild before establishing what is actually wrong with the current system turns a technical problem into a much larger financial risk. Before committing to a replacement, a SysGears assessment covers the codebase, architecture, dependencies, and migration options — the scope is at https://sysgears.com/tech/scala-consulting/ — and gives the board something concrete to decide against.

That is the purpose of a technical assessment. It gives executives enough evidence to decide whether the business needs a rebuild, a narrower modernization program, or simply focused engineering work in the areas causing the most damage.

A Painful Codebase Does Not Automatically Need Replacing

Engineers usually have good reasons for complaining about legacy software. Years of feature development leave behind old dependencies, inconsistent patterns, tightly coupled modules, duplicate logic, and code nobody wants to change.

But technical debt is not binary. Its presence does not tell executives whether replacing the system makes financial sense.

A ten-year-old application might have one subsystem responsible for most performance incidents while the rest of the platform remains stable. Slow releases could come from a brittle test suite rather than the architecture itself. High AWS or Azure bills might point to inefficient database queries or poorly configured infrastructure, not a fundamental problem with the application design.

A software architecture review helps separate those issues.

The assessment should trace business-critical workflows through the system and identify where changes become expensive or risky. That means looking beyond code style. Architecture, databases, infrastructure, deployment pipelines, external integrations, test coverage, observability, and security controls can all affect the cost of maintaining a product.

Tools can help establish part of that picture. SonarQube can surface code-quality and maintainability issues. GitHub CodeQL can identify certain classes of security vulnerabilities. Datadog or New Relic can show where production latency and failures occur. None of them can decide whether the company should spend millions replacing the platform.

That decision requires context.

The Old System Knows Things the Specification Does Not

One of the easiest mistakes to make in a rebuild is assuming that the visible product represents everything that has to be recreated.

It rarely does.

A mature application accumulates business rules over years of production use. A strange validation condition may exist because of an enterprise customer’s contract. An awkward billing workflow may handle an exception introduced six years ago. A scheduled database job that nobody wants to touch may reconcile records with a partner system that behaves differently from its API documentation.

Some rules live in source code. Others hide in database procedures, configuration files, integration mappings, support processes, spreadsheets, or even the knowledge of employees who have worked with the system for years.

This is why legacy system modernization requires more than identifying obsolete technologies.

A proper assessment maps critical business logic and dependencies before anyone decides what can be discarded. Engineers may need to inspect API traffic, database schemas, message queues, scheduled jobs, authentication flows, and infrastructure configuration. Product, operations, support, and compliance teams may know about edge cases that never made it into formal documentation.

Miss those dependencies and the company can end up with a technically cleaner application that does less than the software it replaced.

The problem often appears late. Happy-path features work during demos, while obscure but commercially important cases surface during migration or after customers start using the new platform.

Starting From Scratch Does Not Mean Starting Without Constraints

A greenfield project sounds like freedom: no old architecture, no obsolete framework, no accumulated technical debt.

The reality is less tidy. The new system still has to support existing customers, data, integrations, regulatory obligations, internal processes, and product commitments. It also has to coexist with the old platform until the transition is complete.

There is another risk. Once a rebuild begins, it is tempting to fix everything.

A team replacing a difficult monolith may decide that the new platform should use microservices. Then it needs service boundaries, API contracts, distributed tracing, more sophisticated deployment infrastructure, and a strategy for handling failures across services. Kubernetes might enter the architecture because the organization expects to scale, even though the current workload does not require that operational complexity.

Those choices can be justified. They also carry a cost.

Martin Fowler described the “Second System Effect” years ago: teams building a replacement can load it with ideas and capabilities that never fit into the first system. The technology changes, but the tendency to overdesign remains.

Technical due diligence should therefore challenge the proposed replacement architecture as seriously as it examines the old one. “Modern” is not a business requirement.

The Decision Is Usually Bigger Than Rebuild Versus Do Nothing

The most useful assessment may conclude that the company should keep most of the existing system.

If a few modules account for the majority of incidents or development delays, targeted refactoring can be enough. Teams might separate tightly coupled code, improve automated testing, replace an unsupported dependency, or address a database bottleneck without changing the overall product architecture.

A more substantial problem may call for incremental modernization. The Strangler Fig pattern, popularized by Martin Fowler, is one established approach: functionality is gradually moved out of the legacy application and into new components while the old system continues operating. Traffic and responsibilities shift over time instead of on one launch date.

That reduces the risk of a single large cutover, but it is not free. Running old and new components together creates temporary architectural complexity. Teams need clear boundaries, reliable integration between both environments, and a plan for retiring the legacy pieces. Without that discipline, “temporary” coexistence can last for years.

A full rebuild makes more sense when the constraints are systemic. The architecture may be unable to support expected transaction volumes. Core technologies may no longer receive security updates. Product changes may repeatedly require workarounds across most of the codebase. The data model itself may prevent the business from supporting new products or customer types.

The technical assessment should show which situation the company is actually facing.

The Rebuild Estimate Is Not the Rebuild Cost

Executives are often shown an estimate for building the replacement. That number can be misleading if it excludes the transition.

The existing product does not disappear while the new one is being written. Customers still need support. Security patches still have to ship. Critical features may still need development.

For a period, the company may effectively be financing two systems.

Data migration adds another layer of work. Records need to be extracted, transformed, validated, and reconciled. Authentication may need to move without locking users out. Third-party integrations have to be redirected or rebuilt. If the product processes financial, healthcare, or other regulated data, the migration may introduce additional compliance and audit requirements.

Then there is feature parity. If the new platform takes 18 months to build, the existing product is unlikely to stand still for 18 months. The replacement has to catch a moving target, or the company has to restrict development on the current system. Either option has a business cost.

A credible assessment puts those costs into the decision model. It should consider the engineering effort required to maintain both environments, migration work, infrastructure, testing, customer transition, training, and also the opportunity cost of engineers who cannot work on other priorities.

That gives executives a more useful comparison than “old system maintenance versus new system development.”

Slow Engineering Teams May Have a Process Problem

Architecture gets blamed for delivery problems because it is visible and technical. Sometimes the diagnosis is right. Sometimes it is convenient.

Imagine a company where a small feature takes three weeks to reach production. The codebase may indeed be difficult to modify. But what if the change spends four days waiting for manual QA, another three waiting for approval, and a week sitting in a release queue?

A rewrite will not fix that.

The same applies to reliability. Frequent incidents can point to poor system design, but they can also come from weak monitoring, unsafe deployment practices, missing regression tests, or inadequate incident response.

This is where engineering metrics become useful. Deployment frequency, lead time for changes, change failure rate, recovery time, incident history, cloud spending, and maintenance effort can show where delivery is actually breaking down. DORA metrics are commonly used to examine several of these aspects of software delivery performance.

The important point is causal: executives need to know whether architecture is producing the business problem they are being asked to fund.

Otherwise, the company can spend a large budget rebuilding its software and discover that releases are still slow.

A Useful Assessment Ends With Options, Not a Technical Scorecard

Executives do not need a 70-page report telling them that the codebase contains circular dependencies and outdated libraries. Those findings matter to engineers, but they are not enough to support an investment decision.

A useful assessment connects technical findings to consequences.

If an unsupported dependency creates material technology risk, what happens if the company leaves it in place for another two years? If a tightly coupled architecture slows product development, which parts of the roadmap does that affect? Or if the database is approaching a scaling limit, what growth assumptions would actually push it past that limit?

The recommendations should be equally specific.

A software architecture review might find that the business can get most of what it needs by replacing one subsystem and refactoring two others. Another assessment may show that incremental migration would cost more in the short term but reduce the operational risk of a one-time cutover. In some cases, a rebuild really is the least bad option.

There is no risk-free path. Refactoring preserves more legacy constraints. Incremental modernization creates a period in which two architectures have to coexist. A greenfield rebuild gives the team more freedom, but demands the largest migration effort and usually postpones some of the value until later in the project.

The assessment should make those tradeoffs visible rather than choose the most fashionable architecture.

Fund the Rebuild When the Evidence Supports It

Old software is not valuable because it is old, and replacing it is not progress simply because the new stack looks better on an architecture diagram.

The investment case has to connect engineering constraints with business consequences.

Before releasing a rebuild budget, executive teams should know which parts of the existing system are creating measurable problems, what business logic must survive the transition, how customers and data will move, and why less disruptive alternatives are insufficient.

Sometimes that evidence will make the case for a complete rebuild stronger. Sometimes it will turn a planned multimillion-dollar program into a much narrower modernization effort.

Both are useful outcomes of technical due diligence. The expensive mistake is deciding which answer you want before doing the assessmen