A company needs to change suppliers, the internal team that developed the product has left or a project has been stalled for months and someone needs to restart it. The request to the incoming team sounds straightforward: review the code, determine what remains and provide a budget for continuing the work.
The repository exists. There is also a list of pending features, several documents and an application that works, at least under certain conditions. From the outside, the task may appear to consist of learning the technology and starting on the backlog.
The code, however, explains only part of the project. It may not reveal who controls the infrastructure, how a release reaches production, which data can be trusted, why particular rules exist, what customers have been promised or which supplier maintains an essential component.
It may also describe accurately what was built months ago without reflecting what the business needs today. The scope may have changed, temporary solutions may have accumulated and important manual processes may never have appeared in the repository.
Taking over a development project means recovering control, context and the ability to make decisions. Reading the code is part of that work, but it is not enough to promise dates, agree a fixed budget or decide what should happen next.
Why a project changes when it moves to another team
The previous team did more than write code. It also held an interpretation of the product: which areas were priorities, which incidents could wait, which exceptions the business accepted, how changes were released and whom to contact when an external service failed.
Some of that knowledge will be documented. Other parts will be scattered across conversations, tickets, emails, spreadsheets and decisions that were never formally recorded. There will also be information people consider obvious because they have worked with it for months.
When the team changes, that context does not transfer automatically. The incoming supplier may have access to the code and still not know:
- Which features the company actually uses.
- Which business processes depend on the system.
- Which areas are complete and which only appear to be complete.
- Which failures are known and how they are currently handled.
- Which technical decisions reflect a real constraint.
- Which commercial or contractual promises shape the roadmap.
The takeover needs to turn this fragmented knowledge into a verifiable view of the project. Until that happens, any estimate will depend on assumptions that have not yet been tested.
The first layer: assets, ownership and access
Before assessing code quality, the incoming team must establish whether the company controls the assets required to operate the system. A complete repository has limited value if nobody can access production, renew the domain, administer the database or recover an external account.
The review should identify at least:
- Code repositories and active branches.
- Servers, hosting and cloud services.
- Domains, DNS and certificates.
- Databases and storage systems.
- Transactional email, payment, analytics and monitoring accounts.
- Third-party APIs, integrations and credentials.
- Licences, subscriptions and billing accounts.
- Backups and recovery mechanisms.
For every asset, the team needs to know who owns it, who can administer it, how access can be recovered and what would happen if the previous supplier stopped cooperating immediately. The company should also distinguish what it owns, what it uses under licence and which components are subject to specific conditions.
In some projects, accounts were registered using personal email addresses belonging to the previous team or created inside an organisation shared with other clients. In others, the client pays for the service but cannot administer it. Resolving these dependencies may be more urgent than adding any new feature.
The second layer: architecture and infrastructure
Once the assets are under control, the incoming team needs to understand how the system works as a whole. The repository may contain the main application while excluding scheduled tasks, server configuration, integrations created directly within an external platform or processes running from another tool.
The review should identify the components, their dependencies and how information moves between them. It should also establish how development, testing and production environments are separated, how each one is configured and which steps are required to release a version.
Several initial questions are particularly revealing:
- Can the project be installed and run outside the original developer’s computer?
- Are the required dependencies and configuration variables identified?
- Is there a release process another person can repeat?
- Can a deployment be rolled back if something fails?
- Where are errors recorded, and who receives alerts?
- Can the backups be restored?
- Which components are obsolete or approaching the end of support?
The purpose at this stage is not to redesign the architecture. It is to understand what exists, what supports production and which changes could interrupt the service. A technically sensible improvement can be a poor first decision if it affects a dependency the new team has not yet discovered.
The third layer: business logic and real processes
The code contains rules, validations and calculations, but it does not always explain why they exist. A condition that appears redundant may reflect a contractual requirement. A field that never appears in the interface may feed an external report. A manual task may compensate for an exception the system does not handle.
The technical review therefore needs to be combined with conversations with the people who use and operate the product. The team should follow the main processes from beginning to end and compare what is expected with what actually happens.
This layer includes questions such as:
- Which business problem does each important flow solve?
- Who starts the process, and who needs its result?
- Which decisions are made by the system and which by a person?
- Which exceptions appear frequently?
- Which tasks are completed outside the application?
- Which information is corrected in spreadsheets, email or other tools?
- Which parts of the system are critical to sales, invoicing, service or operations?
Without this information, the incoming team may remove something the business still needs, preserve a temporary workaround as if it were permanent or estimate a feature without understanding every process it affects.
The fourth layer: data, migrations and sources of truth
Data often retains part of the project’s history that documentation does not show. Duplicate tables, incomplete fields, unused states and inconsistent relationships can reveal changes in direction, partial migrations and processes that evolved without the whole model being updated.
Before changing the structure or promising a migration, the team needs to understand the volume, quality and use of the data. It must also establish which system acts as the source of truth when the same information appears across several platforms.
The review should determine:
- Which information each system contains.
- Which data is personal, confidential or critical.
- Which validation rules apply when records are created or changed.
- Which processes synchronise data with other platforms.
- Which inconsistencies or duplicates are already known.
- Which historical information must be retained.
- How backups and restorations are performed.
- What could happen if the current model is changed.
An application can compile successfully while containing a serious data problem. It can also hold valid information within a structure that is difficult to evolve. These are different situations and require different decisions.
The fifth layer: quality, security and ability to change
Reviewing an inherited project is not an exercise in scoring the previous team’s coding style. The goal is to determine how confidently the system can be changed.
Automated tests help, but their absence does not prove that everything needs to be rewritten. The incoming team should establish which critical areas are covered, which behaviours can be verified in other ways and how much risk is involved in changing each component.
The review should also consider error handling, permissions, external dependencies, overdue updates and the exposure of sensitive information. It needs to understand how access is granted, where credentials are stored and what traceability exists for important actions.
Some areas will need tests before they can be changed safely. Others may first require documentation of their current behaviour. In certain cases, part of the system will need stabilising before backlog development continues.
The result should explain what can be changed safely, which areas need additional protection and where uncertainty must be reduced before further work can be estimated.
The sixth layer: backlog, incidents and existing commitments
A list of pending tasks does not always represent the true state of a project. It may combine defects, improvements, ideas, commercial commitments and requests that are no longer priorities. It may also mark features as complete even though they were never validated in production.
Before using that backlog as the basis for a budget, the incoming team should review:
- Which tasks are still required.
- Which requirements have clear acceptance criteria.
- Which incidents currently affect users or operations.
- Which items depend on changes not yet included.
- Which commitments have been communicated and to whom.
- Which dates reflect a real obligation.
- Which work has already started and what state it is in.
A task described as “finish the ERP integration” may involve decisions about data, retries, permissions, invoicing and failure handling. Another called “fix the form” may affect multiple versions, languages or connected systems.
The incoming team needs to reconstruct the scope before converting the backlog into a timeline. Otherwise, the estimate may appear precise because it contains hours and dates while still being based on incomplete definitions.
The seventh layer: people, suppliers and concentrated knowledge
Systems depend on people and companies that do not appear in the repository. There may be a supplier managing infrastructure, an administrator correcting data, an external specialist maintaining an integration or a client who approves every change before release.
The takeover should identify who understands each area, what responsibility they hold and what availability they can offer during the transition. Where possible, speaking to the outgoing team can recover important information about risks, frequent incidents, procedures and pending decisions.
The conversation is more useful when it seeks facts than when it becomes a judgement about whether the project is good or bad. Asking what they would change first, which area they would avoid touching without tests, which process creates the most incidents and what depends on one person usually produces better information.
Contracts, licences, support arrangements and third-party services also need review. A technically stable component can become a risk if its agreement is ending or if the incoming team cannot contact the supplier that maintains it.
Why promising a fixed date or budget at the beginning creates risk
The company needs predictability, and the new supplier needs to define the scope of its responsibility. Asking for a date and budget in the first conversation is understandable. The problem arises when a fixed figure is presented before the assets, architecture, data and backlog have been verified.
To produce that figure, the supplier would need to assume that the documentation is current, the code can run, the necessary access exists, the tasks are clearly defined and the dependencies are as expected. If one of those assumptions is wrong, the options are to increase the budget, reduce the scope or absorb a cost that will eventually affect the relationship and the quality of the work.
A premature estimate creates risk for both parties. The client may make decisions using a figure that does not represent the real state of the system. The supplier may commit to work it cannot yet size responsibly.
It is possible to provide an initial framework, a defined scope for the evaluation and, when enough information is available, conditional ranges. A detailed budget and timeline for the next stage should be based on the evidence gathered during the assessment.
What the initial takeover phase should produce
The assessment should not end with a general description of the code. It needs to create information that supports decisions and action.
Its outputs should include:
- An inventory of assets, access and owners.
- A map of components, systems and integrations.
- A description of critical processes and their relationship with the technology.
- The main technical, operational and continuity risks.
- Incidents requiring immediate stabilisation.
- A review of the backlog and existing commitments.
- Dependencies on people, suppliers and licences.
- A prioritised proposal for stabilising, maintaining and evolving the system.
- The assumptions and boundaries used to prepare the next estimate.
Not every project needs a long report. Every project does need a shared view of its starting point and a clear explanation of what is known, what remains uncertain and what must happen before development accelerates.
Stabilise before accelerating
The company may begin the supplier change with urgent features, waiting customers and a team exhausted by delays. The pressure to start building immediately is real. Adding changes to a system that cannot yet be released, observed or recovered safely, however, increases its fragility.
The first priority may be to recover access, test backups, document releases, resolve a critical incident or add traceability. These tasks do not always produce a visible feature, but they create the conditions for later work to become more predictable.
Stabilisation does not necessarily mean stopping all development for months. Urgent needs can be handled while uncertainty is reduced, provided the team distinguishes essential work from changes that can wait until the system is better understood.
The right sequence depends on risk: first control anything that could interrupt operations, lose data or block the team, and then continue with features from a more reliable foundation.
Continue, modernise or rebuild
An inherited project does not automatically need a rewrite. Even a difficult system may contain years of business logic, integrations and exceptions that would be expensive to reproduce. Starting again creates risks of its own, including data migration, coexistence between versions, loss of useful behaviour and a long period before reaching the functionality already available.
In other cases, continuing to add changes may be unsustainable. The technology may no longer be supported, the architecture may prevent necessary development or the cost of validating every modification may be too high.
The decision should be based on evidence. The business needs to compare the importance and condition of each component, the cost of maintaining it, the ability to test it and future requirements. The outcome may be to continue, stabilise, modernise in stages, replace selected components or plan a controlled rebuild.
The initial assessment does not need to solve the entire future of the product. It does need to prevent a technical preference from becoming the strategy before the system has been understood.
What the company can prepare before the team changes
The transition will be more efficient if the company gathers the available information before the incoming supplier begins. Perfect documentation is not required.
Useful material includes:
- Previous contracts, quotations and scope documents.
- Repositories, accounts and administrator credentials.
- Invoices for infrastructure, licences and external services.
- Backlogs, incident records and functional documentation.
- Diagrams, manuals and release procedures.
- Backups and recovery policies.
- People who understand day-to-day operations.
- Commitments made to customers, users or management.
It also helps to provide an honest explanation of why the change is happening. Taking over a stable product after a reorganisation is different from recovering a stalled development after months of conflict. That context determines which checks should be prioritised.
Taking over a project means recovering the ability to decide
The takeover is complete when the incoming team can understand, operate and change the system with a known level of risk. Reaching that point requires more than access to the code. It requires control of the assets, an understanding of the architecture, knowledge of the processes, visibility over the data and clarity about responsibilities.
At Pibeca, we take over and evolve digital platforms and products created by other teams. Where the project involves CRM, ERP, ecommerce or other business systems, we also review its integrations and automation as part of the complete operation.
If you need to change suppliers, recover a stalled development or understand the true state of a platform before investing further, we can begin with a diagnostic conversation.
The first responsible promise is not an exact delivery date. It is a clear explanation of what needs to be reviewed before an inherited project can move forward under control.
Frequently asked questions about taking over a software project
What does a new team need to take over a software project?
It needs access to the code, infrastructure, data, external services and available documentation. It should also understand the current objectives, business processes, incidents, backlog, existing commitments and the people or suppliers involved in operating the system.
How long does it take to assess an inherited software project?
It depends on the size and importance of the system, the quality of the documentation, the number of connected platforms and the availability of access and knowledgeable people. A small, well-documented product may be reviewed quickly. A critical system with several integrations, sensitive data and fragmented knowledge requires a deeper assessment. The diagnostic scope should be agreed before work begins.
Can a fixed budget be provided before reviewing the code?
The evaluation phase can have a fixed price when its scope is defined. Fixing the budget for the entire development before reviewing the code, infrastructure, data and backlog requires too many assumptions. After the assessment, the incoming team can prepare a better-supported estimate and state which uncertainties remain.
Does the previous supplier need to cooperate?
Not always, although an organised handover can save time and recover valuable context. If the previous supplier is unavailable, the project can still be taken over through the code, infrastructure, documentation, data and knowledge held by users. The lack of a direct handover should be recorded as a risk within the assessment.
Does software built by another team need to be rewritten?
Not necessarily. The incoming team should first determine which areas work, which can evolve safely and where risk is concentrated. The right choice may be to continue, stabilise, modernise gradually, replace specific components or rebuild. Rewriting without an assessment can also lose business logic and create new risks.
What should be reviewed first if the system is already in production?
Access, infrastructure, backups, deployment, monitoring and any incidents that could affect operations or data. Architecture, quality, backlog and future development can then be examined in greater depth. The initial priority is to ensure the system can be maintained and recovered while the wider assessment continues.
