Establish what can be reproduced
Identify the deployed version and try to build the corresponding source in a separate environment. Record the runtime, configuration and external services it needs. If the source and deployed version differ, resolve that gap before attributing behavior to a particular change.
Check the main functions with representative records. Then list reproducible defects, dependency updates, query problems and requested interface changes separately. The steps and affected version make each defect testable.
Find the boundaries of a repair
A dependency update may require a different framework version or database driver. An external interface may no longer support the application’s existing request. Map these compatibility constraints before estimating how much code must change.
For any replacement, identify the records, permissions and connections it must preserve. Include data that does not fit the proposed schema. Decide whether components can change independently or need a coordinated transfer, and how the previous system could be restored.
Compare the work in each option
Use the same required behavior when assessing the options. Otherwise a small repair and a rebuild with extra features cannot be compared meaningfully. The following scope guide can help organize that comparison; it does not select an option for a particular application.
Scroll horizontally to view all columns.
| Option | Work to include |
|---|---|
| Repair existing components | Affected code, compatibility updates and regression checks |
| Replace one component | Interface changes, data transfer and temporary coexistence |
| Rebuild the application | Preserved behavior, migration, release sequence and recovery |