Editorial responsibility: AppMakelaar
Substantively updated:
Practical guidance from AppMakelaar, not independent research or a forecast of your results. External sources support the specific technical or privacy topics identified.
Establish the actual state
Record what demonstrably works, what users need and which blockers exist. Request a demonstration with representative data. A completion percentage without working features, tests or concrete criteria is insufficient for a decision.
Limit further damage
Agree how to handle production issues, access, a safe copy and knowledge preservation. A rushed rebuild can lose useful logic and exceptions. Inventory that knowledge before removing components.
Compare three routes
Compare targeted repair, incremental replacement and stopping or using standard software. For each option, describe remaining costs, dependencies, migration risks and maintenance. Money already spent does not make a future route sensible.
Replace incrementally where useful
Replacing a bounded component can provide learning without switching everything at once. Martin Fowler describes gradual replacement through the Strangler Fig pattern. Suitability depends on system boundaries and whether old and new components can temporarily coexist.
Agree a decision point
Choose a small, testable recovery result and decide when to continue or stop. Do not use a universal percentage of reusable code as the decision rule. Tests, architecture, business knowledge and remaining costs matter together.