Rewrite the legacy system or modernize incrementally?

Separate the problem from the request for a rewrite

Old code alone is not an investment case. Write down the concrete trigger: Does a new customer require stronger data isolation? Does a workflow fail repeatedly? Is it difficult to release a small change? The same symptom can have different causes.

If delivery is slow, distinguish code dependencies from missing tests, environment setup or time spent waiting for decisions. A new application will not automatically solve the latter three. First describe the behavior you want to change and how you will observe it.

Compare the options using the same questions

This table is a framework for assessment, not an automatic decision rule. Weigh an advantage in one row against costs elsewhere. Treat “we don’t know” as investigation work that belongs in the scope.

Evidence to gather before estimating budget and schedule

An initial review should examine operations, data and delivery as well as code quality. Record the source of each finding and what remains unknown:

• Behavior inventory. Business-critical flows, rare exceptions, scheduled jobs and external integrations. A task without a visible screen still belongs in the migration scope.
• Dependency map. Applications updating the same tables, shared authentication, file exchanges and components called during a transaction.
• Current operational evidence. Support records, failure examples, waiting times and deployment history. Keep a rough impression separate from a measured problem.
• Behavior to preserve. Repeatable checks for critical inputs and expected outputs. Agree with the product team which existing behavior is a requirement and which is a defect.
• Team and access conditions. Access to code, environments and data; people who know the system; and who will operate the transition alongside current work. An inaccessible area has not been reviewed.

What does incremental modernization mean in practice?

Martin Fowler’s Strangler Fig approach describes transferring responsibilities from an old system to a new structure over time. Investment and value can become visible in stages instead of relying on one large cutover. The approach does not make modernization easy or guarantee success. Martin Fowler: Strangler Fig.

For the first step, choose a workflow the team can understand and whose results it can verify. Each step should produce usable functionality or resolve a specific uncertainty. Building new infrastructure alone is not enough evidence that the migration is progressing.

Coexistence can be the hardest part of the transition

Microsoft’s architecture guidance highlights the temporary routing layer’s operating costs and its potential to become a bottleneck or single point of failure. Shared data stores and dependencies in both directions also need attention. The transition layer is itself a system to design and observe. Microsoft Azure Architecture Center: Strangler Fig pattern.

• Which system is authoritative for a record? If both can change it, who resolves conflicts?
• Will retrying a request repeat the operation? How will you compare the old and new flows’ results?
• If the new path fails, is rerouting traffic enough, or does data also need correction?
• What allows the temporary adapter and old flow to be removed? Is someone responsible for that work?

When does a rewrite deserve serious consideration?

For a small application with well-understood boundaries, verifying all behavior and preparing one cutover may be practical. “The new technology is cleaner” does not explain scope, migration or ownership. Ask a rewrite proposal to include the old system’s retirement plan as well as development of the new application.

Do not assume incremental change is automatically right either. The intervention needed to separate old and new paths may exceed the available budget or time. Use a bounded technical investigation to test whether separation is feasible. If the result remains uncertain, do not present the delivery plan as settled.

AWS guidance warns that decomposing a system before understanding the business domain can produce unsuitable service boundaries and added cost. The first decision need not be how many services to build. Understand responsibilities and dependencies first. AWS Prescriptive Guidance: Strangler fig pattern.

Example: before extracting report generation

This is a hypothetical SaaS example to illustrate decision steps, not a client case study.

Imagine that a report generated inside an application takes too long. Start by defining which report must complete within an acceptable time under which conditions, before deciding to build a reporting service. A suggested review sequence:

1. List representative reports and permission rules. Explain which data and point in time each result represents.
2. Measure whether the delay comes from queries, computation or file generation. Include a narrow improvement to the existing application as an option if it can solve the problem.
3. If a separate flow is needed, compare trial outputs with current outputs. Check content and authorization correctness as well as whether a file was produced.
4. Write down failure, retry and rollback steps before exposing the new path to limited use. Define how to prevent an output from being sent to a user twice.
5. Transfer responsibility when agreed checks pass. Close the removal of the old scheduled job, query or screen as a separate task with an owner.

Agree on continue and stop conditions upfront

After the first part is complete, look beyond whether the new code runs. Has product behavior been preserved? Is the operating burden understood? Can the team own the flow? If acceptance criteria are not met, investigate before expanding scope. Decide each subsequent step using evidence from the previous one.

Prepare a one-page decision brief

• The business problem and behavior to preserve
• Options assessed and reasons for rejecting alternatives
• Verified findings and open assumptions
• The first step, its owner and acceptance criteria
• Conditions for cutover, rollback and retirement