Replatform, refactor or rewrite? Start with the decision, not the technology.

Technology decisions improve when teams separate the business objective from the implementation fashion. This field note is designed to make that decision easier.

Why the choice is harder than it looks

Modernization programs fail when teams treat architecture style as the decision instead of the consequence. The right path depends on business criticality, change frequency, operational risk, talent availability, integration constraints and how much of the existing behavior is actually worth preserving.

Replatform when the application is valuable but the operating foundation is the constraint

Replatforming is strongest when business behavior is still useful but runtime, infrastructure, deployment or supportability is holding the application back. The goal is to change the platform with limited changes to core business logic.

Refactor when the software can still earn its future

Refactoring makes sense when the architecture itself is blocking change, but the domain logic and product value remain strong. It requires enough testability and system understanding to change structure without silently changing behavior.

Rewrite only when preserving the old system is more expensive than recreating the value

A rewrite can be justified when the existing architecture, technology constraints and accumulated behavior make incremental change uneconomic. The risk is recreating years of hidden business rules, so a rewrite should be treated as a product and migration program, not a coding exercise.

Use a portfolio decision, not a one-application slogan

Most estates need a mix: retain some systems, retire others, replatform stable applications, refactor strategic ones and rewrite only where the economics justify it. Continuous modernization is usually more resilient than a single transformation event.