VulCode

Taking over a software project from another vendor

We take over projects left half-finished or run by a team you no longer work with. We start with a code review and a quote for what is left, and finish with a working release and the documentation that was missing.

Service catalog
A pre-takeover review report for an ordering app in the client panel: the review findings and a decision for each module

When to take a project over

A project takeover means finishing an app or site another team started, without rewriting everything when there is no need to. For companies whose project stalled halfway, where giving up would cost more than finishing.

Today: the project the previous vendor left
What you usually see
  • The contractor vanished
    The code exists, but nobody is left to finish or deploy it.
  • The deadline passed
    The project was due long ago and still does not work.
  • No documentation
    Nobody knows how to run it on a new server.
  • An app nobody looks after
    It works, but nobody updates it and every change is a risk.
  • An in-house team out of time
    Your team is busy and a side project has waited for months.
The previous vendor's schedule
today
  • Test version
    works in part
  • Payment module
    no tests
  • Release
    nobody left to release it
  • Documentation
    nobody knows how to run the project
After the takeover
Where we start
  • The contractor vanished
    Recovering access and a run from scratch.
  • The deadline passed
    A list of what works and what does not.
  • No documentation
    A clean install and the steps written down.
  • An app nobody looks after
    A dependency review and backups.
  • An in-house team out of time
    Agreeing who decides and who accepts stages.
The takeover plan
today
  • Access to the code
    full access after rotated passwords
  • Review
    a report: what to keep, what to rewrite
  • Quote for the rest
    a plan with a quote
  • Finishing
    stages accepted on the test version
  • Release and documentation
    a working project with documentation

  • Diagnosis first

    The quote comes after a code review, not blind.

  • Secrets first

    We rotate passwords, keys and tokens the previous contractor may have known before we change anything.

  • A test version

    You can check each stage before it reaches production.

  • Documentation at the end

    Setup, architecture and deployment written down for the next person.

If you want only a diagnosis first, start with a code audit.

What we take over

A project is more than code: each layer has its own access and goes through the same three steps before we count it as taken over. The drawing shows an example halfway through.

Repository
The repository with history, branches and open changes, written agreements.
Taken over
Server and database
Servers and databases, backups, the deploy process.
In the documentation
Domain and mail
The registrar account, DNS, mailboxes and mail senders.
In your company's name
External services
Payments, API keys, analytics and store accounts.
no access: we rebuild it with you
no access: we rebuild it with you
When there is no access

You recover an account in your company's name from the registrar or provider as its owner, and we tell you what to ask for. A key that lived only on the previous vendor's private account is set up again on your company's account.

What each step means

Repository

  1. New passwords and keys: the previous vendor's account removed, deploy keys replaced.
  2. In your company's name: the repository, with its full history, on your company's account.
  3. In the documentation: setup and deployment described in the repository itself.

Server and database

  1. New passwords and keys: new server and database passwords, old SSH keys removed.
  2. In your company's name: the server on your company's account with the provider.
  3. In the documentation: the backups and the deploy process written down.

Domain and mail

  1. New passwords and keys: a new password for the registrar account.
  2. In your company's name: the domain registered to your company.
  3. In the documentation: a list of the DNS records, mailboxes and mail senders.

External services

  1. New passwords and keys: gateway keys and API tokens issued again, the old ones revoked.
  2. In your company's name: the payment gateway, analytics and store accounts in your company's name.
  3. In the documentation: a list of the services and where their keys live.

What the review report looks like

Before we promise anything, we check what is really in the repository. A sample, shortened review report for an ordering app.

A close-up of the review report in the client panel: the scope, five review findings and the table of decisions for the modules

  1. The state of the repository

    Whether the project builds and runs on a clean machine without the previous team's knowledge. Without it there is no point quoting further work.

  2. Risks, most urgent first

    A key in the repository history is revoked at once. Libraries with fixes to apply and modules without tests go into the work plan.

  3. A recommendation for each module

    Keep, fix, finish or rewrite, with the reason. We walk through the report on a call, and the decision is always yours.

Finish or rewrite

Finishing usually pays off. Not always. The choice is made module by module, not for the whole project.

Finish

  • What works stays as it is.
  • We fix what is broken or unfinished.
  • We finish in stages on a test version.

Rewrite part of it

  • We rewrite only the modules that need it.
  • The rest of the app, if it is sound, stays as it is.
  • The new module gets tests from the start.

The code builds, and the problems sit in individual modules

FinishRewrite part of it

Outweighs: Finish. We fix those modules and finish the rest in stages, without a rewrite.

A module patched many times breaks with every change

FinishRewrite part of it

Outweighs: Rewrite part of it. Patching would cost more than writing it again, with tests from the start.

The data and URLs work and have traffic

FinishRewrite part of it

Outweighs: Finish. That traffic is not worth losing in a move, so we build on what is there.

The library a module stands on is no longer maintained

FinishRewrite part of it

Outweighs: Rewrite part of it. It gets no more security fixes, so we rewrite that module and keep the rest.

When the whole system needs rewriting rather than one module, that is a migration to a new system.

How we take a project over

First we check what is in the code, only then do we quote the rest. An ordering app left by a freelancer who stopped replying.

  1. Access to the code

    We gather the repository, access to servers and services, and anything the previous team left behind, including written agreements.

    you get: full access after rotated passwords
  2. Review

    We run the project on a clean machine and assess the code, dependencies and security.

    Repository and server
    payment keys rotated the same day
    you get: a report: what to keep, what to rewrite
  3. Quote for the rest

    Based on the review you get the scope split into stages, a date for each stage and risks named plainly.

    Missing screens
    the second stage of work
    you get: a plan with a quote
  4. Finishing

    We work in stages on a test version, and every change gets reviewed. You see progress as we go.

    Payment module
    rewritten first, with tests
    a change of scope goes back to the quote: Quote for the rest
    you get: stages accepted on the test version
  5. Release and documentation

    We release the project and document setup, architecture and deployment.

    you get: a working project with documentation

Who does what in a takeover

Gathering access quickly saves the most time.

The list of access to take over in the client panel: the project's layers, passwords and keys and the state of each access

  1. You

    Backups: waiting on your choice

    You give access to the accounts held by your company and pass on the agreements with the previous vendor. You decide the scope and accept the stages.

  2. Us

    Payment gateway: new keys, the old one revoked

    We rotate passwords and keys, do the review and the plan, finish the project on a test version and write the documentation. Passwords and code fall under the confidentiality duty in our terms, clause 9.1.

  3. Previous vendor

    Maps key: on the vendor's private account

    They hold the repository and any access not yet handed over, and knowledge nobody wrote down. When something is missing, we rebuild it with you.

A change of scope mid-way needs both sides' written consent and may change the amount and the date (terms, clause 3.3).

Common questions about project takeovers

Answers about the cost, the state of the code, access and what happens after handover.

Is your project stuck with a previous vendor?

Tell us what exists, what is missing and what you have access to. We will reply within an hour with questions and a quote for the review.