Start here
Keep the useful workflows in view. The scale of change should follow evidence about the current product and the work it needs to support next.
Name the constraint you need to remove.
A slow screen, a recurring fault and an unsupported dependency are different problems. A product that works reliably but lacks one feature needs a different assessment from a system that cannot be built or safely released.
Describe the affected workflow, who encounters the issue and the consequence for the business. Where possible, collect steps to reproduce the fault, examples of the workaround and the change you want to make. This gives the review something concrete to investigate.
- Which task fails or requires manual work?
- Is the problem limited to a component, or does it affect the whole workflow?
- What needs to keep operating while changes are made?
Establish whether the product can be worked on.
A handover assessment needs more than a demonstration of the running product. Code access, documentation, dependencies, environments and the release process affect what can be changed and tested.
Missing information is itself a planning issue. Establish which accounts and materials are available, whether the product can be built and which external services it relies on. Sensitive code and credentials should be shared only through an agreed access arrangement.
- Source code, build instructions and available documentation.
- Hosting, deployment and relevant account ownership.
- Dependencies, integrations and known operating constraints.
- Existing tests, test data and a suitable way to validate changes.
Compare three possible routes.
Maintenance and extension may fit when the current product can support the next requirement. The work might involve a targeted fix, a dependency update or a feature, followed by checks of the affected behaviour.
Refactoring or replacing a part may fit when a component is difficult to change but useful parts can remain. Define the interface between old and new parts, the behaviour to preserve and how compatibility will be checked.
A broader rebuild or migration may be appropriate when the required changes cannot be addressed practically within the existing setup. It still needs an inventory of business rules, data and integrations. Recreating the screens alone does not establish that the business workflow has been preserved.
Treat data and cutover as part of the work.
If records or workflows move, define the mapping, validation and transition plan. Identify which records must remain accessible, how corrections will be handled and what the team needs to do during the change.
Business continuity depends on the system and the selected route. Do not assume uninterrupted operation. Assess acceptable interruption, any parallel operation, release responsibilities and a recovery approach before agreeing the implementation.
Use the assessment to define a first stage.
The first useful outcome may be a focused fix, a documented assessment or a plan to replace one component. It should explain the condition of the product, the available options and the assumptions that still affect cost or timing.
A defined first stage gives you evidence for the next decision without treating a full rewrite as the starting commitment. Further development and ongoing support can then be scoped around what the assessment establishes.
Take the question into the next stage.
Start with the product, the main limitation and the change you want to make. Access and private technical materials can be discussed separately.
Discuss your project