Taking over a web application: changing software supplier without starting again

Your application is live, and its users use it every day. The provider who developed it no longer responds, or no longer develops it at the pace of your business. Sometimes the project has fallen behind and the promised date has passed.

A new provider can build on the existing code. A live application contains business rules: calculations, special cases. Often, they exist nowhere but in the code. The new provider takes it over, understands it, then keeps developing it without breaking what works.

Web application takeover: what a new provider takes over

Taking over an application means carrying on developing it from the existing code, with another team. This applies to applications whose development stopped before they went live, and to those that are live but have become hard to change.

The new provider takes over three things: the source code, the access needed to deploy it, and what is known about the application. The third is often the most fragile. With a single developer, what they know about the software leaves with them if they have not documented it, hence the value of having this knowledge written down as the work progresses.

If an application meets your needs and is easy to change, there is no need for a takeover.

Software handover checklist: what to recover

Before telling your current provider, list what must come back to you. A takeover starts there: gathering what must be in your name, that is, the source code, the hosting, the domain name, and the accounts for the third-party services the application uses (online payment, email sending, mapping).

If these accounts are in the provider’s name, the provider holds the access. Ask for them to be transferred to your company’s name, and open any accounts that do not exist yet in your company’s name.

Ask for the documentation too, if there is any: how to install the application, how to deploy it, which tests check that it works.

Who owns the source code: what your contract says

Having a copy of the code is not enough to develop it further with another provider: you need the right to do so. Paying the invoices does not make you the owner of the code. It is the contract that assigns it to you, through a written assignment of rights that names each right assigned.

So reread your contract before announcing that you are leaving. If part of the code remains the provider’s property, check that the licence they grant you allows you to hand it to someone else. If in doubt, have the clause reviewed by a lawyer.

The reversibility clause in an IT contract

The reversibility clause sets out how you leave: data recovery, access to configurations, handover of documentation, the notice period. If your contract has one, now is the time to invoke it. If it does not, everything depends on what your provider agrees to hand over.

For the contract you sign with the next provider, plan for this departure from day one, and run a trial takeover once, before you need it.

Source code audit: read before changing

Once access has been secured, the application is deployed to an acceptance environment, a copy of the application where every change is checked before it goes live. The new provider administers it, and it mirrors production. There, they read the code, and check that they can build and deploy it without help from the previous team.

Michael Feathers is the author of Working Effectively with Legacy Code, published in 2004, the reference book for developers who take over existing code. In it, he defines legacy code, the code you receive from a previous team, simply as code without tests.

Without tests, nothing lets you check quickly that a change has not broken something elsewhere. Changes are then made in small steps, with caution. Development slows down.

Before any change, automated tests describe what the application does today, on the user journeys its users depend on. Only then is it changed. Every change goes through a deployment pipeline that reruns these tests before it reaches the acceptance environment.

Web application rebuild or takeover: keep what works

Faced with code that is hard to change, the temptation is to start again from scratch. Yet rewriting the application in one go means rediscovering each of its business rules, one by one. Meanwhile, the live application stops being developed. The new version brings its users nothing until it is finished.

The rebuild can be done differently: part by part. A part is replaced when it blocks the changes you need, not because it is old. The rest stays in use in the meantime. And each change goes into production separately, after its acceptance: a small change is less risky than a new version delivered all at once.

Migrating an application is part of this rebuild: moving its code to a more recent version of its framework, to another technology or to another language, without changing what it does for its users.

Web application takeover agency: how a takeover works

At DEVEDANOS, we start by securing access and deploying the application to an acceptance environment. We then write the tests for the user journeys its users depend on, before any change. If there is documentation, we read it.

We replace a part when it blocks the changes you need, and we keep what works. The decision is taken with you, after reading the code.

For a project running late, we go back over the list of planned features with you and rank them by their value to your application’s users. The ones that matter most are designed, developed and put into production first, one by one, each after its acceptance.

For a leisure-vehicle manufacturer, we worked on the development of its marketplace. The project had fallen behind with another provider. Together with the client and that provider, we refocused development on the essential features, the ones that brought the most value. The new deadline was met with a minimal application; the other features were then added continuously.

Legacy application support: after the takeover

Once the application has been taken over, it still has to be maintained. We offer ongoing application maintenance in the same model. Corrective maintenance (bug fixes), adaptive maintenance (dependency updates, security patches, browser compatibility), preventive maintenance (refactoring, performance optimisation) and enhancement maintenance (new features) are all included.

At DEVEDANOS, the same team develops, tests, deploys and maintains your software continuously, in the same pipeline.

DEVEDANOS: taking over your application for a fixed monthly budget

We take over applications in JavaScript and TypeScript first (React, React Native, Next.js, Node.js). For another technology (PHP, Java, Python…), the fundamentals of software engineering hold whatever the language: so just raise it on the first call.

At DEVEDANOS, we develop your custom software, usable within a month, for a fixed monthly budget, and we adjust it continuously as your business evolves. The budget is built with you, from your figures and your goals: together, we set the amount and the problem your application has to solve.

What has been accepted goes into production. Every day, you see the application progress on your acceptance environment.

And so that what worked before the takeover still works after it, we apply a zero-regression guarantee: every regression is fixed and covered by an automated test so that it does not come back, at no extra cost.

The source code, infrastructure, deployment pipeline and documentation are your intellectual property once the first monthly invoice is paid. A trial period of up to 15 working days in the first month: no invoice if you do not want the deliverables.

You can terminate the contract in writing at any time, without justification. During the reversibility month, we support your team until they can build, test and deploy without us.

Our page on application takeover and modernisation sets out what we do on an existing application.

Further reading

Choosing the provider who will take over your application? Our article on a technical partner for SMEs distinguishes the four forms of IT provider and the questions to ask them. And if your need changes along the way, who pays for that change depends on the contract: fixed price with a fixed scope, time and materials, or a fixed budget.

Your provider no longer responds, or your application has stalled? Shall we talk?

Sources

• M. Feathers, Working Effectively with Legacy Code, Prentice Hall, 2004 (legacy code defined as code without tests, in the preface).