Legacy software modernization starts with a business decision: which parts of the current system should remain, change or be replaced? An old application that supports its users reliably may need targeted maintenance. A newer application can still need substantial work if it prevents necessary changes or depends on unsupported components.
This guide is for companies commissioning an assessment or comparing modernization proposals. Its purpose is to help define a transition that can be tested, funded and operated. It does not assume that a full rewrite, cloud migration or new ERP is the right answer.
Establish why the system needs to change
Collect examples of work the current system cannot support: a required integration, a recurring reconciliation problem, a release that cannot be tested or a dependency that no longer receives security fixes. Record the affected process, frequency, business owner and current workaround. Separate a confirmed problem from a requested improvement.
Choose a measurable outcome for each priority. For example, measure how many sales orders staff re-enter into another system during an agreed period. A target can then address that specific duplication. “Use modern technology” does not provide an acceptance condition.
Compare the options against the same workflow
Microsoft distinguishes retaining, retiring, rehosting, replatforming, refactoring and rebuilding applications. These are different interventions with different scopes; moving an application to new infrastructure is not equivalent to redesigning its workflow. See the application modernization strategies.
Use the following comparison as a starting worksheet, then validate it against your system.
| Option | Evidence to request before approval | Cost or constraint to investigate |
|---|---|---|
| Retain and stabilize | Supported dependencies, reproducible releases and tested recovery | Continuing maintenance and unresolved limitations |
| Improve selected components | A demonstrated boundary around the problem and tests for existing behavior | Coupling to code that will remain |
| Replace with an ERP or another product | Your normal and exception workflows demonstrated in the proposed configuration | Licences, extensions, upgrades and operating changes |
| Replace functionality incrementally | A workable handover between old and new components | Temporary integrations and operating two systems |
| Replace the whole application | Complete scope, migration rehearsal and an acceptable interruption plan | Hidden rules, cutover risk and training |
An ERP implementation may fit standard business processes, while custom software may address a workflow that available products cannot reasonably support. Compare both against the same scenarios. Avoid rebuilding a routine capability solely because it exists in the old application.
Create an inventory that suppliers can verify
Prepare a system map covering applications, databases, file stores, scheduled jobs, exports and connected services. Include spreadsheet work and manual corrections. Confirm access to the source repository, deployment configuration and documentation, and establish your contractual rights to modify or replace each component.
For every integration, record the owner, business identifiers, permitted operations and failure handling. Ask users for exceptions that rarely appear in a demonstration: cancelled orders, duplicate imports, corrections after approval and users changing roles. Classify each rule as required, obsolete or still needing a business decision.
Use anonymized examples for early supplier discussions. Production credentials and customer datasets are not necessary for an initial scope conversation.
Check whether incremental replacement is feasible
The Strangler Fig pattern moves selected functionality to a replacement while the existing system continues serving the rest. It needs a usable way to route or separate work. Microsoft notes that it may be unsuitable when there is no changeable integration point or when the old system must be retired quickly. See the pattern and its constraints.
Ask the supplier to identify the exact transition boundary. “We will migrate module by module” is incomplete if every module writes directly to the same tables. The proposal should explain which components can change independently, what adapters are temporary and when they can be removed.
Illustrative pilot: sales-order approval
Consider a hypothetical company that wants a new approval interface while retaining its existing invoicing system. This is a planning example, not a Tarawud customer result.
Define one pilot group, the approval states and which system creates the authoritative order identifier. Specify who owns each editable field. Where practical, keep one authoritative writer for each field or transaction; if both systems must write, require an explicit conflict-resolution and reconciliation design.
Test an approved order, a rejected order, an edit during approval, a repeated request and an unavailable invoicing service. The user needs a visible pending or failed state and a recovery procedure. A successful screen submission alone does not prove that the receiving system recorded the order.
Before expanding, reconcile the agreed records and verify access permissions with the process owner. Keep evidence of exceptions and corrections, not just totals from the happy path.
Define what rollback actually means
Reverting application code may not reverse data transformations or actions already sent to another system. Restoring yesterday's backup can also discard today's valid work. Ask for separate procedures for application rollback, data correction and recovery of external transactions.
The cutover plan should state when editing stops, how final changes are transferred, which checks permit launch and who can postpone it. Rehearse restoration and reconciliation with representative data. Specify how staff continue essential work during an interruption and how that work is entered afterward.
Request a decision record and a complete estimate
Ask each supplier to provide the recommended option, rejected alternatives, evidence still missing and the first deliverable that reduces uncertainty. Separate assessment, implementation, data preparation, integrations, temporary infrastructure, licences, training and ongoing support in the estimate. Unknown data quality or undocumented integrations should appear as assumptions to investigate.
Agree the evidence required to retire the old system: reconciled data, operational reporting, user acceptance, access ownership, support arrangements and a usable archive where needed. A launch date alone does not establish that those conditions are met.
To discuss an assessment with Tarawud, share your current system, its main limitation and the business workflow you need to improve through the contact form. For broader project preparation, read the digital transformation planning guide.
