# Technical Discovery Before a Website or Software Rebuild > Before committing to a rebuild, use technical discovery to check what needs replacing, what is worth keeping and which evidence will help you choose. Canonical page: https://webvelopment.co.za/insights/development/technical-discovery-before-rebuild/ Language: en Development Before you commit to a rebuild, establish which problems require replacement and which might be solved with smaller changes. Technical discovery should give you evidence to compare those choices, including what each option preserves and what still needs checking. Webvelopment · 25 October 2026 “We need a rebuild” often bundles several frustrations into one request. Your team may struggle to update the website, depend on code they do not understand, or work around a process that no longer fits the business. Those problems can be connected, but they may need different remedies. We use technical discovery to investigate the questions that could change the build decision. You should come away able to explain why a particular change is needed, what you can keep and what further evidence is still missing. ## State the decision discovery must support Start by naming the choice you need to make. “Should we replace the application before adding this workflow?” gives an investigation a clearer purpose than “Tell us about our technology.” Other useful questions include which operating rules are embedded in the code, what must survive a website migration and whether an integration is available through authorised access. Then explain what would change with the answer. If the existing platform supports the required workflow, you may be able to retain it. If it cannot, replacement or other enabling work needs to enter the comparison. This keeps attention on uncertainties that affect scope, cost, responsibility or release risk, without asking discovery to define every future feature. ## Establish what is already valuable An awkward website can still have useful content, established URLs and customer routes worth preserving. An unfamiliar application may contain business rules that nobody has written down elsewhere. Ask staff to show both what frustrates them and what they rely on: a replacement brief needs to account for both. Bring the material you already have. We can use it to identify gaps rather than ask you to produce a complete technical history before the work starts. An inventory might cover: - Important customer or staff tasks. - Relevant pages, records and integrations. - Current accounts and responsible owners. - Available source code and operating documentation. - Known issues and examples that reproduce them. - Material that can be reviewed safely with approved access. For a reported fault, include the task someone was trying to complete, the steps they took and what happened instead. An example that can be reproduced is more useful than a general label such as “unreliable”. Agree where inspection or experiments may happen and how sensitive information will be handled before work begins. Providing an inventory does not authorise changes to the live system. ## Choose evidence that can answer the question Match the investigation to the question. A workflow interview can clarify who approves a change and what happens when it is rejected. A small prototype can let staff try an interaction. An authorised code review can identify implementation dependencies, while a controlled integration experiment can examine a particular connection. Be clear about what each method establishes. If a prototype shows that an editor can find and change a page, that answers an interaction question; it does not establish that the production system can publish it correctly. A brief code inspection is not a security certification, and a successful test with synthetic records leaves historical migration data to be checked separately. ## Record decisions and residual uncertainty The handover should make three things easy to find: what the evidence confirmed, what we recommend and what remains unknown. Link important findings to the material reviewed or the task observed, and name who needs to make the next choice. Someone comparing proposals should be able to follow the reasoning without having attended every discussion. | Question | Useful output | | --- | --- | | What should the first release complete? | A bounded workflow or customer journey | | What must be preserved? | An agreed content, data or behaviour inventory | | What depends on another party? | A dependency with an owner and next action | | How will the result be accepted? | Observable examples and review responsibilities | | What could still change the estimate? | Explicit assumptions and unresolved risks | Use the table to check whether the handover answers your decision. For example, “keep existing URLs” is incomplete until the relevant URLs are listed and someone can confirm the list. The amount of documentation should follow the work being assessed. ## Keep more than one outcome available Keep a targeted improvement, a configuration change and deferral in the comparison alongside replacement. Agreeing in advance that a large build must be the answer makes it difficult for the evidence to influence the investment. Compare options against the same problem. An editing improvement and a complete application replacement do different amounts of work; their proposals need to explain which needs each one addresses and which it leaves for later. For a website, the next phase may be [careful modernisation](https://webvelopment.co.za/solutions/website-modernisation/) with redirects and a release plan. For an operating process, it may be [custom software development](https://webvelopment.co.za/services/development/custom-software-development/) around an agreed first workflow. [Technical discovery](https://webvelopment.co.za/solutions/technical-discovery/) provides a smaller starting point for those decisions. [Discuss the uncertain part of your rebuild](https://webvelopment.co.za/contact/) with the current platform, the decision you need to make and the assumption that makes it difficult. ## Worked example: distinguish three different decisions Imagine an organisation whose website is difficult to edit and whose connected application is unfamiliar to the current team. Stakeholders propose replacing both. We would first separate the publishing problem, the application uncertainty and the connection between them. For the publishing question, choose one update an editor actually needs to make. Ask them to show how they find the content, change it and check the result. If they cannot complete the task, note where they get stuck. That gives the investigation something specific to examine: the editing interaction, the publishing behaviour or an operating rule that needs explaining. For the application question, select the next approved workflow and inspect the relevant area through authorised access. List any business rules it must retain. For the connection, identify what information must pass between the systems and test the agreed path with suitable material. Restricted data should only be used through the approved process, with access proportionate to the question. Now compare possible findings. A targeted editing change may solve the publishing problem. An application upgrade may be necessary before the next workflow can be added. The existing connection may already meet the requirement, or it may need separate work. None of those findings alone establishes that both systems need replacing. The handover should show how those findings affect the options. If an editing change is recommended first, say which publishing task it would address and which application questions remain open. If replacement is recommended, list the content, records and behaviour it must preserve. This hypothetical example illustrates how to reach a decision; it does not suggest that discovery always prevents a rebuild. ## Turn an uncertainty into a decision Before commissioning the next phase, check that each recommendation has evidence behind it. Use these questions to spot an assumption that still needs investigation: | Decision | Evidence to prepare | | --- | --- | | Can the platform support the change? | Inspect a representative workflow and the relevant integration or extension point. | | What must survive migration? | List the required URLs, records, assets and business rules, with a person able to confirm each. | | What happens next? | Choose a scoped experiment, incremental change or replacement proposal based on the findings. | Use these checks to [discuss the relevant delivery scope](https://webvelopment.co.za/solutions/technical-discovery/) or [bring a specific question to Webvelopment](https://webvelopment.co.za/contact/). ## Practical questions A few useful answers before you decide. ### What makes a discovery question worth commissioning? Its answer could change the scope, sequence or decision to proceed. Write down what you would do differently depending on the finding. For example, whether a platform can support an approved workflow matters if that answer determines whether you retain or replace it. Also identify who can make that choice once the evidence is available. ### How do we prevent discovery becoming open-ended? Agree the questions to answer, the evidence to examine and the areas that will remain uninspected. Review the findings against that agreement. If inspecting one workflow reveals an unrelated problem, explain its relevance and decide whether it needs a separate task before expanding the investigation. ### Can discovery end with a recommendation to do nothing yet? Yes. The evidence may support deferring a change or resolving a non-technical dependency first. The recommendation should explain why waiting makes sense, which risks remain and what needs to change before you reconsider. That gives you a usable next step even when no build follows immediately. ### Does an assessment require unrestricted production access? Not automatically. Identify the evidence needed and whether limited, synthetic or non-production material can answer the question. Your authorised owners approve access. An investigation should not collect sensitive information simply because broader access would be convenient. ### What should an options comparison include? Explain the problem each option addresses, the required work, dependencies, remaining risks and handover implications. Include what your staff would still need to do after the change. A smaller intervention may address an urgent editing task while leaving a wider application decision unresolved; the comparison should make that trade-off visible. ### How do we use discovery in procurement? Share the approved findings and scope assumptions with candidates where permissions permit. Ask them to identify the work included, who is responsible for dependencies and how completion would be demonstrated. Keep unresolved questions visible so candidates can explain their assumptions, rather than each pricing a different interpretation of the same brief. ## Implementation reference If the existing application uses PHP, consult [PHP’s current supported-version information](https://www.php.net/supported-versions.php) when reviewing its version and upgrade needs. The planning example above is Webvelopment’s general guidance; it is not a client case study. Planning guidance from Webvelopment Editorial. Confirm platform requirements and project assumptions before committing budget. Keep exploring ## Keep the right things connected. [Connected solutions ### Technical discovery before a costly commitment Work through uncertain code, data and integrations with focused technical discovery before deciding what to build, improve or keep.](https://webvelopment.co.za/solutions/technical-discovery/)[Start a conversation ### Let’s make the next move a useful one. Talk to Webvelopment about websites, software, digital marketing, creative services or development capacity.](https://webvelopment.co.za/contact/) Let’s move things forward ## Start a conversation Tell us what you are working towards. We’ll help you find a practical next step. [Discuss this planning question](https://webvelopment.co.za/contact/)