Maintenance and modernisation of bespoke applications

When this service applies

The circumstances that lead companies to look for this service are recognisable and recur often:

The application was inherited from a supplier the company no longer works with, or from a developer who cannot be reached.
The original supplier ceased trading, changed direction, or stopped responding to incidents within reasonable timescales.
The system works correctly, but there is no documentation and no tests, and any modification is seen as a risk.
A specific change is needed, whether for a regulatory change, a new integration or a business requirement, and no team is available to take it on.

Types of maintenance

Corrective

Resolving incidents and correcting defects found in service, within the response times set out in the service level agreement.

Evolutionary

Adding new functionality and modifying existing functionality as business requirements change.

Adaptive

Adjustments arising from changes in the environment, such as language or framework versions falling out of support, server or database migrations, and regulatory changes including those affecting invoicing.

Perfective

Improvements to performance, maintainability and security of functionality that already exists, aimed at reducing accumulated technical debt.

How we work

Six steps, and at every one of them the decision to continue is yours.

First conversation

A first conversation with no commitment, in which all we need to know is what the application does, how long it has been running, what technology it is built on and what you need to resolve.
Confidentiality agreement

A confidentiality agreement is signed before anyone accesses anything, so that neither the code nor the data nor the business information leaves that framework.
Fixed-price audit

The audit is contracted at a fixed price and carried out in read-only mode, without modifying the system in service.
Scope report and quotation

The result is a report setting out the scope, the risks identified and a fixed price for the next phase. The report is yours and keeps its value whether or not you decide to continue.
You decide whether we continue

The audit ends in a decision of yours. You can stop here, contract the next phase, or take the report to another supplier.
Phased delivery

The modernisation is carried out in parts, with a scope and a price agreed before each one begins, and no part of the system is replaced until the new one has been shown to behave the same as the old. The previous system remains available throughout. On completion you receive the application together with the set of checks built during the project, which stays in your repository.

Project lead

The project has a named lead at all times, and no change reaches the system in service without having been reviewed. The procedure is the same on every project and does not depend on who is running it.

Why not simply rewrite it?

Rewrites fail for reasons that have little to do with programming ability. This is what we do differently.

Why not simply rewrite it?
	The usual rewrite	How we do it
Scope of change	The whole system is replaced at once.	In parts, with the system running from day one.
Reference point	A specification nobody ever wrote down.	What your system does today, checked before anything is touched.
Service interruption	A migration weekend, and the risk that it overruns.	None. The current system stays available throughout.
Who decides	The supplier decides when it is ready.	You decide, with the checks done and in front of you.
If something fails	The whole migration is rolled back.	That part is reversed. The rest is unaffected.

Recording behaviour before changing it

Before modifying an application that has neither documentation nor tests, we record how it actually behaves in service and turn that into automated checks. From then on every change is compared against that record, so that an unexpected difference is caught before it reaches production rather than afterwards, through an incident.

That set of checks is delivered to the client and stays in their repository. As well as reducing the risk of each change, it constitutes the functional documentation that many of these systems never had, and it allows any other supplier to continue the work.

Technologies

We work regularly with PHP, both bespoke and on Symfony and Laravel, with Ruby on Rails, with Node.js, with interfaces built in jQuery or AngularJS, and with MySQL and PostgreSQL databases. If the application is built on something else, we will still look at it before ruling out the engagement.

Contracting options

The service is contracted in three ways: a monthly fee, with an agreed number of hours and response times set out in the service level agreement; a block of hours, for occasional work with no commitment to continuity; and on demand, for specific pieces of work quoted separately. Standard cover is 8x5, during Spanish mainland business hours.

Frequently asked questions

Can you maintain software you did not build?

It is most of what we do. The first step in these cases is a review of the system, quoted separately, which establishes whether ongoing maintenance is viable and on what terms.

What do you need in order to start?

Access to the source code, to the environment the application runs in, and to someone at the company who understands how the business works. Existing technical documentation is not a requirement.

How quickly do you respond to an incident?

Response times are set in the service level agreement and vary by severity. Standard cover is 8x5, with incidents classified by priority and separate targets for response and for resolution.

Is there a minimum term?

The monthly fee is contracted with an initial term and a notice period agreed in writing. We do not apply termination penalties.

Shall we talk?

For a first assessment it is enough to know what the application does, how long it has been running, what it is built with, and what needs resolving.

Ask about my application Verifactu for bespoke software