Taking Over an Existing System from a Previous Vendor

Why a System Takeover Is Not Just a Project Continuation#

Organizations often inherit an information system built by someone else. The previous vendor may have stopped working with the client, shifted business direction, or simply become unavailable, while the system still has to keep running. Taking over such a system is a different task from building one from scratch, because you first need to understand the decisions already embedded in the code, the data structure and the infrastructure. Only once that understanding is in place can you plan further changes without risking breaking something that has worked until now.

When a takeover is attempted without a thorough review, the risks tend to surface later, once a fix is already costly and time-consuming. Undocumented decisions, hidden dependencies between modules and an unclear data ownership structure are common reasons an upgrade takes longer than expected. That is why we treat a takeover as a separate phase with its own goal: establishing the actual condition of the system before committing to deadlines or scope, and before making any concrete commitment to the client.

Epix can take over a project in full or as a defined project segment, depending on what the client actually needs. In some cases this means taking over the entire maintenance and further development effort; in others it is limited to a specific module or feature that needs to be extended or fixed. The same approach applies to systems the previous vendor left unfinished – before continuing the work, we first review what already exists, and only then propose the next steps and a realistic scope of work.

Assessing the Current State Before Takeover#

Before we take on responsibility for a system, we review it at four levels: source code, architecture, infrastructure and data. The purpose of this review is not to judge the previous vendor's work, but to establish the actual condition on which further work will be based. Without this review, any estimate of scope, timelines or risk would rest on assumptions rather than facts, increasing the likelihood of misunderstandings and unexpected complications during the takeover itself.

The result of the review forms the basis for deciding whether it makes sense to upgrade the existing system or rebuild certain parts from scratch. Some parts of the system may be solid enough to simply extend, while others may be written in a way that makes safe upgrading without a major intervention impossible. This distinction matters to the client because it directly affects which parts of the work require more time, attention and caution.

Reviewing infrastructure is especially important when the system supports services that must run without interruption, for example in the public sector or in systems used across multiple locations at once. We check how the infrastructure is set up, where potential bottlenecks lie, and whether separate environments exist for development, testing and production. Findings from this phase determine how carefully the transfer of control over the system to a new team needs to be planned.

• Source code: project structure, quality and readability, any technical debt
• Architecture: how individual parts of the system are composed and how they communicate
• Infrastructure: where and how the system runs, the state of production, testing and development environments
• Data: structure, volume and condition of the data that needs to be preserved or migrated

Handover: Documentation, Access and Ownership#

Source code and data belong to the client, not to the vendor that developed or managed them. This principle also applies to a takeover: regardless of who maintained the system before, you as the client have the right to inspect and transfer everything the system consists of. Handover is therefore not a mere formality, but a step that ensures further work can proceed independently of who maintained the system previously.

Documentation is also part of the handover: a description of how the system works, decisions made during development, and instructions for use or administration. Where documentation is missing or incomplete, it needs to be filled in before further work can safely proceed. The same applies to access credentials and passwords for systems, servers, administrative interfaces and third-party services – all of this must be part of the formal handover, not an informal arrangement between teams.

If the handover is incomplete, part of the system may end up inaccessible, or no one may know where or how something is configured. That means lost time and added risk, especially for systems that process sensitive data or support core business processes. That is why, before starting work, we always verify that all access, passwords and documents are actually available, and only then plan the next steps of the takeover.

Separate Development, Test and Production Environments#

After taking over a system, we set up or verify the separation between development, test and production environments. A change tested directly in production carries risk for the system's operation and for the data real users depend on. Separate environments allow a change to first be developed, then tested under conditions resembling production, and only released once it has been confirmed to work as intended without causing side effects.

We do not use real personal data in the test environment, since that would create unnecessary privacy and compliance risk. Instead, we use test data that matches the real data in structure without exposing actual information about users or customers. This matters especially for taken-over systems, where it may not be clear how data has been handled so far or who has had access to it in the past.

Every change goes through review and testing before it is released into the production environment. For taken-over systems this step matters even more, since changes touch code our team did not originally write, requiring extra care in assessing how a change affects the rest of the system. This reduces the risk that a fix in one place causes a new, possibly unrelated, error elsewhere in the system.

Testing and Quality Assurance#

Before we start changing a taken-over system, we need to know how it actually behaves. Testing is therefore not just the last step before releasing a change, but also part of the initial understanding of the system. Test scenarios let us verify the key paths through the system, identify where it behaves unexpectedly, and use that as the starting point for deciding what needs fixing, upgrading, or rebuilding entirely.

For taken-over systems it helps if testing is carried out by a team that was not involved in the original development, since they more easily notice deviations the original team might have overlooked. Where it makes sense, we bring in independent QA, separate from the development team, to review the work from a different angle. This matters especially for larger systems, where an error in one part can affect several connected processes at once.

The test results form the basis for the takeover decision: whether the system meets agreed criteria and is ready for further changes. Acceptance testing criteria are defined in advance together with the client, so it is clear what the system must satisfy before responsibility formally passes to the new team. This avoids ambiguity about when the takeover is actually complete and further work can proceed.

• test scenarios covering the system's key functionality
• manual testing of user paths and edge cases
• automated testing (Playwright, Cypress)
• API and regression testing
• testing within CI/CD
• acceptance testing against criteria agreed in advance

Project Management During a Takeover#

For larger takeovers we assign a project manager who serves as the client's single point of contact for the entire process. The project manager coordinates teams, tracks progress and ensures that decisions made during the system review are actually reflected in further work. This matters especially in takeovers, where several areas need to be coordinated at once – from technical review to handover of documentation and access obtained from the previous vendor.

Together with the client we define team responsibilities, deadlines for individual phases, and the way communication and progress reporting will work. A clear division of responsibility matters more in a takeover than in new development, because work has to be coordinated on a system our team does not yet know in full. Regular reporting lets the client know at all times which phase the takeover is in and what comes next.

We apply the same approach when taking over an unfinished system left halfway done by a previous vendor. Before continuing the work, we review what has already been built, what is missing, and where any incomplete or temporary solutions exist that need to be finished or removed. Only based on this review do we propose a realistic continuation plan, rather than continuing work without a clear picture of what we are actually building on.

After Go-Live: Operational Oversight and SLA#

A system takeover does not end with a successful handover. After go-live, we can take over operational oversight, bug fixing, technical and security updates, and further development. The scope of support is defined per project, since needs vary widely between systems – some require continuous monitoring, others only occasional updates and responses to reported issues. That is why, before support begins, we define together with the client exactly what is included and what falls outside its scope.

Within support, issues and requests are classified into four categories, which allows clear prioritization of each report and prevents minor issues from being treated the same way as a system outage.

Response times for each category are agreed in the support contract and are tailored to the system's criticality and the client's needs – we do not publish universal hourly response times, since these vary between projects. This classification lets the client know in advance how each type of issue will be handled and align that with their own expectations regarding system availability.

For taken-over systems, a clear issue classification is especially useful, since there is often no prior confidence in how stable a system maintained by someone else actually is. Through gradual issue classification and regular reporting, the client gets a transparent view of the system's real condition, rather than relying solely on an initial assessment made at the point of takeover.

• Class 1 – outage: the system or a key part is down; handled with the highest priority
• Class 2 – disruption: the system runs, an individual function does not; handled per agreed priority
• Class 3 – defect: a minor issue with no business impact; scheduled into the next release
• Class 4 – request: a change or upgrade; scope is assessed and a timeline agreed

Team and Competencies for a System Takeover#

Taking over a system often requires a broader range of expertise than building a single new module, since it requires understanding the existing architecture, infrastructure and data model while simultaneously planning further development. That is why we assemble project teams based on what a specific takeover actually requires – from technical code review to long-term maintenance and post-launch support.

We assemble the takeover team from within Epix and its specialist partner network, since the range of expertise needed to analyze and continue work on different systems exceeds what a single team can provide. This means that for a specific takeover we can bring together people with the right technical background, whether the project is a web application, a business information system, or a system supporting the public sector.

Within Epix and its specialist partner network there are also certified experts in cloud services, security and project management, and international quality and security standards are considered within the delivery structure. Certifications and standards are not attributed to Epix Group d.o.o. directly, but understood as part of the broader network from which we assemble a team based on the requirements of each specific takeover project.

• senior engineers
• solution architects
• technical leads
• full-stack developers
• DevOps and cloud engineers
• QA and test automation engineers
• project managers

How Scope and Price Are Determined#

The price of taking over a system cannot be set in advance without a review, since it depends on what the specific system actually needs. Instead of general price lists, we therefore propose a short analysis that breaks the work down into individual segments, so that each segment can be estimated and carried out separately. This lets the client see what an estimate is based on and adjust the scope of work as needed relative to available resources.

The scope of work in a takeover depends on several factors that we assess already during the analysis phase and that directly determine how much work lies ahead.

These factors do not carry equal weight in every takeover. For systems used in the public sector or handling sensitive data, security and compliance requirements often carry more weight than for smaller internal tools. That is why we tailor the review to each system individually, rather than applying the same procedure regardless of what the system actually does and who uses it.

The goal of the analysis is for the client to know, before deciding on a takeover, what to expect – not in terms of a final price, but in terms of which work segments are needed, which parts of the system carry risk, and where it makes sense to start. This avoids a situation where the scope of work shifts substantially during execution relative to what was agreed at the outset of the engagement.

• scope of functionality and number of user roles
• how many existing systems need to be connected and what their APIs look like
• whether it is a new system or a takeover and upgrade of an existing one
• the volume and condition of data that needs to be migrated
• security, audit trail and compliance requirements
• scope of testing and whether independent QA is needed
• the level of post-launch support and agreed response times