EXPLORE THE WORKFLOW
From an inherited system to an informed decision.
1. Confirm ownership
Establish ownership of the project’s source code and scripts, rights to modify it, and full administrative control of hosting, servers, databases, and deployment. A login to the application alone is not a complete handover.
2. Investigate the system
Reproduce the issue in a suitable test environment. Review dependencies, integrations, configuration, and the available documentation before estimating the impact of a change.
3. Compare the routes
Consider a targeted repair, an extension of the existing product, or a replacement. Compare the business fit, maintainability, migration effort, and ongoing support needed for each realistic option.
4. Test the transition
Verify the chosen change against the important business workflows. For a migration, agree data checks, cutover ownership, and recovery steps before switching production traffic or records.
Step 1 of 4
A viable route is identifiedConfirm the scope, responsibilities, and quotation.
Ownership or access is incompleteResolve the handover before modification work begins.
Three options to assess
| Route | When it may fit | What still needs checking |
|---|---|---|
| Repair | A specific failure exists in an otherwise suitable system. | Root cause, affected workflows, and regression risk. |
| Improve | The foundation fits, but a defined feature or integration is missing. | Extension points, maintainability, and compatibility. |
| Replace or consolidate | The current product no longer meets the business need. | Data migration, training, integrations, and transition effort. |
On smaller screens, scroll across the table to compare columns.
A low initial repair estimate can be misleading if the underlying problem is architectural or poorly understood. A replacement can also be disproportionate when the issue is isolated. Investigate before choosing either path.
What a complete handover includes
- Source and build: the full project, scripts, dependencies, and available instructions for creating a working deployment.
- Infrastructure: administrative control of hosting, servers, databases, domains, and the deployment environment.
- Connected services: an inventory of external integrations, scheduled jobs, and their account owners.
- Business context: the critical workflows, known issues, and an example of the expected result.
For BYMTECH’s premium work on software built by another provider, the business must own the source code and scripts and hold the rights to modify and redeploy them. Third-party components and services must also be reviewed for their applicable terms and access requirements.
Why this work is priced differently
Taking over unfamiliar software involves investigation before a reliable implementation estimate is possible. We may need to reconstruct setup steps, reproduce an intermittent bug, or discover a dependency that is not documented.
BYMTECH treats this as a premium service, priced higher than standard development. Feasibility, scope, and cost follow a technical review. Ownership makes assessment possible; it does not guarantee that every system can be repaired economically.
Plan replacement and merging around the data
When combining systems, decide which one is authoritative for each type of record. Map identifiers, remove duplicates deliberately, and agree how conflicting values will be handled. Do not assume two similarly named fields mean the same thing.
Microsoft’s migration planning guidance illustrates the need to inventory dependencies, access, critical workflows, and existing operating expectations. The same assessment questions are useful when planning a smaller business-system transition, even when Azure is not involved.
Test a copy of representative data first. Define the final migration window, how recent changes are reconciled, who verifies the result, and what recovery remains possible once new records have been written.
Start with an assessment brief
Describe what is failing, when it happens, and how it affects work. Include the application’s technology if known, who currently hosts it, and whether the complete source is available. Screenshots with sensitive details removed can help explain an issue.
Keep credentials out of an initial enquiry. Once the project is assessed and access arrangements are agreed, use an appropriate controlled handover. This lets the conversation begin with the business problem and the evidence needed to evaluate it.
Further reading
Official references for the concepts in this guide. The workflow examples are illustrative; the design for your business depends on its systems, access, and operating requirements.