Compare options against the blocked business capability
Alternatives to legacy enterprise software include retaining a supported application, modernizing part of it, adopting SaaS or another packaged product, building a replacement and retiring a capability that is no longer needed. An old runtime is a constraint to investigate, not sufficient evidence that custom replacement is the best purchase.
Use one business workflow to compare the options. Include an exception path and the historical information users still need. Keep application change, infrastructure hosting and business-process change visible as separate decisions.
Use a retain, modernize, buy, build or retire matrix
| Option | Test before committing | Main remaining obligation |
|---|---|---|
| Retain | Supported operation can meet the requirement | Maintenance and acknowledged constraints |
| Modernize | A bounded change removes the blocker | Compatibility and coexistence |
| Buy SaaS or packaged software | Essential workflows fit with acceptable extensions | Migration, integration and vendor dependency |
| Build | Differentiating needs justify custom ownership | Delivery, operation and long-term maintenance |
| Retire | No required consumer or obligation remains | Approved data access and removal evidence |
Low-code sits within a buy-and-configure or build approach depending on its extension model. Test the hardest workflow and upgrade path. Rehosting may preserve useful behavior, but it is not a substitute for functional fit. Several choices can coexist within one portfolio.
Download the evaluation worksheet and record the owner, evidence and decision for each row. Its review fields are blank; it is a reusable template, not a completed assessment.
Run fit-gap analysis with real exceptions
For ERP, CRM, reporting or workflow replacement, record each required capability, its owner, frequency, exception and acceptance evidence. Classify it as standard fit, configuration, extension, process change or unresolved. An Access database or spreadsheet may contain a business rule that nobody has documented elsewhere.
Do not score only familiar screens. Demonstrate corrections, approvals, permissions, exports and failure handling. A rarely used period-end report can be essential. A SaaS replacement is attractive when required behavior fits the supported product model and the operating and exit terms are acceptable. Customization that recreates the old system's complexity needs a separate cost review.
Preserve data meaning and integration contracts
Map identities, keys, business states and authoritative writers. Reconcile records and business totals, including historical corrections and open work. Include identity-provider migration and tenant or role mappings where access changes. A row-count match alone cannot establish that a replacement can support the same decisions.
For retained history, define who can retrieve it, in what format and under which access controls. An approved export may satisfy a requirement without keeping the old runtime, but users must demonstrate the retrieval workflow. A parallel run needs a rule preventing duplicate external effects and an owner for differences.
Compare ownership cost and exit constraints
Include subscription or license fees, implementation, extensions, migration, integration, internal staffing, training and the overlap period. Model the usage and seat assumptions that change the result. A low initial subscription does not establish low transition cost.
Review data residency, access, security evidence, support, export formats and the consequences of ending the agreement. Assign the applicable obligation to its accountable reviewer rather than assuming that a product label establishes compliance. Vendor lock-in can arise from data, workflow extensions or operating knowledge. Identify which dependency would make a later exit difficult.
Accept the replacement before approving retirement
Build a transition plan with pilot users, training, reconciliation, cutover authority and stop conditions. Define how writes and customer actions during the transition will be handled. A rollback plan must remain valid for the data state reached, not just the old deployment package.
Approve retirement separately after consumers have moved, historical access works and the support owner accepts the result. The legacy modernization shortlist helps qualify implementation partners when the chosen path needs engineering. Keep the option decision in the RFP so vendors respond to the same problem rather than selling incompatible replacements.
Sources
Documentation checked .
Continue the conversation
Comments (0)