Your system still runs the business. Orders go through, invoices are issued and customers receive updates. But changes take longer, integrations need more attention, and a small improvement can trigger work across several parts of the system.
One supplier recommends rebuilding. Another proposes upgrading the technology. A third suggests moving to a new platform.
Before comparing proposals, establish which problem each option would solve—and what your business would need to preserve, change or give up.
This article is for Australian business leaders, product leaders and technology decision-makers comparing an upgrade, rebuild or replacement for a system that still runs the business. The distributor example is illustrative and does not describe a Shinetech client engagement.
Migration describes moving an application, data or workload. Modernisation describes improving its technology, architecture or business capability. They can happen together, but they are not the same decision.
In this article, a legacy system mainly refers to a business application and the integrations, data and infrastructure it depends on. That is narrower than the broader term legacy IT used in some government guidance, which can also include hardware, operating systems and network equipment.
Legacy system modernisation is the process of improving, restructuring or replacing an existing business application and its dependencies while protecting the data, workflows and controls the business still needs.
The most useful first step is not to choose a technology. It is to identify which business rules are genuinely differentiating, which are workarounds, and which dependencies make change risky.
The Short Answer
Extension
An extension changes selected parts of an existing system without replacing its core business capability. Choose it when the system still supports the business and targeted integration, technology upgrades or component improvements can address its limitations.
Rebuild
A rebuild creates a substantially new implementation of required capabilities when the existing implementation has become too difficult to change safely. Choose it when tailored capabilities remain necessary, but the current implementation makes essential changes difficult to deliver and maintain.
Replacement
A replacement adopts another application or platform when it can meet essential requirements with acceptable configuration, integration, migration and operating costs.
Replacement does not always mean buying a standard SaaS product. It may involve adopting an industry platform, replacing a custom module with a packaged product, or moving to a new vendor while retaining selected integrations and data services.
Rebuild can cover several forms of re-engineering, from restructuring an existing application to creating a new implementation. AWS uses related labels such as refactor or re-architect for cloud work. The exact scope should be defined in the assessment rather than assumed from the label.
| Choose | When it usually fits | First evidence to collect |
|---|---|---|
| Extend | The system still supports essential workflows and targeted changes can solve the main problems | Integration gaps, support status and recent change history |
| Rebuild | The business needs unique capabilities, but the current implementation makes change risky or expensive | Dependency map, business rules and testability |
| Replace | Another platform can meet essential workflows without excessive customisation | Fit-gap test, migration scope and whole-of-life cost |
Review four things before committing: business fit, the cause of change difficulty, whole-of-life cost and transition risk. These choices can coexist within one system.
Which Business Capabilities Still Need to Be Preserved?
Short answerPreserve the rules the business needs, not every behaviour the old system contains.
Consider an illustrative example: a distributor uses a custom order system with customer-specific pricing, stock allocation and invoicing. Staff manually transfer information to an accounting platform, while customers call for delivery updates.
The manual work is visible. It does not yet establish that the order system needs replacing.
Ask operational users to demonstrate the workflow, including exceptions. Separate:
- Essential rules, such as negotiated pricing or credit controls.
- Standard functions another platform could provide.
- Workarounds caused by missing integrations or old technical limitations.
If the pricing and allocation rules still work well, improving accounting integration and customer updates may address the immediate problem. If a replacement platform can demonstrate those same rules with less ongoing complexity, replacement deserves consideration.
What to askWhich rules are essential to keep, and which behaviours are inherited workarounds?
What strong evidence looks likeEssential workflows, exceptions and dependencies confirmed by their business owners. Test replacement-product fit with representative, appropriately protected data—not just a standard demonstration.
Our article on why preserving every old behaviour can create migration risk explains how to distinguish necessary behaviour from inherited complexity.
What Is Actually Making Change Difficult?
Short answerSlow development is a symptom. It is not sufficient evidence that a system needs rebuilding.
Return to the distributor. Suppose adding an accounting integration takes longer than expected. The cause matters:
- No suitable interface: an integration layer may be enough.
- Unsupported framework: a technology upgrade may address that constraint.
- Pricing changes affect invoicing, stock and reporting unpredictably: deeper redesign may be necessary.
- Nobody understands the rules and testing is manual: the first task may be investigation and stabilisation.
What to askWhere did recent change effort actually go, what broke, and what was the business impact?
What strong evidence looks likeComponent support status, dependencies, and recent change examples showing where effort went, what broke and how the business was affected.
Shinetech’s legacy system services cover integration, technology upgrades, migration, takeover and re-engineering. These are different scopes of engineering work; the findings should determine which is appropriate.
Are You Comparing the Full Cost of Each Option?
Short answerCompare the cost of reaching and maintaining the required business outcome, not only the purchase or build price.
An extension estimate may exclude future maintenance. A rebuild proposal may assume business rules are already documented. A replacement subscription may exclude migration, integrations and changes to working practices.
For the distributor, the replacement price is incomplete until it accounts for pricing rules, historical records, accounting connections, staff training and the transition from the current system.
Compare options over the same planning period, including:
- Development, configuration and integration.
- Data preparation, migration and validation.
- Licences, infrastructure and ongoing support.
- Training, process changes and temporary workarounds.
- Parallel operation and retirement of the old system.
An inexpensive platform can become costly if it requires substantial customisation. A familiar system can also be expensive to retain if changes repeatedly cause incidents or manual reconciliation.
What to askWhat is included, excluded and assumed in each estimate over the same planning period?
What strong evidence looks likeComparable scope, exclusions, recurring costs, and assumptions that could materially change the estimate.
Can You Make the Change While Keeping the Business Working?
Short answerThe proposed end state and the transition to it need separate scrutiny.
For the distributor, moving customer records is only part of the transition. Open orders, reserved stock, partially fulfilled deliveries and invoice corrections also need an agreed handling process.
Incremental replacement can allow parts of a system to change while others remain in use. Microsoft’s Strangler Fig pattern describes this approach and its limitations, including managing coexistence between old and new components.
Running two systems does not prove they agree. That execution question belongs with why dual-running needs reconciliation, not with the initial extend / rebuild / replace choice.
In this illustrative scenario, retaining the order core while improving integrations is one possible outcome—not a predetermined recommendation. Unmanageable security risks, structural constraints or a demonstrably better platform could change the decision.
What to askWhat must keep operating during the change, and who owns the system if validation fails?
What strong evidence looks likeA transition outline with dependencies, acceptance criteria, operational ownership and recovery arrangements.
Compare the Options Before Approving One
| Option | Use it when this evidence exists | Challenge it when |
|---|---|---|
| Extend | Business fit remains strong; targeted integration, technology upgrades or component improvements can address the limitations; support risks and ongoing costs are manageable | Essential changes repeatedly destabilise other functions, or underlying support and security risks remain unresolved |
| Rebuild | Tailored capabilities remain necessary; assessment identifies structural constraints; required behaviour can be defined and tested | The recommendation rests mainly on technology age, while business rules and scope remain unclear |
| Replace | An alternative demonstrates essential workflows and exceptions; integration, transition and ongoing costs are understood | Fit rests on a sales demonstration, with substantial customisation or operational compromises unexplored |
Missing evidence may justify a focused investigation before implementation.
Australian Considerations
When assessing a legacy system in Australia, also confirm:
- Data location: where customer, employee and operational data is stored and processed.
- Offshore access: whether development or support involves personal or sensitive information.
- Australian requirements: whether a replacement platform can support the invoicing, tax-related workflows or industry-specific requirements the business actually uses.
- Vendor access: which vendors, subcontractors and cloud providers can access production data.
- Operating responsibilities: how access control, incident response and data-retention duties would change.
- Contracts: whether they cover intellectual property, confidentiality and source-code access.
These issues may require advice specific to the business, industry and data involved. Our article on offshore IP and data protection considerations covers the access and ownership questions in more detail.
Australian Signals Directorate guidance is primarily intended for Australian Government entities, but it provides useful considerations for other organisations assessing unsupported technology. It discusses replacement, interim mitigations, incremental approaches and whole-of-life cost. These considerations do not mean every business application should be replaced immediately; they indicate why support status and security risk should form part of the decision.
When a Technical Assessment Comes First
A useful next step is often investigation, not implementation. Use a light assessment to see where evidence is missing:
| Assessment area | Key question |
|---|---|
| Business capability | Can the system still support the workflows that differentiate the business? |
| Changeability | Can the team modify it without unpredictable side effects? |
| Security and support | Are the application, framework and infrastructure still supported? |
| Economics | What will each option cost to implement, operate, support and change over the same planning period? |
| Transition feasibility | Can the business change it without losing control of data and operations? |
The result is not an automatic score. It identifies where evidence is missing and which option deserves a more detailed assessment.
A useful assessment should produce a decision record, dependency map, prioritised risk list, comparable cost assumptions and a transition outline—not just a recommendation to rebuild or replace.
Assessment comes first when:
- Business rules have no clear owner.
- Source code, interfaces or dependencies are incomplete or poorly understood.
- The system has little reliable automated testing.
- A proposal rests mainly on system age or technology fashion.
- A replacement platform has not been tested with representative, appropriately protected data and exception workflows.
- Cost estimates contain material unconfirmed assumptions.
The purpose is to establish which option the evidence supports—or whether more than one option should apply to different parts of the system.
Questions to Ask Before You Approve
Ask a development partner to walk through one real workflow—not a generic architecture slide—and answer:
- Fit: Which capabilities still need to be preserved, and which behaviours can be retired?
- Cause: What is actually making change difficult, evidenced by recent work rather than system age?
- Cost: What is included, excluded and assumed over the same planning period?
- Transition: What must continue operating, how will outcomes be verified, and what happens if validation fails?
- Ownership: Who will maintain retained components, support the transition, and continue development afterwards?
What evidence supports your recommendation, and what finding would make you recommend a different approach?
A useful answer connects the work to your actual constraints. It explains what should remain, what should change, what is unknown and what needs testing next.
Before approval, capture those points in a short decision record covering the alternatives, cost assumptions and operational responsibilities.
Not ready to discuss a project? Use the questions above to prepare an internal assessment.
Frequently Asked Questions
Does moving to the cloud remove the need to modernise the application?
Not necessarily. A hosting change may address infrastructure problems while leaving application design and workflow constraints intact. AWS uses the 7 Rs to describe cloud migration approaches, including rehosting, replatforming, repurchasing and refactoring. That terminology is useful, but it should not replace a business-fit and transition assessment.
Can we modernise while continuing feature development?
Potentially, if dependencies, capacity and releases can be managed together. The plan should identify shared components, testing requirements and responsibility for maintenance and customer support. Dividing work into phases does not remove those obligations.
Can some parts of a system be extended while others are rebuilt or replaced?
Yes. These choices can coexist within one system. Phased delivery describes how the work is implemented; it does not determine which option is right for each part.
Does slow development mean the system needs to be rebuilt?
Not by itself. Slow development is a symptom. The cause may be a missing interface, an unsupported framework, entangled business rules, or undocumented behaviour. A new codebase will not automatically resolve unclear requirements or weak ownership.
Discuss What Your Existing System Needs Next
Whether the next step involves connecting existing systems, upgrading technology, taking over maintenance or rebuilding constrained components, it should address a defined business need.
Not sure whether your system needs integration, re-engineering or replacement? Discuss a focused legacy system assessment with Shinetech to identify the constraints, evidence gaps and practical next step.
Discuss a focused assessment →
Read what our clients say about working with Shinetech on Clutch.
Related reading: why preserving every old behaviour can create migration risk · why dual-running needs reconciliation · why migration risk is rarely just technical · post-go-live ownership in legacy migration · why migration timelines should be built around risk visibility
Sources
- Australian Signals Directorate. Managing the risks of legacy IT: practitioner guidance. Replacement, interim mitigations, incremental approaches and whole-of-life cost.
- Microsoft Azure Architecture Center. Strangler Fig pattern. Incremental replacement and coexistence between old and new components.
- AWS Prescriptive Guidance. Migration strategies. Cloud-migration 7 Rs, including rehosting, replatforming, refactoring and repurchasing.
- Shinetech Software. Legacy system services. Integration, technology upgrades, migration, takeover and re-engineering scopes.
This article provides practitioner guidance for comparing extend, rebuild and replace options. It is not a government framework, scoring model, or legal, financial or compliance advice.